Draft Specification

Status:	Web 7.0 Foundation Draft
Version:	0.1.0-draft
Published:	26 March 2026
Latest Version:	https://github.com/trustoverip/dtgwg-cred-tf/discussions/8
Editors:	M. Herman (Web 7.0 Foundation)
Feedback:	ToIP DTGWG Credentials Task Force
Derived From:	GitHub Discussion #8, trustoverip/dtgwg-cred-tf

This document is derived from community discussion at trustoverip/dtgwg-cred-tf Discussion #8.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, Web 7.0 DILibOS™, TDW AgenticOS™, TDW™, Trusted Digital Web™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved.

Abstract

This specification defines Web 7.0 Verifiable Trust Circles (VTCs), a generalized mechanism for expressing verifiable multi-party membership, belonging, and trust relationships using the W3C Verifiable Credentials (VC) Data Model 2.0 and VC Data Integrity Proof Sets. VTCs extend the Partof Architecture Reference Model (PARM) — also referred to as the MemberOf or CitizenOf model — to provide a universal credential pattern that subsumes prior pairwise constructs (PHCs, VRCs) and additionally supports voting-based decision making, meeting requests, task forces, and digital societies.

STATUS

This document is derived from community discussion in the Trust over IP Foundation (ToIP) Digital Trust Graph Working Group (DTGWG) Credentials Task Force, GitHub Discussion #8, November–January 2025–2026.

Table of Contents

1. Introduction

2. Terminology and Definitions

3. Design Principles

4. The Partof Architecture Reference Model (PARM)

5. VTC Data Model

6. VTC Proof Set Lifecycle

7. Roles and Participants

8. Use Cases

9. Privacy and Security Considerations

10. Conformance

11. Relationship to Other Specifications

12. References

1. Introduction

The Web 7.0 paradigm seeks to establish a decentralized, agent-centric, privacy-preserving digital society. Central to this vision is the ability of digital entities — people, organizations, autonomous agents — to form verifiable groups: trust circles that are cryptographically provable, privacy-respecting, and composable.

Prior specifications in the Trust over IP (ToIP) ecosystem defined pairwise constructs (Personhood Credentials, PHCs; and Verifiable Relationship Credentials, VRCs) to link pairs of entities. While useful, these constructs are insufficient to describe multi-party group membership, community affiliation, or collective decision-making.

This specification introduces Verifiable Trust Circles (VTCs), which generalize pairwise credentials into an N-party construct using the standard W3C VC Proof Set mechanism. A single VTC credential can represent a self-credential (N=1), a bilateral relationship (N=2), or any multi-member group (N>2), enabling a single, coherent model for all membership-like relationships.

NOTE	Proof Sets are a normative feature of the W3C VC Data Integrity specification and are explicitly designed for scenarios in which the same data needs to be secured by multiple entities. VTCs leverage this mechanism rather than inventing new cryptographic primitives.

1.1 Motivation

The following observations motivate this specification:

• PHCs and VRCs both express a form of ‘belonging to’ — they are specializations of the same universal pattern.
• The W3C VC Data Model 2.0 already provides Proof Sets as a standard mechanism for multi-party signing.
• A single, generalized Web 7.0 Verifiable Trust Circles (VTCs) pattern — grounded in First Principles Thinking — can subsume both constructs and additionally support voting, community membership, digital governance, and inter-network trust.
• The SSC 7.0 Metamodel defines three controller layers (Beneficial, Intermediate, Technical) at which VTCs may apply, enabling rich composability.

1.2 Scope

This specification defines:

1. The VTC data model, including required and optional properties.
2. The roles of Initiator, Responder(s), and Notary within a VTC.
3. The lifecycle of a VTC Proof Set, from initial issuance through multi-party endorsement.
4. Use case profiles: self-credential, bilateral relationship, multi-party group, and voting scenario.
5. Privacy and security considerations specific to multi-party proof sets.

This specification does not define transport protocols, DID method requirements, or verifiable presentation formats, except where necessary to illustrate the VTC pattern.

2. Terminology and Definitions

