architecture proposed 2026-05-26

W3C Verifiable Credentials / DID Compatibility Layer

Context

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.

Decision

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.

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

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

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?
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).
DID method commitment. did:web (the cheap default), did:key, did:jwk, or a custom OPDA method? Resolution endpoint specification.
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.)
Status lists. cred:CredentialStatus and revocation registries (StatusList2021). Where does the OPDA registry live; who operates it?
JSON-LD context. https://opda.uk/contexts/v1 or similar — the JSON-LD context the catalogue commits to.
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.
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.
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

Alternatives

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

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

References

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.