§ Decentralized Trust Graph Credentials - Core Specification

Version: 1.0
Document Status: Working Draft 02
GitHub: https://github.com/trustoverip/dtgwg-cred-spec

Editors:

• Alberto Leon, Applied Technology Lab at Harvard University
• Brendan A. Miller, Applied Technology Lab at Harvard University
• Geoff Turk, First Person Project
• Martina Kolpondinos, First Person Project, Kosma Connect
• Drummond Reed, First Person Project

Contributors:

• Sankarshan Mukhopadhyay
• Glenn Gore
• The participants of the Decentralized Trust Graph Working Group (DTGWG)

Abstract

A Decentralized Trust Graph (DTG) is a graph of cryptographically verifiable trust relationships between entities (people, communities, devices, and software agents (including AI agents)). This specification defines eight DTG Core Credential types, expressed as W3C verifiable credentials. Six fall into two functional categories, and two sit outside them. Edge Credentials comprise the Verifiable Membership Credential (VMC), the Verifiable Relationship Credential (VRC) and the Verifiable Delegation Credential (VDC), which establish graph edges representing community membership, peer-to-peer relationships, and the appointment of one entity to act in another’s name. The Annotation Credentials comprise the Verifiable Persona Credential (VPC), Verifiable Endorsement Credential (VEC) and Verifiable Witness Credential (VWC), which associate personas for intentional correlation, verifiable assertions about counterparties, including endorsements, and witness attestations of relationship formation, with existing relationships. Standing outside both categories, because neither forms a graph edge nor annotates existing structure, the Verifiable Invitation Credential (VIC) authorizes onboarding of a prospective member, bootstrapping a node into a community, and the Verifiable Authority Credential (VAC) confers permission to act within a named scope and may be attenuated by its holder so that an agent or device carries strictly less authority than the party it acts for. The DTG credentials can be presented in privacy-preserving ways using zero-knowledge proof mechanisms. Such presentations can support holders to limit information they disclose and reduce correlation across contexts. The specification also defines a mechanism for associating credentials with the trust task context in which they were issued, allowing its meaning to be interpreted in the context of that exchange.

Intellectual Property Rights

This specification is provided under the Joint Development Foundation (JDF) charter for Trust Over IP (ToIP) and is subject to the intellectual property rights policy of the Decentralized Trust Graph Working Group (DTGWG):

Copyright: Creative Commons Attribution 4.0 International (CC BY 4.0)
Patent: W3C Mode (based on the W3C Patent Policy)
Source Code: Apache License, Version 2.0

THESE MATERIALS ARE PROVIDED “AS IS.” The parties expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user. IN NO EVENT WILL THE PARTIES BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THIS DELIVERABLE OR ITS GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER MEMBER HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

§ Introduction

This section is informative.

A decentralized trust graph (DTG) is a graph of trust relationships between people, organizations, devices, and AI agents in which every node and every edge can be cryptographically verified. This specification defines the DTG Core Credentials: eight VC types that are used to create, annotate, and govern access within that graph. These credentials are W3C-compliant verifiable credentials and may be presented using standard VC presentation methods when privacy preservation is not desired. They should, however, be presented using privacy-preserving zero-knowledge proofs (ZKPs) — of personhood, community membership, and facts about relationships — whenever privacy preservation is desired, since ZKPs are the only inherently privacy-preserving option for proof of personhood with DTG credentials (cf. Personhood Credentials, Adler et al. 2024). Used this way, ZKPs allow holders to prove what they need to prove from the perspective of the entities involved while maintaining minimal correlation across contexts.

Six of the eight credential types fall into two functional categories, and two sit outside them:

1. Edge credentials — establish relationships between existing entities (nodes) in the DTG:

   • VRC (verifiable relationship credential) — attests to a relationship between two entities; the relationship is verified through a bi-directional pair of VRCs
   • VMC (verifiable membership credential) — attests to the membership of an entity in a community; membership is verified through a bi-directional pair of VMCs
   • VDC (verifiable delegation credential) — attests that one entity has appointed another to act in its name, for a bounded set of acts; the delegation is verified through a grant and a matching acceptance

2. Annotation credentials — attach data to existing edges without creating new graph structure:

   • VPC (verifiable persona credential) — links a persona to a relationship
   • VEC (verifiable endorsement credential) — endorses skills or reputation
   • VWC (verifiable witness credential) — third-party attestation of an edge

Standing outside those categories, because neither forms a graph edge nor annotates existing structure:

• VIC (verifiable invitation credential) — authorizes onboarding of a prospective member, bootstrapping a node into a community rather than annotating one already in the graph
• VAC (verifiable authority credential) — states what its subject may do at a named scope, and may be attenuated by its holder to equip an agent or device with strictly less authority than they hold themselves

Important: These two categories are descriptive only and aid understanding. They do not appear in credential schemas. The formal type hierarchy has only one abstract parent: DTGCredential.

This Working Draft supersedes the v0.3 proposal draft published in the DTG Credentials Task Force repository.

Note on identifiers: The DTG model is designed to be compatible with verifiable identifiers (VIDs) in general, consistent with the ToIP Trust Spanning Protocol. This version of the specification uses decentralized identifiers (DIDs) exclusively. Future versions may generalize to other VID types (such as X.509 certificates or KERI AIDs) as ecosystem demand emerges.

§ Related Specifications

This specification is designed to work alongside the following planned companion specifications of the DTGWG. Neither has been published yet; this section will be updated with references as they become available.

• DTG Core Trust Task Protocols (planned) — will define the trust task protocols necessary to offer, issue, request, present, and revoke the DTG Core Credentials defined in this specification. It will also define the structure of the Trust Task completion artifact (outcome evidence) referenced by the taskContext binding mechanism in this specification.

• DTG Verifiable Data Structures (planned) — will define verifiable data structure (VDS) types that are exchanged over DTG relationships but are not DTG credentials, including:

  • r-card (relationship card) — a combination of human-readable and machine-readable data describing its publisher, exchanged in conjunction with VRCs; a modern, self-updating analog of a vCard.
  • Agent card — a VDS describing the identity and capabilities of an AI agent (its provider, capabilities, and skills), similar in spirit to an r-card but modeled on the Agent2Agent (A2A) protocol’s AgentCard discovery document.

§ Requirements Language

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in IETF RFC 2119.

§ Terminology

This section is informative.

This section defines the terms required for a reader to understand this specification. These terms and definitions are drawn from the DTG Glossary maintained by the DTGWG and are managed using the Spec-Up-T glossary features.

Any hyperlinked term not included in this section is referenced from one of the following glossaries:

• ToIP Main Glossary
• ToIP General IT Glossary

cloud VTAs (cloud VTA)

A VTA that operates on a network server, meaning a system that provides services to other computers over a network, such as cloud computing infrastructure. Unlike a local VTA, a cloud VTA should be highly available and accessible for routing private channel messages and other trust tasks. If a cloud VTA represents an individual, it operates as a server-based user agent (similar to webmail). If a cloud VTA represents a VTC, it will typically be controlled by the PNMs or VTA networks representing VTC members. Contrast with local VTA.

community trust anchor (CTAs, community trust anchors, CTA)

A person or a VTA invited by an initiator to serve as a trust anchor for a VTC. A CTA is issued a VMC on accepting the trust anchor role, and becomes a VTC member by issuing the reverse VMC that completes the membership edge.

community VTA networks (community VTA network)

A VTA network that controls the VTA representing a VTC as a DTG node. A community VTA network will typically consist of multiple VTC members, such as CTAs, each operating their own PNMs or personal VTA networks. Contrast with personal VTA network.

community VTAs (community VTA)

A VTA that represents the DTG node for a VTC. Contrast with personal VTA.

correlation scopes (correlation scope)

The breadth over which the holder of a DTG verifiable identifier intends that identifier to be correlated. Correlation scope is declared by the holder — it is not inferred from the identifier’s value, from where the identifier was encountered, or from the role its holder plays, though a role may rule out declarations it would make false. It is ordered from narrowest to widest and takes one of three values: pairwise (known to exactly one counterparty), directed (known to a set of counterparties the holder chooses) or public (correlation unbounded; ordinarily published so that it can be found). Correlation scope answers how widely may this identifier be correlated; the credential in which the identifier appears answers what role its holder plays. The two are independent, and conflating them is what the retired R-DID / M-DID / C-DID / P-DID identifier types did.

decentralized trust graph (DTGs, DTG)

A heterarchical graph of trust relationships defined by DTG edge credentials. Each trust relationship forms a DTG edge that connects two DTG nodes. The open standard specifications for the DTG are being developed by the DTGWG.

Decentralized Trust Graph Working Group (DTGWG)

A working group of the Trust Over IP (ToIP) project of Linux Foundation Decentralized Trust responsible for defining the specifications for all aspects of an open standard DTG. The DTGWG charter is published on the DTGWG home page.

DTG annotation credentials (DTG annotation credential)

A type of DTG credential that annotates an existing DTG edge with additional assertions about the trust relationship. The DTG Credentials Specification defines three subtypes of DTG annotation credentials: VPCs, VECs, and VWCs.

DTG authority credential (verifiable authority credential, DTG authority credentials, VACs, VAC)

A type of DTG credential that confers authority: it states what its subject may do at a named scope, as distinct from asserting something about the subject (an VEC) or establishing that the subject is connected to a node (a VMC or VRC). A VAC names a scope — a DTG node or a resource governed by one — and the actions the subject is permitted to take within it. A VAC may be attenuated: unless it forbids this, its holder may derive a further VAC conferring a subset of what they hold, bound to a narrower scope and a shorter validity period, without returning to the original issuer. A VAC is granted for a limited period and revocably: it is withdrawn by expiry or by revocation by its issuer, and revoking one withdraws every VAC attenuated from it. Authority is not delegation: a VAC says the subject may act, in their own name, within the scope granted; it does not authorize acting on behalf of the issuer.

DTG credentials (DTG credential)

A VC defined by the DTG Credentials Specification that is used to create or annotate a trust relationship in a DTG. There are three subtypes of DTG credentials: DTG edge credentials, DTG annotation credentials, and DTG invitation credentials.

DTG Credentials Specification

A technical specification from the DTGWG that defines the requirements for DTG credentials. This document is the current Working Draft of that specification; it supersedes the v0.3 proposal draft.

DTG edge credentials (DTG edge credential)

A type of DTG credential that identifies one direction of a bidirectional trust relationship in a DTG. DTG edge credentials are issued in pairs, one in each direction, to form a DTG edge connecting two DTG nodes. There are three subtypes of DTG edge credentials: VRCs, VMCs, and VDCs.

DTG edges (DTG edge)

In a DTG, a DTG edge represents a cryptographically verifiable trust relationship between two DTG nodes.

DTG invitation credential (verifiable invitation credential, DTG invitation credentials, VICs, VIC)

A type of DTG credential issued by an existing VTN, VTC, or VTC member to invite a new member. The purpose of DTG invitation credentials is to automate onboarding of a new member by a VTA. A proof of the DTG invitation credential is intended to at least partially satisfy the membership requirements (some VTCs may have additional membership requirements). There are two subtypes of DTG invitation credentials: VTC invitation credentials and VTN invitation credentials.

DTG nodes (DTG node)

In a DTG, a DTG node represents an entity that participates in trust relationships with other DTG nodes. DTG node types include persons, devices, AI agents, VTCs, VTNs, and services — a service being an operated endpoint that holds its own identifier and participates in trust relationships in its own right, such as a message mediator, a DID host, or a trust registry, as distinct from the VTSP that operates it. The list is illustrative rather than closed: what makes something a DTG node is that it holds a DTG verifiable identifier and forms DTG edges, not membership of an enumerated set. Being a node does not make something a possible target of every credential — a VMC in particular binds a member to a node that has members, which not every node kind does. A DTG node is always identified by at least one DTG verifiable identifier (VID) and can be interacted with via a VTA.

DTG verifiable identifiers (VID, VIDs, DTG verifiable identifier)

A verifiable identifier (VID) used to identify a DTG node. The DTG specifications use decentralized identifiers (DIDs) for verifiable identifiers. A VID is not typed by the role its holder plays — that is established by the credentials the identifier appears in. What a VID may carry is a declared correlation scope: how widely its holder intends it to be correlated. The R-DID / M-DID / C-DID / P-DID identifier types used in earlier drafts are retired.

identity verification credential (IDVCs, identity verification credentials, IDVC)

A VC issued by an IDVP in order to meet the identity proofing requirements established by a VTC for a prospective new VTC member. Although IDVCs may be commonly used by VTCs, they are not a standard DTG credential.

A VTC may authorize a prospective new member to obtain an IDVC by issuing a VTC invitation credential to the prospect’s proposed member identifier. The prospect may present a proof of the VTC invitation credential to the IDVP. If the IDVP successfully completes the identity proofing process, the IDVP will issue the IDVC to that same identifier.

identity verification provider (IDVPs, identity verification providers, IDVP)

A commercial provider of identity verification services. Examples of providers of identity verification services include Veriff, Jumio, Yoti, Onfido, ID.me, Socure, and Trulioo. If a VTC has a requirement for new members to obtain a qualified IDVC, the VTC governing body can determine the qualifications an IDVP must meet to be approved to issue an IDVC acceptable to the VTC.

initiators (initiator)

A person or persons who initiate the establishment of a new VTC. Depending on the policies governing the VTC, the initiator(s) will typically generate the identifier that identifies the VTC, instantiate the VTA representing the VTC, and invite the set of CTAs who may then begin inviting other VTC members.

local VTAs (local VTA)

A VTA that operates on a local device at the edge of the network, such as a smartphone, laptop, smart TV, or smart car. A local VTA is typically a user agent (similar to a browser or an email client) used by a single person. A local VTA used by a person is also called a PNM. Contrast with cloud VTA.

personal network manager (PNMs, personal network managers, PNM)

A user agent that serves as a VTA for an individual person to control and manage their trust relationships and trust tasks within one or more VTCs and VTNs. A PNM may be either a local VTA or a cloud VTA. If a person uses more than one PNM—for example a local VTA on multiple devices—these PNMs may work together with a cloud VTA as a personal VTA network. Also sometimes called a “VTA client.” VTA clients may also serve as “Community Network Managers” managing elements of a VTC.

personal network vault (PNV)

A digital vault (sometimes called a wallet) where a person stores their DTG credentials and associated signing keys for the DTG verifiable identifiers (DIDs) associated with those credentials. This vault is under the exclusive control of that person, although the person may sometimes choose to delegate use of their credentials or keys to a VTA, such as a PNM, for specific purposes.

personal trust networks (personal trust network)

The set of personal trust relationships represented by DTG edges that a person has with other DTG nodes, e.g., other persons, devices, AI agents, or VTCs. A person manages their personal trust network with their PNM.

personal VTA networks (personal VTA network)

A VTA network representing a person as a DTG node. For example, a personal VTA network might consist of a PNM on a smartphone, another PNM on a laptop, and a cloud VTA hosted by a VTSP. Contrast with community VTA network.

personal VTAs (personal VTA)

A VTA that represents the DTG node for an individual person. Contrast with community VTA.

personas (persona)

An identity controlled by the person it identifies (or their delegate) in order to manage correlation privacy. In a DTG, a persona has a unique verifiable identifier, ordinarily declared with a directed correlation scope, that may be shared using a VPC.

A persona is what a directed declaration is for: an identifier the holder deliberately uses across a set of counterparties they choose, so as to be recognized as the same party by that set and by no one else. Membership in a VTC does not require a persona — a member who declares pairwise toward the community has none — but a member who wishes to be recognized as the same person by other members, or across communities, is asserting a persona and declares the identifier directed accordingly.

personhood credential (PHCs, personhood credentials, PHC)

A digital credential used to provide proof of personhood, i.e., that the holder of the credential is a real unique person (unique at least in the scope of the PHC issuer). The general concept of a PHC was proposed in an August 2024 paper called Personhood Credentials.