The following terms are used throughout this specification. Unless stated otherwise, terms have the meanings assigned in the W3C Verifiable Credentials Data Model 2.0 [VC-DATA-MODEL].

Verifiable Trust Circle (VTC)	A Verifiable Credential whose credential subject identifies a multi-party trust relationship, and whose proof property contains a Proof Set with one proof contribution per participating member, plus the Notary’s initial proof.
Web 7.0 Verifiable Trust Circles (VTCs)	The generalised name for the VTC pattern when applied to the broader class of MemberOf, PartOf, and CitizenOf relationships. A VTC is a UMC.
Proof Set	As defined in W3C VC Data Integrity [VC-DATA-INTEGRITY], a set of proofs attached to a single secured document where the order of proofs does not matter. Each proof is contributed by a distinct signer.
Initiator (A)	The entity that proposes or originates a VTC. Identified by a DID. Corresponds to the ‘from’ role in VTC credential subject properties.
Responder (B, …, Z)	One or more entities that accept membership in a VTC by contributing their cryptographic proof to the Proof Set. Identified by DIDs. Corresponds to entries in the ‘to’ array.
Notary (N)	A trusted third party — trusted by both Initiator and all Responders — that issues the initial credential shell and contributes the first proof. The Notary is assigned to the VC ‘issuer’ role. In some use cases the Notary MAY be the Initiator or a Responder, provided they play both roles distinctly.
PARM	Partof Architecture Reference Model. The universal pattern underlying VTCs, encompassing MemberOf, CitizenOf, and PartOf relationships.
SSC 7.0 Metamodel	Self-Sovereign Control 7.0 Metamodel. Defines three controller layers — Beneficial Controller, Intermediate Controller (Agent), and Technical Controller (Agent) — at which VTCs may be anchored.
DTG	Digital Trust Graph. A graph of trust relationships between entities, each edge of which may be represented by a VTC.
PHC	Personhood Credential. A pairwise credential representing proof of personhood; a degenerate VTC where N=1.
VRC	Verifiable Relationship Credential. A pairwise credential representing a bilateral relationship; a degenerate VTC where N=2.
DID	Decentralized Identifier, as defined in [DID-CORE].

3. Design Principles

This specification adheres to the following design principles, consistent with the ToIP DTGWG Design Principles [DTGWG-DESIGN]:

3.1 As Simple As Possible But No Simpler

VTCs are grounded in existing W3C VC standards. No new cryptographic primitives or credential types are defined. The only structural addition is the deliberate use of the proof array (Proof Set) to carry per-member proofs alongside the Notary proof.

3.2 First Principles Thinking

PHCs and VRCs are recognized as specializations of a single underlying relationship pattern (PARM). Rather than defining multiple credential types for essentially the same concept, this specification derives one universal type that covers all cases by varying the cardinality of the ‘to’ array and the composition of the Proof Set.

3.3 Privacy by Design

VTC credential subjects SHOULD use confidentialSubject semantics wherever selective disclosure is required. Members of a VTC should be able to prove membership to a verifier without unnecessarily revealing the full membership list. Zero-Knowledge Proof (ZKP) integration in Proof Sets is explicitly supported and encouraged.

3.4 Composability

VTCs compose at each layer of the SSC 7.0 Metamodel. A VTC at the Beneficial Controller layer expresses human-level trust relationships; one at the Intermediate Agent layer expresses agent-level relationships; one at the Technical Controller layer expresses device/key-level relationships.

3.5 Cross-Network Trust

The PARM model is network-agnostic. The same VTC pattern supports trust relationships across and between independent, distinct networks and ecosystems.

4. The Partof Architecture Reference Model (PARM)

The Partof Architecture Reference Model (PARM) provides the conceptual foundation for VTCs. It observes that a large class of real-world relationships — membership, citizenship, parthood, employment, participation — share a common logical structure:

Relationship Type	Example
MemberOf	Alice is a member of the Working Group Trust Circle.
PartOf	Bob is part of the study group.
CitizenOf	Carol is a citizen of the Digital Nation State of Sovronia.
EmployeeOf	Dave is an employee of Acme Corp (DID-identified).
ParticipantOf	Eve is a participant of the 09:00 meeting (a VC-based meeting request).
VoterFor	Frank has cast a vote for Candidate 1 by contributing his proof to that VTC.

