generated from coulomb/repo-seed
tegwick
1c1b5c9bc6
Backfill all 23 research source notes with terminology extracts, modeling assumptions, conflicts, canonical mappings, and references. Refresh terminology artifacts, refine the conceptual model with explicit scenario paths, reconcile canon surfaces and open questions, and mark the workplan finished.
4.6 KiB
4.6 KiB
OpenID for Verifiable Credentials (OpenID4VC)
Source Type
Standard suite. OpenID4VCI (issuance), OpenID4VP (presentation), and related OAuth 2.0 profiles for verifiable credentials.
Domain
VC issuance and presentation protocols, wallet-holder flows, and federation of verifiable credential ecosystems.
Why This Source Matters
OpenID4VC bridges OAuth/OIDC infrastructure with W3C Verifiable Credentials, connecting federation protocols to portable claim semantics.
Key Concepts
- OpenID4VCI: issuer-to-holder credential issuance using OAuth 2.0 access tokens and credential offers.
- OpenID4VP: holder-to-verifier presentation using authorization requests and VP tokens.
- Credential Issuer: OIDC/OAuth entity issuing VCs.
- Wallet / Holder: stores credentials and responds to presentation requests.
- Verifier: requests and validates presentations.
- Credential Offer: deeplink/URI initiating issuance to wallet.
- Proof of possession: holder proves control of key bound to credential.
- Authorization Request (VP): verifier specifies required credential types.
- SD-JWT VC: selective disclosure JWT credential format (parallel track).
- mDL / ISO 18013-5: mobile document format integrated in some profiles.
Relevant Terminology
| Term | Source meaning |
|---|---|
| Credential Issuer | OAuth/OIDC party issuing VCs. |
| Wallet | Holder software storing VCs. |
| Verifier | Party requesting VP from wallet. |
| Credential offer | Issuance initiation artifact. |
| Authorization request | Presentation request to wallet. |
| VP token | Presentation response token. |
| c_nonce | Issuance proof challenge. |
| format | VC encoding (jwt_vc, ldp_vc, sd-jwt). |
| credential_definition | Type/filter for requested credential. |
| presentation_definition | Verifier's input requirements. |
Modeling Assumptions
- Issuance is OAuth-mediated between issuer, wallet, and optional broker.
- Presentation is verifier-driven with explicit requested claim types.
- Holder wallet is trust boundary for credential storage and selective disclosure.
- OIDC identity may bootstrap wallet or issuer trust.
- Multiple credential formats coexist (JWT, JSON-LD, SD-JWT).
- Revocation/status checked at verification time.
- Pairwise issuance possible for privacy-preserving credentials.
Identity-Canon Implications
- OpenID4VCI issuance flow maps to Credential creation with Claim, Issuer Scope, and Evidence Source (issuance event).
- OpenID4VP presentation maps to verifier Trust Relationship evaluating Credential + Claim subset.
- Wallet maps to holder Actor + storage Scope (custody boundary).
- OIDC authentication preceding issuance maps to Authenticated Subject → Account → VC Subject binding via Identifier Binding.
- Selective disclosure supports S14 (privacy-limited claims).
- Bridges federation (OIDC) and VC layers for S13 strong links.
- Reinforces projection pattern: OIDC for auth, VC for claims.
Terminology Conflicts
- Issuer: OIDC issuer vs. VC issuer — often same entity, different roles.
- Subject: OIDC sub in token vs. VC credentialSubject.
- Credential: OAuth credential vs. Verifiable Credential.
- Verifier vs. RP: overlapping roles with added VP verification.
- Wallet vs. Account: wallet is credential store, not always login account.
Candidate Canonical Mappings
| OpenID4VC concept | Candidate canonical concept |
|---|---|
| Credential Issuer | Issuer Scope + Trust Relationship |
| Wallet / Holder | Actor (custody) + Scope |
| Verifier | Verifier / RP Scope |
| Issued VC | Credential + Claim |
| Credential offer | Evidence Source (issuance initiation) |
| Presentation | Credential presentation (operational) |
| OIDC auth prior to issuance | Authenticated Subject → Identifier Binding |
| presentation_definition | Verifier policy (downstream) |
| SD-JWT selective disclosure | Privacy-limited Claim exposure |
| Status check | Lifecycle State verification |
Open Questions
- Should wallet custody be a canonical Scope specialization (Holder Scope)?
- How should OIDC sub to VC subject binding strength be classified (weak vs. strong Synonymity)?
- Does OpenID4VP verifier policy belong in canon or strictly downstream?
- Should SD-JWT credentials map to Credential subtype with disclosure metadata?