In the context of a DTG, a personhood credential is implemented as the community-issued VMC of a membership edge in a VTC whose governance specifies that members must be real humans who have exactly one membership in that VTC. VTCs who implement such policies may themselves be members of a VTN that enforces network-wide policies for VMCs to qualify as PHCs.

policy enforcement point (PEPs, PEP)

The policy engine for a VTC that enforces the community’s policies for issuance and revocation of DTG credentials.

relationship card (r-cards, relationship cards, r-card)

A VDS containing a combination of human-readable and machine-readable data describing the publisher. R-cards are typically exchanged in conjunction with VRCs. As a VDS, an r-card may be encapsulated in a standard VC. One use of r-cards is to serve as a modern, self-updating version of a vCard. The open standard specification for r-cards will be a deliverable of the DTGWG.

relationship invitations (relationship invitation)

A process by which two or more entities exchange DTG verifiable identifiers (VIDs) in order to form a cryptographically verifiable connection, such as by scanning a QR code (in person or remotely) or clicking a deep link. Relationship invitations may be made by issuing a VTC invitation credential or a VTN invitation credential.

Also known as an out-of-band introduction (OOBI).

verifiable credential (VC)

A verifiable credential is a tamper-evident credential that has authorship that can be cryptographically verified.

See the credential specification for more details.

verifiable data structure (verifiable data structures, VDS)

A data structure digitally signed by the publisher so that subscribers are able to cryptographically verify the authenticity of both the original and any updates. A VC is one kind of VDS. An r-card is another type of VDS.

Note: One kind of VDS, such as a verifiable credential, can contain another type of VDS, such as an r-card.

verifiable delegation credential (VDCs, verifiable delegation credentials, VDC)

A DTG edge credential that attests that one entity (the delegator) has appointed another entity (the delegate) to act in the delegator’s name, for a bounded set of acts, for a limited period, revocably. Within that scope, what the delegate does is attributed to the delegator.

A VDC expresses delegation, not authority. Authority is a matter of what a party may do as itself; delegation is a matter of whether a party may act in another’s name. Neither implies the other: a service permitted to read a person’s mailbox has not thereby been appointed to send mail as that person. A VDC therefore never widens what may be done — a delegate cannot do in the delegator’s name what the delegator could not do itself. Authority is conferred by the VAC, which a VDC never stands in for and never supplies.

A VDC neither carries authority nor confers it. Nothing the delegator holds is copied to the delegate: a verifier substitutes the delegator for the delegate and then asks whether the delegator may perform the act. The reach of a delegation is therefore the intersection of what the delegator may do and what the VDC appoints the delegate for.

A VDC attests only to the existence and bounds of the appointment; the act of exercising it is an invocation carried out within a trust task, not a DTG credential.

For example, a person may issue a VDC to an AI agent appointing it to correspond in their name within a specific VTC, for a specific set of acts, for a specific period.

verifiable endorsement credential (VECs, verifiable endorsement credentials, VEC)

A DTG annotation credential that enables one party to a DTG edge trust relationship to issue verifiable assertions about the counterparty. The “verifiability” applies to cryptographic assurance in the issuer’s digital signature, not to the truth of the assertions (which must be evaluated independently). The assertion vocabulary for a VEC may be defined by a VTC or a VTN. VECs can be used in conjunction with other DTG credentials as a basis for a contextual reputation system.

verifiable membership credential (VMCs, verifiable membership credentials, VMC)

A DTG edge credential that defines membership in a VTC. VMCs are issued in pairs, one in each direction. In the community-issued VMC, the issuer is identified with the VTC’s own identifier and the member is the subject; the member chooses the identifier it is named by, and the correlation scope it declares for it. In the member-issued VMC, those roles are reversed: the member issues from the same identifier by which it was named as subject, and the VTC’s identifier is the subject. The member-issued VMC acknowledges a specific community-issued VMC and is the member’s consent to the membership. Whether a verifier treats a VMC as an edge of a particular graph is determined under the Edge Verifiability section of this specification.

For example, a VMC issued by a VTC whose governance specifies that the holder of the credential must be a real person who has exactly one membership in the scope of that VTC can serve as a PHC.

verifiable persona credential (VPCs, verifiable persona credentials, VPC)

A DTG annotation credential that enables one party to a DTG edge relationship to assert a persona to the counterparty. The issuer of the VPC is identified with an identifier ordinarily declared at a directed correlation scope. The counterparty (holder) can now prove that the counterparty knows the issuer in the context of that persona. Asserting a persona is how an individual controls intentional correlation deliberately, rather than acquiring it as a side effect of reusing an identifier.

verifiable relationship credential (VRCs, verifiable relationship credentials, VRC)

A DTG edge credential that represents one half of a bidirectional peer-to-peer trust relationship in a DTG. Each peer chooses the identifier it appears under and the correlation scope it declares for it; the two halves need not agree. Whether a verifier treats a VRC as an edge of a particular graph is determined under the Edge Verifiability section of this specification, which defines that property with respect to the anchor set a verifier accepts.

verifiable trust agent (VTAs, verifiable trust agents, VTA)

A digital agent that represents a DTG node. The network endpoint for a VTA is discoverable via the DTG verifiable identifier (VID) for the entity it represents. A VTA may represent a person, device, AI agent, or VTC. A VTA may be either a local VTA or a cloud VTA. Note: to control correlation privacy, individuals may have multiple VIDs and VTA network endpoints all controlled by the same underlying VTA or VTA network.

verifiable trust community (VTCs, verifiable trust communities, VTC)

A trust community identified with a verifiable identifier (VID) that serves as a DTG node. A VTC does not identify a person, agent, or device; rather it identifies a logical entity that has persons, devices, AI agents, and/or other VTCs as members. A VTC is represented digitally by a VTA—usually (but not always) a cloud VTA.

A VTC may be created for any size or purpose, from a family to a social group to an open source project to a company to a nation state. The verifiable identifier for a VTC can only truthfully be declared with a public correlation scope: a community that cannot be found cannot be joined. Membership in a VTC is defined by a pair of VMCs, one issued in each direction. A VTC member may be invited to join using a VTC invitation credential.

VTCs can be nested, in which case they form a hierarchy. However since a VTC can be a member of any number of other VTCs, VTCs can also be connected in a heterarchy.

verifiable trust network (VTNs, verifiable trust networks, VTN)

A trust network whose members are a set of VTCs. A VTN is defined by a governance framework that determines the set of VTN trust anchors. The VTC trust anchors for a VTN are typically discoverable and verifiable via a trust registry or a trust registry network.

A DTG may support any number of VTNs. VTNs may also be nested hierarchically or interconnected heterarchically.

A VTN may be designed to accomplish any set of trust objectives. For example, a VTN designed for governance of PHCs can meet the requirements described in the Personhood Credentials paper. The First Person Network is an example of this type of VTN.

verifiable trust service provider (VTSPs, verifiable trust service providers, VTSP)

A service provider that offers verifiable trust services on behalf of individuals, VTCs, or VTNs. A VTSP may provision local VTAs, host cloud VTAs, operate trust registries, and handle routing of private channel messages, queuing, and notifications.

verifiable witness credential (VWCs, verifiable witness credentials, VWC)

A DTG annotation credential that enables one party to a DTG edge trust relationship to issue a verifiable assertion about the authenticity of another DTG edge represented by a VRC. The issuer could be a person who personally witnesses the two parties exchanging VRCs, or it may be a VTA, such as the VTA for a VTC who applies the VTC’s policies for witnessing a relationship. For example: both parties provided: a) proof to the VTA that they were at the same event at the same time, and/or b) proof of biometric liveness at the time of relationship formation.

VTA network endpoints (VTA network endpoint)

A network address for communicating with a VTA. The VTA network endpoint can be discovered via the DTG verifiable identifier (VID) for the entity identified by the VID and represented by the VTA. Note: to control correlation privacy, individuals may have multiple VIDs and VTA network endpoints all controlled by the same underlying VTA or VTA network. This form of herd privacy can be offered by a VTSP.

VTA networks (VTA network)

A set of VTAs used by one or more controllers to control a DTG node. There are two basic types of VTA networks: personal VTA networks and community VTA networks.

VTC invitation credentials (VTC invitation credential)

A type of DTG invitation credential issued by a VTC or a VTC member to invite a new VTC member. A VTC invitation credential is issued to the identifier the prospective new member proposes to use in that community.

VTC members (VTC member)

A person or any other type of DTG node that has accepted a VMC from a VTC by issuing the reverse VMC that completes the membership edge. If the new member is another VTC, it is identified using that VTC’s own identifier; otherwise the new member is identified using an identifier of its choosing, at whatever correlation scope it declares for that membership. A common pattern (depending on VTC governance) is for existing VTC members to invite new members by issuing them a VTC invitation credential.

VTC trust anchors (VTC trust anchor)

A person or a VTA that serves as a trust anchor for a VTC. For VTCs that support community-based invitations, there are two subtypes of VTC trust anchors: initiators and CTAs.

VTN invitation credentials (VTN invitation credential)

A type of DTG invitation credential issued by a VTN or VTN member to invite a new VTN member. A VTN invitation credential is issued to the identifier of the prospective new member VTC.

VTN members (VTN member)

A VTC that has accepted a VMC in a VTN by issuing the reverse VMC that completes the membership edge. In the VMC issued by the VTN, the VTC member is identified using its own identifier as subject; the VTC issues its acknowledgement from that same identifier. A common pattern (depending on VTN governance) is for existing VTN members to invite new members by issuing them a VTN invitation credential.

VTN members are typically registered in one or more trust registries serving the VTN.

VTN trust anchors (VTN trust anchor)

A VTC that serves as a trust anchor for a VTN.

§ DTG Credential Taxonomy

This section is informative.

This section provides a visual overview of the DTG Core Credential types and their formal type hierarchy. The two functional categories (edge, annotation) are descriptive aids only; they do not appear in credential schemas. Two types belong to neither and are shown attached directly to DTGCredential: the VIC, which bootstraps a node into a community rather than annotating one already in the graph, and the VAC, which neither forms an edge nor annotates existing structure.

Formal W3C type hierarchy.

VerifiableCredential
└── DTGCredential
    ├── MembershipCredential (VMC)
    ├── RelationshipCredential (VRC)
    ├── DelegationCredential (VDC)
    ├── InvitationCredential (VIC)
    ├── PersonaCredential (VPC)
    ├── EndorsementCredential (VEC)
    ├── WitnessCredential (VWC)
    └── AuthorityCredential (VAC)

Note: The r-card (relationship card) that appeared in earlier drafts of this specification is a verifiable data structure (VDS), not a DTGCredential subtype. It will be defined in the planned DTG Verifiable Data Structures specification (see Related Specifications).

§ W3C Verifiable Credentials Version Support

This section is normative.

§ Primary Standard: v2.0

This specification is written using W3C Verifiable Credentials Data Model v2.0 syntax. All DTG implementations MUST support v2.0 credential verification and SHOULD support v2.0 credential issuance.

§ Legacy System Compatibility: v1.1

Many existing identity verification providers (IDVPs), trust registries, and community infrastructure may only support W3C VC Data Model v1.1. To ensure broad interoperability and avoid forcing costly system migrations:

• DTG implementations SHOULD accept and verify v1.1 credentials
• Existing credential issuers MAY issue DTG-compliant credentials using v1.1 syntax
• New implementations SHOULD prioritize v2.0 but MAY also issue v1.1 when required by ecosystem constraints

Design Intent: This dual-version support enables:

• Legacy IDVPs to issue IDVCs (identity verification credentials) without system upgrades
• Existing VTCs to participate in the DTG using their current infrastructure
• Gradual ecosystem migration from v1.1 to v2.0 without breaking trust relationships

§ Property Mapping

The only differences between v1.1 and v2.0 DTG credentials are:

All DTG-specific schemas (types, issuer requirements, credentialSubject structure) are identical.

Implementation Note: Verifiers supporting both v1.1 and v2.0 credentials MUST be able to process proof types commonly used in both versions. Issuers SHOULD use well-supported proof types and include all necessary contexts.

§ Dual-Version Examples

For readability, the examples throughout this specification reuse a single member identifier across a community’s credentials. Under a declaration that identifier is directed, not pairwise; see Correlation Scope.

v2.0 (Primary):

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://firstperson.network/credentials/dtg/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "type": ["VerifiableCredential", "DTGCredential", "MembershipCredential"],
  "issuer": "did:webvh:QmSbCcXWDDJmqE8m1nZ...:chess-club.example",
  "validFrom": "2026-01-06T10:00:00Z",
  "validUntil": "2027-01-06T10:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6MkpTHR8VNs..."
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-01-06T10:00:00Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:webvh:QmSbCcXWDDJmqE8m1nZ...:chess-club.example#key-1",
    "proofValue": "z3FXQjecWJKT..."
  }
}

v1.1 (Legacy Compatibility):

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://firstperson.network/credentials/dtg/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "type": ["VerifiableCredential", "DTGCredential", "MembershipCredential"],
  "issuer": "did:webvh:QmSbCcXWDDJmqE8m1nZ...:chess-club.example",
  "issuanceDate": "2026-01-06T10:00:00Z",
  "expirationDate": "2027-01-06T10:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6MkpTHR8VNs..."
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-01-06T10:00:00Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:webvh:QmSbCcXWDDJmqE8m1nZ...:chess-club.example#key-1",
    "proofValue": "z3FXQjecWJKT..."
  }
}

Note: All examples in this specification use v2.0 syntax unless explicitly labeled otherwise. When implementing v1.1 support, use the property mappings above.

§ Correlation Scope

This section is normative, except where a subsection is marked informative. Its requirements apply to a correlation scope that has been declared; this version does not yet define where a declaration is carried (see Declaring scope), so no credential is non-conforming for the absence of one.

A DTG verifiable identifier MAY carry a declared correlation scope: the breadth over which its holder intends it to be correlated. Scope is declared by the holder, and is independent of the role the holder plays — which is established by the credentials the identifier appears in. A role may nonetheless constrain which scopes a holder can truthfully declare, as it does for a VTC's own identifier and for a VWC witness’s; a role never supplies the scope, it only rules some declarations out.

A counterparty here is a party to a relationship the identifier establishes or annotates. Disclosure to a party in a supporting role for that same relationship — a VWC witness, an IDVP performing identity proofing for a membership, or the resolution infrastructure the identifier depends on — does not by itself widen scope, though it does place the identifier beyond the holder’s control; see Privacy Considerations.

The values are ordered, narrowest first. Where this specification states a minimum scope for a purpose, a declaration narrower than that minimum does not satisfy it, and a verifier MUST NOT treat it as if it did; elsewhere a holder MAY declare any of the three. A verifier MUST NOT rely on an identifier’s value, its DID method, or the context in which it was encountered as a substitute for a declaration.

There are three values rather than four because each must answer the same question — who may correlate this identifier? — and answer it by the holder’s own choice. pairwise confines correlation to one counterparty, directed confines it to a set the holder directs the identifier at, and public declines to confine it. There is deliberately no separate value for an identifier used within a community: an identifier a member uses only with the community is pairwise, and one the member also uses with other members is directed. A value bounded by the community would take its bound from a credential rather than from the holder — the conflation this section exists to remove — and would give a verifier two middle values it has no way to tell apart. What such a value appeared to capture is a property of the community rather than of the identifier; see Scope the holder cannot declare alone.

§ Roles are conferred by credentials

An identifier is not “a membership identifier”; it is an identifier that has a VMC. It is not “a persona identifier”; it is one that has a VPC. Membership is still established by the VMC pair and a persona is still asserted by a VPC; a scope declaration is orthogonal to both.

The R-DID (relationship), M-DID (membership), C-DID (community) and P-DID (persona) identifier types used in drafts before WD02 are retired. Each named a role and a correlation width in one token, and the two can disagree — an identifier holding a VMC and issuing a VRC answered to two of the four names at once.