All of these reduce to the same credential structure: a VC whose credentialSubject.id identifies the group or decision entity (the ‘circle’), and whose proof array contains proofs from the Notary and each member who has accepted membership. PHCs and VRCs are degenerate cases of this pattern with N=1 and N=2 respectively.

5. VTC Data Model

5.1 Overview

A VTC is a valid W3C Verifiable Credential [VC-DATA-MODEL] with the following structural characteristics:

• The issuer property identifies the Notary (N).
• The credentialSubject (or confidentialSubject) object includes from, to, and optionally metadata properties that identify the Initiator, Responders, and relationship metadata respectively.
• The credentialSubject.id identifies the relationship or group itself, expressed as a DID.
• The proof property is an array (Proof Set), containing one proof per signer, ordered as: Notary first, then Initiator, then Responders.

5.2 Minimal Pairwise VTC (N=2, Alice and Bob)

The following non-normative example illustrates a bilateral VTC between Alice (Initiator) and Bob (Responder), notarised by a Notary entity:

{

“@context”: [

“https://www.w3.org/ns/credentials/v2”,

“https://w3id.org/vtc/v1”

],

“id”: “did:envelope:1234”,

“type”: [“VerifiableCredential”, “VerifiableTrustCircle”],

“issuer”: “did:example:notaryabcd”,

“validFrom”: “2026-01-01T00:00:00Z”,

“credentialSubject”: {

“id”: “did:vrc:2468”,

“from”: “did:example:alice”,

“to”: [“did:example:bob”],

“metadata”: { “label”: “Alice-Bob Bilateral Trust Circle” }

},

“proof”: [

{

“id”: “did:example:notaryabcd”,

“type”: “DataIntegrityProof”,

“…”: “Notary initial proof…”

},

{

“id”: “did:example:alice”,

“type”: “DataIntegrityProof”,

“…”: “Alice proof…”

},

{

“id”: “did:example:bob”,

“type”: “DataIntegrityProof”,

“…”: “Bob proof…”

}

]

}

5.3 Multi-Party VTC (N=3+, Alice through Zelda)

For groups with more than two members, the to array is extended to include all Responders, and the proof array gains one additional entry per additional Responder:

{

“id”: “did:envelope:5678”,

“type”: [“VerifiableCredential”, “VerifiableTrustCircle”],

“issuer”: “did:example:notaryabcd”,

“credentialSubject”: {

“id”: “did:vrc:9999”,

“from”: “did:example:alice”,

“to”: [

“did:example:bob”,

“did:example:carol”,

“…”,

“did:example:zelda”

],

“metadata”: {

“label”: “Working Group Trust Circle”,

“policy”: “did:policy:majority”

}

},

“proof”: [

{ “id”: “did:example:notaryabcd”, “…”: “Notary proof…” },

{ “id”: “did:example:alice”,     “…”: “Alice proof…”  },

{ “id”: “did:example:bob”,       “…”: “Bob proof…”    },

{ “id”: “did:example:carol”,     “…”: “Carol proof…”  },

{ “id”: “did:example:zelda”,     “…”: “Zelda proof…”  }

]

}

5.4 Self-Credential VTC (N=1, PHC equivalent)

When to contains only the Initiator’s own DID, or when from and credentialSubject.id are the same entity, the VTC degenerates to a Personhood Credential (PHC):

{

“credentialSubject”: {

“id”: “did:phc:alice-self”,

“from”: “did:example:alice”,

“to”: [“did:example:alice”],

“metadata”: { “label”: “Alice Self-Attestation” }

},

“proof”: [

{ “id”: “did:example:notaryabcd”, “…”: “Notary proof…” },

{ “id”: “did:example:alice”,      “…”: “Alice proof…”  }

]

}

5.5 Voting VTC

For a voting scenario, one VTC is created per candidate. Voters cast their vote by contributing their individual proof to the VTC of the candidate they support. The vote count is the number of valid member proofs in the Proof Set.

