Verifiable Trust Circles (VTCs) using VC Proof Sets

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.¶

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

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.¶

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.¶

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:¶

{
  "@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-proof>"
    },
    {
      "id": "did:example:alice",
      "type": "DataIntegrityProof",
      "...": "<alice-proof>"
    },
    {
      "id": "did:example:bob",
      "type": "DataIntegrityProof",
      "...": "<bob-proof>"
    }
  ]
}

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:¶

{
  "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>" }
  ]
}

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):¶

{
  "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>" }
  ]
}

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",
      "...": "<official-proof>" },
    { "id": "did:example:voter001",
      "...": "<vote-proof>" },
    { "id": "did:example:voter002",
      "...": "<vote-proof>" }
  ]
}

6.6. Properties Reference

The following table defines the normative properties of a VTC credential:¶

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.¶

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.¶

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.¶

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].¶

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.¶

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.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.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.¶
• 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.¶