§ Choosing a scope

This subsection is informative.

Because scope is the holder’s choice, it is a choice a person can be asked to make — at the moment of joining a community, and again for each relationship. Three values are few enough to put in front of a human being:

1. pairwise — a single-counterparty pseudonym. Known to this counterparty and to no other, and not necessarily short-lived: a pairwise identifier toward a VTC lasts as long as the membership. Where the counterparty is a VTC, that means known to the VTA and not to fellow members.
2. directed — a private persona. Known to this counterparty and to whoever else the holder chooses, which may include other members of the same community, or parties in other communities. This is the identifier under which a persona is ordinarily asserted.
3. public — a public persona. Known to anyone.

The three values also determine when proving intentional correlation costs anything. Where a holder deliberately uses one directed or public identifier across several credentials, the correlation is evident on the face of them and needs no proof. A zero-knowledge proof of common control is needed only in the opposite case: where the holder has used pairwise identifiers, which are distinct by definition, or distinct directed or public identifiers, and wishes to demonstrate that a single party controls them all.

§ Scope the holder cannot declare alone

A declared scope binds its holder’s own disclosure. It does not bind what a counterparty does with the identifier once disclosed, and for one counterparty — a community — that gap is wide enough to require governance.

A member may declare the identifier they use with a VTC pairwise, but that declaration stays truthful only if the VTC keeps it so. A VTC that publishes a member directory, or that presents a member-issued VMC to a third party as Privacy Considerations permits, has widened the identifier’s exposure without the member having chosen it.

A VTC that issues VMCs MUST therefore publish, in its governance framework or its trust registry, whether member identifiers are disclosed beyond the VTA and to whom. A verifier MUST NOT infer from a member’s pairwise declaration that the community treats the identifier as such, and a VTA SHOULD make the community’s answer available to a prospective member before that member chooses a scope for joining.

This is the general case of a fact that holds for any DTG edge whose two halves are held by different parties: a declaration constrains its own holder, and the disclosure an identifier actually experiences is the widest of the places either party puts it.

Consequence for relationships inside a community. Where a member uses one pairwise identifier with the VTC and a second pairwise identifier with another member, the two differ by construction, and a Community-Anchored Zero-Knowledge Proof must then establish common control across them rather than reading a single identifier out of both credentials. Members who expect to prove community-anchored relationships will in practice declare directed for intra-community use — the VTA together with the members they connect to — which is an accurate description of what that identifier is for.

§ Declaring scope

A declaration is only meaningful if a verifier can read it. Two placements were considered, and only one is available:

1. In the credential, by the party whose identifier it is. Each credential declares the scope of its issuer’s identifier — the one party in a position to speak for it. Bidirectional DTG edges make this complete on their own: in a VMC pair the community declares its own scope in the grant and the member declares theirs in the acknowledgement, so both halves of the edge carry a first-party declaration.
2. In the DID document, resolved with the identifier. This is not available where it is most needed. A did:key document, and a did:peer numalgo-0 document, are derived from the identifier value — there is no document to add a property to — and those are the methods DID Method Considerations recommends for pairwise and directed identifiers. Encoding scope into the identifier value itself would place the declaration where this section forbids a verifier from reading one, and resolving a document to learn the scope has the observability cost that Privacy Considerations records for the resolution layer.

The declaration is therefore carried in the credential. Two consequences follow:

• A declaration is a property of the identifier, not of a credential. All credentials issued under one identifier MUST declare the same scope; a contradiction between two of them falsifies the declaration, on the same footing as reuse of a pairwise identifier.
• A first-party declaration covers only an issuer’s own identifier. In a bidirectional DTG edge the reciprocal credential supplies the other half, but until that half exists — a membership grant not yet acknowledged — the subject’s scope is undeclared, and for VPCs, VWCs, VICs and VECs no credential declares the subject’s scope at all.

Editor’s note: The property that carries the declaration, and its @context term, are not yet named. Until they are, the requirements of this section bind a declaration that has been made and do not require one; the examples in this specification carry no declaration.

§ Base Structure

This section is normative.

All DTG credentials share this W3C VC structure (v2.0 shown; see Legacy System Compatibility for v1.1 compatibility):

Schema:

• @context (array, REQUIRED): MUST include "https://www.w3.org/ns/credentials/v2" and "https://firstperson.network/credentials/dtg/v1", plus any additional contexts required by the proof type
• type (array, REQUIRED): MUST include "VerifiableCredential", "DTGCredential", and exactly one concrete subtype
• issuer (string, REQUIRED): DID of the issuing entity. Its correlation scope is declared by the holder rather than encoded in the identifier — see Correlation Scope
• validFrom (string, REQUIRED): ISO 8601 datetime (issuanceDate in v1.1)
• validUntil (string, OPTIONAL): ISO 8601 datetime (expirationDate in v1.1)
• credentialSubject (object, REQUIRED):
  • id (string, REQUIRED): DID of the subject
  • Additional type-specific properties
• taskContext (string, OPTIONAL unless a credential type requires it): identifier (threadId) of the trust task exchange in which this credential was issued. See Trust Task Context Binding.
• proof (object, REQUIRED): W3C VC proof object

Example:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://firstperson.network/credentials/dtg/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "type": ["VerifiableCredential", "DTGCredential", "MembershipCredential"],
  "issuer": "did:example:vtcCommunityDid",
  "validFrom": "2026-01-06T10:00:00Z",
  "validUntil": "2027-01-06T10:00:00Z",
  "credentialSubject": {
    "id": "did:example:memberMdid"
  },
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2026-01-06T10:00:00Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "did:example:vtcCommunityDid#key-1",
    "proofValue": "z3FXQjecWJKT..."
  }
}

§ DID Method Considerations

This subsection is informative.

This specification does not mandate a decentralized identifier method. What a method must supply depends on what the identifier is required to do — chiefly how long it must remain verifiable and how widely its holder intends it to be correlated (its correlation scope) — and a deployment may use different methods for different purposes. What follows states those properties in terms of the identifier’s job, so implementers can judge whether a candidate method is suitable for any identifier in a deployment, including ones this specification does not otherwise name.

Durable identifiers. A VTC's identifier — declared public — issues VMCs and is expected to outlive any particular key, operator, or hosting arrangement, and a member’s identifier must stay verifiable across the lifetime of that membership. The determining property is how long the identifier must remain verifiable: a VTA issuing VWCs on behalf of a VTC, which VWC (Verifiable Witness Credential) permits in place of the member’s own identifier, must be verifiable for as long as the attestations it issued are relied upon, and so belongs here too. A method used for these purposes should provide:

• Verifiable key history, so that a verifier can establish which key was authoritative when a credential was signed rather than only which key is authoritative now. This matters because a DTG credential may be presented long after issuance, and Security Considerations requires verifiers to validate the verification method.
• Key rotation without changing the identifier, so that an edge of the graph survives key compromise. An identifier that cannot rotate makes every credential issued under it unrecoverable on compromise.
• Pre-rotation or an equivalent commitment to successor keys, limiting what an attacker holding a current key can do.
• Independence from a single operator or hosting location, so that loss of a domain does not sever the identifier from the graph built on it.
• Discoverable service endpoints, since the VTA endpoints, credentialStatus mechanism, and trust registry references relied on elsewhere in this specification are resolved through them.

Methods that publish a verifiable, append-only history of DID document versions — such as did:webvh, whose log entries commit to successor keys and may be countersigned by DID log witnesses — satisfy the first three properties. A DID log witness countersigns versions of a DID document and is a distinct role from the witness of a VWC, which attests to an edge; the two share only a name, and this subsection uses the qualified term wherever the DID log sense is meant.

Independence from a hosting location needs to be confirmed separately, because some methods make it a decision that can only be taken when the identifier is created. A did:webvh identifier resolves its log at a web origin and can be relocated only where the portable parameter was set in the first log entry; it defaults to off, and a later entry cannot enable it. Methods that separate the identifier from the location of its verification metadata — such as did:scid, under development at ToIP, whose identifier is a self-certifying value that carries no location — do not present this choice at all. Implementers selecting a method for an identifier expected to outlive its current hosting arrangement should confirm both that the method supports relocation and that any capability which must be enabled at inception has been.

Methods that resolve to a document with no verifiable history, such as did:web, satisfy rotation and endpoint discovery but provide neither verifiable history nor any commitment to successor keys. Such a document is rotated by republishing it, which leaves a verifier unable to distinguish a legitimate rotation from a key substituted by an attacker, and unable to establish which key was authoritative at issuance.

Narrow-scope identifiers (pairwise and directed). A pairwise identifier is known to one counterparty; a directed identifier — a persona, for instance — is known to a set the holder chooses. Both exist to limit correlation, and both are expected to be created in quantity. A method used for these should provide:

• Cheap creation with no registration step, since a deployment may mint one identifier per relationship or per persona.
• No shared resolution origin, so that resolving one identifier does not reveal the existence of, or a common controller for, the others. See Privacy Considerations.
• No dependency on infrastructure that observes identifier use, since a party that resolves, or acts as a DID log witness for, many of a person’s pairwise identifiers is positioned to correlate them regardless of the identifiers themselves.

Peer and key-based methods such as did:peer and did:key satisfy these properties. A method requiring each identifier to be published at a web origin is a poor fit for these roles even where it is the right choice for a public identifier, because the origin is common to every identifier published under it.

Durability and scope are chosen independently. The two groups above are not two ends of one dial, and an implementation that reads “narrow scope” as a synonym for “disposable” will get this wrong. An identifier a member uses only with their community is pairwise, and it must nevertheless remain verifiable for as long as the membership does — so it needs verifiable key history and rotation while still avoiding a shared resolution origin. Durability follows the lifetime of the credentials issued under an identifier; correlation scope follows the holder’s disclosure choice. A method has to be judged against both.

Mixing methods. Because the properties above pull in opposite directions — durability and recoverability against disposability and non-correlation — implementations should expect to use more than one method, rather than seeking a single method that serves every role. Nothing in this specification requires the issuer and credentialSubject.id of a credential to use the same method, and the examples throughout reflect this: durable issuers are shown with did:webvh and member and peer subjects with did:key or did:peer.

§ Digest Encoding

Four credential types reference another credential by cryptographic digest rather than by identifier: the member-issued VMC's digestMultibase (the grant it acknowledges), the VWC's digestMultibase (the edge credential it witnesses), the VDC's delegation.parent and delegation.accepts (the delegation it derives from, or the grant it accepts), and the VAC's authority.parent (the VAC it was attenuated from). All five members MUST be encoded identically, as specified here. The property name digestMultibase is the one VC Data Model 2.0 defines for a value of this form; parent and accepts carry the same encoding under names that state their role.

These references are digests rather than identifiers for two different reasons, and it is worth keeping them apart. Three of them — the acknowledgement’s digestMultibase, the acceptance’s accepts, and the witness’s digestMultibase — are statements about the exact content of the credential they name: the member consents to that grant, the delegate to that appointment, the witness attests to that edge, and a verifier re-derives nothing from the referenced credential but takes it as what was consented to or witnessed. An identifier would not do here, because the referenced credential could be re-issued with different claims under the same identifier and carry the consent or attestation with it. The two chain references — a VDC’s and a VAC’s parent — do not need the digest to keep a chain from widening: a verifier re-checks every link against the parent it is presented, so a substituted parent could never confer more than the chain’s root did. They take the same form so that every cross-credential reference in this specification is produced and matched in one way, so that a reference never names anything a verifier could be induced to fetch, and so that no credential has to carry a top-level id merely in order to be referenced. But the digest is doing more than uniformity here, and withdrawal is where it becomes load-bearing: it is what binds a child to the exact parent it was derived from, so that a child cannot be re-parented onto a later issue of that parent. This is what makes the cascade of Withdrawal hold without a register — an issuer that revoked a VAC and re-issued it under the same id would, under an identifier reference, silently revive every attenuation beneath it. The cost of the same property is that a re-issued parent does not carry its existing children with it; each must be re-derived, which for a chain of narrowing authority or representation is the intended behaviour.

A digest value MUST be produced as follows:

1. Take the referenced credential’s JSON representation excluding its top-level proof member, and canonicalize it with the JSON Canonicalization Scheme (JCS, RFC 8785). Excluding the proof means a digest binds to the credential’s claims rather than to one signature over them, so a re-proofed credential carrying identical claims still satisfies an existing reference.
2. Compute the SHA-256 hash of the resulting UTF-8 bytes.
3. Form a Multihash value by prefixing the digest with the sha2-256 algorithm header (0x12) and the digest length in bytes (0x20), each encoded as a varint, per CID v1.0 §2.5.
4. Encode the resulting 34 bytes with the base-58-btc alphabet and prefix the Multibase header z, per CID v1.0 §2.4.

This is the encoding defined for the digestMultibase property in VC Data Integrity §2.6. A digest of the empty string, for example, is expressed as:

zQmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n

Issuers MUST use base-58-btc so that a single canonical form exists for any given digest. Verifiers MUST NOT rely on string comparison to determine whether two digest values refer to the same credential: a conforming verifier decodes the Multibase value, decodes the Multihash to recover the algorithm identifier and the raw digest, and compares those. This requirement applies wherever the specification calls for digest values to match — notably when an acceptance VDC’s accepts is matched against a grant, when a derived VDC’s parent is matched against the credential it derives from (see Delegation Chains), and when an attenuated VAC’s parent is matched against the VAC it was attenuated from (see Attenuation).

Where a governing VTC or VTN requires a stronger hash, it MAY permit additional Multihash algorithm identifiers registered in CID v1.0 §2.5. Because the algorithm is carried in the value itself, such a change does not alter the format of the property. Verifiers MUST reject a digest whose Multihash identifies an algorithm they do not accept, rather than treating it as a mismatch.

Editor’s note: A digest over low-entropy content can be reversed by enumeration where the referenced credential is not disclosed, because an observer who knows the schema and the governing vocabulary can try the plausible values. None of the digest-valued members above is salted in this version. Blinding them is cross-cutting work with the ZKP task force and is tracked in #38; this section fixes the encoding so that a blinding scheme can later change what is hashed without a second encoding migration.

§ Edge Credentials

This section is normative.

Edge credentials establish relationships between existing entities (nodes) in the DTG: VRCs attest to relationships between two entities, VMCs attest to community membership, and VDCs attest that one entity has appointed another to act in its name. In each case, a bi-directional pair of credentials forms a complete DTG edge.

§ VRC (Verifiable Relationship Credential)

Purpose: Attests to a relationship between two entities; two VRCs (one each direction) form a complete DTG edge.

Schema:

• type (array, REQUIRED): MUST include "RelationshipCredential"
• issuer (string, REQUIRED): DID of the source party. This specification places no constraint on its correlation scope, which is the source party’s own declaration — see Correlation Scope
• credentialSubject (object, REQUIRED):
  • id (string, REQUIRED): DID of the target party as used in this relationship

Example:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://firstperson.network/credentials/dtg/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "type": ["VerifiableCredential", "DTGCredential", "RelationshipCredential"],
  "issuer": "did:peer:2.Ez6LSbysKZ...",
  "validFrom": "2026-01-06T10:00:00Z",
  "credentialSubject": {
    "id": "did:peer:2.Ez6LSpSrLxn..."
  },
  "proof": { "//": "..." }
}

Note: a pairwise correlation scope is RECOMMENDED for privacy. A wider declaration is permitted — directed, for a relationship the holder intends to be correlated with others they choose, including relationships inside a shared VTC — but it is a disclosure the holder makes deliberately (see Choosing a scope and Privacy Considerations).

§ Unilateral Relationship Identification

An identifier generated by a controller for the explicit purpose of establishing a VRC, and declared pairwise, serves as a globally unique identifier for that relationship edge from the perspective of the controller.