{

“credentialSubject”: {

“id”: “did:sovronia:election2026:district103:candidate1”,

“from”: “did:example:electionofficial”,

“to”: [],

“metadata”: { “label”: “Candidate 1 — District 103 — 2026” }

},

“proof”: [

{ “id”: “did:example:electionofficial”, “…”: “Official proof…” },

{ “id”: “did:example:voter001”,         “…”: “Vote proof…”    },

{ “id”: “did:example:voter002”,         “…”: “Vote proof…”    }

]

}

NOTE	The to array MAY be populated in advance with eligible voter DIDs, or it MAY be left empty and populated as votes are cast, depending on the election policy and privacy requirements.

5.6 Properties Reference

Property	Req.	Description
id	REQUIRED	DID identifying the VTC credential itself. SHOULD use did:envelope or equivalent.
type	REQUIRED	MUST include ‘VerifiableCredential’ and ‘VerifiableTrustCircle’.
issuer	REQUIRED	DID of the Notary (N). The Notary MUST be trusted by all members.
credentialSubject.id	REQUIRED	DID identifying the relationship or group itself. This is C in the PARM model.
credentialSubject.from	REQUIRED	DID of the Initiator (A).
credentialSubject.to	REQUIRED	Array of DIDs of Responders. MAY be empty for open voting VTCs. MAY include the Initiator’s DID.
credentialSubject.metadata	OPTIONAL	Arbitrary structured metadata about the relationship (label, policy, expiry, etc.).
proof	REQUIRED	Array of proof objects (Proof Set). First proof MUST be from the Notary. Subsequent proofs are from Initiator then Responders in any order.
proof[].id	REQUIRED	DID of the signer contributing this proof entry.

6. VTC Proof Set Lifecycle

The VTC Proof Set lifecycle consists of the following phases. At each phase t, the VTC applies to the Notary and the first t members who have contributed their proof.

Phase 0 — Null VTC

The credential shell is created by the Notary with an empty or pre-populated to array. The Notary contributes the initial proof. No member relationships are yet verified. t = 0.

Phase 1..t — Progressive Endorsement

Each Responder, in any order, reviews the credential and — if they consent to membership — adds their individual proof to the existing Proof Set using the ‘add-proof-set-chain’ algorithm defined in [VC-DATA-INTEGRITY]. The VTC becomes valid for those t members who have signed. Non-signing members are not yet bound.

Phase N — Complete VTC

All Responders listed in the to array have contributed their proofs. The VTC is fully executed and represents a complete, verifiable, multi-party trust relationship.

NOTE	Partial VTCs (0 < t < N) are valid credentials representing the subset of relationships established so far. Verifiers MUST check which proofs are present before asserting full circle membership.

6.1 Adding a Proof

To add a proof to an existing secured VTC, implementors MUST follow the algorithm specified in W3C VC Data Integrity [VC-DATA-INTEGRITY], Section ‘add-proof-set-chain’. The proof is appended to the existing proof array without modifying prior proofs.

6.2 Proof Ordering

Proof Sets are unordered by definition. However, this specification RECOMMENDS the following conventional ordering for readability and auditability: (1) Notary proof, (2) Initiator proof, (3) Responder proofs in the same order as the to array.

7. Roles and Participants

7.1 Notary (N) — Issuer

The Notary is the credential issuer. It MUST be trusted by both the Initiator and all Responders. The Notary is responsible for creating the credential shell, pre-populating the to array (or defining the voting policy), and contributing the first proof. In some use cases, the Notary MAY be the same entity as the Initiator or a Responder, provided that entity plays each role distinctly and the resulting credential satisfies all REQUIRED properties.

7.2 Initiator (A) — From

The Initiator proposes the trust circle. The Initiator’s DID appears in credentialSubject.from. The Initiator contributes a proof to the Proof Set to signify their acceptance of the relationship.

7.3 Responders (B … Z) — To

Each Responder is identified in the credentialSubject.to array. A Responder accepts membership by contributing their individual proof. A Responder who does not contribute a proof is proposed but not yet a verified member.

RULE	The cardinality t of verified members at any time equals the number of valid member proofs (excluding the Notary proof) present in the Proof Set.

8. Use Cases

