W3C Verifiable Credentials / DID Compatibility Layer

    Context and Problem Statement

    Status: deferred-named. This ODR is created as a placeholder stub per Scope-Check 1 (2026-05-26) Q7c verdict (8-1 NAME the work; 2 strong spawn-now from Davis and Pandit; others “name-but-defer”). Activation triggers are named below in ## Rules. The session ratifying this ODR (Session 016) does not run in Phase 1.

    PDTF carries the word Trust in its name and ships a verifiedClaims envelope shaped after OIDC4IDA / eIDAS. The PDTF business glossary names Claim, Issuer, Holder, Verifier, Trust Framework — the W3C Verifiable Credentials Data Model 2.0 and DID Core 1.0 lexicon. ODR-0009 (Claims, Evidence & Provenance) cites the W3C VC family by reference and asks (Q8) whether opda:Claim is cred:VerifiableCredential-compatible, but does not ratify a binding.

    A property-data Trust Framework that publishes its claims without committing to the VC data model and DID resolution patterns produces an ontology that the actual external consumers — EU eIDAS 2.0 wallets, gov.uk OneLogin, W3C VCDM 2.0 implementations, ToIP-aligned issuers — cannot consume. ODR-0009 is correct to defer the binding in the schema-to-ontology round, but the deferral is not free: by the time Phase 4 closes (Claims + Governance), the cost of not having a VC/DID alignment record rises sharply because consent receipts (Pandit’s Phase-2 ambition) are W3C VC-shaped at every level.

    The scope-check Council recognised this as a real gap and named the ODR forward rather than spawn-now: Phase 1 work does not require it, but the work is too consequential to surface only in an ad-hoc late session. Naming forward fixes the URI, opens the catalogue admission of cred: and did: prefixes (per Baker’s session-002 amendment), and gives ODR-0009 Q8 a record to defer into rather than an open question.

    Guizzardi raised a Truth-Maker question that belongs in this ODR’s deliberation: what makes true a Verifiable Credential? PROV-O names a derivation chain; the VC names a cryptographic signature; the assurance level names a regulatory judgement. Three truth-makers, one Claim. ODR-0009 collapses these into the PROV-O backbone plus the opda:assuranceLevel SKOS layer; ODR-0016 separates them per the VC ecosystem’s own discipline.

    Considered Options

    • Option A (chosen) — Name ODR-0016 as deferred-but-named with fixed activation triggers. The chosen approach: fix the URI, open the catalogue admission of cred: and did: prefixes, and give ODR-0009 Q8 a record to defer into.
    • Option B — Defer indefinitely, refresh ODR-0009’s Q8 ad hoc. Rejected by scope-check (8-1 NAME): the URI cost of late naming + the catalogue-admission cost of cred:/did: prefixes are both better paid up front.
    • Option C — Fold into ODR-0009 (Claims, Evidence & Provenance). Rejected: ODR-0009 deliberately scoped to the PROV-O backbone and assurance layer; binding to W3C VCDM 2.0 + DID Core + signature suites + status lists is a separate Council-cycle volume (Hendler’s session-001 framing — each W3C Rec is its own URI-graph commitment).
    • Option D — Spawn now (Davis + Pandit position). Rejected by majority (6-2 defer-with-name): Phase 1 work does not require it; spawning now adds a session without a clear MVP-blocking question.

    Decision Outcome

    Chosen option: “Name ODR-0016 as deferred-but-named with fixed activation triggers”, because the scope-check Council recognised this as a real gap and naming it forward fixes the URI, opens cred:/did: catalogue admission, and gives ODR-0009 Q8 a record to defer into without requiring a session Phase 1 does not need.

    Name ODR-0016 (W3C VC / DID Compatibility Layer) as a deferred-but-named record. Activation triggers and scope are fixed; the substantive ## Rules are placeholder until activation. The catalogue (ODR-0002) admits cred: (W3C VCDM 2.0) and did: (DID Core) prefixes immediately in the Defer tier with an activation pointer to this ODR.

    Consequences

    • ODR-0002 admits cred: and did: prefixes in the Defer tier immediately, with activation pointers to this ODR. Session 002 ratifies the admission.
    • ODR-0009 Q8 (“opda:Claim as cred:VerifiableCredential-compatible?”) defers into this ODR rather than being answered inline. ODR-0009’s ## References cites this ODR explicitly.
    • ODR-0012 (Governance) Phase-2 ambition (consent / lawful-basis class vocabulary) has a target ODR for receipt shapes when it activates.
    • Trust Framework citation honoured — the verifiedClaims envelope’s claim that PDTF is a trust framework now has a record committing the framework to interop.
    • Plan §5 adds a Phase 7 (deferred) for Session 016. Cost: zero until activated; one Full Council session when activated.
    • If no activation trigger fires through MVP, this ODR stays proposed and is reviewed at programme retirement (ODR-0003 retirement gate).

    More Information

    • Council methodology: ODR-0001.
    • Programme anchor: ODR-0003.
    • Catalogue: ODR-0002 — admits cred: and did: prefixes in Defer tier with activation pointers here.
    • Upstream: ODR-0009 — PROV-O backbone + assurance layer + Q8 deferred here.
    • Downstream consumers: ODR-0012 — Phase-2 consent receipts; Pandit’s lawful-basis ambition.
    • Deliberation provenance: Scope-Check 1 — Programme cut, Q7c. Named-but-deferred per 8-1 verdict.
    • External standards: W3C Verifiable Credentials Data Model 2.0; W3C DID Core 1.0; W3C Data Integrity 1.0; W3C VC Status List 2021; W3C VC Consent Receipt (Community Group draft); EU eIDAS 2.0 Regulation; Trust over IP (ToIP) layers; OIDC4IDA (already referenced by ODR-0009).
    • Truth-Maker discipline: Guarino (DOLCE truth-making); Guizzardi’s appendix to Scope-Check 1 Q7c.

    Rules

    All rules below are placeholder until Session 016 runs. The activation triggers and the convening shape are normative; the binding content lands at session time.

    Activation triggers (any one fires the session).

    1. Session 009 Q8 surfaces real VC-side decisions — ODR-0009’s deliberation reveals that the cred:VerifiableCredential binding cannot be deferred without leaking into the PROV-O backbone.
    2. Pandit’s Phase-2 ambition lands — ODR-0012’s deliberation extends DPV adoption to consent / lawful-basis / purpose class vocabulary, which is W3C VC consent-receipt-shaped.
    3. A real wallet or DID-method consumer enters scope — gov.uk OneLogin integration, EU eIDAS 2.0 wallet, OPDA-issued credentials for buyer wallet, or any consumer that requires did:web/did:key/did:jwk resolution.

    Scope when activated.

    1. Claim binding. opda:Claim rdfs:subClassOf cred:VerifiableCredential? Or a prov:Entity-only opda:Claim with a separate opda:VerifiableCredentialPresentation class for the wallet-side?
    2. Issuer / Holder / Verifier role bindings. Map ODR-0006’s RoleMixin pattern onto VC’s Issuer/Holder/Verifier; clarify which Roles are W3C VC roles and which are domain-specific (Conveyancer, Estate Agent, AML Verifier).
    3. DID method commitment. did:web (the cheap default), did:key, did:jwk, or a custom OPDA method? Resolution endpoint specification.
    4. Data Integrity / signature suites. Which signature suites does the assurance layer admit? (Ed25519Signature2020 default; BBS+ for selective disclosure of PII evidence; ECDSA for legacy CA chains.)
    5. Status lists. cred:CredentialStatus and revocation registries (StatusList2021). Where does the OPDA registry live; who operates it?
    6. JSON-LD context. https://opda.uk/contexts/v1 or similar — the JSON-LD context the catalogue commits to.
    7. Truth-maker discipline (Guizzardi). PROV-O derivation vs cryptographic signature vs regulatory assurance-level — what makes true a claim under the OPDA Trust Framework? Three truth-makers, one Claim — express the relationship.
    8. Consent receipts — if Pandit’s Phase-2 ambition (ODR-0012) lands, the consent-receipt shape (W3C VC consent-receipt draft) is the natural target. Receipt structure ratified here, not in 0012.
    9. eIDAS 2.0 / ToIP alignment. Where the OPDA Trust Framework cites eIDAS levels (Substantial, High) and ToIP layers — the existing opda:assuranceLevel SKOS scheme (ODR-0009) maps onto these. Confirm the mapping.

    Convening constraints for Session 016 (when activated).

    • Format: Full Council (substantive linked-data decision; credible split between VC purists and Trust-Framework pragmatists).
    • Queen: Luc Moreau (continuity with ODR-0009 — owns PROV-O ↔ VC alignment) OR a W3C VC WG voice (Manu Sporny or Drummond Reed — extended panel) if the binding deliberation needs deeper VC-ecosystem grounding. The convening block resolves.
    • DA: Harshvardhan Pandit (the strongest credible opponent of an under-scoped binding — challenges the deferral as cover for the VC ecosystem’s larger ambitions; consent-receipt completeness).
    • Extended panel: Manu Sporny / Drummond Reed (VC WG); Nicola Guarino (Truth-Maker question carries).
    • Standing panel slice: Allemang (working-ontologist pragmatism), Hendler (W3C web architecture), Cagle (operational SHACL on signed claims).

    MUST land before:

    • The first OPDA-issued credential is signed for a real wallet consumer.
    • ODR-0012 (Governance) ratifies consent-receipt instances, if Phase-2 activates.

    ODR Dependency Graph

    The diagram below shows how ODR-0016 sits in the programme graph: which records it depends on and which downstream records point back to it.

    flowchart LR accTitle: ODR-0016 dependency graph accDescr: Shows ODR-0016 depends-on ODR-0002 and ODR-0009, implements ODR-0003, and is consumed by ODR-0012. ODR0002["ODR-0002
    Ontology Language
    Adoption"]:::process ODR0003["ODR-0003
    PDTF Ontology
    Programme"]:::process ODR0009["ODR-0009
    Claims, Evidence
    & Provenance"]:::process ODR0016["ODR-0016
    W3C VC / DID
    Compatibility Layer"]:::warning ODR0012["ODR-0012
    Data Governance
    Layer"]:::success ODR0002 -->|"admits cred: did:
    Defer tier"| ODR0016 ODR0009 -->|"Q8 defers into"| ODR0016 ODR0003 -->|"implemented by"| ODR0016 ODR0016 -->|"consent-receipt
    target for"| ODR0012

    OPDA Claims and Evidence mapped to W3C VC Structures

    The diagram below traces how OPDA’s existing claim and evidence concepts (from ODR-0009) correspond to the roles and structures named in the W3C Verifiable Credentials Data Model 2.0.

    flowchart LR accTitle: OPDA claim and evidence mapping to W3C VC structures accDescr: Shows how opda:Claim, opda:Evidence, opda:assuranceLevel, and PROV-O derivation map to cred:VerifiableCredential, Issuer, Holder, Verifier, and cred:CredentialStatus. subgraph OPDA["OPDA (ODR-0009)"] C["opda:Claim"]:::process E["opda:Evidence"]:::process AL["opda:assuranceLevel
    (SKOS)"]:::process PV["prov:Entity /
    derivation chain"]:::process end subgraph VC["W3C VCDM 2.0"] VC1["cred:VerifiableCredential"]:::success ISS["Issuer"]:::success HOL["Holder"]:::success VER["Verifier"]:::success CS["cred:CredentialStatus
    (StatusList2021)"]:::success end Q{"Binding
    (Q8 — deferred
    to ODR-0016)"}:::warning C -->|"subClassOf?"| Q Q --> VC1 E -->|"supports"| C AL -->|"maps to eIDAS /
    ToIP assurance"| VC1 PV -->|"truth-maker 1:
    derivation"| Q VC1 -->|"truth-maker 2:
    cryptographic signature"| Q AL -->|"truth-maker 3:
    regulatory judgement"| Q VC1 --> CS VC1 --- ISS VC1 --- HOL VC1 --- VER

    VC Issuance and Verification Sequence

    The diagram below illustrates the issuance and verification flow for an OPDA claim presented as a W3C Verifiable Credential, incorporating the Issuer, Holder, and Verifier roles that this ODR will bind to the RoleMixin pattern from ODR-0006.

    sequenceDiagram accTitle: OPDA VC issuance and verification sequence accDescr: Shows Issuer creating a signed VerifiableCredential from an opda:Claim, Holder storing it, and Verifier checking the credential status and trust framework. participant Issuer as Issuer
    (OPDA Trust Framework) participant Holder as Holder
    (e.g. Buyer wallet) participant Verifier as Verifier
    (e.g. Conveyancer) participant Registry as Status Registry
    (StatusList2021) Issuer->>Issuer: Assemble opda:Claim
    + prov:derivation chain Issuer->>Issuer: Apply signature suite
    (Ed25519 / BBS+) Issuer->>Holder: Issue VerifiableCredential
    (signed, with assuranceLevel) Holder->>Holder: Store in wallet Holder->>Verifier: Present VerifiablePresentation Verifier->>Registry: Check cred:CredentialStatus Registry-->>Verifier: Status (active / revoked) Verifier->>Verifier: Verify signature suite Verifier->>Verifier: Confirm trust_framework +
    assurance_level mapping Verifier-->>Holder: Accept / Reject presentation

    Activation Triggers — Decision Flowchart

    The diagram below shows the three named activation triggers and how any one of them convenes Session 016 to ratify the substantive rules of this ODR.

    flowchart TD accTitle: ODR-0016 activation trigger decision flowchart accDescr: Shows three named activation triggers — ODR-0009 Q8, Pandit Phase-2 consent receipts, and a real wallet or DID consumer — each leading to Session 016. T1["Trigger 1:
    ODR-0009 Q8 surfaces
    real VC-side decisions"]:::process T2["Trigger 2:
    Pandit Phase-2 consent /
    lawful-basis ambition lands"]:::process T3["Trigger 3:
    Real wallet or
    DID-method consumer enters scope"]:::process D{"Any trigger
    fires?"}:::warning T1 --> D T2 --> D T3 --> D D -->|"yes"| S016["Convene Session 016
    (Full Council)"]:::success D -->|"no"| DEFER["ODR-0016 stays proposed;
    reviewed at programme retirement"]:::user S016 --> RULES["Ratify substantive ## Rules:
    Claim binding · DID method ·
    Signature suites · Status lists ·
    JSON-LD context · Truth-makers ·
    Consent receipts · eIDAS mapping"]:::success

    Amendments

    2026-06-14 — Reviewed at the programme-retirement gate; WAIVED (no trigger fired)

    ODR-0003 retired this date. Per its retirement criterion, ODR-0016 counts toward the gate only if an activation trigger has fired. Author-level review (no council; pragmatist path) adjudicated all three triggers not fired:

    1. Session 009 Q8 forces a VC binding — not fired. ODR-0009 is accepted; Q8 deferred cleanly into this ODR with no leak into the PROV-O backbone.
    2. ODR-0012 Phase-2 consent-receipt vocab lands — not fired. ODR-0012 (session-033) settled the lawful-basis layer by reference but explicitly holds consent-records / odrl:Policy instances (the consent-receipt-shaped Phase-2 work) deferred.
    3. A real wallet/DID/VC consumer enters scope — not fired in the sense this ODR governs. This ODR governs the core ontology VC/DID binding (Claim ⊑ cred:VerifiableCredential, Issuer/Holder/Verifier role bindings, signature suites, status lists, JSON-LD context). ADR-0004’s accreditation-directory did:web + VCDM 2.0 commitment is harness-level governance apparatus (June-2 namespace decision: “not a term, not a new standard”), is not yet operational (accreditation build C1–C4 awaits member-firm VC readiness), and the emitted core ontology carries zero cred:/did: terms — it routed around the core binding rather than activating it.

    Disposition. WAIVED at the gate; status stays proposed (consistent with §Decision Outcome: “if no activation trigger fires through MVP, this ODR stays proposed and is reviewed at programme retirement”). The activation triggers above survive as forward pointers: should any fire after retirement, it spawns a fresh ODR (per ODR-0003 §retirement), not a reactivation of this stub. The cred:/did: catalogue admission (ODR-0002 Defer tier) and the ODR-0009 Q8 deferral remain valid.

    ← Back to ODR Corpus  |  Download Markdown source

    This record's status, scope and dated amendments identify its current authority. Historical decisions retain their recorded context; later corrections remain auditable in Git history.

    Comments

    Loading comments…