Therefore, a relationship within the DTG can be canonically identified by two independent identifiers:

• The source identifier (controlled by the Issuer)
• The target identifier (controlled by the Subject)

Semantic statements, metadata, or private context regarding the relationship MAY be anchored solely to the controller’s own identifier, without requiring the resolution or inclusion of the counterparty’s identifier.

An identifier declared pairwise MUST NOT be used with more than one counterparty. A verifier that observes a pairwise identifier with a second counterparty MUST treat the declaration as false and MUST NOT rely on it. Implementations SHOULD default to minting a distinct identifier for each new relationship.

§ Pairwise Zero-Knowledge Proof

The holder of a VRC MAY construct a zero-knowledge proof that demonstrates possession of a valid VRC and selectively discloses chosen attributes, subject DIDs, or predicates over them. A common application is to disclose the parties’ directed persona identifiers while hiding the underlying pairwise ones, enabling a public, verifiable claim that two known personas have a relationship without exposing the private pairwise channel between them or enabling correlation across the holder’s other presentations. This construction is available to any two parties who hold a VRC between them, regardless of whether they share membership in a VTC. It supports selective disclosure and minimal correlation across contexts. It does not by itself confer any community-level assurance (e.g., personhood); whatever assurance it carries derives from the parties’ own out-of-band context, the public reputation attached to any disclosed persona DIDs, and the cryptographic integrity of the VRC.

§ VMC (Verifiable Membership Credential)

Purpose: Attests to the membership of an entity in a VTC or VTN; two VMCs (one each direction) form a complete DTG edge.

Editor’s note — membership requires something that has members. This specification now records that the DTG node types are illustrative rather than closed, which invites the question of whether a VMC may bind to any of them. It may not, and the constraint is worth stating before the question is asked in a form that assumes otherwise: a VMC binds a member to a node that has members. A VTC has members. A VTN has members. A service has registered clients, and a device has authorized identities — both are collectives, whatever else they are.

A person is not a collective, and a VMC MUST NOT be read as attesting membership in one. That relationship already has two credentials that fit it: a VRC where the parties are peers, and a VDC where one acts in the other’s name. Reading membership onto a person would re-collapse a distinction the catalog spends effort keeping — the same collapse the Authority section describes between asserting something about a party and conferring something on them.

This note states a constraint, not a broadening: it does not extend what a VMC may bind to beyond the VTC and VTN the schema below names. It records the boundary that any future broadening should respect, so that the question the node-type change raises has a bounded answer rather than an open one.

Schema:

A VMC is issued in each direction of a membership edge. The two directions are distinguished by the issuer and subject rules below together with the presence of digestMultibase, not by separate type strings. Where both endpoints are communities, as in VTN membership, the issuer and subject rules do not distinguish the directions and digestMultibase is the discriminator: a VMC carrying it is a member-issued acknowledgement, and a VMC without it is a community-issued grant.

• type (array, REQUIRED): MUST include "MembershipCredential"
• issuer (string, REQUIRED):
  • For the community-issued VMC (the membership grant): DID of the VTC or VTN
  • For the member-issued VMC (the membership acknowledgement): DID of the member — the same identifier the grant names as its subject
• credentialSubject (object, REQUIRED):
  • id (string, REQUIRED):
    • For the community-issued VMC: DID of the member (a person, device, agent, service, or, for VTN-to-VTC membership, a member VTC)
    • For the member-issued VMC: DID of the VTC or VTN
  • digestMultibase (string, REQUIRED on the member-issued VMC, MUST be omitted on the community-issued VMC): A cryptographic hash of the community-issued VMC being acknowledged, computed over the credential excluding its top-level proof member and encoded as specified in Digest Encoding.

A community’s own identifier can only truthfully be declared public: a community that cannot be found cannot be joined. The member’s identifier carries whatever correlation scope the member declared for it, and this specification does not constrain that choice — see Choosing a scope and Scope the holder cannot declare alone.

Example (community-issued VMC — membership grant):

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://firstperson.network/credentials/dtg/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "type": ["VerifiableCredential", "DTGCredential", "MembershipCredential"],
  "issuer": "did:webvh:QmSbCcXWDDJmqE8m1nZ...:chess-club.example",
  "validFrom": "2026-01-06T10:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6MkpTHR8VNs..."
  },
  "proof": { "//": "..." }
}

Example (member-issued VMC — membership acknowledgement):

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://firstperson.network/credentials/dtg/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "type": ["VerifiableCredential", "DTGCredential", "MembershipCredential"],
  "issuer": "did:key:z6MkpTHR8VNs...",
  "validFrom": "2026-01-06T10:05:00Z",
  "credentialSubject": {
    "id": "did:webvh:QmSbCcXWDDJmqE8m1nZ...:chess-club.example",
    "digestMultibase": "zQmZ3zhk4n6yVDrJwbo4FX5ou27L2tgNnuFRxYrQrGQfUUN"
  },
  "proof": { "//": "..." }
}

§ Membership Edge Completion

A membership edge is complete only when both VMCs of the pair exist and are valid: the community-issued VMC that grants membership, and the member-issued VMC that acknowledges it.

The community-issued VMC MUST be issued first, and the member-issued VMC MUST carry a digestMultibase of it. A member-issued VMC whose digestMultibase does not match a valid community-issued VMC MUST NOT be treated as completing a membership edge.

Because the digestMultibase is computed over the credential’s claims and not over its proof, an acknowledgement survives a re-proofing of the community-issued VMC it references: a re-signed grant carrying identical claims satisfies an existing acknowledgement. The member’s consent binds to the membership granted, not to a particular signature over it.

Where the subject of a community-issued VMC demonstrates possession of that credential as evidence of its own membership, together with proof of control of the subject DID, a verifier MAY accept it alone. The demonstration is itself the member’s participation, and it is available only to a party holding the subject’s key — which is precisely what a community asserting someone’s membership does not have. This holds whether the demonstration is a direct presentation or a possession statement carried inside a zero-knowledge proof. These are the cases that the Community-Anchored Zero-Knowledge Proof and Personhood Credentials rely on.

Where a VTC, VTN, or any party other than the member asserts that an entity is a member, the verifier MUST require the member-issued VMC. A community-issued VMC alone MUST NOT be accepted as evidence that the named entity is a member. A community asserting an entity’s membership MUST be able to produce the member-issued VMC that completes the edge. The third statement of a Community-Anchored Zero-Knowledge Proof is a claim of this kind; that section states what a verifier may conclude from it.

The member-issued VMC is the member’s consent artifact, and this is why the pair is required rather than a single directed credential. A community can always issue a credential naming someone as a member, but it cannot produce the acknowledgement without that party’s signature. Requiring the acknowledgement therefore makes unconsented membership claims unprovable — and a community that cannot show one is visibly asserting a membership that was never agreed to.

Editor’s note — membership lifecycle: Withdrawal, revocation, and re-issuance of either VMC, and the protocol by which the pair is exchanged, are deferred to the planned DTG Core Trust Task Protocols specification (see Related Specifications). Because the member is the issuer of the member-issued VMC, withdrawal of consent is self-sovereign and requires no cooperation from the community. The open question left to that specification is where a verifier discovers the status of a member-issued VMC, which must be under the member’s control rather than the community’s trust registry, so that a member never depends on the community to invalidate their own credential. Until that mechanism exists, a verifier can confirm that an acknowledgement matches its grant but cannot learn that it has since been withdrawn. Two interim controls follow from digestMultibase binding the acknowledgement to the grant’s claims: a short validUntil on the community-issued VMC forces periodic re-acknowledgement, because a re-issued grant carries different claims and therefore a different digest that the earlier acknowledgement no longer matches; and a short validUntil on the member-issued VMC bounds how long the community holds a presentable proof of the member’s consent (see Privacy Considerations).

§ Community-Anchored Zero-Knowledge Proof

A VRC is a signed verifiable credential. It MAY be presented and verified using standard W3C VC presentation methods when privacy preservation is not required, and it SHOULD be presented using a zero-knowledge proof whenever privacy preservation is desired. Community membership is not a precondition for issuing, holding, or presenting a VRC; two entities that do not share (or do not hold) a VMC can still exchange VRCs, and the resulting edges are valid trust attestations standing on their cryptographic signatures and on whatever real-world context the parties bring to them.

When both parties to a VRC hold VMCs from the same community, the holder MAY construct a community-anchored ZKP of the relationship. In such a proof, the holder demonstrates:

1. Possession of the VRC
2. Possession of the underlying community-issued VMC (proving membership in the community)
3. The VRC issuer possesses a community-issued VMC from the same community identifier

Statement 2 is a demonstration by the holder of a credential whose subject is the holder, and is the case the presentation rule in Membership Edge Completion covers. Statement 3 is not: it rests on a community-issued VMC whose subject is the VRC issuer rather than the holder, and under that rule a community-issued VMC alone does not establish that its subject is a member. The evidence that would establish it is the VRC issuer’s own member-issued VMC — the acknowledgement of the grant that statement 3 refers to — which is signed by the issuer and names the community. Whether the holder obtains that acknowledgement in the course of exchanging VRCs, and how statement 3 is then proven in zero knowledge, are deferred to the trust task and ZK protocol work respectively (see the editor’s note above and Zero-Knowledge and Selective Disclosure). Until those are specified, a verifier of a community-anchored proof SHOULD treat statement 3 as establishing that the community attested the VRC issuer’s membership, and SHOULD NOT treat it as establishing that the issuer acknowledged that membership.

Statements 2 and 3 concern the identifiers named in the VMCs, which need not be the identifiers the same parties used in the VRC. Where a party declared one directed identifier and used it both with the community and with its counterparty, a single identifier appears in both credentials and the proof reads it directly. Where a party used a pairwise identifier with each, the two identifiers differ by construction and the proof must additionally establish common control of them. This is the member’s choice to make rather than the specification’s; see Scope the holder cannot declare alone.

This allows the relationship’s existence to be proven within a shared community’s governance context without revealing the specific DIDs or other credential details. Whatever assurances the community’s trust registry attaches to its VMCs (e.g., personhood, when the VMCs qualify as PHCs) carry forward into the proof.

This is one proof construction available to relationships within a shared community. Detailed ZK protocols and registry-ZK interactions are out of scope for this specification (see Zero-Knowledge and Selective Disclosure).

Note: Implementations SHOULD make ZKP presentation the default behavior so that users obtain privacy preservation without having to opt in. See Privacy Considerations.

§ VDC (Verifiable Delegation Credential)

Purpose: Attests that one entity (the delegator) has appointed another entity (the delegate) to act in the delegator’s name, for a bounded set of acts, for a limited period, revocably. Within the appointed scope, what the delegate does is attributable to the delegator. Two VDCs — a grant and a matching acceptance — form a complete DTG edge.

A VDC differs from every other credential in this specification in kind, not only in payload. The VRC, VMC, VIC, VPC, VEC, and VWC all attest that something is true about the graph; a verifier evaluates each as a claim and asks whether it is true. A VDC establishes representation; a verifier asks a different question — whether this party may stand in for that one, for this act, at this moment — and answering it requires steps that evaluating a claim does not: scope containment, chain resolution, invocation binding, and timely revocation. That is why delegation is defined as its own concrete subtype rather than expressed through the payload of an existing type.

§ Grant and Invocation

This subsection is informative.

Delegation divides cleanly along the test in Credentials versus Trust Task Artifacts:

• The grant — “this delegator has appointed this delegate to act in its name, for this scope, until this time” — is true standing alone and outlives the exchange in which it was issued. It is a credential, defined here.
• The invocation — “the delegate is acting in the delegator’s name, now, to do this particular thing” — is meaningful only inside the exchange in which it occurs. It is a trust task artifact, correlated by threadId and defined in the planned DTG Core Trust Task Protocols specification.

This specification therefore defines what a delegation is and how a verifier establishes that it is valid and in force. It does not define how a delegation is exercised.

§ Delegation and Authority

This subsection is informative.

Delegation and authority are distinct, and a VDC expresses only delegation. Keeping the two apart is what tells an implementer which credential to reach for.

• Authority answers may this party do this thing? The party acts as itself. What it does is attributed to it, and it may do it because it has been permitted to.
• Delegation answers may this party act in another’s name? The delegate acts as the delegator. What it does within scope is attributed to the delegator, and is bounded by what the delegator could have done itself.

Neither implies the other. A service granted access to a person’s mailbox may read that mail as itself; it has not thereby been appointed to send mail in that person’s name. Conversely, a delegate appointed to correspond in a person’s name holds that appointment whether or not it has been given access to any particular mailbox — and where it has not, the appointment gets it nowhere. The first is authority without delegation; the second is delegation without authority. A credential that conflated them would leave a verifier unable to tell which of the two it had been shown.

A VDC establishes delegation and nothing else. Guardianship, succession, estate administration, custodianship, and other representative authority that arises from an external mandate are conferred by whatever governed process confers them, and are not expressed by a VDC. A representative so appointed may in turn delegate, by issuing a VDC bounded by the authority it actually holds; the originating authority stays separate.

When to use a VDC. Ask whose name the act is performed in.

• The actor’s own name — the actor is doing something it has been permitted to do, and the act is attributed to it. This is a question of authority, and a VDC is the wrong credential; the VAC is the right one (see VAC (Verifiable Authority Credential)).
• Another entity’s name — the actor is standing in for that entity, and the act is attributed to that entity. This is delegation, and a VDC is the credential that establishes it.

An AI agent acting for a person can be equipped either way, and the same test decides which; see Relationship to the VDC.

§ How a Delegation Composes with Authority

This subsection is informative.

A VDC neither carries authority nor confers it on the delegate. When a delegate presents a VDC and asks to perform an act, the verifier does not ask what the delegate is permitted to do, and it does not treat the VDC as a permission the delegator has handed over. It substitutes the delegator for the delegate and then asks the question it would have asked of the delegator directly. A VDC moves the question; it does not answer it.

Three checks, each independent of the others:

1. Is this the delegate, and may it act in the delegator’s name for this act? Established by the VDC, together with Delegation Chains and Invocation Binding. This specification defines this check.
2. May the delegator perform this act? Established by whatever the act requires of the delegator — community membership, a governance framework, an IDVC, a VAC, or the verifier’s own policy. This specification does not define this check, and a VDC does not influence its outcome.
3. Must the delegate independently qualify? A governance determination. Some communities will require a delegate to hold a VMC of its own, or to satisfy the same requirements as any other actor, before it may act for anyone; others will not.

The reach of a delegation is the intersection of what the delegator may do and what the VDC chain appoints the delegate for — never the union, and never more than either.

Three consequences follow, and they answer the question of what, exactly, has been handed over:

• Nothing the delegator holds is copied to the delegate. A credential issued to the delegator remains the delegator’s. The issuer’s assurance about the delegator does not extend to the delegate, and a delegator cannot re-issue to a delegate what it was itself issued. A delegation is a statement by the delegator about who may speak in its name; it is not a transfer of anything the delegator was given.
• Withdrawing the delegator’s own permission ends the delegate’s ability to act immediately, without revoking the VDC, because check 2 is evaluated at the time of the act rather than at the time of the appointment. Revoking the VDC and withdrawing the underlying permission are different remedies with different reach, and a delegator may need either.
• A scope may exceed what the delegator itself may do. This is not an error: a delegator’s own permissions change over the life of a durable appointment. A verifier MUST NOT treat such a scope as conferring anything beyond what check 2 allows, and issuers SHOULD NOT issue one as a matter of hygiene.

Credentials expressing authority are defined separately: the VAC is one of the things that can satisfy check 2, and a VDC never stands in for it. Confining the VDC to delegation is what lets the two coexist without either reinterpreting the other or contending with it for the same semantic ground; see Relationship to the VDC.

Schema:

