Web 7.0 Foundation Governance Council M. Herman Internet-Draft Web 7.0 Foundation Intended status: Informational 26 March 2026 Expires: 27 September 2026 Verifiable Trust Circles (VTCs) using VC Proof Sets draft-herman-vtc-proof-sets-01 Abstract This document specifies 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 [W3C.VC-DATA-MODEL] and VC Data Integrity Proof Sets [W3C.VC-DATA-INTEGRITY]. VTCs extend the Partof Architecture Reference Model (PARM) to provide a universal credential pattern that subsumes prior pairwise constructs (Personhood Credentials (PHCs) and Verifiable Relationship Credentials (VRCs)) and additionally supports voting-based decision making, meeting requests, task forces, and digital societies. Derivation Notice This note is to be removed before publishing as an RFC. This Internet-Draft is derived from the Web 7.0 Foundation specification "SDO: Verifiable Trust Circles (VTCs) using VC Proof Sets (Web 7.0)" [WEB70-VTC] authored by Michael Herman, published 26 March 2026, and from community discussion at the Trust over IP Foundation Digital Trust Graph Working Group (DTGWG) Credentials Task Force, GitHub Discussion #8 [DISCUSSION-8]. Licensed under the Creative Commons Attribution-ShareAlike 4.0 International Public License. Web 7.0(TM), Web 7.0 DIDLibOS(TM), TDW AgenticOS(TM), TDW(TM), Trusted Digital Web(TM), and Hyperonomy(TM) are trademarks of the Web 7.0 Foundation. All Rights Reserved. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Herman Expires 27 September 2026 [Page 1] Internet-Draft Verifiable Trust Circles March 2026 Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 September 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 5 3. Terminology and Definitions . . . . . . . . . . . . . . . . . 5 4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 6 4.1. As Simple As Possible But No Simpler . . . . . . . . . . 6 4.2. First Principles Thinking . . . . . . . . . . . . . . . . 6 4.3. Privacy by Design . . . . . . . . . . . . . . . . . . . . 6 4.4. Composability . . . . . . . . . . . . . . . . . . . . . . 7 4.5. Cross-Network Trust . . . . . . . . . . . . . . . . . . . 7 5. The Partof Architecture Reference Model (PARM) . . . . . . . 7 6. VTC Data Model . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Minimal Pairwise VTC (N=2, Alice and Bob) . . . . . . . . 8 6.3. Multi-Party VTC (N=3+) . . . . . . . . . . . . . . . . . 9 6.4. Self-Credential VTC (N=1, PHC Equivalent) . . . . . . . . 10 6.5. Voting VTC . . . . . . . . . . . . . . . . . . . . . . . 11 6.6. Properties Reference . . . . . . . . . . . . . . . . . . 12 7. VTC Proof Set Lifecycle . . . . . . . . . . . . . . . . . . . 14 7.1. Phase 0 - Null VTC . . . . . . . . . . . . . . . . . . . 14 7.2. Phase 1..t - Progressive Endorsement . . . . . . . . . . 14 7.3. Phase N - Complete VTC . . . . . . . . . . . . . . . . . 14 7.4. Adding a Proof . . . . . . . . . . . . . . . . . . . . . 14 7.5. Proof Ordering . . . . . . . . . . . . . . . . . . . . . 14 8. Roles and Participants . . . . . . . . . . . . . . . . . . . 15 8.1. Notary (N) - Issuer . . . . . . . . . . . . . . . . . . . 15 8.2. Initiator (A) - From . . . . . . . . . . . . . . . . . . 15 Herman Expires 27 September 2026 [Page 2] Internet-Draft Verifiable Trust Circles March 2026 8.3. Responders (B ... Z) - To . . . . . . . . . . . . . . . . 15 9. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 15 9.1. Bilateral Trust Relationship (VRC Equivalent) . . . . . . 15 9.2. Personhood Credential (PHC Equivalent) . . . . . . . . . 15 9.3. Web 7.0 Foundation Governance Council . . . . . . . . . . 16 9.4. VC-Based Meeting Request . . . . . . . . . . . . . . . . 16 9.5. Voting-Based Decision Making . . . . . . . . . . . . . . 16 9.6. Verifiable Decentralized Registry . . . . . . . . . . . . 16 9.7. Digital Society / Digital Nation State . . . . . . . . . 16 10. Conformance . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Relationship to Other Specifications . . . . . . . . . . . . 17 11.1. W3C VC Data Model 2.0 . . . . . . . . . . . . . . . . . 17 11.2. W3C VC Data Integrity . . . . . . . . . . . . . . . . . 17 11.3. ToIP DTGWG Design Principles . . . . . . . . . . . . . . 17 11.4. SSC 7.0 Metamodel . . . . . . . . . . . . . . . . . . . 17 11.5. Trust Spanning Protocol (TSP) . . . . . . . . . . . . . 17 12. Privacy Considerations . . . . . . . . . . . . . . . . . . . 17 12.1. Selective Disclosure . . . . . . . . . . . . . . . . . . 18 12.2. ZKP Integration . . . . . . . . . . . . . . . . . . . . 18 12.3. Privacy Budget and Reconstruction Ceiling . . . . . . . 18 12.4. Notary Trust . . . . . . . . . . . . . . . . . . . . . . 18 13. Security Considerations . . . . . . . . . . . . . . . . . . . 18 13.1. Voting Integrity . . . . . . . . . . . . . . . . . . . . 18 13.2. Proof Integrity . . . . . . . . . . . . . . . . . . . . 19 13.3. Partial VTC Assertions . . . . . . . . . . . . . . . . . 19 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 15.1. Normative References . . . . . . . . . . . . . . . . . . 19 15.2. Informative References . . . . . . . . . . . . . . . . . 20 Appendix A. VTC Cardinality and Credential Type Mapping . . . . 21 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 21 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 21 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, and 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. Herman Expires 27 September 2026 [Page 3] Internet-Draft Verifiable Trust Circles March 2026 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 VTC 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. Herman Expires 27 September 2026 [Page 4] Internet-Draft Verifiable Trust Circles March 2026 This specification does not define transport protocols, DID method requirements, or verifiable presentation formats, except where necessary to illustrate the VTC pattern. 2. Conventions and Definitions The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, NOT RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals as shown here. Unless stated otherwise, terms have the meanings assigned in the W3C Verifiable Credentials Data Model 2.0 [W3C.VC-DATA-MODEL]. 3. Terminology and Definitions 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 generalized name for the VTC pattern when applied to the broader class of MemberOf, PartOf, and CitizenOf relationships. A VTC is a Universal Membership Credential (UMC). Proof Set: As defined in W3C VC Data Integrity [W3C.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 the 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. Herman Expires 27 September 2026 [Page 5] Internet-Draft Verifiable Trust Circles March 2026 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 [W3C.DID-CORE]. 4. Design Principles This specification adheres to the following design principles, consistent with the ToIP DTGWG Design Principles [DTGWG-DESIGN]: 4.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. 4.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. 4.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. Herman Expires 27 September 2026 [Page 6] Internet-Draft Verifiable Trust Circles March 2026 4.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. 4.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. 5. 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, and participation - share a common logical structure. Representative relationship types and examples are shown below: +===================+========================================+ | 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. | +-------------------+----------------------------------------+ Table 1 Herman Expires 27 September 2026 [Page 7] Internet-Draft Verifiable Trust Circles March 2026 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. 6. VTC Data Model 6.1. Overview A VTC is a valid W3C Verifiable Credential [W3C.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. 6.2. Minimal Pairwise VTC (N=2, Alice and Bob) The following non-normative example illustrates a bilateral VTC between Alice (Initiator) and Bob (Responder), notarized by a Notary entity: Herman Expires 27 September 2026 [Page 8] Internet-Draft Verifiable Trust Circles March 2026 { "@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", "...": "" }, { "id": "did:example:alice", "type": "DataIntegrityProof", "...": "" }, { "id": "did:example:bob", "type": "DataIntegrityProof", "...": "" } ] } 6.3. Multi-Party VTC (N=3+) 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: Herman Expires 27 September 2026 [Page 9] Internet-Draft Verifiable Trust Circles March 2026 { "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", "...": "" }, { "id": "did:example:alice", "...": "" }, { "id": "did:example:bob", "...": "" }, { "id": "did:example:carol", "...": "" }, { "id": "did:example:zelda", "...": "" } ] } 6.4. Self-Credential VTC (N=1, PHC Equivalent) When "to" contains only the Initiator's own DID, or when "from" and credentialSubject.id identify the same entity, the VTC degenerates to a Personhood Credential (PHC): Herman Expires 27 September 2026 [Page 10] Internet-Draft Verifiable Trust Circles March 2026 { "credentialSubject": { "id": "did:phc:alice-self", "from": "did:example:alice", "to": ["did:example:alice"], "metadata": { "label": "Alice Self-Attestation" } }, "proof": [ { "id": "did:example:notaryabcd", "...": "" }, { "id": "did:example:alice", "...": "" } ] } 6.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:cand1", "from": "did:example:electionofficial", "to": [], "metadata": { "label": "Candidate 1 - District 103 - 2026" } }, "proof": [ { "id": "did:example:electionofficial", "...": "" }, { "id": "did:example:voter001", "...": "" }, { "id": "did:example:voter002", "...": "" } ] } Herman Expires 27 September 2026 [Page 11] Internet-Draft Verifiable Trust Circles March 2026 | 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. 6.6. Properties Reference The following table defines the normative properties of a VTC credential: Herman Expires 27 September 2026 [Page 12] Internet-Draft Verifiable Trust Circles March 2026 +============================+==========+===========================+ | 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. | +----------------------------+----------+---------------------------+ | credentialSubject.from | REQUIRED | DID of the Initiator | | | | (A). | +----------------------------+----------+---------------------------+ | credentialSubject.to | REQUIRED | Array of Responder DIDs. | | | | MAY be empty for open | | | | voting VTCs. | +----------------------------+----------+---------------------------+ | credentialSubject.metadata | OPTIONAL | Arbitrary structured | | | | metadata (label, policy, | | | | expiry, etc.). | +----------------------------+----------+---------------------------+ | proof | REQUIRED | Array of proof objects | | | | (Proof Set). First | | | | proof MUST be from the | | | | Notary. Subsequent | | | | proofs are from the | | | | Initiator then | | | | Responders in any order. | +----------------------------+----------+---------------------------+ | proof[].id | REQUIRED | DID of the signer | | | | contributing this proof | | | | entry. | +----------------------------+----------+---------------------------+ Table 2 Herman Expires 27 September 2026 [Page 13] Internet-Draft Verifiable Trust Circles March 2026 7. 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. 7.1. 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. 7.2. 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 [W3C.VC-DATA-INTEGRITY]. The VTC becomes valid for those t members who have signed. Non-signing members are not yet bound. 7.3. 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. 7.4. Adding a Proof To add a proof to an existing secured VTC, implementors MUST follow the algorithm specified in W3C VC Data Integrity [W3C.VC-DATA-INTEGRITY], Section "add-proof-set-chain". The proof is appended to the existing proof array without modifying prior proofs. 7.5. Proof Ordering Proof Sets are unordered by definition. However, this specification RECOMMENDED to follow the conventional ordering for readability and auditability: (1) Notary proof, (2) Initiator proof, (3) Responder proofs in the same order as the "to" array. Herman Expires 27 September 2026 [Page 14] Internet-Draft Verifiable Trust Circles March 2026 8. Roles and Participants 8.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. 8.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. 8.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. 9. Use Cases 9.1. Bilateral Trust Relationship (VRC Equivalent) Alice and Bob wish to establish a verifiable bilateral trust relationship. A mutually trusted Notary issues a VTC with from = Alice and to = [Bob]. Both Alice and Bob contribute proofs. The result is a two-party VTC equivalent to a classic VRC. 9.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 [PHC-PAPER]. Herman Expires 27 September 2026 [Page 15] Internet-Draft Verifiable Trust Circles March 2026 9.3. Web 7.0 Foundation Governance Council A task force of N participants is formed. A Notary (the working group 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. 9.4. VC-Based Meeting Request An organizer issues a VTC with credentialSubject.id equal to the meeting DID, from = organizer, and to = [attendee1, ..., attendeeN]. Attendees RSVP by contributing their proofs. Attendance at the meeting is verifiable from the Proof Set. 9.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). 9.6. Verifiable Decentralized Registry VC-based voting can be applied to implement a Verifiable Data Registry (VDR). Append operations to a distributed registry are authorized through a VTC whose members are the registry trustees. 9.7. Digital Society / Digital Nation State A digital society (e.g., a digital 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. 10. Conformance A conforming VTC implementation: * MUST produce VTC credentials that are valid W3C Verifiable Credentials conforming to [W3C.VC-DATA-MODEL]. * MUST use a proof array (Proof Set) as defined in [W3C.VC-DATA-INTEGRITY]. * MUST include the issuer property identifying the Notary. Herman Expires 27 September 2026 [Page 16] Internet-Draft Verifiable Trust Circles March 2026 * MUST include credentialSubject.id, credentialSubject.from, and credentialSubject.to. * MUST use the "add-proof-set-chain" algorithm from [W3C.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 [W3C.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 [W3C.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], the DTG-ZKP Requirements [DTGWG-ZKP], and the VRC Design Proposals [DTGWG-VTC-13]. 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. Privacy Considerations Herman Expires 27 September 2026 [Page 17] Internet-Draft Verifiable Trust Circles March 2026 12.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. 12.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. 12.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. 12.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. 13. Security Considerations 13.1. Voting Integrity For voting VTCs, the following security properties MUST be considered: * *Eligibility:* Only eligible voters can contribute proofs. * *Anonymity:* Voter DIDs SHOULD be anonymized or pseudonymized. * *Non-repudiation:* Each proof is cryptographically bound to the voter's key. Herman Expires 27 September 2026 [Page 18] Internet-Draft Verifiable Trust Circles March 2026 * *Single-vote enforcement:* The "to" array or the Notary's policy SHOULD prevent duplicate proof contributions from the same voter DID. 13.2. Proof Integrity Verifiers MUST validate each proof entry in a Proof Set independently against the secured document using the algorithm specified in [W3C.VC-DATA-INTEGRITY]. The presence of a valid Notary proof does not substitute for validating member proofs, and vice versa. 13.3. Partial VTC Assertions Verifiers MUST NOT assert full circle membership based solely on the presence of the Notary proof or a subset of member proofs. Assertions about membership MUST be scoped to the verified set of proof contributors at the time of verification. 14. IANA Considerations This document has no IANA actions. The "VerifiableTrustCircle" credential type identifier is defined within the W3C VC ecosystem and SHOULD be registered in the W3C VC Extensions Registry upon advancement of this specification. 15. References 15.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [W3C.DID-CORE] Sporny, M., Guy, A., Sabadello, M., and D. Reed, "Decentralized Identifiers (DIDs) v1.0", W3C Recommendation, July 2022, . [W3C.VC-DATA-INTEGRITY] Sporny, M. and D. Longley, "Verifiable Credential Data Integrity 1.0", W3C Recommendation, 2024, . Herman Expires 27 September 2026 [Page 19] Internet-Draft Verifiable Trust Circles March 2026 [W3C.VC-DATA-MODEL] Sporny, M., Longley, D., and D. Chadwick, "Verifiable Credentials Data Model v2.0", W3C Recommendation, 2024, . 15.2. Informative References [DISCUSSION-8] Herman, M., "Web 7.0 Verifiable Trust Circles (VTCs)", GitHub Discussion #8, trustoverip/dtgwg-cred-tf, 2025, . [DTGWG-DESIGN] Trust over IP Foundation, "DTGWG Design Principles", GitHub Discussion #11, trustoverip/dtgwg-cred-tf, 2025, . [DTGWG-VTC-13] Trust over IP Foundation, "VRC Design Proposals", GitHub Discussion #13, trustoverip/dtgwg-cred-tf, 2025, . [DTGWG-ZKP] Trust over IP Foundation, "DTG-ZKP Requirements", GitHub Discussion #12, trustoverip/dtgwg-cred-tf, 2025, . [PHC-PAPER] Crites, B., "Personhood Credentials", arXiv preprint 2408.07892, 2024, . [SSC-7] Herman, M., "Self-Sovereign Control (SSC) 7.0 Metamodel", Hyperonomy, December 2025, . [TSP] Trust over IP Foundation, "Trust Spanning Protocol", 2025, . Herman Expires 27 September 2026 [Page 20] Internet-Draft Verifiable Trust Circles March 2026 [WEB70-VTC] Herman, M., "SDO: Verifiable Trust Circles (VTCs) using VC Proof Sets (Web 7.0)", Licensed under Creative Commons Attribution-ShareAlike 4.0 International Public License, March 2026, . Appendix A. VTC Cardinality and Credential Type Mapping The following table summarizes the mapping between VTC cardinality (size of the "to" array) and the equivalent prior credential construct: +=============+=================+==================+==============+ | N (members) | VTC Type | Prior Equivalent | Proof Count | +=============+=================+==================+==============+ | 0 | Null VTC | None | 1 (Notary | | | | | only) | +-------------+-----------------+------------------+--------------+ | 1 | Self-Credential | PHC | 2 (Notary + | | | | | A) | +-------------+-----------------+------------------+--------------+ | 2 | Bilateral | VRC | 3 (Notary + | | | | | A + B) | +-------------+-----------------+------------------+--------------+ | N > 2 | Multi-Party | None (new) | N+2 (Notary | | | | | + A + B...Z) | +-------------+-----------------+------------------+--------------+ | Open | Voting VTC | None (new) | 1 + votes | | | | | cast | +-------------+-----------------+------------------+--------------+ Table 3 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 [DISCUSSION-8]. Author's Address Herman Expires 27 September 2026 [Page 21] Internet-Draft Verifiable Trust Circles March 2026 Michael Herman Web 7.0 Foundation Bindloss Alberta Canada Email: mwherman@gmail.com URI: https://hyperonomy.com/about/ Herman Expires 27 September 2026 [Page 22]