# 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