• type (array, REQUIRED): MUST include "DelegationCredential"
• issuer (string, REQUIRED): DID of the delegator — a person, device, or agent; a VTC where a community delegates to a VTA or other service; or an identifier under which a persona is asserted, where the delegation is made under that persona. The delegator chooses the identifier and the correlation scope it declares for it; see Privacy Considerations item 10
• validUntil (string, REQUIRED): ISO 8601 datetime (expirationDate in v1.1). Unlike the base structure, validUntil is REQUIRED for a VDC: an appointment with no expiry cannot be reasoned about by a verifier that cannot reach the delegator.
• credentialStatus (object, CONDITIONAL): a W3C VC status mechanism through which a verifier can determine whether the delegation has been revoked. A verifier MUST be able to establish that an appointment is currently in force without contacting the delegator. Two things satisfy that: a validUntil short enough that expiry alone bounds the exposure, with the delegator withdrawing the appointment by declining to re-issue; or a credentialStatus the verifier can check. A VDC MUST carry credentialStatus where its validity period exceeds the freshness window the governing VTC or VTN defines for delegations, and MAY omit it otherwise. Issuers SHOULD prefer short validity and re-issuance wherever the delegator is reachable, because a status check is a live lookup that reveals the verification event to whoever hosts the status list (see Privacy Considerations item 12); a long-lived appointment made in advance of a delegator’s unavailability is the case credentialStatus exists for. The status mechanism used is determined by the governing VTC or VTN.
• credentialSubject (object, REQUIRED):
  • id (string, REQUIRED): DID of the delegate
  • delegation (object, REQUIRED):
    • scope (array of strings, REQUIRED on a grant, MUST be omitted on an acceptance): the acts the delegate may perform in the delegator’s name. MUST contain at least one entry; the vocabulary is defined by the governing VTC or VTN, as for the endorsement structure of a VEC. A VDC MUST NOT express an unbounded appointment by omitting or emptying scope. Scope entries are opaque strings compared for exact equality: this specification defines no wildcard, prefix, or hierarchical semantics, so that the subset test in Delegation Chains is set inclusion over exact matches and a governing vocabulary that wants structure must define it in the terms themselves.
    • parent (string, OPTIONAL): the digest of the VDC from which this delegation was derived, when the delegator is itself acting under a delegation, encoded as specified in Digest Encoding. A VDC with no parent is a root delegation.
    • maxDepth (integer, OPTIONAL): the number of further re-delegations permitted below this one. A value of 0 prohibits re-delegation. When absent, re-delegation is prohibited. Setting maxDepth above 0 is the delegator’s explicit authorisation to re-delegate; there is no other.
    • accepts (string, REQUIRED on an acceptance, MUST be omitted on a grant): the digest of the grant being accepted, encoded as specified in Digest Encoding. See Delegation Edges.

Example (grant):

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://firstperson.network/credentials/dtg/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "type": ["VerifiableCredential", "DTGCredential", "DelegationCredential"],
  "issuer": "did:peer:2.Ez6LSbysKZ...",
  "validFrom": "2026-01-06T10:00:00Z",
  "validUntil": "2026-04-06T10:00:00Z",
  "credentialStatus": {
    "id": "https://chess-club.example/status/3#94567",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential": "https://chess-club.example/status/3"
  },
  "credentialSubject": {
    "id": "did:key:z6MkpTHR8VNs...",
    "delegation": {
      "scope": ["schedule:read", "schedule:propose"],
      "maxDepth": 0
    }
  },
  "proof": { "//": "..." }
}

Example (acceptance):

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://firstperson.network/credentials/dtg/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "type": ["VerifiableCredential", "DTGCredential", "DelegationCredential"],
  "issuer": "did:key:z6MkpTHR8VNs...",
  "validFrom": "2026-01-06T10:05:00Z",
  "validUntil": "2026-04-06T10:00:00Z",
  "credentialSubject": {
    "id": "did:peer:2.Ez6LSbysKZ...",
    "delegation": {
      "accepts": "zQmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n"
    }
  },
  "proof": { "//": "..." }
}

§ Delegation Edges

A VDC whose delegation object has no accepts property is a grant: the delegator states the appointment it has made. A VDC whose delegation object has an accepts property is an acceptance: the delegate acknowledges the appointment it has taken on, and thereby the accountability that attaches to acting in another’s name. Together they form a complete DTG edge, consistent with the bidirectional pairing of VRCs and VMCs.

• In an acceptance, issuer MUST be the credentialSubject.id of the grant, and credentialSubject.id MUST be the issuer of the grant.
• An acceptance carries no scope of its own. What the delegate consented to is the scope of the grant identified by accepts; a verifier reads it from the grant, which it must hold in any case. Restating the scope in the acceptance would require an equality check across the two credentials, which cannot be satisfied under selective disclosure of either.
• The acceptance is REQUIRED. A verifier MUST obtain and verify the acceptance before accepting any party as acting under the delegation; a grant alone establishes what the delegator appointed, not what the delegate agreed to, and MUST NOT be accepted as evidence that the delegate took on the appointment. This is the same consent rule as Membership Edge Completion, for the same reason: a delegator can always issue a credential naming someone as its delegate, but cannot produce the acceptance without that party’s signature. It also means that a party holding only the delegate’s key cannot manufacture new appointments — creating one requires the delegator to issue and the delegate to countersign.
• The edge is directional. A delegation runs from delegator to delegate; the acceptance makes the appointment mutually acknowledged, it does not make it symmetric. Nothing in an acceptance appoints the delegator to act in the delegate’s name.
• A VDC neither requires nor implies a VRC between the parties. A VRC is relationship evidence and a VDC is delegation evidence, and a verifier learns nothing about one from the other. A governing VTC or VTN MAY require both for a particular use.

§ Delegation Chains

A delegate MAY appoint a further delegate only where the VDC it holds explicitly permits this through maxDepth, and only for a subset of the acts it was itself appointed for. The default is a single hop: a delegate whose VDC does not permit re-delegation, and that needs a further delegate, asks the principal, who issues a fresh root delegation directly — so that the principal always holds the complete register of who may act in its name and can withdraw any of them. Re-delegation exists for the case where that round trip is unavailable, and a governing VTC or VTN MAY forbid it for particular acts. Where a VDC carries a parent, verifiers MUST evaluate the whole chain:

1. Every VDC in the chain MUST independently satisfy the verification requirements of this specification, including proof verification, validity period, and revocation status.
2. The scope of each VDC MUST be a subset of the scope of the VDC identified by its parent. A verifier MUST reject any chain in which a delegation broadens the appointment it derives from.
3. The validUntil of each VDC MUST NOT be later than the validUntil of its parent.
4. Depth is bounded by every ancestor. A VDC derived from a parent bearing maxDepth n MUST NOT itself bear a maxDepth greater than n − 1, and a verifier MUST reject a chain in which any VDC lies more than n steps below an ancestor bearing maxDepth n. A verifier MUST reject any re-delegation below a VDC that omits maxDepth or sets it to 0.
5. The chain MUST terminate in a root delegation whose issuer is the principal — the entity in whose name the acts would ultimately be performed. A verifier MUST establish that this principal is the party it intends to deal with; a chain that cannot be resolved to such a root establishes no representation. A governing VTC or VTN MAY additionally restrict which entities may delegate which acts, published via the applicable trust registry.

As with the VWC digestMultibase, a parent value is only as useful as the verifier’s access to the credential it references. Holders presenting a derived VDC SHOULD make the full chain available alongside it. Doing so discloses the whole ancestry, including the identity of the principal, to the verifier — which is why a single hop is the default and why chain validity is a candidate for zero-knowledge presentation (see Zero-Knowledge and Selective Disclosure and Privacy Considerations item 13).

§ Invocation Binding

A VDC is not a bearer token. A verifier MUST NOT accept a party as acting in the delegator’s name unless that party demonstrates control of the verification method associated with credentialSubject.id at the time of the request. A VDC presented without such a demonstration is evidence that a delegation exists; it is not evidence that the party presenting it is the delegate. This section states only what a verifier must have established; how the demonstration is requested and carried is part of the trust task in which the delegation is exercised and is defined by the DTG Core Trust Task Protocols specification (see Grant and Invocation).

§ Relationship to Capability Models

This subsection is informative.

Chaining, attenuation, and invocation are well-explored outside the W3C VC data model, notably in ZCAP-LD and UCAN. The VDC reuses their mechanics — attenuation-only re-delegation, chains resolving to a recognized root, and binding to a demonstration of key control at invocation — rather than inventing a different set.

The semantics differ, and the distinction in Delegation and Authority is exactly the one at issue: those models chain permissions, whereas a VDC chains representation. Within this specification, chained permissions are the VAC's territory, and its Attenuation rules apply the same mechanics to authority. The mechanics are shared because both must answer how a grant narrows as it passes down a chain and how it is bound to the party invoking it, not because the thing being passed is the same.

The VDC expresses those mechanics as a DTG credential, rather than referencing an external capability token, for two reasons. First, a delegation is a durable edge of the graph and is expected to be reasoned about alongside the other DTG edges. Second, this specification’s schemas are kept minimal so that holders can satisfy predicates in zero knowledge; an opaque embedded token would place the one payload a verifier most needs to reason about — the scope — outside the reach of that machinery. Mappings between VDCs and these formats are left to future work.

§ Edge Verifiability

This section is normative.

A DTG edge credential whose proof verifies establishes that its issuer made the statement the credential carries. Whether a verifier additionally treats that statement as an edge of a particular graph is a separate determination, made against the set of VTCs that verifier accepts as trust anchors. This section defines that determination.

An edge credential is verifiable as a DTG edge by a given verifier when both of the following hold:

1. The credential satisfies the verification requirements of Security Considerations.
2. The verifier can establish, per Membership Edge Completion, that the credential’s issuer’s membership in a VTC in the anchor set that verifier accepts is complete.

Edge verifiability is therefore a property of a credential with respect to a verifier, not of the credential alone. The same credential MAY be an edge to a verifier that accepts a given anchor set and not an edge to one that does not, and neither verifier is in error. A VTN is the common case of such an anchor set, but this specification does not require a verifier to be reasoning within a VTN, nor require any VTN to exist. In particular, an edge whose two halves trace to VTCs anchored in different VTNs, or in none, is an edge to any verifier whose accepted anchor set includes the VTC each half traces to.

Condition 2 MAY be satisfied by either of two routes:

• By disclosure, where the credential’s issuer identifier is the one its VMC names as subject, and the verifier obtains the community-issued and member-issued VMC pair (or the issuer’s own demonstration of its community-issued VMC, per Membership Edge Completion) and checks the issuing VTC against its anchor set.
• By proof, where the holder presents a Community-Anchored Zero-Knowledge Proof, which establishes the same predicate without revealing the DIDs or the credentials.

Neither route is privileged in principle. A VRC whose issuer identifier is pairwise and distinct from the one its VMC names, presented with a valid community-anchored proof, is an edge on the same terms as one issued from the VMC’s own subject identifier and presented by disclosure. Today’s construction establishes the two memberships unevenly, however: for the holder’s own membership (proof statement 2), the proof is equivalent to the holder disclosing their own completed VMC pair; for the counterparty’s membership (proof statement 3), it currently establishes only that the community attested it, not that the counterparty acknowledged it — the same open status the note below records for the linkage between a pairwise identifier and its holder’s VMC, and one that the trust task and ZK protocol work will need to close in the same pass (see Community-Anchored Zero-Knowledge Proof). Because the pairwise form is the one this specification RECOMMENDS on privacy grounds (see Unilateral Relationship Identification and Privacy Considerations), a definition of edge verifiability that admitted only the disclosure route would exclude the construction the specification recommends.

Each half of an edge is issued and signed by its own issuer, and is evaluated independently under this section. Nothing here requires a single credential to carry signatures from both peers, requires both halves of an edge to satisfy this section, or requires them to satisfy it by the same route.

Note: The identity linkage on which the proof route depends — that the party controlling the identifier appearing in the credential is the party holding the VMC under a different identifier — is not yet encoded by this credential model. Until that encoding is specified, the proof route states an intended design goal rather than an implementable construction, and implementations SHOULD expect the encoding to constrain the proof’s witness data. It does not affect whether an edge established by that route counts.

§ VIC (Verifiable Invitation Credential)

This section is normative.

Purpose: Authorizes a prospective member to join a VTC or VTN when presented to the VTA/PEP. The DTG invitation credential has two functional variants distinguished by issuer and subject rules (not by separate type strings): the VTC invitation credential and the VTN invitation credential.

Schema:

• type (array, REQUIRED): MUST include "InvitationCredential"
• issuer (string, REQUIRED):
  • For VTC invitation: DID of the VTC, or of an authorized member (per policy)
  • For VTN invitation: DID of the VTN, or of a member VTC (per policy)
• credentialSubject (object, REQUIRED):
  • id (string, REQUIRED):
    • For VTC invitation: DID of the prospective member, or of a prospective member VTC
    • For VTN invitation: DID of the prospective member VTC

Example (VTC member invitation):

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://firstperson.network/credentials/dtg/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "type": ["VerifiableCredential", "DTGCredential", "InvitationCredential"],
  "issuer": "did:key:z6MkhaXgBZD...",
  "validFrom": "2026-01-06T10:00:00Z",
  "validUntil": "2026-02-06T10:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6MkpTHR8VNs..."
  },
  "proof": { "//": "..." }
}

Editor’s note — roles and access control: Roles and access control policy details are primarily inferred from the issuer plus the trust registry. An earlier open question for this Working Draft was whether any of this information should be embedded in the VIC itself. It should not: what a party may do is conferred by a VAC (see VAC (Verifiable Authority Credential)), which can be reissued or attenuated without touching the invitation that admitted them.

§ Annotation Credentials

This section is normative.

Annotation credentials do not create graph structure. They attach data to existing edges or parties.

§ VPC (Verifiable Persona Credential)

Purpose: Links a persona to an existing relationship, enabling the holder to control intentional correlation across relationships.

Schema:

• type (array, REQUIRED): MUST include "PersonaCredential"
• issuer (string, REQUIRED): DID under which the persona is asserted, ordinarily declared directed — a persona exists to be recognized across a set of counterparties the holder chooses
• credentialSubject (object, REQUIRED):
  • id (string, REQUIRED): DID of the counterparty as used in the relationship

Example:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://firstperson.network/credentials/dtg/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "type": ["VerifiableCredential", "DTGCredential", "PersonaCredential"],
  "issuer": "did:key:z6MkrKqT9pL...",
  "validFrom": "2026-01-06T10:00:00Z",
  "credentialSubject": {
    "id": "did:peer:2.Ez6LSpSrLxn..."
  },
  "proof": { "//": "..." }
}

§ VWC (Verifiable Witness Credential)

Purpose: Third-party attestation that an edge was established under specific conditions. The witness may be a person or a VTA applying the witnessing policies of a VTC — for example, verifying that both parties were present at the same event, or provided proof of biometric liveness at the time of relationship formation.

Because the meaning of a witness attestation depends on the conditions under which the witnessing occurred, a VWC MUST be bound to the trust task exchange in which it was issued via the taskContext property (see Trust Task Context Binding).

A witnessed exchange of a complete DTG edge is bidirectional: two edge credentials, one in each direction, are formed in a single witnessing event — two VRCs for a peer-to-peer edge, or the two VMCs of a membership edge. For such exchanges the witness SHOULD issue one VWC per direction. In each VWC, credentialSubject.id MUST be the DID of the issuer of the edge credential that the VWC attests (the credential referenced by digestMultibase), so that the two VWCs of an exchange are unambiguously bound to their respective directions.

A VWC’s credentialSubject.id and taskContext alone identify only the observed party and the trust task exchange, not the edge being witnessed. Binding a VWC to a specific edge therefore requires digestMultibase: a verifier holding the referenced edge credential can recover both endpoints of the edge (the credential’s issuer and credentialSubject.id) and confirm the exact credential the witness attested to. This binding is only as strong as the verifier’s access to that credential — a digestMultibase without the referenced credential to hand is an opaque hash, not an identified edge. Issuers and holders presenting a VWC as evidence of a specific edge SHOULD make the referenced edge credential available alongside it.

