OpenVTC Wiki

37 min read

DTG Credentials Core Specification (ToIP DTGWG)

Repo: github.com/trustoverip/dtgwg-cred-spec — normative spec, Version 1.0, Document Status Working Draft 0.6.0 (main since #68, 2026-09-28; not yet tagged). Tagged drafts: WD01 and WD02 (the last ordinal tags, 2026-09-07), then semver tags v0.4.0 (2026-09-15, #54) and v0.5.0 (2026-09-22, #59). Titled “DTG Core Credentials V1.0” until 2026-09-24 (#61/#62). Supporting materials and discussions: github.com/trustoverip/dtgwg-cred-tf (no commits since 2026-08-18).

The authoritative specification for the Decentralized Trust Graph credential family, maintained by the Trust over IP Foundation’s DTG Working Group Credentials Task Force. This is the definitive source for DTG credential semantics — what each credential type means, how it’s constructed, what proofs it supports, and how the wider trust graph composes from them. Implementations track this spec; where the wiki and the spec disagree, the spec wins.

Since late September 2026 the specification no longer stands alone: it names two published companions — Trust Tasks (dtgwg-trust-tasks-spec, which defines how a credential names and binds the exchange it cites and what counts as evidence that the exchange completed) and Verifiable Trust Infrastructure (dtgwg-vti-spec) — and one normative registry, the DTG VSC Predicate Registry (dtgwg-vsc-registry, served at https://registry.trustoverip.org/dtg/), which defines the predicate profiles (including the two core ones the spec names, VEC and VWC) and hosts the frozen credential @context. The working-group scope rule behind the split: a credential specification defines its types, properties and high-level requirements, and points at the Trust Tasks and VTI specifications for exchange processing and composition.

In July 2026 the spec moved home and became a formal ToIP deliverable: the informal dtg.md v0.3 that lived in the task-force repo was migrated into the ToIP Spec-Up-T template in a new repo, dtgwg-cred-spec, as DTG Core Credentials V1.0 — Working Draft 01. It follows the Linux Foundation JDF process — a sequence of Working Drafts until the task force submits it for a vote as a Working Group Approved Deliverable. The old repo (dtgwg-cred-tf) deleted its copy of the spec in August (#38) and keeps only supporting materials (use_cases.md, witnessed_vrc_flow.md, links to the First Person Project whitepaper, VTC Bootstrapping Process, DTG Glossary) plus the discussions board; spec-specific issues go to the new repo. RFC 2119 key words are binding only in sections that open with “This section is normative.” — the Introduction, Terminology, Taxonomy and all Considerations sections are informative.

September 2026 was the spec’s biggest month since the migration. Working Draft 02 (28 commits in five weeks) grew the catalog from six credential types to eight — adding the Verifiable Delegation Credential (VDC) and Verifiable Authority Credential (VAC), the first credentials that confer rather than attest — retired the four DID types (R/M/C/P-DID) in favor of a holder-declared correlation scope (pairwise | directed | public), fully specified the member-issued VMC so a membership edge is actually constructible, and replaced the sha256:<hex> digest with the W3C digestMultibase encoding. Then, in the ten days after the tag, main went further still: the VAC gained key-control binding, revocation and an attenuation limit; the VIC was promoted out of its single-member category; and the Verifiable Statement Credential (VSC) absorbed the VEC and VWC as predicate profiles, bringing the type count back down to seven. Numbered drafts were retired in favor of a semver Document Status. And in the last ten days of the month (fifteen commits, #50–#71) the draft became implementable as written: the correlation-scope declaration got its property name — issuerScope, REQUIRED on every credential — the placeholder firstperson.network namespace was replaced by the decided registry IRIs and a byte-frozen @context at https://registry.trustoverip.org/dtg/context/v1, taskContext was bound to the published Trust Tasks mechanisms with a companion taskDigestMultibase, proofs were fixed to Data Integrity (eddsa-jcs-2022 RECOMMENDED), the informative categories were dropped (only Edge Credentials survives, as a class with requirements), and the two core predicate profiles’ member definitions moved out to the registry. Document Status went 0.4.0 → 0.5.0 (#59) → 0.6.0 (#68). The dtg-credentials crate crossed to 0.6.0 and the v1 context in 0.12.0 (2026-09-30), so for the first time since July the implementation and main describe the same wire format.

The wiki entity for the implementation that tracks this spec is dtg-credentials (0.12.0+ track Document Status 0.6.0 and the v1 context; 0.7.0–0.11.0 tracked WD02; 0.2.0–0.6.0 tracked WD01); for the conceptual taxonomy it defines, see dtg-credentials-overview.

Contents

Spec-Up-T layout (specs.json → spec/), rendered to docs/. Described as of main on 2026-10-07 (Working Draft 0.6.0, HEAD = #71 of 2026-09-30); where the WD02 tag differs, it is noted. The body is shorter than it was at WD02 (1,434 lines; the WD02 → HEAD diff is +733 / −1,132), chiefly because #55 removed the category scaffolding and #71 moved the two core profiles’ member lists to the registry.

  • header.md — title “DTG Credentials Core Specification” (#61; was “DTG Core Credentials V1.0”), Version 1.0 / Document Status Working Draft 0.6.0 (WD02 tag: “Working Draft 02”), six editors alphabetized with updated affiliations (#59, #63): Glenn Gore (Affinidi — moved from contributors to editors), Martina Kolpondinos (Kosma Connect), Alberto Leon and Brendan A. Miller (Harvard Applied Technology Lab), Drummond Reed (First Person Cooperative), Geoff Turk (ic3 Software); contributors Sankarshan Mukhopadhyay (QBF Consulting) and the DTGWG participants; abstract listing the seven types flat, the VSC “with its first two predicate profiles” the VEC and VWC; IPR (CC BY 4.0, W3C patent mode, Apache 2.0)
  • intro.md — the seven credential types as a flat list, with one sentence of grouping (“the first three are edge credentials … the other four are each complete on the issuer’s signature alone. That is the only grouping this specification makes”); Related Specifications now naming two published companions — Trust Tasks (dtgwg-trust-tasks-spec) and VTI (dtgwg-vti-spec) — two planned ones (DTG Core Trust Task Protocols, DTG Verifiable Data Structures: r-card, agent card) and the DTG VSC Predicate Registry (dtgwg-vsc-registry, “a repo-driven registry rather than a specification”); and the Specification Versioning section (#54) defining the _Version:_ / _Document Status:_ split, Compatibility Rules and the ratification lifecycle
  • terms-and-definitions-intro.md + terms-definitions/*.md — ~51 glossary terms, one file each. WD02 deleted community_did, membership_did, relationship_did, persona_did and added correlation_scope, verifiable_authority_credential, verifiable_delegation_credential; main adds verifiable_statement_credential, deletes dtg_annotation_credential (#55) and rewrites the VEC/VWC/VPC/VAC entries. The VTA topology vocabulary (personal / community / local / cloud VTA, VTA networks, PNM, PNV, VTSP — see vta-topology) and community roles (initiator, CTA, PEP, IDVP/IDVC) are unchanged
  • body.md — the normative core, in narrative order: Taxonomy (no diagram since #55; “every concrete type is a direct subtype of DTGCredential”) → W3C VC version support (v2.0 primary, v1.1 legacy) → Correlation Scope (with Roles are conferred by credentials, Choosing a scope, Scope the holder cannot declare alone, and Declaring scope — the issuerScope rationale) → Base Structure (@context order and exact-bytes comparison, issuerScope, taskContext, taskDigestMultibase, proof as DataIntegrityProof; Context Versions with the pinned v1 digest; informative DID Method Considerations; normative Digest Encoding, now covering six members) → Edge Credentials as a class (VRC, VMC with Membership Edge Completion, VDC with Delegation Edges / Chains / Invocation Binding, Edge Verifiability) → VIC → VPC → VSC (Statements and Establishment, Predicate Handling, What Verification Establishes, Predicate Profiles — nine required members, Statements in the Graph, the dtg:endorses (VEC) and dtg:witnessed (VWC) profiles by reference to the registry, Community-Defined Predicates with a Worked Example: An Identity Vetting Predicate) → VAC (Attenuation, Invocation, Withdrawal, Authority is not delegation, Relationship to the VDC, Authority and membership are separate credentials) → Trust Task Context Binding (Credentials versus Trust Task Artifacts, taskContext, taskDigestMultibase, Outcome Interpretability) → Supporting Concepts (PHC, Trust Registries, IDVC, ZK & Selective Disclosure) → Security (grouped: every credential / membership and invitation / delegation / authority) / Privacy / Governance / I18N / Accessibility Considerations → Conformance (issuer / holder / verifier targets) → References (Normative now includes the DTG VSC Predicate Registry with its three IRIs)
  • appendix.md — acknowledgements
  • design-notes/delegation-design-time-window.md (non-normative) — the rationale record for the VDC as merged, and what WD02 did not take from the August single-hop proposal
  • CONTEXT.md — an LLM/contributor style guide with per-term “avoid” lists; a useful quick reference for current terminology
  • README.md — now also carries the house style: Working Drafts are numbered with semver, RFC keywords bind only in normative sections, and (#65) spec prose never cites a GitHub issue, PR or discussion number — “those are process artifacts … and mean nothing to a reader who wasn’t in the room”

Wiki pages derived from this spec

  • credential-categories — The functional categories; dropped as informative groupings in #55 (2026-09-22). Only Edge Credentials survives, as a normative class (VRC, VMC, VDC); the other four types are “each complete on the issuer’s signature alone”
  • correlation-scope — The holder-declared scope (pairwise | directed | public), carried since #68 as the REQUIRED issuerScope property
  • statement-credential — The VSC: one type, a governed predicate IRI, an object of exactly one kind; the VEC and VWC are its first two profiles, defined in the registry
  • authority-credential / delegation-credential — The VAC (confers; attenuable, maxAttenuation, Invocation, Withdrawal) and the VDC (appoints; grant + acceptance; “moves the permission question, does not answer it”)
  • did-types — The formal DID taxonomy (C-DID, M-DID, R-DID, P-DID) — retired in WD02 in favor of correlation scope; page needs rewriting
  • trust-task-context-binding — taskContext: binding a credential to the exchange that produced it, without making it proof of the outcome
  • vta-topology — The VTA vocabulary: personal / community, local / cloud, VTA networks, PNM, PNV, VTSP
  • trust-registries — Governance layer that determines PHC status and policies
  • verifiable-trust-network — VTN concept; WD02’s Edge Verifiability makes the VTN one example of a verifier’s anchor set rather than a precondition
  • witnessed-vrc-exchange — The five-phase witnessed exchange protocol (supporting material in the task-force repo; its per-direction VWC pattern is normative, now for VMC pairs too)
  • witness-credential — VWC: the dtg:witnessed profile (https://registry.trustoverip.org/dtg/vsc/witnessed/1); requires taskContext and taskDigestMultibase, its object is the witnessed edge credential’s digest, one VWC per direction SHOULD be issued; members defined by the registry entry since #71
  • endorsement-credential — VEC: the dtg:endorses profile (https://registry.trustoverip.org/dtg/vsc/endorses/1); the role-conferring use it once carried belongs to the VAC
  • trust-task-context-binding — taskContext is the id of the innermost attesting exchange’s initiating document (not a threadId, corrected in #56), and taskDigestMultibase binds the credential to that document’s task digest
  • persona-credential — VPC and the “Banksy Maneuver”; the persona identifier is now “ordinarily declared directed”
  • invitation-credential — VIC with issuer policy details; now a top-level section outside the categories
  • membership-credential — VMC; both directions now specified, the acknowledgement carries digestMultibase of the grant
  • relationship-credential — VRC; pairwise RECOMMENDED, Edge Verifiability defined per-verifier
  • zero-knowledge-proofs — Pairwise vs community-anchored ZKP constructions; ZKPs by default; new predicates for chains, shared-subject and statements
  • decentralized-identifiers / did-webvh — WD02’s DID Method Considerations: durable vs narrow-scope identifiers, did:webvh in examples, portable caveat
  • Plus updates to personhood-credential, dtg-credentials-overview, decentralized-trust-graph, verifiable-trust-community, and others
  • trust-tasks — the companion framework the spec now depends on for naming and binding a cited exchange and for outcome evidence
  • Not yet in the wiki: the DTG VSC Predicate Registry (dtgwg-vsc-registry) has no entity page, although the spec now depends on it normatively for the two core profiles and the frozen @context

Recent Development

The spec is at v1.0, Document Status Working Draft 0.6.0 on main (HEAD #71, 2026-09-30); the last tags are v0.5.0 (09-22) and v0.4.0 (09-15), with WD02 (09-07) the last ordinal draft. Activity is per-PR. Entries before July 2026 refer to PRs in the old dtgwg-cred-tf repo.

Normative delta WD02 → 0.6.0, at a glance

For an implementer coming from the WD02 tag, these are the changes that alter what is on the wire or what a verifier must do; everything else since the tag is editorial. The dtg-credentials crate implements all of them as of 0.12.0, except that credentialStatus resolution remains the caller’s.

  1. @context is ["https://www.w3.org/ns/credentials/v2", "https://registry.trustoverip.org/dtg/context/v1", …] — W3C first, DTG second, compared as exact bytes; firstperson.network/credentials/dtg/v1 is not recognized. The v1 document is byte-frozen and its digest pinned (zQmSWyCagdx8oPfXn3piSUx6yqVy5MZ7ZG7nW1TC64QvKZh); verifiers SHOULD verify against a local copy and SHOULD NOT dereference. Later contexts MUST NOT redefine a protected DTG term. Credentials issued before the Implementers Draft are non-conformant whatever context they list (#64, #68).
  2. issuerScope (string, REQUIRED): exactly one of pairwise | directed | public, case-sensitive, declaring the scope of the identifier in issuer only; a verifier MUST reject a credential whose issuerScope is absent or invalid; all credentials under one identifier MUST declare the same scope; a credential MUST NOT restate another identifier’s scope. A community-issued VMC can only truthfully declare public (#68).
  3. Type strings: EndorsementCredential and WitnessCredential are removed; StatementCredential is added, carrying credentialSubject.predicate (an absolute IRI, byte-compared, no CURIEs or expansion) and object (exactly one of id | digestMultibase | value). Verifiers fail closed on any predicate not in their configured accept set and never follow equivalences (VSC commit of 09-15; #64 for the IRIs).
  4. The two core profiles are https://registry.trustoverip.org/dtg/vsc/endorses/1 (VEC) and https://registry.trustoverip.org/dtg/vsc/witnessed/1 (VWC), their members defined normatively by the DTG VSC Predicate Registry, which is a Normative Reference. The VWC’s object is the witnessed edge credential’s digest; its subject MUST be that credential’s issuer; one VWC per direction SHOULD be issued (#64, #70, #71).
  5. taskContext is the id of the document that initiated the innermost attesting exchange (WD02 said threadId). taskDigestMultibase is REQUIRED wherever taskContext is REQUIRED (so on every VWC) and SHOULD accompany an optional taskContext: the task digest of that document with its top-level proof removed, SHA-256 + base-58-btc as for every other digest. Outcome interpretability now delegates the outcome-evidence checks to the Trust Tasks specification; minimum companion Document Status 0.4.0 (#56).
  6. proof MUST be a DataIntegrityProof with the suite in proof.cryptosuite; eddsa-jcs-2022 RECOMMENDED (no @context resolution at verification; same canonicalization as the digests). Selective disclosure is carried by other mechanisms, not this property (#56).
  7. VAC: authority.audience removed; authority.maxAttenuation OPTIONAL (0 forbids attenuation, a child MUST NOT exceed its parent’s value minus one); a verifier MUST NOT accept a party as holding a VAC’s authority without proof of control of the leaf’s credentialSubject.id; credentialStatus MUST be checked on every chain link that carries one and its absence MUST NOT be treated as a defect; revocation cascades to every attenuation (#39–#41).
  8. Categories: the Edge / Invitation / Annotation grouping is gone from schemas, glossary and taxonomy; Edge Credentials remains as a normative class — “a statement that would need the counterparty’s agreement to be true is an edge credential, not a VSC predicate profile” (#55).
  9. Digest Encoding now governs six members: the member-issued VMC’s digestMultibase, a VSC’s object.digestMultibase, a VDC’s delegation.parent and delegation.accepts, a VAC’s authority.parent, and taskDigestMultibase (#56, #64).
  10. Document Status follows semver; a holder/verifier conformant to M.N MUST accept credentials issued under M.K, K ≤ N, and SHOULD tolerate unknown OPTIONAL properties. Pre-ratification, a new REQUIRED property may ship as a MINOR — which is how #68 is 0.6.0 rather than 1.0.0 (#54).

main 2026-09-22 → 09-30 — issuerScope named, the registry IRIs decided, taskDigestMultibase, categories dropped, title settled (#50, #55, #56, #59–#65, #67–#71)

Fifteen commits in nine days, by four authors (Gore, Turk, Miller, and dependabot). The thread running through them is that decisions deferred in WD02 — what is the property called, where do predicates live, which namespace — were taken, and the draft stopped hedging.

  • #56 — 2026-09-22 — taskContext bound to the published Trust Tasks mechanisms; proofs are Data Integrity. The credential-side half of a split with the Trust Tasks specification (issue #18). taskContext is the id of the innermost attesting exchange’s initiating document, per Trust Tasks’ “Naming an Exchange from Outside the Framework” — Base Structure had said threadId, which contradicted that published rule. New taskDigestMultibase, REQUIRED wherever taskContext is: the witness/session/submit and vetting/session registry specifications already required it on the credential and said its schema belonged here. Outcome Interpretability keeps its MUST NOT and points at Trust Tasks’ outcome-evidence checks and at VTI for what a relying party may conclude across a composition; the holder conformance item follows (present the outcome evidence with the credential). Related Specifications lists Trust Tasks and VTI as published companions, resolving #11. proof is a DataIntegrityProof, suite in proof.cryptosuite, eddsa-jcs-2022 RECOMMENDED; the ZK section no longer calls the spec format-agnostic without qualification.
  • #50 — 2026-09-22 — identity vetting as a worked statement profile (informative). Peer identity vetting “is a record of a procedure … not an endorsement and not a witnessing, so it gets a predicate of its own rather than borrowing one.” The payload an earlier draft carried in a VEC’s endorsement body becomes the statement’s object.value unchanged; the example is defined in a community namespace to show how a community defines a predicate of its own, and exercises every member the profile rules require (identityCommitment, cardDigestMultibase, …). #70 (09-30) then aligned it with the registry’s vetted/1 — camelCase enumerations, taskDigestMultibase added, attestationTextDigest optional — naming the registry entry as the normative definition and the community IRI as the illustration. See peer-identity-vetting.
  • #55 — 2026-09-22 — the informative credential categories are dropped; Edge Credentials kept as a class. Resolves the categorization question in #28. The test applied: “a grouping earns a heading only if the specification says something about the group that it does not say about each member.” Edge credential passes (Edge Verifiability, the profile-versus-type test, the dtg:witnessed profile and three glossary entries all depend on it); Annotation credential fails (a one-sentence preamble, and its only other use was the VAC explaining why it was not in it). Introduction and abstract list the seven types flat; the mermaid taxonomy diagram goes; the Edge Credentials preamble states the bilateral test once; VPC and VSC become top-level sections; the glossary entry DTG annotation credential is deleted. No schema, type string or @context change.
  • #59, #60, #61, #62, #63 — 2026-09-22/25 — housekeeping with consequences. Document Status 0.4.0 → 0.5.0 (#59; tag v0.5.0), editors alphabetized and Linux Foundation affiliations updated; the title settled as “DTG Credentials Core Specification” in the header and specs.json (#61, #62 — README and header had been naming the document differently); Glenn Gore moves from contributors to editors (#63).
  • #64 — 2026-09-28 — the DTG namespace placeholder is replaced by the decided registry IRIs (closes #48). Three namespaces, each versioning differently: predicates at https://registry.trustoverip.org/dtg/vsc/<name>/<n> (flat per-predicate integer versioning, “each <name>/<n> immutable and distinct”); vocabulary — types and properties such as DTGCredential and taskContext — at the unversioned https://registry.trustoverip.org/dtg/credentials# (a changed meaning is a new term, not a new version); and the credential @context at https://registry.trustoverip.org/dtg/context/v1, one frozen document per vN. All hosted by the DTG VSC Predicate Registry (dtgwg-vsc-registry). Every example and the Base Structure schema line swap to the new context; the two worked profiles move to their versioned IRIs.
  • #65, #67 — 2026-09-28 — style. Every GitHub issue/PR/discussion citation is removed from spec prose and restated as fact or a named dependency, with a README rule so it “doesn’t need re-deciding next time” (#65); prose is unwrapped to one line per paragraph (#67). #69 bumps spec-up-t 1.9.0 → 2.3.0.
  • #68 — 2026-09-28 — the correlation-scope declaration is named issuerScope; the v1 context is pinned; Document Status 0.6.0. The property WD02 #30 left unnamed, per the decision in #46: issuerScope, REQUIRED on every DTG credential, carrying the issuer’s declaration (pairwise, directed or public); verifiers reject a credential without a valid value. The new Declaring scope subsection records why the credential and not the DID document carries it — a did:key or did:peer numalgo-0 document is derived from the identifier and has nowhere to put a property, and those are exactly the methods recommended for pairwise and directed identifiers — and its two consequences: all credentials under one identifier MUST declare the same scope, and a credential MUST NOT restate any other identifier’s scope (so until a grant is acknowledged the member’s scope is simply undeclared). Every example carries it; the “not yet defined” hedges are gone. New Context Versions subsection: the exact IRI form and @context order, the v1 digest pinned as a base-58-btc Multihash over the bytes the registry serves, verifiers SHOULD keep a checked local copy and SHOULD NOT dereference, the protected-terms rule for later contexts (a profile needing a term of its own picks a name the DTG context does not define), profile members living in the core context (so adding one is a new context version), and pre-Implementers-Draft credentials out of scope. The planned “DTG Predicate Vocabulary” is renamed to the DTG VSC Predicate Registry, which now exists. A new REQUIRED property is a breaking change, released as a MINOR under the pre-ratification clause: Working Draft 0.6.0.
  • #71 — 2026-09-30 — the two core profiles are defined by the registry. The dtg:endorses and dtg:witnessed sections say what a VEC and a VWC are and refer to the registry entries endorses/1 and witnessed/1 for the profiles’ members, which the registry now defines normatively; headings, anchors, the VEC/VWC names and both examples stay, and nothing on the wire changes. The “where profiles live” editor’s note becomes an informative note on the steady state — “the registry is not tagged, and serving the IRIs was the real gate.” Review kept the one-VWC-per-direction SHOULD in the spec, because the registry’s governance treats its profile.md as prose rather than a normative member; and the registry enters the Normative References with its three IRIs.

What is still open on main. No tag for 0.6.0 yet. The outcome-evidence minimum companion version is recorded as “the first Document Status of [Trust Tasks] that defines outcome evidence for a cited exchange” — pending. A committed (ZK-openable) form of the taskContext / taskDigestMultibase citation is “under consideration”, because the two members link every presentation of a credential even when the rest is proven in zero knowledge. The VDC’s Invocation Binding still defers how key control is demonstrated to the planned DTG Core Trust Task Protocols. And the specification names only two core predicates; vetted/1 and presented/1, which dtg-credentials also implements, are registry entries the spec does not mention (beyond the vetting example’s pointer).

main after WD02 — 2026-09-10 → 09-15 — the VAC hardened, the VIC promoted, the VSC arrives, and Document Status goes semver

Ten days after the WD02 tag, seven substantive changes landed on main. At the time none was in a tagged draft and dtg-credentials had not implemented them; #54 became tag v0.4.0, and the crate caught up in 0.12.0 (2026-09-30).

  • #54 — 2026-09-15 — semantic versioning for Document Status. _Version:_ (1.0) is now the release the group is converging toward and moves only at ratification; _Document Status:_ carries the Working Draft’s own semver, Working Draft 0.4.0 — continuing from the pre-migration v0.3 rather than restarting at 0.1.0, so that “01”/“02” are not mistaken for 0.1/0.2. New Compatibility Rules (MAJOR for breaking, MINOR for additive, PATCH for editorial; a pre-ratification escape clause lets breaking changes stay MINOR while MAJOR is 0; a holder/verifier conformant to M.N MUST accept credentials issued under M.K, K ≤ N, and SHOULD tolerate unknown OPTIONAL properties) and a Ratification and Stable Release Line subsection, shared with the sibling Trust Tasks and VTI specs. Also corrects the taskContext binding’s minimum companion version to Trust Tasks Document Status 0.4.0.
  • Commit 5a660ea — 2026-09-15 — the Verifiable Statement Credential (VSC) (refs #45, #28, #48, #52; not a numbered PR). The problem: each new “I attest X about Y” predicate was becoming its own credential type, and a type string and a payload could disagree. The fix: one StatementCredential type carrying credentialSubject.id (subject), predicate (an absolute IRI from a governed vocabulary — no CURIEs, no JSON-LD expansion, NFC, byte-exact comparison) and object (exactly one of id | digestMultibase | value). The VEC and VWC become its first two predicate profiles, dtg:endorses and dtg:witnessed; the type strings EndorsementCredential and WitnessCredential are removed. Three new normative subsections: Predicate Handling (verifiers fail closed on any predicate not in a configured vocabulary; equivalences like owl:sameAs are never followed; predicates resolve at configuration time, never at verification), What Verification Establishes (a VSC attests and never establishes — “a predicate named mayActFor is a string”), and Predicate Profiles (the nine things a profile must state). The VWC’s direction binding becomes unconditional: credentialSubject.id MUST be the issuer of the credential named by object.digestMultibase. Type count: eight → seven. The dtg: namespace (https://firstperson.network/credentials/dtg/v1#) is a placeholder pending #48; predicates beyond the core profiles will live in a DTG Predicate Vocabulary registry (#52). Governance gains “which vocabularies a verifier accepts is a governance decision”; a new Security item 7 (Predicate acceptance).
  • VIC promoted to a top-level section — 2026-09-10 (closes #28; decision D-B of #31). “Invitation Credentials” had exactly one member. The categories are now two — Edge (VRC, VMC, VDC) and Annotation (VPC, VSC on main) — with the VIC and VAC standing outside both: neither forms an edge nor annotates one. No normative change; abstract and CONTEXT.md follow (#7ca543c).
  • #41 — 2026-09-10 — a VAC is not a bearer credential. New Invocation subsection: a verifier MUST NOT accept a party as holding a VAC’s authority unless it demonstrates control of the presented VAC’s credentialSubject.id at the time of the request — the same rule the VDC already had, and sharper here because a captured presentation is a captured chain. Only the leaf’s subject demonstrates anything. Consequently the OPTIONAL audience property is removed: once the presenter must be the subject it can only repeat the subject or be unsatisfiable. New Security item 21 (Bearer use of a VAC), and Conformance Target 3 gains the key-control rule.
  • #40 — 2026-09-10 — a governing party can bound or forbid attenuation. New OPTIONAL authority.maxAttenuation: 0 forbids attenuation outright; a child MUST NOT bear a value greater than its parent’s minus one; the effective limit is the strictest on the chain. The section now argues why attenuation is opt-out while re-delegation is opt-in: forbidding attenuation doesn’t stop a holder equipping an agent, it makes them lend their key. Deliberately not called maxDepth (which fails closed on a VDC). Also new: a governing party MAY require the subject of an attenuated VAC to independently qualify (the authority-side twin of the VDC’s third check) — Governance item 8.
  • #39 — 2026-09-10 — how authority is withdrawn from a VAC. New Withdrawal subsection: expiry is the primary mechanism (validUntil REQUIRED), credentialStatus is CONDITIONAL on the governing party’s freshness window (mirroring the VDC), only a VAC’s issuer can revoke it, a verifier MUST check status on every chain link that carries one and MUST NOT treat its absence as a defect, and revocation cascades — revoking a VAC withdraws everything attenuated from it, which is what makes unregistered attenuation safe. The converse is stated: a chain with no status cannot show an ancestor was revoked, so exposure is bounded by the shortest validUntil. Security items 20 and 22, Privacy item 14 (a root’s status list observes the timing of agents the governing party never issued to), Governance item 7.
  • #42 — 2026-09-10 — what the ZK predicates are waiting on. The Zero-Knowledge section now says plainly that four of its predicates rest on one unbuilt primitive — a proof of common control of two credentials or identifiers (#9) — which carries the community-anchored ZKP wherever VMC and VRC identifiers differ (the ordinary case under correlation scope), the shared-subject requirement, and ZK forms of both chains; the unsalted digest binders are #38. It points at the ZKP task force’s working draft and construction catalog (records 007, 010, 020, 008) and states that nothing in the spec is unverifiable meanwhile — “the cost is privacy rather than correctness.”

WD02 — 2026-09-07 — Working Draft 02 (#44), the merge sequence #12 → #20 → #16 → #27 → #26 → #30 → #19 → #29

The tag sits on the status-line bump (#44) after five PRs landed in three days (#27, #26, #30, #19, #29), on top of three from late August (#12, #20, #16). A caveat on the tags: both WD01 and WD02 were created retroactively on 2026-09-07, and WD01 was placed at #37 (2026-09-05) — so the tagged WD01..WD02 diff contains only the five September PRs, while #12, #20 and #16 (all merged after the wiki’s last refresh recorded WD01 at PR #14) are technically inside the WD01 tag. This log treats all eight as the WD01 → WD02 delta, since that is what changed for implementers. Infrastructure PRs in the same window: spec-up-t 1.9.0 (#33), Dependabot (#32), Actions pinned to SHAs (#37), README backlink (#34).

PR #29 — 2026-09-07 — the Verifiable Authority Credential (VAC)

The catalog had six credentials and none conferred permission, so implementations were packing authority into a VEC — putting a decision that belongs to the governing party into a claim that reads as reputation. The VAC is “a statement to a verifier” rather than about a party: issuer governs a scope, credentialSubject.authority carries scope (DID or URI; exact match unless the governing party publishes containment) and actions (non-empty; empty confers nothing; no action implies another). Attenuation is what earns its place: a holder MAY issue a narrower VAC — issuer MUST be the parent’s subject, authority.parent is the parent’s digest, no new actions, no later validUntil, no wider scope — so a person’s AI agent can carry four hours of read-only access instead of the person’s standing authority. Verifiers MUST walk the whole chain to a VAC from the governing party and reject any widening link; the holder presents the chain, the verifier never fetches it; depth capped at 8. validUntil REQUIRED. Two rules recorded where implementers will meet them: authority is not delegation (a VAC never authorizes acting on behalf of another) and authority and membership are separate credentials (proving both in ZK with the subject withheld MUST include a shared-subject proof, else two parties pool credentials). Placed as a top-level section outside the three categories rather than a single-member fourth category. Also resolves the VIC editor’s note: roles and access control do not belong in the invitation. Security items 15–18, Privacy item 13 extended. (WD02 shipped with an OPTIONAL audience; removed on main by #41.)

PR #19 — 2026-09-06 — the Verifiable Delegation Credential (VDC) and the digestMultibase encoding

The glossary already assumed delegation (“the person it identifies (or their delegate)”), AI agents are first-class nodes, but nothing could say an agent may act for a person. The VDC is the seventh type and third edge credential: issuer = delegator, credentialSubject.id = delegate, credentialSubject.delegation carries scope (non-empty, opaque strings compared for exact equality), optional parent (digest), optional maxDepth (absent or 0 prohibits re-delegation — single-hop by default), and, on the acceptance, accepts (digest of the grant). A grant plus a matching acceptance forms the edge, and the acceptance is REQUIRED — the same consent logic as the VMC pair: a delegator cannot forge the countersignature. The spec draws the line hard: delegation is not authority. A VDC “moves the permission question; it does not answer it” — the verifier substitutes the delegator and asks whether the delegator may act; reach is the intersection of the appointment and the delegator’s own permission; nothing the delegator holds is copied. validUntil REQUIRED; credentialStatus CONDITIONAL (required only where validity exceeds the governing freshness window — short validity and re-issuance is the preferred default, because a status lookup is a correlation surface). Invocation Binding: a VDC is not a bearer token — the presenter MUST demonstrate control of credentialSubject.id. Grant vs invocation is split by the spec’s own credential/artifact test (the invocation is a Trust Task artifact). Security items 9–14 (incl. personhood laundering via delegation), Privacy items 10–13, Governance items 5–6. A design note records the August single-hop-only proposal and what WD02 did and didn’t take from it.

The same PR added the normative Digest Encoding section: every cross-credential reference — the member-issued VMC’s and the VWC’s digestMultibase, the VDC’s parent/accepts, the VAC’s authority.parent — is the SHA-256 of the referenced credential’s JCS canonical form excluding its top-level proof, wrapped as a sha2-256 Multihash and base58btc-encoded with the z Multibase prefix, exactly as VC Data Integrity §2.6 defines digestMultibase. This replaces WD01’s bespoke sha256:<lowercase hex> and renames the VWC/VMC property digest → digestMultibase. Verifiers MUST compare decoded bytes, never strings; a digest naming an unaccepted hash algorithm MUST be rejected rather than treated as a mismatch. Excluding proof means a re-signed grant still satisfies an existing acknowledgement. An editor’s note records that none of the digests is salted (#38). Note the irony for dtg-credentials: the crate’s original 0.2.0 divergence was that it emitted exactly this multibase form; WD02 moved to the crate’s encoding (minus the proof), not the other way round.

PR #30 — 2026-09-05 — the four VID types are replaced by a declared correlation scope

Resolves #22 and cred-tf discussion #41. R-DID, M-DID, C-DID and P-DID each packed two independent things into one name — what the identifier is attached to and how widely it may be correlated — and the two disagree as soon as an M-DID appears in a VRC (which the VRC section permitted). The role is already carried by the credential the identifier appears in; only the width needs declaring. So: a VID MAY carry a holder-declared correlation scope, one of three ordered values — pairwise (one counterparty), directed (a set the holder chooses — the ordinary home of a persona), public (unbounded; a VTC’s identifier can only truthfully be public). “Roles are conferred by credentials; scope is declared by the holder.” Three values not four: a community-bounded value would take its bound from a credential rather than the holder — the exact conflation being removed. New normative subsection Scope the holder cannot declare alone: a VTC issuing VMCs MUST publish whether member identifiers are disclosed beyond the VTA, and a verifier MUST NOT infer from a member’s pairwise declaration that the community treats it so. Under strict pairwise, the identifier toward the VTC and toward a counterparty differ by construction, so the community-anchored ZKP must prove common control — members expecting to prove such relationships will in practice declare directed. The property that carries the declaration is not yet named; until it is, no credential is non-conforming for lacking one. Four glossary entries deleted outright; CONTEXT.md now lists R/M/C/P-DID under Avoid. Reflected (as stale) in did-types.

PR #26 — 2026-09-05 — Edge Verifiability defined normatively

Fixes #21, reported independently by two implementations: the conditions for a VRC being “verifiable as a DTG edge” lived only in the glossary, contradicted the body, and one (both peers signing one VRC) was unsatisfiable by any credential. New normative section: an edge credential is verifiable as a DTG edge by a given verifier when its proof verifies and the verifier can establish, per Membership Edge Completion, that the issuer’s membership in a VTC in the anchor set that verifier accepts is complete. A VTN is the common anchor set but need not exist. Condition 2 MAY be met by disclosure or by proof (community-anchored ZKP), and the two are equivalent in principle — a pairwise did:peer VRC with a valid proof is an edge on the same terms as one issued from the VMC’s own identifier. Each half is evaluated independently. Glossary VRC/VMC entries reduced to pointers. Bears on verifiable-trust-network and relationship-credential.

PR #27 — 2026-09-05 — effective disclosure of an edge

Addresses #23. A declared scope binds only its holder; the effective disclosure of an edge is the wider of its two halves — a correctly pairwise half is still correlated to a named party if the counterparty published the opposing half under a directed/public identifier. Generalised to any joint presentation. Privacy item 9.

PR #12 — 2026-08-28 — both VMC directions specified, so membership requires member consent

Issue #8 flagged a structural contradiction: five places said two VMCs form an edge, but the schema made the reverse credential unconstructible. The two directions are now distinguished by issuer/subject rules and by the presence of a digest, not by type strings: the community-issued VMC (grant) goes from the VTC/VTN to the member; the member-issued VMC (acknowledgement) reverses the roles and carries a digest of the grant. New Membership Edge Completion subsection: the grant MUST be issued first; an acknowledgement whose digest matches no valid grant MUST NOT complete the edge; where anyone other than the member asserts membership the verifier MUST require the acknowledgement, and a community asserting membership MUST be able to produce it — the acknowledgement is the member’s consent artifact, which makes unconsented membership claims unprovable. Deliberately direction-sensitive: a member presenting their own grant with proof of key control MAY be accepted alone (the presentation is the consent), which is what keeps the community-anchored ZKP and PHC constructions working. Per-direction witnessing generalised from VRCs to both edge subtypes. Lifecycle (withdrawal, revocation, re-issuance) deferred to the Trust Task Protocols spec, with two interim controls via short validUntil. Security item 7; Privacy item 8 (the acknowledgement as a disclosure artifact the community holds). Reflected in membership-credential.

PR #20 — 2026-08-27 — did:webvh in examples; DID Method Considerations

Examples switched from did:web (no verifiable history, no recovery on compromise) to did:webvh for durable issuers; subjects stay on did:key/did:peer. New informative DID Method Considerations: the spec mandates no method but says what it relies on one for. Durable identifiers (a VTC’s, a member’s, a witnessing VTA’s) need verifiable key history, rotation without changing the identifier, pre-rotation, independence from a single operator (note: did:webvh is relocatable only if portable was set in the first log entry; did:scid avoids the choice), and discoverable endpoints. Narrow-scope identifiers need cheap creation, no shared resolution origin, and no infrastructure that observes their use — so a DID log witness set or a shared web origin is itself a correlation channel (Privacy item 4). Durability and scope are independent axes; expect to mix methods. Bears on did-webvh and decentralized-identifiers.

PR #16 — 2026-08-28 — abstract rewritten for readability

dtgwg-cred-tf #38 — 2026-08-18 — old repo retires its copy of the spec

dtg.md removed; README points to dtgwg-cred-spec as the normative home and to its issue tracker for spec issues. use_cases.md and witnessed_vrc_flow.md (v0.2, non-normative) stay as supporting material; discussions remain in the old repo.

PR #14 — 2026-08-12 — VWC digest becomes REQUIRED, binding the credential to a specific edge

With only issuer, taskContext and credentialSubject.id required, a conforming VWC could attest merely that some activity involving the subject occurred during a trust task — not that a specific relationship edge was established. digest is promoted OPTIONAL → REQUIRED. New guidance: credentialSubject.id and taskContext identify only the observed party and the exchange, not the edge; a digest without the referenced VRC to hand is an opaque hash, so issuers and holders presenting a VWC as evidence of a specific edge SHOULD make the referenced VRC available alongside it. witnessContext stays OPTIONAL. Reflected in witness-credential.

PR #13 — 2026-08-06 — narrative ordering; status set to Working Draft 01

Taxonomy diagram flipped to left-to-right in the order VRC, VMC, VIC, VPC, VWC, VEC; the VWC section moved before VEC under Annotation Credentials; header status “Working Draft” → “Working Draft 01”. No normative text changed.

PR #7 — 2026-07-30 — implementation feedback from Keyring Wallet: VWC digest canonicalization + per-direction witnessing

Two fixes driven by a real implementation (Keyring Wallet’s witness server): (a) v0.3 said the digest was “a multibase string (multihash + multibase)” while its example showed sha256:<hex> — contradictory and unimplementable. WD01 settled on: the digest MUST be the SHA-256 of the credential’s JSON canonicalised with JCS (RFC 8785), encoded as the string sha256: followed by the lowercase hex digest. (b) Per-direction witnessing: a witnessed exchange of a complete edge is bidirectional — two VRCs, one each way, in a single witnessing event — so the witness SHOULD issue one VWC per direction, and in each VWC credentialSubject.id MUST be the DID of the issuer of the VRC being attested. The dtg-credentials crate (0.2.0) at the time encoded the digest as a multibase/multihash (z…) instead — a flagged divergence that the crate fixed in 0.4.0 by adopting the hex form, only for WD02 (#19) to move the spec itself to the multibase digestMultibase encoding (minus proof), which the crate then adopted in 0.7.0. The encoding question is now closed on both sides.

PR #3 — 2026-07-13 — migrate v0.3 into the Spec-Up-T template (Working Draft)

Beyond the re-templating, several substantive changes:

  • New normative section “Trust Task Context Binding” and a new base-structure property taskContext (the threadId of the trust-task exchange in which the credential was issued): OPTIONAL on all types, REQUIRED on VWC. A credential without taskContext MUST be interpretable standing alone; a verifier MUST NOT treat a taskContext-bearing credential as proof the associated task completed unless the matching outcome evidence is present and verified. Informative test: “true outside the exchange? → credential; only meaningful inside? → artifact.” See trust-task-context-binding.
  • W-DID dropped from the identifier taxonomy — the VWC issuer is “an M-DID, or the DID of a VTA acting according to VTC policy”; four official DTG identifier types remain (R-DID, M-DID, C-DID, P-DID). Reflected in did-types. (All four were themselves retired in WD02.)
  • RCard section removed; the relationship card is a VDS, not a DTGCredential, and moves to the planned DTG Verifiable Data Structures spec (alongside a planned agent card). The category count accordingly drops four → three (VDS gone). Reflected in credential-categories, dtg-credentials-overview.
  • VWC purpose broadened (the witness may be a person or a VTA applying VTC witnessing policy — e.g. same-event presence, biometric liveness); VIC explicitly has two functional variants — VTC invitation and VTN invitation — distinguished by issuer/subject rules, not type strings; VPC purpose adds “control intentional correlation across relationships”.
  • New Security Considerations (7 items — incl. VIC replay: short validity, single-use at the accepting VTA/PEP), Privacy (2 → 6 items), Governance (4 — “whether a VMC qualifies as a PHC is a governance determination, not a schema property”), Conformance targets (issuers / holders / verifiers; no test suites yet), I18N/Accessibility stubs, normative/informative references.
  • ZKP text, PHC, trust registries, IDVC carried over unchanged in substance from v0.3 (post-#31/#33). ~50 glossary terms imported as Spec-Up-T definitions.

PR #2 / #1 — 2026-07-07/08 — repo created from the Spec-Up-T template; README for DTG Core Credentials V1.0

PR #33 — 2026-05-08 — Split VRC/VMC ZKP proofs into pairwise and community-anchored constructions

  • The old single “Zero-Knowledge Proof Requirements” subsection (under VRC) is replaced by two distinct constructions:
    • Pairwise ZKP (under VRC §5.1) — available to any two VRC holders, regardless of shared community membership; selectively discloses P-DIDs while hiding R-DIDs
    • Community-Anchored ZKP (under VMC §5.2) — requires both parties to hold VMCs from the same community; the three-part proof (VRC + VMC + same C-DID) is preserved but reframed as one option among several
  • Section 5 reordered: VRC (5.1) now precedes VMC (5.2)
  • Overview rewritten: DTG credentials are W3C-compliant VCs that MAY use standard presentation but SHOULD use ZKPs whenever privacy preservation is desired (citing Adler et al. 2024 — Personhood Credentials)
  • New guidance: implementations SHOULD make ZKP presentation the default
  • Privacy Considerations gained a “ZKPs by default” bullet
  • Reflected in zero-knowledge-proofs, relationship-credential, membership-credential, persona-credential, credential-categories, dtg-credentials-overview

PR #31 — 2026-04-30 — Bidirectional Edge Credentials

See also: dtg-credentials (the Rust implementation), dtg-credentials-overview (the credential taxonomy as currently in the wiki).

Graph View

Backlinks