8.1 Bilateral Trust Relationship (VRC Equivalent)

Alice and Bob wish to establish a verifiable bilateral trust relationship. A Notary (mutually trusted) issues a VTC with from = Alice and to = [Bob]. Both Alice and Bob contribute proofs. The result is a two-party VTC that is equivalent to a classic VRC.

8.2 Personhood Credential (PHC Equivalent)

Alice wishes to create a self-signed personhood credential. A Notary issues a VTC with from = Alice and to = [Alice]. Alice contributes her proof. The result is a one-party VTC equivalent to a PHC.

8.3 Working Group or Task Force

A task force of N participants is formed. A Notary (the WG chair or a community DID) issues a VTC with from = chair and to = [member1, …, memberN]. Members join by contributing their proofs. The VTC provides a cryptographically verifiable roster.

8.4 VC-Based Meeting Request

An organiser issues a VTC with credentialSubject.id = the meeting DID, from = organiser, and to = [attendee1, …, attendeeN]. Attendees RSVP by contributing their proofs. Attendance at the meeting is verifiable from the Proof Set.

8.5 Voting-Based Decision Making

One VTC per candidate is issued by an election official (Notary). Eligible voters cast their vote by contributing their individual proof to the VTC of their chosen candidate. Vote tallying is performed by counting the number of valid member proofs in each candidate’s VTC. This supports maximum flexibility in vote-counting policies (simple majority, ranked-choice, threshold).

8.6 Verifiable Decentralised Registry (VDR)

VC-based voting can be applied to implement a VC-based Verifiable Data Registry (VDR). Append operations to a distributed registry are authorised through a VTC whose members are the registry trustees.

8.7 Digital Society / Digital Nation State

A digital society (e.g. a digital religion, community, or nation state) is defined by a VTC whose members are the citizens. Governance operations — electing trustees, passing resolutions — are performed through subsidiary voting VTCs.

9. Privacy and Security Considerations

9.1 Selective Disclosure

Implementations are STRONGLY RECOMMENDED to use confidentialSubject semantics and selective disclosure proof mechanisms (e.g. BBS+ signatures) to allow individual members to prove their membership in a VTC without revealing the full membership list or metadata.

9.2 ZKP Integration

The Proof Set mechanism is compatible with zero-knowledge proof (ZKP) contributions. A member MAY contribute a ZKP as their proof entry, revealing only that they meet the membership criteria without revealing their DID. Implementations SHOULD define a profile for ZKP-based proof entries.

9.3 Privacy Budget and Reconstruction Ceiling

When multiple agents controlled by one First Person contribute to a shared VTC, care must be taken to ensure that the combined disclosure across proof entries does not exceed the privacy budget of the First Person. The reconstruction ceiling — the probability that an observer can reconstruct the First Person’s identity from the combined proof data — MUST be maintained below the threshold defined by the applicable trust framework.

NOTE	This consideration was raised during community discussion in the context of internal VTCs and the Trust Spanning Protocol (TSP) between two agents controlled by one First Person.

9.4 Notary Trust

The Notary (issuer) occupies a privileged position: it issues the credential shell and contributes the first proof. Verifiers MUST independently verify that the Notary is trusted by all relevant parties. The Notary SHOULD be a well-known, community-governed DID with transparent governance.

9.5 Voting Integrity

For voting VTCs, the following security properties MUST be considered: (1) eligibility — only eligible voters can contribute proofs; (2) anonymity — voter DIDs SHOULD be anonymised or pseudonymised; (3) non-repudiation — each proof is cryptographically bound to the voter’s key; (4) single-vote enforcement — the to array or the Notary’s policy SHOULD prevent duplicate proof contributions from the same voter DID.

10. Conformance

A conforming VTC implementation:

• MUST produce VTC credentials that are valid W3C Verifiable Credentials conforming to [VC-DATA-MODEL].
• MUST use a proof array (Proof Set) as defined in [VC-DATA-INTEGRITY].
• MUST include the issuer property identifying the Notary.
• MUST include credentialSubject.id, credentialSubject.from, and credentialSubject.to.
• MUST use the ‘add-proof-set-chain’ algorithm from [VC-DATA-INTEGRITY] when adding proofs incrementally.
• SHOULD include ‘VerifiableTrustCircle’ in the type array.
• SHOULD implement selective disclosure mechanisms for credentialSubject properties.
• MAY extend the credentialSubject.metadata property with domain-specific claims.

