commerce-canon/research/verifiable-claims/openid4vc.md

# 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?

## References

- OpenID4VCI — https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html
- OpenID4VP — https://openid.net/specs/openid-4-verifiable-presentations-1_0.html
- OpenID4VCI SD-JWT profile — https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-sd-jwt-vc