A witness’s identifier is directed at minimum. It must be recognizable to both parties to the witnessed edge, and to the community whose witnessing policy the attestation is issued under, so a pairwise declaration cannot describe it truthfully.

Schema:

• type (array, REQUIRED): MUST include "WitnessCredential"
• issuer (string, REQUIRED): DID of the witness — a member, or a VTA acting according to VTC policy
• taskContext (string, REQUIRED): threadId of the trust task exchange in which the witnessing occurred
• credentialSubject (object, REQUIRED):
  • id (string, REQUIRED): DID of the observed party
  • digestMultibase (string, REQUIRED): A cryptographic hash of the witnessed edge credential, binding the VWC to the specific edge established, computed over the credential excluding its top-level proof member and encoded as specified in Digest Encoding.
  • witnessContext (object, OPTIONAL): Context of the witnessing event
    • event (string, OPTIONAL): Human-readable event name
    • sessionId (string, OPTIONAL): Session or nonce identifier
    • method (string, OPTIONAL): Verification method used

Example:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://firstperson.network/credentials/dtg/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "type": ["VerifiableCredential", "DTGCredential", "WitnessCredential"],
  "issuer": "did:webvh:QmVzTd9hRkPqLu4WgXyN...:witness-service.example",
  "validFrom": "2026-01-06T10:00:00Z",
  "taskContext": "thread-abc-123",
  "credentialSubject": {
    "id": "did:key:z6MkpTHR8VNs...",
    "digestMultibase": "zQmdfTbBqBPQ7VNxZEYEj14VmRuZBkqFbiwReogJgS1zR1n",
    "witnessContext": {
      "event": "EthDenver 2024",
      "sessionId": "session-abc-123",
      "method": "in-person-proximity"
    }
  },
  "proof": { "//": "..." }
}

§ VEC (Verifiable Endorsement Credential)

Purpose: Attaches endorsements (skills, reputation) to a party. The verifiability applies to cryptographic assurance in the issuer’s signature, not to the truth of the assertions, whose vocabulary is defined by the governing VTC or VTN.

Schema:

• type (array, REQUIRED): MUST include "EndorsementCredential"
• issuer (string, REQUIRED): DID of the endorser
• credentialSubject (object, REQUIRED):
  • id (string, REQUIRED): DID of the endorsed party
  • endorsement (object, REQUIRED): Community/VTN-defined endorsement structure
    • Structure and fields determined by community policy

Example:

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://firstperson.network/credentials/dtg/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "type": ["VerifiableCredential", "DTGCredential", "EndorsementCredential"],
  "issuer": "did:key:z6MkhaXgBZD...",
  "validFrom": "2026-01-06T10:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6MkpTHR8VNs...",
    "endorsement": {
      "type": "SkillEndorsement",
      "name": "Software Development",
      "competencyLevel": "expert"
    }
  },
  "proof": { "//": "..." }
}

§ VAC (Verifiable Authority Credential)

This section is normative.

A VAC confers permission. It differs from every other credential here in what it does to the graph: an edge credential establishes that two nodes are connected, an annotation credential attaches a claim to structure that already exists, and an invitation credential bootstraps a node into a community. A VAC creates none of those. It states what a party may do within a scope that some node governs.

The distinction that matters most is between a VAC and a VEC. An endorsement is a statement about a party — that they are skilled, trusted, or of good standing — and a verifier decides for itself what to do with that statement. A VAC is a statement to a verifier: the issuer, who governs the scope, has decided. Conflating the two puts a decision that belongs to the governing party into a claim that reads as reputation, and leaves verifiers to infer permission from adjectives.

This is a section rather than a new “Authority Credentials” category, following the reasoning in issue #28: a category with a single member is the structural problem that issue exists to remove, and adding a fourth one would repeat it. The VIC stands as its own section for the same reason. The categories are informative, so a credential standing outside them decides nothing about its schema.

Purpose: Confers authority on a party to perform specified actions within a named scope governed by the issuer.

Schema:

• type (array, REQUIRED): MUST include "AuthorityCredential"
• issuer (string, REQUIRED): DID of the party that governs the scope — a VTC or VTN, another DTG node such as a shared resource or service, or a holder attenuating authority they themselves hold (see Attenuation below). As for every DTG credential, the issuer’s correlation scope is declared rather than encoded in the identifier; see Correlation Scope
• credentialSubject (object, REQUIRED):
  • id (string, REQUIRED): DID of the party receiving the authority
  • authority (object, REQUIRED):
    • scope (string, REQUIRED): the DID or URI the authority applies to. A verifier MUST reject a VAC whose scope does not match the resource being accessed; scope matching is exact unless the governing party publishes a containment rule.
    • actions (array of strings, REQUIRED): the permitted actions, drawn from a vocabulary the governing party defines. MUST NOT be empty — an empty array is not a wildcard, and a verifier MUST treat it as conferring nothing. Action strings are compared as exact, case-sensitive strings; a verifier MUST NOT infer that one action implies another ("admin" does not grant "write" unless the governing party’s VAC says both).
    • parent (string, OPTIONAL): the digest of the VAC this one was attenuated from, encoded as specified in Digest Encoding. Absent means this VAC was issued directly by the governing party.
    • maxAttenuation (integer, OPTIONAL): the number of further attenuations permitted below this VAC. 0 prohibits attenuating it at all. When absent, attenuation is permitted as far as the maximum chain depth allows. This is the opposite default from the VDC's maxDepth, which prohibits re-delegation unless it is set; the field is named differently for that reason. See Attenuation.
• validUntil (string, REQUIRED): ISO 8601 datetime (expirationDate in v1.1). Unlike the base structure, validUntil is REQUIRED for a VAC, as it is for a VDC and for a reason the VAC feels more sharply: nothing about the subject’s current standing is consulted when a VAC is verified, so authority that does not expire is authority nobody can withdraw by waiting. Expiry is also the one withdrawal mechanism that costs a verifier no network access; see Withdrawal.
• credentialStatus (object, CONDITIONAL): a W3C VC status mechanism through which a verifier can determine whether this VAC has been revoked. A VAC MUST carry credentialStatus where its validity period exceeds the freshness window the party governing the scope defines for authority at that scope, and MAY omit it otherwise. The status mechanism is determined by that governing party. See Withdrawal.

Example (a member granted write access to a shared resource):

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://firstperson.network/credentials/dtg/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "type": ["VerifiableCredential", "DTGCredential", "AuthorityCredential"],
  "issuer": "did:webvh:z6Mkw...:example.com:rooms:7f3a",
  "validFrom": "2026-01-06T10:00:00Z",
  "validUntil": "2026-07-06T10:00:00Z",
  "credentialStatus": {
    "id": "https://example.com/rooms/7f3a/status/1#284",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "284",
    "statusListCredential": "https://example.com/rooms/7f3a/status/1"
  },
  "credentialSubject": {
    "id": "did:key:z6MkpTHR8VNs...",
    "authority": {
      "scope": "did:webvh:z6Mkw...:example.com:rooms:7f3a",
      "actions": ["read", "write", "curate"]
    }
  },
  "proof": { "//": "..." }
}

§ Attenuation

A VAC holder MAY issue a further VAC conferring a subset of the authority they hold, without involving the governing party. This is what allows a party to equip an agent, a device, or a short-lived session with only the authority that task requires, rather than lending it their own.

Attenuation is permitted by default; re-delegation is not. A VDC forbids re-delegation unless its maxDepth explicitly authorises it, and this section takes the opposite default deliberately. Extending the two chains does different things. A further delegation adds a party who may act in the principal’s name, so the principal must keep the register of who can speak for it, and a delegate that needs help can ask the principal for a fresh root delegation; failing closed costs little. A further attenuation only narrows, and its subject acts as itself, so nothing new is attributed to the governing party or to the attenuating holder. More to the point, forbidding attenuation does not stop a holder equipping an agent. It makes them lend their own key instead — which confers everything they hold rather than a subset, lasts as long as their own authority does, and is indistinguishable to a verifier from the holder acting in person. Attenuation is the safer of the two things a holder will actually do, and a default that pushed holders toward the other would buy nothing.

A governing party can still forbid it. authority.maxAttenuation bounds how far a chain may extend below the VAC that carries it, and 0 forbids attenuation outright — for an action sensitive enough that the governing party wants to decide personally who holds it. A VAC attenuated from a parent bearing maxAttenuation n MUST NOT itself bear a maxAttenuation greater than n − 1, and a verifier MUST reject a chain in which any VAC lies more than n steps below an ancestor bearing maxAttenuation n. Any link MAY set a limit lower than its parent’s, or set one where its parent set none; none may raise one. The effective limit on a chain is therefore the strictest that any of its links imposes, in keeping with attenuation never widening what it derives from.

An attenuated VAC:

• MUST set issuer to the credentialSubject.id of the VAC being attenuated — the attenuating holder’s own DID. Only the party a VAC was issued to may attenuate it.
• MUST set authority.parent to the digest of the VAC being attenuated, encoded as specified in Digest Encoding.
• MUST NOT confer any action absent from the parent’s actions.
• MUST NOT specify a validUntil later than the parent’s.
• MUST NOT widen scope.
• MUST NOT bear a maxAttenuation greater than one less than its parent’s, where the parent carries one; and MUST NOT exist at all where the parent bears 0.
• SHOULD carry a validUntil short enough that expiry alone bounds the exposure. An attenuating holder is often a person, a device, or an agent rather than an operator of a status list, and may be unreachable at the moment its grant needs taking back; see Withdrawal.

Verification. A verifier presented with a VAC that carries parent MUST verify the entire chain to a VAC issued by the governing party, and MUST reject the chain if any link widens what its parent conferred, in actions, scope, or validity period, if any link’s issuer is not the credentialSubject.id of its parent, if any link lies further below an ancestor than that ancestor’s maxAttenuation permits, or if any link that carries credentialStatus has been revoked (see Withdrawal). The second check is what gives the first its meaning: without it, a chain could cite a VAC its issuer never held, and “narrowing” would be satisfiable by anyone holding a copy of a governing party’s VAC. A verifier that checks only the presented credential has verified nothing: attenuation is only a narrowing if somebody walks the chain.

The holder presents the chain; the verifier does not fetch it. A presentation carrying an attenuated VAC MUST include every VAC from the presented one up to and including the one issued by the governing party, and a verifier MUST reject a chain it cannot complete from the presentation alone.

parent is a digest rather than an identifier so that this is structural rather than merely required. A digest names nothing that can be fetched: verification cannot come to depend on network availability, a verifier cannot be induced to make a request against an address of the holder’s choosing, and nobody who hosts an identifier learns when or how often a credential is used. Bearer-side presentation keeps verification offline, constant in its network behaviour, and free of that correlation channel. A digest also binds an attenuated VAC to the exact claims its issuer narrowed from: re-issuing a parent with different claims does not re-parent the VACs attenuated from the old one, while re-proofing it with identical claims leaves them undisturbed, because the digest excludes proof (see Digest Encoding).

Chain depth is bounded. A verifier MUST enforce a maximum chain depth and MUST NOT accept a chain of more than 8 VACs including the one issued by the governing party. Chain verification is linear in depth and runs on every presentation, so an unbounded chain is a denial-of-service vector against the verifier. The known uses need far less — a person attenuating to an agent is depth 2, and an agent attenuating to a sub-agent is depth 3 — so issuers SHOULD stay well below the ceiling, and a party finding itself near it should treat that as a signal the authority is being re-delegated further than intended.

This ceiling and maxAttenuation are different controls and a chain MUST satisfy both. The ceiling is a resource bound that every verifier enforces whether or not any issuer asked for it; maxAttenuation is a policy an issuer sets for its own grant. A chain of five under a root bearing maxAttenuation 2 is within the ceiling and still invalid.

Who may hold derived authority. A valid chain establishes that authority was narrowed by parties entitled to narrow it. It does not establish that the party now holding it is one the scope is willing to deal with: an attenuated VAC may name a subject the governing party has never encountered, and that subject acts as itself rather than in its attenuator’s name. A governing party MAY require that the subject of an attenuated VAC independently qualify — hold a VMC at the scope, or satisfy whatever the scope asks of any other actor — and a verifier enforcing such a policy MUST reject a chain whose subject does not, however well formed the chain is. This is the authority-side counterpart of the third check in How a Delegation Composes with Authority, and the reason a VAC and a VMC stay separate credentials.

Example (a member attenuating read-only, short-lived authority to their AI agent):

{
  "@context": [
    "https://www.w3.org/ns/credentials/v2",
    "https://firstperson.network/credentials/dtg/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "type": ["VerifiableCredential", "DTGCredential", "AuthorityCredential"],
  "issuer": "did:key:z6MkpTHR8VNs...",
  "validFrom": "2026-01-06T10:00:00Z",
  "validUntil": "2026-01-06T14:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6MkfR2aQ9Xv...",
    "authority": {
      "scope": "did:webvh:z6Mkw...:example.com:rooms:7f3a",
      "actions": ["read"],
      "parent": "zQmSfwf25HTvhmHve5VVWjwmQ9z7LFDWsB9hTweoieva2cd",
      "maxAttenuation": 0
    }
  },
  "proof": { "//": "..." }
}

The parent value above is the digest of the preceding example, computed as specified in Digest Encoding.

§ Invocation

A VAC is not a bearer credential. A verifier MUST NOT accept a party as holding the authority a VAC confers unless that party demonstrates control of the verification method associated with the credentialSubject.id of the presented VAC, at the time of the request. A VAC presented without such a demonstration is evidence that authority was conferred on somebody; it is not evidence that the party presenting it is that somebody.

This matters more here than for a VDC, because a VAC chain is presented in full on every use. A captured presentation is a captured chain, so a specification that let a holder be identified by possession alone would make every verifier a distribution point for the authority it was shown. It is also what Relationship to Capability Models already claims of this section: the mechanics the VDC borrows are attenuation-only derivation, chains resolving to a recognized root, and binding to a demonstration of key control at invocation. The VAC applied the first two and left the third unsaid.

There is no second party check, and no field naming one. An earlier draft of the VAC carried an OPTIONAL audience naming the DID that must present the credential. The rule above makes it redundant: the presenter must be the subject, so an audience either names that same subject and adds nothing, or names someone else and no presentation can ever satisfy both. It is removed rather than kept as a weaker second check. A VAC is bound to the party it was issued to by credentialSubject.id, and to the resource it may be used against by scope; naming an intended verifier as well would restrict where a presentation may be made, which is a question for the trust task rather than the credential.

Only the presented VAC’s subject demonstrates anything. The parties named in the links above it are not present and are not asked for anything. Requiring otherwise would defeat attenuation, whose whole purpose is that the party who attenuated is not in the loop when its agent acts.

This section states only what a verifier MUST have established. How the demonstration is requested and carried is part of the trust task in which the authority is exercised, and is defined by the planned DTG Core Trust Task Protocols specification, as it is for a VDC (see Invocation Binding).

§ Withdrawal

A VAC is withdrawn in one of two ways: it expires, or its issuer revokes it. There is no third. A VDC has a remedy a VAC does not — its verifier re-asks the permission question of the delegator at the time of the act, so withdrawing the delegator’s own authority stops every delegate at once without touching a single credential. A VAC is that answer rather than a pointer to it: nothing about the subject’s current standing is consulted at verification, and an authority that can neither expire nor be revoked cannot be taken back at all.

Expiry is the primary mechanism. validUntil is REQUIRED on every VAC, and issuers SHOULD set it no later than the purpose requires. Expiry costs a verifier no network access, discloses nothing to anyone, and cannot fail open or closed, so it is the only withdrawal mechanism that survives the offline verification this section is built around. A governing party that wants authority it can take back quickly issues it for a short period and re-issues it, rather than issuing it for a year and relying on a status list to undo it.