11. Relationship to Other Specifications

11.1 W3C VC Data Model 2.0

VTCs are valid W3C Verifiable Credentials. All normative requirements of [VC-DATA-MODEL] apply. VTCs use the issuer and credentialSubject properties as defined therein.

11.2 W3C VC Data Integrity

VTCs rely on the Proof Set mechanism defined in [VC-DATA-INTEGRITY], specifically the ‘add-proof-set-chain’ algorithm for incremental proof contributions.

11.3 ToIP DTGWG Design Principles

This specification is consistent with the ToIP DTGWG Design Principles [DTGWG-DESIGN] and the DTG-ZKP Requirements [DTGWG-ZKP].

11.4 SSC 7.0 Metamodel

VTCs integrate with the Self-Sovereign Control 7.0 Metamodel [SSC-7]. VTCs may be anchored at the Beneficial Controller, Intermediate Controller, or Technical Controller layer.

11.5 Trust Spanning Protocol (TSP)

VTCs are compatible with the Trust Spanning Protocol [TSP] as a credential format for expressing channel-level membership and authorization relationships.

12. References

12.1 Normative References

[VC-DATA-MODEL]	W3C. Verifiable Credentials Data Model v2.0. W3C Recommendation. https://www.w3.org/TR/vc-data-model-2.0/
[VC-DATA-INTEGRITY]	W3C. Verifiable Credential Data Integrity 1.0. W3C Recommendation. https://www.w3.org/TR/vc-data-integrity/
[DID-CORE]	W3C. Decentralized Identifiers (DIDs) v1.0. W3C Recommendation. https://www.w3.org/TR/did-core/

12.2 Informative References

[DTGWG-DESIGN]	Trust over IP. DTGWG Design Principles. GitHub Discussion #11. https://github.com/trustoverip/dtgwg-cred-tf/discussions/11
[DTGWG-ZKP]	Trust over IP. DTG-ZKP Requirements. GitHub Discussion #12. https://github.com/trustoverip/dtgwg-cred-tf/discussions/12
[DTGWG-VTC-13]	Trust over IP. VRC Design Proposals. GitHub Discussion #13. https://github.com/trustoverip/dtgwg-cred-tf/discussions/13
[DISCUSSION-8]	M. Herman et al. Web 7.0 Verifiable Trust Circles (VTCs). GitHub Discussion #8. https://github.com/trustoverip/dtgwg-cred-tf/discussions/8
[PHC-PAPER]	B. Crites et al. Personhood Credentials. arXiv preprint 2408.07892. https://arxiv.org/pdf/2408.07892
[SSC-7]	M. Herman. Self-Sovereign Control (SSC) 7.0 Metamodel. Hyperonomy. https://hyperonomy.com/2025/12/10/self-sovereign-control-ssc-7-0-metamodel/
[W7-AARM]	M. Herman. Web 7.0 Agentic OS Agent Architecture Reference Model. Hyperonomy. https://hyperonomy.com/2025/10/14/web-7-0-agentic-os-agent-architecture-reference-model-aarm/
[W7-TRUST-GRAPH]	M. Herman. Web 7.0 Trust Graph — Pure Peer Model. Hyperonomy. https://hyperonomy.com/2025/10/25/web-7-0-trust-graph-pure-peer-model/
[TSP]	Trust over IP. Trust Spanning Protocol. https://trustoverip.org/
[FIRST-PRINCIPLES]	M. Herman. First Principles Thinking. Hyperonomy. https://hyperonomy.com/2021/03/10/first-principles-thinking/

Acknowledgements

This specification was derived from community discussion contributions by: Michael Herman (mwherman2000), @talltree, @adamstallard, @mitchuski, @peacekeeper, @GraceRachmany, and other participants of the Trust over IP Foundation DTGWG Credentials Task Force. The editors gratefully acknowledge all contributors to GitHub Discussion #8.