OpenID for Verifiable Credentials is a family of protocols supporting implementation of applications with Verifiable Credentials, i.e. verifiable credential issuance, credential presentation, and pseudonyms authentication.
3. #identiverse
Verifiable Credentials: A Paradigm Shift
Issuer
(Website)
Verifier
(Website)
Holder
(Digital Wallet)
Can be hosted locally on the
user’s device, have cloud
components, or be entirely
hosted in the cloud
Issue
Credentials
Present
Credentials
● Verifiable credential is a tamper-evident credential with a cryptographically verifiable
authorship that contains claims about a subject.
● This enables
○ decoupling issuance from presentation
○ multi-use of the credentials
○ combination of multiple credentials in one presentation
5. #identiverse
Verifiable Credentials: Benefits
- End-Users gain more control, privacy, and portability over their identity
information.
- Cheaper, faster, and more secure identity verification, when transforming
physical credentials into digital ones using verifiable credentials.
- Universal approach to handle identification, authentication, and
authorization in digital and physical space
- Issuers gain more flexibility :
- No need for public service with high availability depending on the process
- Diverse presentation channels offered by the wallet
6. #identiverse
③ OpenID for Credential Issuance (Issuance
of verifiable credentials)
Components of the “OpenID for Verifiable Credentials”
specification family
Issuer
(Website)
Verifier
(Website)
Holder
(Digital Wallet)
Can be hosted locally on the
user’s device, have cloud
components, or be entirely
hosted in the cloud
Issue
Credentials
Present
Credentials
① OpenID Connect for Verifiable Presentations
(Presentation of verifiable credentials)
② Self-Issued OP v2 (authentication using identifiers
not namespaced to the third-party identity providers)
7. #identiverse
- Self-Issued OP (SIOP) has been in OpenID Connect Core from
ratification and provides a good starting point
- Leverages simplicity and security of OpenID Connect and OAuth 2.0
- Existing libraries, only HTTPS communication, developer familiarity
- Great for mobile applications, no firewall hassles
- Security of OpenID Connect has been tested and formally analysed
- Existing OpenID Connect RPs can receive verifiable credentials;
Existing OpenID Connect OPs can issue verifiable credentials
Why use OpenID Connect & OAuth2.0 as a basis?
11. #identiverse
① RP requests
Credential(s)*
OpenID for Verifiable Presentations
Website or App
(Verifier)
Wallet
OP
Alice
⓪ User tries to access
a resource
Stored
Verifiable Credentials
② Wallet returns Verifiable
Presentation(s) in VP Token
- Query language to granularly specify what kind
of credential Verifier wants. (utilizes DIF
Presentation Exchange 2.0)
- Verifiable Presentations* are returned in a newly
defined VP Token
- Simple overall architecture, e.g. device local
communication when same device flow is used
*can be any credential/presentation format, not limited to not limited to W3C Verifiable Credentials.
12. #identiverse
OpenID4VPs allows choices across components
in the VC Tech Stack.
Component Implementer’s choices when using OpenID4VP
Credential Format Any format (W3C JWT-VC or LDP-VC, ISO mDL, SD-JWT, …)
Method to obtain
Public Keys
Any DID method, raw keys, or X.509 certs
Cryptography Any cryptosuite (EdDSA, ES256K, etc.)
Revocation Any mechanism (Status List 2021, Revocation List 2020, Accumulators,
etc.)
Trust Management Any mechanism for managing trusted Issuers, Wallets and Relying Parties
(Trusted Registries, Ledgers, …)
15. #identiverse
Self-Issued OP v2
Website (RP)
User
Agent
OP
Alice
⓪ User tries to access
a resource
- ID Tokens are signed with user-controlled key
material (pseudonymous authentication with
pairwise subject identifiers)
- Identifiers are user controlled and do not depend
on a third-party identity provider
- Can be used in combination with OpenID4VPs,
when the use case requires end-user
authentication, i.e. the features of OpenID
Connect, such as issuance of ID Tokens.
② OP on the user
device issues subject-
signed ID Token
① RP requests ID
Token
16. #identiverse
Why use OpenID4VPs & SIOP v2
- Credential format/crypto suite agnostic
- Same device and cross device scenarios
- Mutual authentication of RP and wallet
- Pseudonymous authentication to RPs through SIOP v2
- Works well with OAuth for authorization of API-based payments and remote signature
creation
- Offline - work in progress (MOSIP)
- Selective disclosure (if supported by credential format)
- Note: referenced by ISO/IEC 18013-7 and 23220-4 Mobile Driving Licences related draft
standards as a data release method
17. #identiverse
- First Implementer’s Drafts approved (both SIOP v2 and OpenID4VPs)
- Can be implemented with IPR protection
- Targeting Second Implementer’s Draft by the end of 2022
- Existing & ongoing Implementations:
- The European Blockchain Services Infrastructure (EBSI)
- Microsoft
- Workday
- Ping Identity
- Convergence.Tech
- IDunion
- walt.id (eSSIF-Lab)*
- Sphereon
- Gimly
Status: Credential Presentation
22. #identiverse
OpenID 4 Verifiable Credentials Issuance
Credentia
l Issuer
Website or App
(RP)
Wallet
OP
Alice
⓪ User tries to log in
RP
Stored
Verifiable Credentials
② Wallet issues
Verifiable Presentation(s)
① RP requests
Credential(s)
⓪ Wallet requests & User
authorizes credential issuance
③ Credential is issued
① access token(, refresh
token)
② Wallet requests credential
issuance
Credential issuance via simple OAuth-authorized API
23. #identiverse
- Defined a new OAuth-protected Credential Endpoint
- in addition to Authorization/Token Endpoints
- Two authorization flows:
- Code flow (others OAuth 2.0 grant types possible): authorization for one or
more credentials at the Authorization Endpoint once the wallet is invoked
- Pre-authorized code flow (new grant type): authorization for one or more
credentials prior to the Wallet being invoked.
- Supports different methods for the Wallet to prove possession of key material used to
bind credential
Design Principles
24. #identiverse
Why use OpenID4VCI?
- Credential format/crypto suite agnostic
- Hardware-backed key material for cryptographic binding of attribute
attestations (leveraging HSMs, SEs, TEEs)
- Same device and cross device scenarios
- Mutual authentication of wallet and issuer
- Can extend existing OAuth/OpenID deployments, simple way for existing
AS/IDPs to become PID/(Q)EAA issuers
- Note: will be added to ISO 23220-3 electronic ID standards
25. #identiverse
- Targeting First Implementer’s draft by the end of 2022.
- https://openid.net/specs/openid-connect-4-verifiable-credential-issuance-1_0.html
- Planned and ongoing implementations:
- The European Blockchain Services Infrastructure (EBSI)
- Microsoft
- Mattr
- IDunion
- walt.id & yes.com & BCDiploma (eSSIF-Lab)
- Sphereon
- Talao.io
- Convergence.Tech
Status of the Issuance specification
26. #identiverse
Whitepaper “OpenID for Verifiable Credentials”
- Aims to assist decision-makers, architects and
implementers in the decision-making process when
building verifiable credentials ecosystem.
- Some popular sections…
- Demystifying myths about verifiable credentials
- Various scopes of “decentralization”
- Shift in the trust model brought by verifiable
credentials
- Business drivers
- Use-Cases
27. #identiverse
- Security and simplicity guaranteed – OAuth/OpenID Connect deployment experience
(3B+ users, millions applications), and OpenID Foundation Certification program
- Fast, scalable adoption - easy integration/deployment on existing infrastructure given the
familiarity of the developers and administrators with OAuth/OpenID
- Adoption underway
- Projects in the EU (EBSI/ESSIF, Secure Digital Identities Showcase)
- Incorporated into major participant’s products (e.g. Microsoft, Ping Identity, walt.id)
- Global Assured Identity Network PoC
- Could meet high security requirements with FAPI Security Profile
- Interoperability on the protocol layer that is both credential format agnostic, and allows for
interoperability between markets
Why use OpenID for Verifiable Credentials?
28. #identiverse
Call to Action
1. Implement the specifications to unlock your use cases and provide us
feedback
2. Read the whitepaper and stay up to date with the recent developments
30. Example: Authorization Request
HTTP/1.1 302 Found
Location: https://server.example.com/authorize?
response_type=code //any other grant type
&client_id=s6BhdRkqt3
&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
&code_challenge_method=S256
&scope=openid_credential:https://example.org/idcard
&redirect_uri=https://client.example.org/cb