Revocation covers what expiry cannot. Where authority must be withdrawn before it expires — a member leaves, a device is lost, an agent misbehaves — the issuer revokes the VAC through the credentialStatus it carries. Only the issuer of a VAC can revoke it: an attenuating holder revokes what it issued, the party governing the scope revokes what it issued, and neither can revoke the other’s directly.

Verification. A verifier MUST check the status of every VAC in a chain that carries credentialStatus, and MUST reject the chain if any of them has been revoked. A VAC that carries none is evaluated on its validity period alone, and its absence is not a defect; a governing party MAY require credentialStatus for a class of authority at its scope, in which case a verifier enforcing that policy MUST reject a VAC that omits it. This keeps the network cost of verification proportional to what a chain actually claims: short-lived attenuations under a long-lived root cost one status check between them, and a chain whose every link is short-lived costs none.

Revocation cascades. A VAC confers no more than the VAC it was attenuated from, so revoking a VAC withdraws every VAC attenuated from it, transitively, whether or not the revoking issuer knows those derivations exist. This is what makes attenuation safe to permit without the governing party’s involvement: a governing party that revokes its own grant withdraws the whole tree beneath it in a single act, and needs no register of what its holder went on to issue. It also means an attenuator’s grants die with its own — a holder whose authority is revoked cannot leave a working agent behind it.

A revoked parent is not always visible, and that is the trade. A verifier presented with a chain whose root carries credentialStatus learns that the root was revoked and rejects the chain. A verifier presented with a chain whose links carry none learns nothing beyond their validity periods, and will accept an attenuation whose parent was revoked an hour ago. Offline verification bounds that exposure rather than removing it, and what bounds it is the shortest validUntil in the chain. Holders attenuating authority SHOULD keep that value as short as the task allows for this reason, and a governing party that cannot tolerate the gap SHOULD require credentialStatus on the VACs it issues, together with a freshness window short enough to close it.

§ Authority is not delegation

A VAC authorizes its subject to act in their own name, within a scope. It does not authorize acting on behalf of another party, and a verifier MUST NOT read it as doing so. The two are separate questions — may this party do this here? and may this party stand in for that one? — and answering both with one credential means a verifier cannot tell which it has been shown.

Editor’s note — the actions vocabulary is deliberately open, and that has a cost. Each governing party defines its own action strings, which is what lets a room, a community and a service each grant what makes sense for it without a registry negotiating between them. The cost is that "write" issued by one governing party carries no defined relationship to "write" issued by another: the strings are only meaningful within the scope that issued them, and a verifier that generalises across scopes is reading something the specification does not say. That is tolerable while authority is checked by the party governing the scope, which is the case this specification describes. It would need revisiting if VACs are ever expected to be interpreted across governance boundaries — a shared core vocabulary with room for extension is the obvious answer, and is deliberately not attempted here.

§ Relationship to the VDC

The VDC and the VAC draw the same line from opposite sides. A VDC establishes that one party may act in another’s name; it never supplies authority, and the verifier re-asks the permission question of the delegator, live, at the time of the act (see How a Delegation Composes with Authority). A VAC answers that question: it is the credential a delegator can hold that check 2 of that section looks for. The two compose — the reach of a delegated act is the intersection of what the VDC appoints the delegate for and what the delegator’s own authority covers — and neither substitutes for the other. A verifier MUST NOT read an attenuated VAC as an appointment to act in the attenuator’s name, nor a VDC as conferring any of the delegator’s authority on the delegate.

They also differ in what they ask of a verifier. A VAC chain is precommitted: every link only narrows what its parent fixed, the holder presents the whole chain, and a verifier reaches the network only for those links that carry credentialStatus (see Withdrawal). A VDC is live by design: the permission question is answered at invocation against the delegator’s current standing, so withdrawing the delegator’s own authority stops every delegate at once without touching a single VDC. Folding one into the other would give up whichever of those properties the merged credential lacked.

Which one an agent’s grant is. A person equipping an AI agent could, on the face of it, do either, and the test in Delegation and Authority — whose name is the act in? — decides it. The agent example above is a VAC because the agent is to act as itself: the room records the agent as the actor, the agent answers for its acts, and the chain records only who equipped it — that is provenance of its authority, not attribution of its acts. The person’s own VAC is the ceiling the chain narrows from, and nothing else of the person’s travels with it: authority is not membership, and an agent acting under a VAC is credited with nothing a PHC or a VMC attests about its principal. If instead the room needs the act attributed to the person — the person is answerable for it, and the record should say the person acted, through an agent — the person issues a VDC, the agent presents it, and the agent’s reach is whatever the person may itself do. Which of the two a governing party admits for agents is a governance determination; that a verifier can always tell which it has been shown is what keeping them as separate credentials buys.

§ Authority and membership are separate credentials

A VAC does not attest membership and MUST NOT be accepted as evidence of it; a VMC does not confer authority and MUST NOT be accepted as evidence of that. Keeping them separate lets a governing party change what a member may do without touching the membership edge, and lets a holder prove authority without proving which member they are.

Where a verifier requires both — that the presenter is a member and holds authority — and the presentation is a zero-knowledge proof that withholds the subject identifier, the presentation MUST include a proof that both credentials share the same subject. Without it, two parties may pool credentials: one contributes membership, the other contributes authority, and the combination verifies as a single party holding both. See Zero-Knowledge and Selective Disclosure.

§ Trust Task Context Binding

This section is normative.

DTG credentials are frequently issued during broader multi-step exchanges — trust tasks carried out through ceremonies governed by a VTC or VTN. A credential exchanged inside such a ceremony can be cryptographically valid as an artifact while still being insufficient evidence that the ceremony reached its intended terminal state. This section defines the mechanism that prevents such credentials from escaping their task context and being misinterpreted.

§ Credentials versus Trust Task Artifacts

This subsection is informative.

The boundary between this specification and the planned DTG Core Trust Task Protocols specification is drawn by the following test:

• A credential is a durable claim about the graph that is true standing alone (e.g., VRC, VMC, VPC). It lives on after the exchange in which it was issued.
• An artifact is a work-product of a trust task (intermediate or completion), only meaningful within its exchange. It is carried as a Trust Task document, correlated by a shared threadId, with its terminal state expressed at the trust task layer — not as a new credential type.

Test for any new thing: true outside the exchange? → credential. Only meaningful inside? → artifact.

All seven credential types in this specification pass the credential side of this test. The VDC is the boundary case that most clearly illustrates it: the delegation grant is durable and passes, while the invocation of a delegation does not and is left to the trust task layer (see Grant and Invocation). The structure of trust task completion artifacts (outcome evidence) is out of scope for this specification and will be defined in the DTG Core Trust Task Protocols specification.

§ The taskContext Property

A credential whose meaning depends on a trust task completing MUST carry a taskContext property containing the threadId of the originating trust task exchange. This requirement is a property of the credential type, not a per-issuer choice:

• For credential types where this specification marks taskContext as REQUIRED (currently only the VWC), issuers MUST include it.
• For all other DTG credential types, taskContext is OPTIONAL.
• A DTG credential without a taskContext property MUST be interpretable standing alone, independent of any exchange.

§ Outcome Interpretability

A verifier MUST NOT interpret a taskContext-bearing credential as proof that the associated trust task or ceremony completed unless the matching trust task outcome evidence is also present and verified. That outcome evidence MUST be reachable by the verifier — either it travels with the presentation, or the taskContext value enables the verifier to locate it.

§ Supporting Concepts

This section is informative.

§ Personhood Credentials (PHC)

A PHC is the community-issued VMC (the membership grant) issued by a VTC whose governance enforces:

• Real human personhood
• Exactly one membership per person

No additional schema fields are required. PHC status is determined by governance and trust registries, not by credential structure. Issuers may optionally add "PersonhoodCredential" to the type array as a non-authoritative hint.

A grant is a PHC whether or not the member has acknowledged it. The member may present an unacknowledged grant as evidence of their own membership under the presentation rule in Membership Edge Completion; the acknowledgement gates only the community’s ability to assert that membership to others. “Exactly one membership per person” is counted over grants, and is enforced by governance rather than by credential structure.

Example:

{
  "type": [
    "VerifiableCredential",
    "DTGCredential",
    "MembershipCredential",
    "PersonhoodCredential"
  ],
  "issuer": "did:webvh:QmRfN7pKwEbTs2LcMqDh...:government-idv.example",
  "credentialSubject": {
    "id": "did:key:z6MkpTHR8VNs..."
  }
}

§ Trust Registries

• Authoritative source for roles (initiator, trust anchor, member, IDVP, etc.)
• Map DIDs to roles and policies
• Determine acceptable issuers
• Schema and APIs out of scope for this specification
• Handle revocations, etc.

§ Identity Verification Credentials (IDVC)

• IDVCs are not DTGCredential subtypes
• Any W3C VC satisfying a VTC/VTN’s identity-proofing requirements
• Issuers, assurance levels, and requirements governed by VTC/VTN policy and trust registries

§ Zero-Knowledge and Selective Disclosure

• This specification is format-agnostic (no binding to BBS+, SD-JWT-VC, etc.)
• Two ZKP constructions are defined for proving relationships: the Pairwise Zero-Knowledge Proof (available to any two VRC holders) and the Community-Anchored Zero-Knowledge Proof (available when both parties hold VMCs from the same community)
• Schemas are kept simple to enable common predicates:
  • “Holder has valid community-issued VMC from recognized VTC”
  • “Issuer is authorized member”
  • “Two distinct VRCs exist”
  • “Holder has a valid, unrevoked delegation to act in the name of a member of a recognized VTC, covering act X”
  • “This delegation chain is valid: each scope nests in its parent’s, depth is bounded, expiry is monotone, and the root is issued by a member of a recognized VTC” — without disclosing the chain
  • “Holder holds a VAC conferring action X at scope S, and its chain is valid and unrevoked: each link is issued by its parent’s subject, narrows its parent, no link is revoked, depth is within every limit its links set, and the root is issued by the party governing S” — without disclosing the chain
  • “Two credentials presented together share a subject” — required by Authority and membership are separate credentials whenever membership and authority are both proven with the subject withheld
• Detailed ZK protocols and registry-ZK interactions are left to the ZKP task force; what that work is blocked on, and what holds until it lands, is set out below

Editor’s note — what is waiting on the ZKP task force. The predicates above are requirements on the schemas rather than constructions. This specification fixes what must be provable and leaves how to the ZK protocol work, so the list should not be read as describing machinery that exists today.

Four of those predicates rest on one primitive no DTG specification yet defines: a proof that two credentials, or two identifiers, are under common control, without disclosing either. It is tracked in #9, and it carries:

• the Community-Anchored Zero-Knowledge Proof, wherever a party’s VMC identifier and its VRC identifier differ;
• the shared-subject requirement of Authority and membership are separate credentials, which exists precisely to stop two parties pooling one’s membership with the other’s authority;
• proving a VDC chain valid without disclosing it, per Delegation Chains;
• proving a VAC chain valid without disclosing it, per Attenuation.

Correlation Scope makes the first of these the ordinary case rather than an edge case. A member who declares pairwise toward their community and pairwise toward a counterparty holds two identifiers that differ by construction, so a community-anchored proof must cross them rather than read one identifier out of both credentials.

Separately, none of the digest-valued members fixed in Digest Encoding is salted, so a digest over low-entropy content can be reversed by enumeration where the referenced credential is not disclosed. Blinding them is cross-cutting work with the same task force and is tracked in #38.

The ZKP task force’s work on these is visible in its working draft and the accompanying construction catalogue, where records 007 (common control), 010 (community-anchored composition), 020 (delegation chains) and 008 (blinded binders) bear on the dependencies above. That draft is proposed rather than merged, and a record in the catalogue is a statement, its witness requirements, and the open questions around it, not a completed proof; nothing there closes #9 or #38, and the shared-subject and VAC-chain cases in particular still need their own mapping and evidence rather than inheriting one because common control appears in the catalogue. Glossary cross-references will follow once that specification is merged and its terms are published.

What holds until this work lands. Nothing in this specification is unverifiable in the meantime: every requirement here can be checked by presenting the credentials themselves, which is what a holder must do today to satisfy any predicate above. The cost is privacy rather than correctness, and it falls hardest where a chain is involved, because the disclosure boundary is the whole chain rather than the credential presented (see Privacy Considerations item 13). Implementations should not defer shipping a rule of this specification on the grounds that its zero-knowledge form is unspecified.

§ Security Considerations

This section is informative.

§ Every credential

1. Proof verification. Verifiers must cryptographically verify the proof of every DTG credential, including resolution of the issuer’s DID and validation of the verification method, before relying on any claim in the credential.
2. Validity period and revocation enforcement. Verifiers must reject credentials outside their validFrom/validUntil window (or v1.1 equivalents). Where a credential carries credentialStatus, verifiers must check it within the freshness window the governing party defines, and should consult the governing trust registry or governance framework for that window and for whether status is required at all: the registry is where the policy lives, and the credential is where the status lives. See Withdrawal for VACs and the credentialStatus rule of VDC (Verifiable Delegation Credential) for VDCs.
3. Issuer authorization. A cryptographically valid credential is not necessarily an authorized one. Verifiers must evaluate whether the issuer is authorized for the claimed role (e.g., a community-issued VMC’s issuer being a recognized VTC, a member-issued VMC’s issuer being the subject of the grant it acknowledges, a VIC issuer being permitted to invite) using the applicable trust registry or governance framework.
4. Key compromise. Compromise of the private key controlling any DID used in a DTG credential (issuer or subject) undermines all credentials anchored to it. Key rotation and revocation procedures are governed by the applicable DID methods and trust registries.
5. Context collapse. A credential presented outside the trust task exchange in which it was issued may be misinterpreted as evidence of a completed ceremony. The requirements of Trust Task Context Binding exist to prevent this class of attack and must be enforced by verifiers.
6. Digest integrity. A verifier relying on a VWC’s binding to a specific edge must have the referenced edge credential available, recompute the digest over its JCS (RFC 8785) canonical form with the top-level proof member removed, and confirm it matches digestMultibase — comparing decoded digest bytes rather than encoded strings, as set out in Digest Encoding. A mismatch invalidates the attestation. Without the referenced credential in hand, digestMultibase cannot be resolved to an edge, and the VWC should not be treated as evidence of which edge was witnessed. The same requirement applies to the digestMultibase that a member-issued VMC carries of the community-issued VMC it acknowledges, to a VDC’s parent and accepts, and to a VAC’s authority.parent: a mismatch invalidates the acknowledgement, the derivation, or the attenuation.

§ Membership and invitation

7. Unconsented membership assertion. A community-issued VMC alone does not establish that the named entity agreed to be a member, since a community can issue one without that party’s involvement. Verifiers evaluating a membership claim made by anyone other than the member should require the member-issued VMC of the pair, per Membership Edge Completion.
8. Replay of invitation credentials. VICs should be issued with short validity periods and should be treated as single-use by the accepting VTA/PEP, to prevent replay of an intercepted invitation.

§ Delegation (VDC)

