An identity standard that defines how verifiable credentials are issued and presented using OpenID-based protocols. It lets wallets, issuers, verifiers, and relying parties exchange credentials in a way that can be tested for interoperability and assurance across different ecosystems.
Expanded Definition
OpenID for Verifiable Credentials, often abbreviated as OpenID4VC, is a family of profile specifications that uses OpenID-based request and response patterns to issue and present verifiable credentials across wallets, issuers, and verifiers. It is part of an evolving interoperability layer rather than a single monolithic standard, so definitions vary across vendors and ecosystem implementations.
In NHI and agentic identity contexts, OpenID4VC matters because it helps formalise trust between autonomous actors without relying on long-lived shared secrets. A wallet can request a credential, an issuer can bind it to a subject, and a verifier can check presentation rules using workflows that are more structured than ad hoc API exchanges. The closest operational analogue is not classic user login, but portable proof exchange with policy checks, audience constraints, and revocation considerations. For protocol context, see the NIST SP 800-63 Digital Identity Guidelines and the OWASP Non-Human Identity Top 10 for the security expectations that surround credential lifecycle design.
The most common misapplication is treating OpenID4VC as if it automatically makes any credential trustworthy, which occurs when implementers ignore issuer assurance, wallet binding, and verifier policy.
Examples and Use Cases
Implementing OpenID4VC rigorously often introduces ecosystem coordination overhead, requiring organisations to weigh interoperability and portability against issuer governance, wallet compatibility, and verification assurance.
- A workforce wallet receives a credential from an employer issuer and later presents it to a verifier that checks whether the credential was issued by the right authority and is still valid.
- A partner ecosystem uses OpenID4VC to exchange role or membership credentials across organisations without reissuing every assertion in a proprietary format.
- An AI agent presents a credential representing delegation scope before being allowed to access a downstream service, reducing reliance on static shared secrets. The threat patterns around brittle secret handling are discussed in Guide to the Secret Sprawl Challenge.
- A verifier applies policy to accept only credentials from approved issuers, following guidance consistent with OWASP Non-Human Identity Top 10 principles around trust boundaries and credential handling.
- A phishing-resistant access flow uses credential presentation instead of password exchange, but only after the wallet and verifier have been aligned on format, binding, and revocation checks.
These patterns are especially relevant when teams want portability across ecosystems but cannot tolerate uncontrolled credential reuse. Real-world breach reporting such as the Cisco Active Directory credentials breach shows why identity assertions must not be confused with mere authentication artifacts.
Why It Matters in NHI Security
OpenID4VC is important because NHI security fails when credentials are easy to copy, difficult to revoke, or accepted without strong issuer validation. Aembit’s 2024 Non-Human Identity Security Report found that 88.5% of organisations say their non-human IAM practices lag behind or are only on par with human IAM, which is a strong indicator that interoperable credential frameworks are being adopted faster than governance maturity. That gap matters when verifiable credentials are used to represent workloads, services, or delegated agent actions.
Used well, OpenID4VC can reduce dependency on static secrets and improve portability across trust domains. Used poorly, it can create a false sense of assurance if teams assume presentation format equals security. The same operational lesson appears in the 2024 Non-Human Identity Security Report, where dynamic credential expectations are rising faster than policy discipline. In practice, defenders should pair protocol adoption with issuer vetting, revocation design, and wallet protection.
Organisations typically encounter the risk only after a credential is replayed, misissued, or accepted by the wrong verifier, at which point OpenID4VC becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST Zero Trust (SP 800-207) set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP Non-Human Identity Top 10 | NHI-02 | Covers secure handling of NHI credentials and secret-like artifacts in trust workflows. |
| NIST SP 800-63 | IAL/AAL/FAL | Defines digital identity assurance concepts that map to credential issuance and presentation strength. |
| NIST Zero Trust (SP 800-207) | SC-3 | Zero trust relies on continuous verification, which OpenID4VC can support for delegated access. |
Map OpenID4VC issuance and presentation to assurance levels and validate binding and verifier policy.
Related resources from NHI Mgmt Group
- How should organisations govern trust for verifiable credentials across ecosystems?
- How do verifiable credentials change enterprise identity governance?
- How should security teams decide where to use verifiable credentials in customer journeys?
- How do organisations reduce identity data exposure when using verifiable credentials?