9. Misreading a VDC as a claim (VDC). A VDC establishes representation rather than asserting a fact, so a verifier that evaluates it with the logic it applies to the other DTG credentials will accept a party as standing in for another without having bounded what that party may then do. Verifiers must apply the scope, chain, and invocation requirements of VDC (Verifiable Delegation Credential) in full, and must not accept a syntactically valid VDC as representation for anything outside its scope.
10. Treating a delegation as a permission (VDC). A VDC establishes that the delegate may act in the delegator’s name; it says nothing about whether the act requested is one the delegator could perform. A verifier that treats a valid VDC as sufficient grounds to proceed lets a delegate do in the delegator’s name what the delegator could not do itself, and a verifier that evaluates the delegate’s own permissions instead of the delegator’s answers the wrong question entirely. The checks are independent and must each be made, as set out in How a Delegation Composes with Authority.
11. Delegation chain escalation (VDC). Re-delegation that broadens scope, extends validity beyond the parent, or exceeds the permitted depth converts a narrow appointment into a wide one. Verifiers must evaluate every VDC in a chain, not only the one presented, and must reject any chain that does not resolve to a root delegation issued by the principal in whose name the acts would be performed.
12. Delegation revocation latency (VDC). An appointment already made is withdrawn either by letting it expire or by revoking it, and the usefulness of revocation is bounded by how recently the verifier checked: a verifier holding a cached status accepts an act performed after revocation, and a verifier that fails hard on an unreachable status endpoint turns the issuer’s outage into its own. Delegators should keep validUntil as short as the delegated purpose allows, so that expiry gives a bounded and stated exposure window; where a VDC carries credentialStatus, verifiers should check it within the freshness window defined by the governing VTC or VTN.
13. Bearer use of a VDC. A VDC that is presented without a demonstration of key control by the delegate proves only that a delegation exists. Verifiers must enforce Invocation Binding; otherwise a captured VDC is usable by whoever holds a copy of it.
14. Personhood laundering via delegation. A PHC asserts that its holder is a real person with exactly one membership. Because a delegate’s acts are attributable to the delegator, a verifier that cannot distinguish the two may credit an agent with its principal’s personhood, and may credit several agents of one person as several people. Verifiers must treat an act performed under a VDC as an act by the delegate in the delegator’s name — never as an act by the delegator in person — and communities whose governance depends on personhood should state whether delegated acts are recognized at all.

§ Authority (VAC)

15. Authority chain verification. A VAC carrying authority.parent confers nothing on its own. Verifiers must verify every link to a VAC issued by the party governing the scope, and reject the chain if any link widens the actions, scope, or validity period its parent conferred, is issued by a party other than its parent’s subject, or lies further below an ancestor than that ancestor’s maxAttenuation permits. Verifying only the presented credential accepts a self-issued grant of arbitrary authority.
16. Chain resolution is bearer-side by design. authority.parent is a digest, so it names nothing a verifier could fetch: every link comes from the presentation, and a chain that cannot be completed from it is rejected. A resolvable reference in its place would make verification depend on network availability, expose the verifier to server-side request forgery against an address the holder chooses, and signal credential use to whoever hosts the identifier.
17. Chain depth is a denial-of-service surface. Verification is linear in depth and runs on every presentation, so the maximum-depth rule is a resource bound, not a stylistic one.
18. Credential pooling under zero-knowledge presentation. Where membership and authority are proven together with the subject identifier withheld, a verifier must require proof that both credentials share a subject. Otherwise two parties can combine one’s membership with the other’s authority and present as a single party holding both.
19. Authority revocation latency (VAC). A VAC is the answer to the permission question rather than a pointer to it, so nothing about the subject’s current standing is consulted at verification and expiry or revocation are the only ways authority is taken back. The usefulness of revocation is bounded by how recently the verifier checked: a verifier holding a cached status accepts an act performed after revocation, and one that fails hard on an unreachable status endpoint turns the issuer’s outage into a denial of the scope it governs. Issuers should keep validUntil as short as the purpose allows, so that expiry gives a bounded and stated exposure window even where status is unavailable, and governing parties should state the freshness window within which a status check must have been made.
20. Bearer use of a VAC. A VAC presented without a demonstration of key control by its subject proves only that authority was conferred on someone. Because a chain is presented in full on every use, a captured presentation is a captured chain, and a verifier that accepts possession as identification lets whoever captured it exercise the whole of what the chain confers. Verifiers must enforce Invocation; a VAC names no second party whose presentation would be accepted instead, so a verifier that skips the key-control demonstration has no weaker check to fall back on.
21. Revocation cascades down a chain, and is invisible where status is absent (VAC). Revoking a VAC withdraws everything attenuated from it, which is what lets a governing party withdraw derivations it never saw. The reverse is the exposure: a verifier presented with a chain whose links carry no credentialStatus cannot learn that an ancestor was revoked, and will accept an attenuation until the shortest validUntil in the chain expires. Holders attenuating authority should keep that period short, and a governing party that cannot tolerate the gap should require status on the VACs it issues.

§ Privacy Considerations

This section is informative.

§ Identifiers and correlation

1. Pairwise really means pairwise. Reusing one identifier across counterparties creates exactly the correlation a pairwise declaration promises to avoid. As required in Unilateral Relationship Identification, such reuse is prohibited, and it also falsifies a declaration the holder made — which is the more useful thing for a verifier to be able to say. A holder who wants an identifier to reach more than one counterparty should declare directed and say so, rather than declare pairwise and reuse it.
2. Intentional correlation via personas. Correlation across relationships should occur only through the holder’s deliberate assertion of a persona (via a VPC) or through an identifier the holder has deliberately declared directed or public — never as a side effect of credential structure.
3. What a community does with a member’s identifier. A member’s declared scope constrains the member’s own disclosure and nothing else. A community that publishes a member directory, or that presents a member-issued VMC to a third party, widens the exposure of an identifier its holder may have declared pairwise. This is why a VTC’s governance is required to state its disclosure practice, and why a member’s scope choice at join time is only as meaningful as that statement; see Scope the holder cannot declare alone.
4. Correlation through the resolution layer. Correlation does not require the credentials themselves. Where several of a party’s narrow-scope identifiers resolve through common infrastructure — a shared web origin, a shared registry, or a shared set of DID log witnesses countersigning their updates — that infrastructure can associate identifiers that the credential structure was designed to keep apart, and can observe when each is used. Choosing a DID method for these is therefore a privacy decision as much as a key management one; see DID Method Considerations.

§ Disclosure

5. Minimal disclosure. DTG credential schemas are intentionally minimal so that holders can satisfy common predicates (membership, relationship existence) using zero-knowledge or selective disclosure mechanisms without revealing underlying DIDs or credential contents.
6. ZKPs by default. Implementations should use ZKP presentation by default so that privacy preservation does not require any extra effort on behalf of users.
7. Witness data. The optional witnessContext of a VWC may reveal information about where and when parties met. Issuers should include only what the witnessing purpose requires, and holders should be able to withhold witnessContext details when proving the attestation.
8. The acknowledgement as a disclosure artifact. A member-issued VMC is a signed, transferable credential naming both the member and the community, and it is held by the community. It exists so that a community cannot assert a membership it is unable to prove — but the same property lets the community prove that membership to a third party without the member’s involvement, which a community-issued VMC alone did not allow. Members should treat issuing an acknowledgement as a durable and delegable disclosure of the membership. The acknowledgement is issued from the same identifier the grant names as its subject, so the exposure it carries is the exposure of whatever scope the member chose for joining — a pairwise identifier confines it to this community, and a directed or public one carries the membership into every context that identifier reaches (see items 1 and 3). A member may also bound the disclosure with a short validUntil (see the editor’s note in Membership Edge Completion). This specification defines no selective-disclosure or zero-knowledge form for the acknowledgement, so a community proving membership to a third party currently discloses the whole credential.
9. Effective disclosure of an edge. A declared scope constrains only the disclosure of the party who declared it. Each half of an edge is issued by its own party, under an identifier whose scope that party chose; neither party controls, and neither can necessarily discover, what the other does with its own half. An edge’s effective disclosure is therefore the wider of its two halves’ scopes, not the narrower: a correctly pairwise half is still correlated to a named party if the counterparty published the opposing half under a directed or public identifier. Implementations should compute the privacy of an edge over both halves, not from the half they issued, and should not represent a pairwise half as making the edge pairwise. The same reasoning applies to any joint presentation: what a set of credentials discloses together may exceed what any of them discloses alone.

§ Delegation and authority chains

10. Delegation correlation. A VDC links a delegator and a delegate, and every invocation of it exposes that link to the verifier. A VDC is presented to arbitrary verifiers, each of whom sees the delegator’s identifier, so that identifier is known to a holder-chosen set by construction: delegators should issue VDCs from an identifier declared directed and scoped to the context in which the appointment will be exercised, rather than from a public identifier or from a directed one already used across contexts, so that a delegate’s activity in one context does not correlate its principal’s activity in another. The same applies on the delegate’s side: a delegate holding appointments from several principals should accept each under a distinct identifier, since presenting two appointments under one credentialSubject.id links the two principals to the verifier without either having chosen it.
11. Scope terms as identifiers. The scope of a VDC is community-defined text that may be narrow enough to identify the delegator, the delegate, or the underlying arrangement. Issuers should choose scope vocabularies that are no more specific than the appointment requires, and holders should be able to prove scope containment in zero knowledge rather than disclosing the full scope array.
12. Status lookups as a correlation surface. A credentialStatus check is a live lookup: whoever hosts the status list learns which verifier checked which credential, and when. Herd privacy over the list’s contents does not touch the fetch itself. This is why the VDC prefers short validity and re-issuance to status where the delegator is reachable, and why a governing VTC or VTN that requires status for a class of delegations should state the correlation it accepts in doing so.
13. Chain disclosure. Establishing representation under a derived VDC requires the verifier to see the whole chain up to the root, whose issuer is the principal. Selective disclosure over the leaf credential does not help, because the disclosure boundary is the chain, not the credential. Holders should expect a derived VDC to reveal its ancestry, and delegators should prefer single-hop appointments where the round trip to the principal is available. The same holds for an attenuated VAC, whose chain the holder presents in full: an agent presenting one discloses to every verifier the identifier of the party that equipped it.
14. Status on a root gives back part of what bearer-side presentation bought. A VAC chain is presented rather than fetched, so verifying one ordinarily tells its issuers nothing. Where the root carries credentialStatus, that changes for the root alone: whoever hosts its status list learns that a verifier checked it, and when, which for a chain of attenuations means the governing party observes the timing of activity by agents and devices it never issued to and cannot see. The exposure is one lookup for the whole chain rather than one per link, and it discloses timing rather than content — but it is the reason Withdrawal prefers short validity to status wherever re-issuance is available, and a governing party that requires status should state the correlation it accepts in doing so, as item 12 requires of delegations.

§ Governance Considerations

This section is informative.

This specification deliberately delegates most policy decisions to the governance frameworks of individual VTCs and VTNs, consistent with the ToIP Governance Metamodel:

1. Membership criteria, invitation policies, and identity-proofing requirements (including acceptable IDVPs and IDVCs) are defined by each community’s governance framework and published via trust registries.
2. Whether a VMC qualifies as a PHC is a governance determination, not a schema property.
3. Whether member identifiers are disclosed beyond the VTA is a governance determination; that a VTC state its answer is a normative requirement on the VTC as issuer, not a governance option, because it decides whether a member’s pairwise declaration remains truthful once the membership exists. See Scope the holder cannot declare alone.
4. Endorsement vocabularies for VECs and witnessing policies for VWCs are defined by the governing VTC or VTN.
5. Delegation scope vocabularies for VDCs, the status mechanism used for their revocation, the freshness window that determines when a VDC must carry credentialStatus, whether re-delegation is permitted for particular acts, and whether delegated acts are recognized at all where personhood is required, are defined by the governing VTC or VTN.
6. Whether a delegate must independently qualify — hold a VMC of its own, or meet the same requirements as any other actor — before it may act in another’s name is a governance determination, not a property of the VDC. A VDC establishes only that the appointment was made; see How a Delegation Composes with Authority.
7. Action vocabularies for VACs at a scope, the status mechanism used for their revocation, the freshness window that determines when a VAC must carry credentialStatus and how recently a verifier must have checked it, and whether status is required outright for a class of authority, are defined by the party governing that scope — a VTC or VTN through its governance framework, or another DTG node through whatever it publishes for the scope it governs. See Withdrawal.
8. Whether the subject of an attenuated VAC must independently qualify — hold a VMC at the scope, or meet whatever the scope asks of any other actor — before authority derived from another party’s grant is honoured, is a governance determination rather than a property of the VAC. Attenuation establishes only that the authority was narrowed by someone entitled to narrow it; whether the party now holding it is one the scope will deal with is a separate question, and the counterpart of the same determination for delegates in item 6. See Attenuation.
9. New credential types proposed by higher-layer trust task protocol specifications are expected to be coordinated between the DTGWG task forces responsible for credentials and trust tasks.

§ Internationalization Considerations

This section is informative.

Human-readable values in DTG credentials (e.g., endorsement names, witness event names) are community-defined and may appear in any language. Detailed internationalization guidance will be completed before this specification advances beyond Working Draft status.

§ Accessibility Considerations

This section is informative.

This specification defines data structures rather than user interfaces. Accessibility guidance for implementations presenting DTG credentials to users will be completed before this specification advances beyond Working Draft status.

§ Conformance

This section is normative.

This specification defines normative requirements, using the keywords defined in Requirements Language, for the following conformance targets:

§ Conformance Targets

1. Issuers — entities that issue DTG credentials. A conforming issuer MUST produce credentials that satisfy the Base Structure and the schema of the concrete credential type, including the taskContext requirements of Trust Task Context Binding. Where it declares a correlation scope for its identifier, a conforming issuer MUST satisfy the declaration requirements of Correlation Scope; a conforming issuer that is a VTC issuing VMCs MUST also publish its member-identifier disclosure practice as Scope the holder cannot declare alone requires.
2. Holders — entities that store and present DTG credentials. A conforming holder MUST present credentials without altering their contents and MUST include reachable trust task outcome evidence when presenting taskContext-bearing credentials as evidence of task completion.
3. Verifiers — entities that verify DTG credentials and presentations. A conforming verifier MUST implement the verification requirements of the Security Considerations and the outcome interpretability rule of Trust Task Context Binding, and MUST support W3C VC Data Model v2.0 verification per W3C Verifiable Credentials Version Support. Where a presented identifier carries a declared correlation scope, a conforming verifier MUST apply the verifier requirements of Correlation Scope. A verifier that accepts VACs MUST additionally implement the chain verification rule of Attenuation, the status-checking rule of Withdrawal, and the key-control rule of Invocation.

§ Conformance Tests

Conformance test suites for this specification have not yet been defined and are expected to be developed as the specification matures toward Working Group Approved Deliverable status.

§ References

§ Normative References

• W3C Verifiable Credentials Data Model v2.0
• W3C Verifiable Credentials Data Model v1.1
• W3C Decentralized Identifiers (DIDs) v1.0
• IETF RFC 2119: Key words for use in RFCs to Indicate Requirement Levels
• IETF RFC 8785: JSON Canonicalization Scheme (JCS)
• W3C Verifiable Credential Data Integrity v1.0
• W3C Controlled Identifiers (CIDs) v1.0
• ISO 8601: Date and time format

§ Informative References

• ToIP Trust Registry Query Protocol
• ToIP Governance Metamodel Specification V1.0
• Trust Tasks (ToIP Glossary) and the community proposals at trusttasks.org
• IETF RFC 7095: jCard: The JSON Format for vCard
• Agent2Agent (A2A) Protocol: AgentCard
• Personhood Credentials (arXiv:2408.07892)
• Authorization Capabilities for Linked Data (ZCAP-LD)
• User Controlled Authorization Networks (UCAN)
• W3C Bitstring Status List v1.0
• DTG Credentials v0.3 proposal draft (superseded by this specification)

§ Appendices

§ Appendix A: Acknowledgements

The editors gratefully acknowledge the participants of the Decentralized Trust Graph Working Group (DTGWG) and its task forces, whose discussions and contributions shaped this specification — in particular Sankarshan Mukhopadhyay, whose analysis of the credential/trust-task boundary shaped the Trust Task Context Binding section, and Glenn Gore, for the verifiable identifier interoperability considerations.

Copyright © 2026 Trust Over IP (ToIP) Contributors
This work is licensed under a Creative Commons Attribution 4.0 International License.