openid-4-vp | December 2022 | |
Terbu, et al. | Standards Track | [Page] |
This specification defines a protocol for requesting and presenting Verifiable Credentials.¶
This specification defines a mechanism on top of OAuth 2.0 [RFC6749] that enables presentation of Verifiable Credentials. W3C [VC_DATA] formats as well as other Credential formats, like [ISO.18013-5] and AnonCreds [Hyperledger.Indy], are supported.¶
OAuth 2.0 [RFC6749] is used as a base protocol as it provides the required rails to build simple, secure, and developer friendly credential presentation on top of it. Moreover, implementers can, in a single interface, support credential presentation and the issuance of access tokens for access to APIs based on Verifiable Credentials in the wallet. OpenID Connect [OpenID.Core] deployments can also extend their implementations using this specification with the ability to transport Verifiable Presentations.¶
This specification can also be combined with [SIOPv2], if implementers require OpenID Connect features, such as the issuance of subject-signed ID tokens.¶
Credential¶
A set of claims about a subject made by an Issuer.¶
Note: the definition of a term "credential" in this specification is different from that in [OpenID.Core].¶
Verifiable Credential (VC)¶
A tamper-evident credential that has authorship of the Issuer that can be cryptographically verified. Can be of any format used in the Issuer-Holder-Verifier Model, including, but not limited to those defined in [VC_DATA], [ISO.18013-5] and [Hyperledger.Indy] (AnonCreds).¶
W3C Verifiable Credential¶
A Verifiable Credential compliant to the [VC_DATA] specification.¶
Presentation¶
Data derived from one or more Verifiable Credentials that can be from the same or different issuers that is shared with a specific verifier.¶
Verifiable Presentation (VP)¶
A tamper-evident presentation that has authorship of the Holder that can be cryptographically verified to provide Cryptographic Holder Binding. Can be of any format used in the Issuer-Holder-Verifier Model, including, but not limited to those defined in [VC_DATA], [ISO.18013-5] and [Hyperledger.Indy] (AnonCreds).¶
W3C Verifiable Presentation¶
A Verifiable Presentations compliant to the [VC_DATA] specification.¶
Issuer¶
An entity that creates Verifiable Credentials.¶
Holder¶
An entity that receives Verifiable Credentials and has control over them to present them to the Verifiers as Verifiable Presentations.¶
Verifier¶
An entity that requests, checks and extracts the claims from Verifiable Presentations.¶
Issuer-Holder-Verifier Model¶
A model for claims sharing where claims are issued in the form of Verifiable Credentials independent of the process of presenting them as Verifiable Presentation to the Verifiers. Issued Verifiable Credential can (but must not necessarily) be used multiple times.¶
Cryptographic Holder Binding¶
Ability of the Holder to prove legitimate possession of a Verifiable Credential by proving control over the same private key during the issuance and presentation. Mechanism might depend on the Crednetial Format. For example, in jwt_vc_json
Credential Format, a VC with Cryptographic Holder Binding contains a public key or a reference to a public key that matches to the private key controlled by the Holder. Claim-based or biometrics-based holder binding is also possible.¶
Base64url Encoding¶
Base64 encoding using the URL- and filename-safe character set defined in Section 5 of [RFC4648], with all trailing '=' characters omitted (as permitted by Section 3.2 of [RFC4648]) and without the inclusion of any line breaks, whitespace, or other additional characters. Note that the base64url encoding of the empty octet sequence is the empty string. (See Appendix C of [RFC7515] for notes on implementing base64url encoding without padding.)¶
Wallet¶
Entity used by the Holder to receive, store, present, and manage Verifiable Credentials and key material. There is no single deployment model of a Wallet: Verifiable Credentials and keys can both be stored/managed locally, or by using a remote self-hosted service, or a remote third party service. In the context of this specification, the Wallet acts as an OAuth 2.0 Authorization Server (see [RFC6749]) towards the Credential Verifier which acts as the OAuth 2.0 Client.¶
This specification defines mechanisms to¶
request presentation of Verifiable Credentials in arbitrary formats.¶
provide a verifier with one or more Verifiable Presentations in a secure fashion.¶
customize the protocol to the specific needs of a particular credential format. Examples are given for credential formats as specified in [VC_DATA], [ISO.18013-5] and [Hyperledger.Indy].¶
combine the credential presentation with user authentication through [SIOPv2].¶
combine the credential presentation with the issuance of OAuth access tokens.¶
This specification defines a mechanism on top of OAuth 2.0 to request and provide Verifiable Presentations. Verifiable Presentations are requested by adding a parameter presentation_definition
as defined by [DIF.PresentationExchange] to an OAuth 2.0 Authorization Request. The Verifiable Presentations are returned to the Verifier in a vp_token
response parameter, depending on the grant type either in the authorization or the token response.¶
OpenID for Verifiable Presentations supports scenarios where the Authorization Request is sent from the Verifier to the Wallet using redirects on the same device (same-device flow) and where the Authorization Request is passed across devices (cross-device flow).¶
Implementations can use any pre-existing OAuth grant type and response type in conjunction with this specifications to support different deployment architectures. This specification also introduces a new OAuth response mode direct_post
to support the cross device flow (see Section 6.4).¶
This specification supports any Credential format used in the Issuer-Holder-Verifier Model, including, but not limited to those defined in [VC_DATA], [ISO.18013-5] and [Hyperledger.Indy] (AnonCreds) even in the same transaction. The examples given in the main part of this specification use W3C Verifiable Credentials, but examples in other Credential formats are given in Appendix A.¶
Implementations can also be build on top of OpenID Connect Core, since OpenID Connect Core is based on OAuth 2.0. To benefit from the subject-signed ID Token feature, this specification can also be combined with the Self-Issued OP v2 specification [SIOPv2].¶
The authorization request follows the definition given in [RFC6749].¶
The following new parameters are defined by this specification:¶
presentation_definition
: CONDITIONAL. A string containing a presentation_definition
JSON object as defined in Section 4 of [DIF.PresentationExchange]. See Section 5.1 for more details.¶
presentation_definition_uri
: CONDITIONAL. A string containing an HTTPS URL pointing to a resource where a presentation_definition
JSON object as defined in Section 4 of [DIF.PresentationExchange] can be retrieved . See Section 5.2 for more details.¶
nonce
: REQUIRED. This parameter follows the definition given in [OpenID.Core]. It is used to securely bind the verifiable presentation(s) provided by the AS to the particular transaction.¶
response_mode
OPTIONAL. as defined in [OAuth.Responses]. If the parameter is not present, the default value is fragment
. This parameter is also used to request signing & encryption (see Section 6.3) as well as to ask the wallet to send the response to the Verifier via an HTTPS connection (see Section 6.4).¶
Additional considerations need to be considered for the following parameters defined in [RFC6749]:¶
response_type
: REQUIRED. This specification can be used with all response types as defined in the registry established by [RFC6749]. This specification introduces the new response type vp_token
. This response type asks the Authorization Server (AS) to return a vp_token
authorization response parameter.¶
scope
: OPTIONAL. The wallet MAY allow verifiers to request presentation of Verifiable Credentials by utilizing a pre-defined scope value. See Section 5.3 for more details.¶
Note: A request MUST contain either a presentation_definition
or a presentation_definition_uri
or a single scope
value representing a presentation definition, those three ways to request credential presentation are mutually exclusive. The wallet MUST refuse any request violating this requirement.¶
Note: A verifier MAY pass public keys to be used as input to the key agreement for encryption of the authorization response (see Section 6.3) in the jwks
or jwks_uri
claim within the client_metadata
request parameter (see Section 9.1).¶
This is an example request:¶
GET /authorize? response_type=vp_token &client_id=https%3A%2F%2Fclient.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &presentation_definition=... &nonce=n-0S6_WzA2Mj HTTP/1.1¶
presentation_definition
Parameter
This parameter contains a JSON object conforming to the syntax defined for presentation_definition
parameters in Section 4 of [DIF.PresentationExchange].¶
The following shows an example presentation_definition
parameter:¶
{ "id": "vp token example", "input_descriptors": [ { "id": "id card credential", "format": { "ldp_vc": { "proof_type": [ "Ed25519Signature2018" ] } }, "constraints": { "fields": [ { "path": [ "$.type" ], "filter": { "type": "string", "pattern": "IDCardCredential" } } ] } } ] }¶
This simple example requests the presentation of a credential of a certain type.¶
The following example shows how the RP can request selective disclosure or certain claims from a credential of a particular type.¶
{ "id": "vp token example", "input_descriptors": [ { "id": "id card credential with constraints", "format": { "ldp_vc": { "proof_type": [ "Ed25519Signature2018" ] } }, "constraints": { "limit_disclosure": "required", "fields": [ { "path": [ "$.type" ], "filter": { "type": "string", "pattern": "IDCardCredential" } }, { "path": [ "$.credentialSubject.given_name" ] }, { "path": [ "$.credentialSubject.family_name" ] }, { "path": [ "$.credentialSubject.birthdate" ] } ] } } ] }¶
RPs can also ask for alternative Verifiable Credentials being presented, which is shown in the next example:¶
{ "id": "alternative credentials", "submission_requirements": [ { "name": "Citizenship Information", "rule": "pick", "count": 1, "from": "A" } ], "input_descriptors": [ { "id": "id card credential", "group": [ "A" ], "format": { "ldp_vc": { "proof_type": [ "Ed25519Signature2018" ] } }, "constraints": { "fields": [ { "path": [ "$.type" ], "filter": { "type": "string", "pattern": "IDCardCredential" } } ] } }, { "id": "passport credential", "format": { "jwt_vc": { "alg": [ "RS256" ] } }, "group": [ "A" ], "constraints": { "fields": [ { "path": [ "$.vc.type" ], "filter": { "type": "string", "pattern": "PassportCredential" } } ] } } ] }¶
The VC and VP formats supported by an AS should be published in its metadata (see Section 8). The formats supported by a client may be set up using the client metadata parameter vp_formats
(see Section 9.1). The AS MUST ignore any format
property inside a presentation_definition
object if that format
was not included in the vp_formats
property of the client metadata.¶
Note that when the Client is requesting presentation of a VP containing a VC, Client MUST indicate in the vp_formats
parameter, supported formats of both VC and VP.¶
presentation_definition_uri
Parameter
presentation_definition_uri
is used to the retrieve the presentation_definition
from the resource at the specified URL, rather than being passed by value. The AS will send a GET request without additional parameters. The resource MUST be exposed without further need to authenticate or authorize.¶
The protocol for the presentation_definition_uri
MUST be HTTPS.¶
For example the parameter value "https://server.example.com/presentationdefs?ref=idcard_presentation_request" will result in the following request¶
GET /presentationdefs?ref=idcard_presentation_request HTTP/1.1 Host: server.example.com¶
and response.¶
HTTP/1.1 200 OK ... Content-Type: application/json { "id": "vp token example", "input_descriptors": [ { "id": "id card credential", "format": { "ldp_vc": { "proof_type": [ "Ed25519Signature2018" ] } }, "constraints": { "fields": [ { "path": [ "$.type" ], "filter": { "type": "string", "pattern": "IDCardCredential" } } ] } } ] }¶
scope
Parameter to Request Verifiable Credential(s)
Wallets MAY support requesting presentation of Verifiable Credentials using OAuth 2.0 scope values.¶
Such a scope value MUST be an alias for a well-defined presentation definition as it will be
refered to in the presentation_submission
response parameter.¶
The concrete scope values and the mapping between a certain scope value and the respective presentation definition is out of scope of this specification.¶
Possible options include normative text in a specification defining scope values along with a description of their
semantics or machine readable definitions in the wallet's server metadata, mapping a scope value to an equivalent
presentation_definition
object as defined in [DIF.PresentationExchange].¶
The definition MUST allow the verifier to determine the identifiers for presentation definition and input descriptors
used in the respective presentation submission response parameter as well as the credential formats and types in
the vp_token
response parameter.¶
It is RECOMMENDED to use collision-resistant scopes values.¶
Below is a non-normative example of an Authorization Request using the scope value com.example.IDCardCredential_presentation
,
which is an alias for the first presentation definition example given in Section 5.1:¶
GET /authorize? response_type=vp_token &client_id=https%3A%2F%2Fclient.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &scope=com.example.healthCardCredential_presentation &nonce=n-0S6_WzA2Mj HTTP/1.1¶
aud
of a Request Object
When an RP is sending a Request Object as defined in Section 6.1 of [OpenID.Core] or [RFC9101], the aud
Claim value depends on whether the recipient of the request can be identified by the RP or not:¶
the aud
Claim MUST equal to the issuer
Claim value, when Dynamic Discovery is performed.¶
the aud
Claim MUST be "https://self-issued.me/v2", when Static Discovery Metadata is used.¶
Note: "https://self-issued.me/v2" is a symbolic string and can be used as an aud
Claim value even when this specification is used standalone, without SIOPv2.¶
Whether vp_token
is provided to the Client in the Authorization Response or Token Response depends on the response type used in the request (see Section 5).¶
If the response type value is vp_token
or vp_token id_token
, the vp_token
is provided in the authorization response.¶
In all other cases, such as when response type is code
, and if the parameter presentation_definition
is present in the authorization request, the vp_token
is provided in the Token Response.¶
This specification defines the response type vp_token
.¶
The reponse type vp_token
can be used with different response modes as defined in [OAuth.Responses]. The default encoding is fragment
, i.e. the Authorization Response parameters are encoded in the fragment added to the redirect_uri
when redirecting back to the Client.¶
A response of type vp_token
consists of the following parameters:¶
vp_token
REQUIRED. String parameter that MUST either contain a single verifiable presentation or an array of Verifiable Presentations which MUST be represented as a JSON string or an object depending on a format as defined in Section 9.3 of [OpenID.VCI]. If Appendix E of [OpenID.VCI] defines a rule for encoding the respective credential format in the credential response, this rules MUST also be followed when encoding credentials of this format in the vp_token
response parameter. Otherwise, this specification does not require any additional encoding when a credential format is already represented as a JSON object or a JSON string. Credential formats expressed as binary formats MUST be Base64url encoded and returned as a JSON string.¶
presentation_submission
. REQUIRED. The presentation_submission
element as defined in [DIF.PresentationExchange] links the input descriptor identifiers as specified in the corresponding request to the respective Verifiable Presentations within the VP Token along with format information. The root of the path expressions in the descriptor map is the respective verifiable presentation, pointing to the respective Verifiable Credentials.¶
The presentation_submission
element MUST be included as a separate response parameter alongside the vp_token. Clients MUST ignore any presentation_submission
element included inside a VP.¶
Including the presentation_submission
parameter as a separate response parameter allows the AS to provide the RP with additional information about the format and structure in advance of the processing of the VP Token, and can be used even with the credential formats that do not allow for the direct inclusion of presentation_submission
parameters inside a credential itself.¶
In case the AS returns a single verifiable presentation in the VP Token, the descriptor_map
would then contain a simple path expression "$".¶
The following is an example response to a request of a response type vp_token
, where the presentation_submission
is a separate response parameter:¶
HTTP/1.1 302 Found Location: https://client.example.org/cb# presentation_submission=... &vp_token=...¶
This is an example of a VP Token containing a single verifiable presentation¶
{ "@context": [ "https://www.w3.org/2018/credentials/v1" ], "type": [ "VerifiablePresentation" ], "verifiableCredential": [ { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "https://example.com/credentials/1872", "type": [ "VerifiableCredential", "IDCardCredential" ], "issuer": { "id": "did:example:issuer" }, "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "given_name": "Fredrik", "family_name": "Strömberg", "birthdate": "1949-01-22" }, "proof": { "type": "Ed25519Signature2018", "created": "2021-03-19T15:30:15Z", "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..PT8yCqVjj5ZHD0W36zsBQ47oc3El07WGPWaLUuBTOT48IgKI5HDoiFUt9idChT_Zh5s8cF_2cSRWELuD8JQdBw", "proofPurpose": "assertionMethod", "verificationMethod": "did:example:issuer#keys-1" } } ], "id": "ebc6f1c2", "holder": "did:example:holder", "proof": { "type": "Ed25519Signature2018", "created": "2021-03-19T15:30:15Z", "challenge": "n-0S6_WzA2Mj", "domain": "https://client.example.org/cb", "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..GF5Z6TamgNE8QjE3RbiDOj3n_t25_1K7NVWMUASe_OEzQV63GaKdu235MCS3hIYvepcNdQ_ZOKpGNCf0vIAoDA", "proofPurpose": "authentication", "verificationMethod": "did:example:holder#key-1" } }¶
with a matching presentation_submission
.¶
{ "id": "Selective disclosure example presentation", "definition_id": "Selective disclosure example", "descriptor_map": [ { "id": "ID Card with constraints", "format": "ldp_vp", "path": "$", "path_nested": { "format": "ldp_vc", "path": "$.verifiableCredential[0]" } } ] }¶
A descriptor_map
parameter MUST contain a path_nested
parameter referring to the actual credential carried in the respective verifiable presentation.¶
This is an example of a VP Token containing multiple verifiable presentations,¶
[ { "@context": [ "https://www.w3.org/2018/credentials/v1" ], "type": [ "VerifiablePresentation" ], "verifiableCredential": [ { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "https://example.com/credentials/1872", "type": [ "VerifiableCredential", "IDCardCredential" ], "issuer": { "id": "did:example:issuer" }, "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "given_name": "Fredrik", "family_name": "Strömberg", "birthdate": "1949-01-22" }, "proof": { "type": "Ed25519Signature2018", "created": "2021-03-19T15:30:15Z", "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..PT8yCqVjj5ZHD0W36zsBQ47oc3El07WGPWaLUuBTOT48IgKI5HDoiFUt9idChT_Zh5s8cF_2cSRWELuD8JQdBw", "proofPurpose": "assertionMethod", "verificationMethod": "did:example:issuer#keys-1" } } ], "id": "ebc6f1c2", "holder": "did:example:holder", "proof": { "type": "Ed25519Signature2018", "created": "2021-03-19T15:30:15Z", "challenge": "n-0S6_WzA2Mj", "domain": "https://client.example.org/cb", "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..GF5Z6TamgNE8QjE3RbiDOj3n_t25_1K7NVWMUASe_OEzQV63GaKdu235MCS3hIYvepcNdQ_ZOKpGNCf0vIAoDA", "proofPurpose": "authentication", "verificationMethod": "did:example:holder#key-1" } }, "eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZCI6ImRpZDpleGFtcGxlOjB4YWJjI2tleTEifQ. eyJpc3MiOiJkaWQ6ZXhhbXBsZTplYmZlYjFmNzEyZWJjNmYxYzI3NmUxMmVjMjEiLCJqdGkiOiJ1cm46 dXVpZDozOTc4MzQ0Zi04NTk2LTRjM2EtYTk3OC04ZmNhYmEzOTAzYzUiLCJhdWQiOiJkaWQ6ZXhhbXBs ZTo0YTU3NTQ2OTczNDM2ZjZmNmM0YTRhNTc1NzMiLCJuYmYiOjE1NDE0OTM3MjQsImlhdCI6MTU0MTQ5 MzcyNCwiZXhwIjoxNTczMDI5NzIzLCJub25jZSI6IjM0M3MkRlNGRGEtIiwidnAiOnsiQGNvbnRleHQi OlsiaHR0cHM6Ly93d3cudzMub3JnLzIwMTgvY3JlZGVudGlhbHMvdjEiLCJodHRwczovL3d3dy53My5v cmcvMjAxOC9jcmVkZW50aWFscy9leGFtcGxlcy92MSJdLCJ0eXBlIjpbIlZlcmlmaWFibGVQcmVzZW50 YXRpb24iLCJDcmVkZW50aWFsTWFuYWdlclByZXNlbnRhdGlvbiJdLCJ2ZXJpZmlhYmxlQ3JlZGVudGlh bCI6WyJleUpoYkdjaU9pSlNVekkxTmlJc0luUjVjQ0k2SWtwWFZDSXNJbXRwWkNJNkltUnBaRHBsZUdG dGNHeGxPbUZpWm1VeE0yWTNNVEl4TWpBME16RmpNamMyWlRFeVpXTmhZaU5yWlhsekxURWlmUS5leUp6 ZFdJaU9pSmthV1E2WlhoaGJYQnNaVHBsWW1abFlqRm1OekV5WldKak5tWXhZekkzTm1VeE1tVmpNakVp TENKcWRHa2lPaUpvZEhSd09pOHZaWGhoYlhCc1pTNWxaSFV2WTNKbFpHVnVkR2xoYkhNdk16Y3pNaUlz SW1semN5STZJbWgwZEhCek9pOHZaWGhoYlhCc1pTNWpiMjB2YTJWNWN5OW1iMjh1YW5kcklpd2libUpt SWpveE5UUXhORGt6TnpJMExDSnBZWFFpT2pFMU5ERTBPVE0zTWpRc0ltVjRjQ0k2TVRVM016QXlPVGN5 TXl3aWJtOXVZMlVpT2lJMk5qQWhOak0wTlVaVFpYSWlMQ0oyWXlJNmV5SkFZMjl1ZEdWNGRDSTZXeUpv ZEhSd2N6b3ZMM2QzZHk1M015NXZjbWN2TWpBeE9DOWpjbVZrWlc1MGFXRnNjeTkyTVNJc0ltaDBkSEJ6 T2k4dmQzZDNMbmN6TG05eVp5OHlNREU0TDJOeVpXUmxiblJwWVd4ekwyVjRZVzF3YkdWekwzWXhJbDBz SW5SNWNHVWlPbHNpVm1WeWFXWnBZV0pzWlVOeVpXUmxiblJwWVd3aUxDSlZibWwyWlhKemFYUjVSR1Zu Y21WbFEzSmxaR1Z1ZEdsaGJDSmRMQ0pqY21Wa1pXNTBhV0ZzVTNWaWFtVmpkQ0k2ZXlKa1pXZHlaV1Vp T25zaWRIbHdaU0k2SWtKaFkyaGxiRzl5UkdWbmNtVmxJaXdpYm1GdFpTSTZJanh6Y0dGdUlHeGhibWM5 SjJaeUxVTkJKejVDWVdOallXeGhkWExEcVdGMElHVnVJRzExYzJseGRXVnpJRzUxYmNPcGNtbHhkV1Z6 UEM5emNHRnVQaUo5ZlgxOS5LTEpvNUdBeUJORDNMRFRuOUg3RlFva0VzVUVpOGpLd1hoR3ZvTjNKdFJh NTF4ck5EZ1hEYjBjcTFVVFlCLXJLNEZ0OVlWbVIxTklfWk9GOG9HY183d0FwOFBIYkYySGFXb2RRSW9P Qnh4VC00V05xQXhmdDdFVDZsa0gtNFM2VXgzclNHQW1jek1vaEVFZjhlQ2VOLWpDOFdla2RQbDZ6S1pR ajBZUEIxcng2WDAteGxGQnM3Y2w2V3Q4cmZCUF90WjlZZ1ZXclFtVVd5cFNpb2MwTVV5aXBobXlFYkxa YWdUeVBsVXlmbEdsRWRxclpBdjZlU2U2UnR4Snk2TTEtbEQ3YTVIVHphbllUV0JQQVVIRFpHeUdLWGRK dy1XX3gwSVdDaEJ6STh0M2twRzI1M2ZnNlYzdFBnSGVLWEU5NGZ6X1FwWWZnLS03a0xzeUJBZlFHYmci XX19.ft_Eq4IniBrr7gtzRfrYj8Vy1aPXuFZU-6_ai0wvaKcsrzI4JkQEKTvbJwdvIeuGuTqy7ipO-EY i7V4TvonPuTRdpB7ZHOlYlbZ4wA9WJ6mSVSqDACvYRiFvrOFmie8rgm6GacWatgO4m4NqiFKFko3r58L ueFfGw47NK9RcfOkVQeHCq4btaDqksDKeoTrNysF4YS89INa-prWomrLRAhnwLOo1Etp3E4ESAxg73CR 2kA5AoMbf5KtFueWnMcSbQkMRdWcGC1VssC0tB0JffVjq7ZV6OTyV4kl1-UVgiPLXUTpupFfLRhf9Qpq MBjYgP62KvhIvW8BbkGUelYMetA" ]¶
with a matching presentation_submission
parameter.¶
{ "id": "Selective disclosure example presentation", "definition_id": "Selective disclosure example", "descriptor_map": [ { "id": "ID Card with constraints", "format": "ldp_vp", "path": "$[0]", "path_nested": { "format": "ldp_vc", "path": "$[0].verifiableCredential[0]" } }, { "id": "Ontario Health Insurance Plan", "format": "jwt_vp", "path": "$[1].presentation", "path_nested": { "format": "jwt_vc", "path": "$[1].presentation.vp.verifiableCredential[0]" } } ] }¶
Implementations MAY use JARM [JARM] to sign, or sign and encrypt the response on the application level. Furthermore, this specification allows for JARM with encrypted, unsigned responses, in which case, the JWT containing the response parameters is only encrypted.¶
For authorization responses with response type vp_token
, the response JWT contains the following parameters as defined in Section 6.2:¶
The key material used for encryption and signing SHOULD be determined using existing metadata mechanisms, such as the jwks
client metadata parameter.¶
There are use-cases when the Authorization Request was received from a Verifier that is unreachable using redirects (i.e. it is on another device) from the Wallet on which the requested Credential is stored.¶
For such use-cases, this specification defines a new Response Mode direct_post
to enable the Wallet to send the response to the Verifier via an HTTPS connection.¶
This specification defines the following Response Mode in accordance with [OAuth.Responses]:¶
direct_post
In this mode, Authorization Response parameters are encoded in the body using the application/x-www-form-urlencoded
content type and sent using the HTTP POST
method instead of redirecting back to the Client.¶
HTTP POST request MUST be sent to the URL obtained from the redirect_uri
parameter in the Authorization Request.¶
Note that Response Mode "direct_post" could be less secure than redirect-based Response Mode. For details, see Section 11.1.¶
The following is a non-normative example request object with Response Mode direct_post
:¶
{ "client_id": "https://client.example.org/post", "redirect_uri": "https://client.example.org/post", "response_type": "vp_token", "response_mode": "direct_post" "presentation_definition": {...}, "nonce": "n-0S6_WzA2Mj" }¶
that could be used in a request URL like this (either directly or as QR Code).¶
https://wallet.example.com? client_id=https%3A%2F%2Fclient.example.org%2Fcb &request_uri=https%3A%2F%2Fclient.example.org%2F567545564¶
The respective HTTP POST response to the Verifier would look like this:¶
POST /post HTTP/1.1 Host: client.example.org Content-Type: application/x-www-form-urlencoded presentation_submission=...& vp_token=...¶
Note that in the Cross-Device Flow, the Wallet can change the UI based on the Verifier's response to the HTTP POST request.¶
The error response follows the rules as defined in [RFC6749], with the following additional clarifications:¶
invalid_scope
:¶
Requested scope value is invalid, unknown, or malformed.¶
invalid_request
:¶
The request contains more than a presentation_definition
parameter or a presentation_definition_uri
parameter or a
scope value representing a presentation definition.¶
invalid_client
:¶
client_metadata
or client_metadata_uri
parameters defined in Section 9.1 are present, but the Wallet recognizes client_id
and knows metadata associated with it.¶
Pre-registered client metadata has been found based on the client_id
, but client_metadata
parameter is also present.¶
Usage of client_metadata
or client_metadata_uri
parameters with client_id
that the AS might be seeing for the first time is mutualy exclusive with the registration mechanism where Self-Issued OP assigns client_id
to the RP after receiving RP's metadata.¶
This document also defines the following additional error codes and error descriptions:¶
vp_formats_not_supported
¶
The Wallet does not support any of the formats requested by the RP such as those included in the vp_formats
registration parameter.¶
The Verifier has the choice of the following mechanisms to invoke a Wallet:¶
Custom URL scheme as an authorization_endpoint
(for example, openid4vp://
as defined in Section 10.1.2)¶
Domain-bound Universal Links/App link as an authorization_endpoint
¶
no specific authorization_endpoint
, user scanning a QR code with Authorization Request using a manually opened Wallet, instead of an arbitrary camera application on a user-device (neither custom URL scheme nor Universal/App link is used)¶
This specification introduces additional AS metadata to enable Client and AS to determine credential formats, proof types and algorithms to be used in a protocol exchange.¶
This specification introduces additional Client metadata to enable Client and AS to determine credential formats, proof types and algorithms to be used in a protocol exchange.¶
This specification defines the following new client metadata parameters according to [RFC7591]:¶
vp_formats
: REQUIRED. An object defining the formats and proof types of verifiable presentations and verifiable credentials that a RP supports. Valid format identifier values are defined in Annex E of [OpenID.VCI] and include jwt_vc_json
, jwt_vc_json-ld
, ldp_vc
, jwt_vp_json
, jwt_vp_json-ld
, ldp_vp
, and mso_mdoc
. Deployments can extend the formats supported, provided Issuers, Holders and Verifiers all understand the new format.¶
client_metadata
¶
OPTIONAL. This parameter enables RP Metadata to be passed in a single, self-contained parameter. The value is a JSON object containing RP Registration Metadata values. The client metadata parameter value is represented in an OAuth 2.0 request as a UTF-8 encoded JSON object. MUST NOT be present if client_metadata_uri
parameter is present.¶
client_metadata_uri
¶
OPTIONAL. This parameter enables RP Registration Metadata to be passed by reference, rather than by value. The request_uri
value is a URL referencing a resource containing a RP Registration Metadata Object. The scheme used in the client_metadata_uri
value MUST be https. The client_metadata_uri
value MUST be reachable by the AS. MUST NOT be present if client_metadata
parameter is present.¶
Claims to be included in client_metadata
and client_metadata_uri
parameters are defined in Section 4.3 and Section 2.1 of the OpenID Connect Dynamic RP Registration 1.0 [OpenID.Registration] specification as well as [RFC7591].¶
AS utilizing this specification has multiple options to exchange metadata:¶
AS obtains Client metadata prior to a transaction, e.g using [RFC7591] or out-of-band mechanisms. See Section 9.2.1 for the details.¶
Client provides metadata to the AS just-in-time in the Authorization Request using one of the following mechanisms defined in this specification:¶
client_metadata
or client_metadata_uri
parameter when client_id
equals redirect_uri
(see Section 9.2.2.1 for the details), or client_id
is a Decentralized Identifier (see Section 9.2.2.2 for the details).¶
Entity Statement when OpenID Federation 1.0 Automatic Registration is used (see Section 9.2.2.3 for the details).¶
Just-in-time metadata exchange allows OpenID4VP to be used in deployments models where the AS does not or cannot support pre-registration of Client metadata.¶
When the Wallet has obtained Client metadata prior to a transaction, e.g using [RFC7591] or out-of-band mechanisms, client_id
MUST equal to the client identifier the RP has obtained from the Wallet during pre-registration. When the Authorization Request is signed, the public key for signature verification MUST be (re-)obtained using pre-registration process.¶
In this case, client_metadata
and client_metadata_uri
parameters defined in Section 9.1 MUST NOT be present in the Authorization Request.¶
Below is an example for an RP registering using Dynamic Client Registration:¶
{ "client_id": "s6BhdRkqt3", "redirect_uris": [ "https://client.example.org/callback", "https://client.example.org/callback2" ], "client_name": "My Example", "token_endpoint_auth_method": "client_secret_basic", "application_type": "web", "response_types": "code", "grant_types": "authorization_code", "vp_formats": { "jwt_vp": { "alg": [ "EdDSA", "ES256K" ] }, "ldp_vp": { "proof_type": [ "Ed25519Signature2018" ] } } }¶
When the RP has not pre-registered, it may pass its metadata to the AS in the Authorization Request.¶
No registration response is returned. A successful Authorization Response implicitly indicates that the client metadata parameters were accepted.¶
client_id
equals redirect_uri
In the simplest option, the Client can proceed without registration as if it had registered with the Wallet and obtained the following Client Registration Response:¶
In this case, the Authorization Request cannot be signed and all client metadata parameters MUST be passed using client metadata parameter defined in Section 9.1.¶
Below is a non-normative example of a request when client_id
equals redirect_uri
.¶
HTTP/1.1 302 Found Location: https://client.example.org/universal-link? response_type=vp_token &client_id=https%3A%2F%2Fclient.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &presentation_definition=... &nonce=n-0S6_WzA2Mj &client_metadata=%7B%22vp_formats%22:%7B%22jwt_vp%22:% 7B%22alg%22:%5B%22EdDSA%22,%22ES256K%22%5D%7D,%22ldp _vp%22:%7B%22proof_type%22:%5B%22Ed25519Signature201 8%22%5D%7D%7D%7D¶
The client_id
MAY be expressed as a Decentralized Identifier as defined in [DID-Core].¶
The Authorization Request MUST be signed. A public key to verify the signature MUST be obtained from the verificationMethod
property of a DID Document. Since DID Document may include multiple public keys, a particular public key used to sign the request in question MUST be identified by the kid
in the header. To obtain the DID Document, AS MUST use DID Resolution defined by the DID method used by the RP.¶
All RP metadata other than the public key MUST be obtained from the client_metadata
parameter as defined in Section 9.1.¶
Below is a non-normative example of a request when client_id
is a DID, sent as a request object using request_uri
:¶
{ "client_id": "did:example:123", "redirect_uris": [ "https://client.example.org/callback" ], "client_name": "My Example (SIOP)", "application_type": "web", "response_types": "vp_token id_token", "client_metadata": { "vp_formats": { "jwt_vp": { "alg": [ "EdDSA", "ES256K" ] }, "ldp_vp": { "proof_type": [ "Ed25519Signature2018" ] } } } }¶
When Relying Party's client_id
is expressed as an https
URI, and does not equal to a redirect_uri
value when using simple string comparison ([RFC3986] section 6.2.1), Automatic Registration defined in [OpenID.Federation] MUST be used. The Relying Party's Entity Identifier defined in Section 1.2 of [OpenID.Federation] MUST be client_id
.¶
The Authorization Request MUST be signed. The AS MUST obtain the public key from the jwks
property in the Relying Party's Entity Statement defined in Section 3.1 of [OpenID.Federation]. Metadata other than the public keys MUST also be obtained from the Entity Statement.¶
Note that to use Automatic Registration, clients would be required to have an individual identifier and an associated public key(s), which is not always the case for the public/native app clients.¶
Often RPs will want to request Verifiable Credentials from an issuer who is a member of a federation or trust scheme, rather than from a specific issuer, for example, a "BSc Chemistry Degree" credential from a US University rather than from a specifically named university.¶
In order to facilitate this, federations will need to determine how an issuer can indicate in a verifiable credential that they are a member of one or more federations/trust schemes. Once this is done, the RP will be able to create a presentation_definition
that includes this filtering criteria. This will enable the wallet to select all the Verifiable Credentials that match this criteria and then by some means (for example, by asking the user) determine which matching verifiable credential to return to the RP. Upon receiving this verifiable credential, the RP will be able to call its federation API to determine if the issuer is indeed a member of the federation/trust scheme that it says it is.¶
Indicating the federations/trust schemes that an issuer is a member of may be achieved by defining a termsOfUse
property [VC_DATA].¶
Note: [VC_DATA] describes terms of use as "can be utilized by an issuer ... to communicate the terms under which a verifiable credential ... was issued."¶
The following terms of use may be defined:¶
{ "termsOfUse":[ { "type":"<uri that identifies this type of terms of use>", "federations":[ "<list of federations/trust schemes the issuer asserts it is a member of>" ] } ] }¶
Federations that conform to those specified in [OpenID.Federation] are identified by the type
urn:ietf:params:oauth:federation
. Individual federations are identified by the entity id of the trust anchor. If the federation decides to use trust marks as signs of whether an entity belongs to a federation or not then the federation is identified by the type
urn:ietf:params:oauth:federation_trust_mark
and individual federations are identified by the entity id of the trust mark issuer.¶
Trust schemes that conform to the TRAIN [TRAIN] trust scheme are identified by the type
https://train.trust-scheme.de/info
. Individual federations are identified by their DNS names.¶
An example claims
parameter containing a presentation_definition
that filters VCs based on their federation memberships is given below.¶
{ "vp_token": { "presentation_definition": { "id": "32f54163-7166-48f1", "input_descriptors": [ { "id": "federationExample", "purpose": "To pick a UK university that is a member of the UK academic federation", "constraints": { "fields": [ { "path": [ "$.termsOfUse.type" ], "filter": { "type": "string", "const": "https://train.trust-scheme.de/info" } }, { "path": [ "$.termsOfUse.federations" ], "filter": { "type": "string", "const": "ukuniversities.ac.uk" } } ] } } ] } } }¶
This example will chose a VC that has been issued by a university that is a member of the ukuniversities.ac.uk
federation and that uses the TRAIN terms of use specification for asserting federation memberships.¶
Current version of this document does not support presentation of a VP nested inside another VP, even though [DIF.PresentationExchange] specification theoretically supports this by stating that the nesting of path_nested
objects "may be any number of levels deep".¶
One level of nesting path_nested
objects is sufficient to describe a VC included inside a VP.¶
When HTTP "POST" method is used to send VP Token, there is no session for the Verifier to validate whether the Response is sent by the same Wallet that has received the Authorization Request. It is RECOMMENDED for the Verifiers to implement mechanisms to strengthen such binding.¶
To prevent replay attacks, verifiable presentation container objects MUST be linked to client_id
and nonce
from the Authentication Request. The client_id
is used to detect presentation of Verifiable Credentials to a different party other than the intended. The nonce
value binds the presentation to a certain authentication transaction and allows the verifier to detect injection of a presentation in the OpenID Connect flow, which is especially important in flows where the presentation is passed through the front-channel.¶
Note: These values MAY be represented in different ways in a verifiable presentation (directly as claims or indirectly be incorporation in proof calculation) according to the selected proof format denoted by the format claim in the verifiable presentation container.¶
Note: This specification assumes that a verifiable credential is always presented with a cryptographic proof of possession which can be a Verifiable presentation. This cryptographic proof of possession is bound to audience and transaction as described in this section.¶
Here is a non-normative example for format=jwt_vp
(only relevant part):¶
{ "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21", "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5", "aud": "s6BhdRkqt3", "nonce": "343s$FSFDa-", "nbf": 1541493724, "iat": 1541493724, "exp": 1573029723, "vp": { "@context": [ "<https://www.w3.org/2018/credentials/v1",> "<https://www.w3.org/2018/credentials/examples/v1"> ], "type": ["VerifiablePresentation"], "verifiableCredential": [""] } }¶
In the example above, the requested nonce
value is included as the nonce
and client_id
as the aud
value in the proof of the verifiable presentation.¶
Here is a non-normative example for format=ldp_vp
(only relevant part):¶
{ "@context": [ ... ], "type": "VerifiablePresentation", "verifiableCredential": [ ... ], "proof": { "type": "RsaSignature2018", "created": "2018-09-14T21:19:10Z", "proofPurpose": "authentication", "verificationMethod": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1", "challenge": "343s$FSFDa-", "domain": "s6BhdRkqt3", "jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5 XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh 4vGHSrQyHUGlcTwLtjPAnKb78" } }¶
In the example above, the requested nonce
value is included as the challenge
and client_id
as the domain
value in the proof of the verifiable presentation.¶
A verifier MUST validate the integrity, authenticity, and holder binding of any verifiable presentation provided by an OP according to the rules of the respective presentation format.¶
This requirement holds true even if those Verifiable Presentations are embedded within a signed OpenID Connect assertion, such as an ID Token or a UserInfo response. This is required because Verifiable Presentations might be signed by the same holder but with different key material and/or the OpenID Connect assertions may be signed by a third party (e.g., a traditional OP). In both cases, just checking the signature of the respective OpenID Connect assertion does not, for example, check the holder binding.¶
Note: Some of the available mechanisms are outlined in Section 4.3.2 of [DIF.PresentationExchange].¶
It is NOT RECOMMENDED for the Subject to delegate the presentation of the credential to a third party.¶
In many instances the referenced server will be operated by a known federation or other trusted operator, and the URL's domain name will already be widely known. OPs (including SIOPs) using this URI can mitigate request forgeries by having a pre-configured set of trusted domain names and only fetching presentation_definitions from these sources. In addition, the presentation definitions could be signed by a trusted authority, such as the ICO or federation operator.¶
Clients intending to authenticate the end-user utilizing a claim in a verifable credential MUST ensure this claim is stable for the end-user as well locally unique and never reassigned within the credential issuer to another end-user. Such a claim MUST also only be used in combination with the issuer identifier to ensure global uniqueness and to prevent attacks where an attacker obtains the same claim from a different issuer and tries to impersonate the legitimate user.¶
OpenID for Verifiable Presentations is credential format agnostic, i.e. it is designed to allow applications to request and receive Verifiable Presentations and Verifiable Credentials in any format, not limited to the formats defined in [VC_DATA]. This section aims to illustrate this with examples utilizing different credential formats. Customization of OpenID for Verifiable Presentation for credential formats other than those defined in [VC_DATA] uses extensions points of Presentation Exchange [DIF.PresentationExchange].¶
The following is an JWT-based W3C Verifiable Credential that will be used through this section.¶
{ "iss": "https://example.gov/issuers/565049", "nbf": 1262304000, "jti": "http://example.gov/credentials/3732", "sub": "did:example:ebfeb1f712ebc6f1c276e12ec21", "vc": { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "type": [ "VerifiableCredential", "IDCredential" ], "credentialSubject": { "given_name": "Max", "family_name": "Mustermann", "birthdate": "1998-01-11", "address": { "street_address": "Sandanger 25", "locality": "Musterstadt", "postal_code": "123456", "country": "DE" } } } }¶
This is an example presentation request.¶
GET /authorize? response_type=vp_token &client_id=https%3A%2F%2Fclient.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &presentation_definition=... &nonce=n-0S6_WzA2Mj HTTP/1.1 Host: wallet.example.com¶
The requirements regarding the credential to be presented are conveyed in the presentation_definition
parameter. It's content is is given in the following example.¶
{ "id": "example_jwt_vc", "input_descriptors": [ { "id": "id_credential", "format": { "jwt_vc": { "proof_type": [ "JsonWebSignature2020" ] } }, "constraints": { "fields": [ { "path": [ "$.vc.type" ], "filter": { "type": "array", "contains": { "const": "IDCredential" } } } ] } } ] }¶
It contains a single input_descriptor
, which sets the desired format to JWT VC and defines a constraint over the vc.type
parameter to select Verifiable Credentials of type IDCredential
.¶
An example presentation response look like this:¶
HTTP/1.1 302 Found Location: https://client.example.org/cb# presentation_submission=... &vp_token=...¶
The content of the presentation_submission
is given in the following:¶
{ "definition_id": "example_jwt_vc", "id": "example_jwt_vc_presentation_submission", "descriptor_map": [ { "id": "id_credential", "path": "$", "format": "jwt_vp", "path_nested": { "path": "$.vp.verifiableCredential[0]", "format": "jwt_vc" } } ] }¶
It refers to the VP in the vp_token
parameter provided in the same response, which looks as follows.¶
{ "iss": "did:example:ebfeb1f712ebc6f1c276e12ec21", "jti": "urn:uuid:3978344f-8596-4c3a-a978-8fcaba3903c5", "aud": "https://client.example.org/cb", "nbf": 1541493724, "iat": 1541493724, "exp": 1573029723, "nonce": "n-0S6_WzA2Mj", "vp": { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "type": [ "VerifiablePresentation" ], "verifiableCredential": [ "eyJhbGci...Qssw5c" ] } }¶
Note: the VP's nonce
claim contains the value of the nonce
of the presentation request and the aud
claims contains the client id of the verifier. This allows the verifier to detect replay of a presentation as recommened in Section 11.2.¶
The following is an LDP-based W3C Verifiable Credential that will be used through this section.¶
{ "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "https://example.com/credentials/1872", "type": [ "VerifiableCredential", "IDCredential" ], "issuer": { "id": "did:example:issuer" }, "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "given_name": "Max", "family_name": "Mustermann", "birthdate": "1998-01-11", "address": { "street_address": "Sandanger 25", "locality": "Musterstadt", "postal_code": "123456", "country": "DE" } }, "proof": { "type": "Ed25519Signature2018", "created": "2021-03-19T15:30:15Z", "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..PT8yCqVjj5ZHD0W36zsBQ47oc3El07WGPWaLUuBTOT48IgKI5HDoiFUt9idChT_Zh5s8cF_2cSRWELuD8JQdBw", "proofPurpose": "assertionMethod", "verificationMethod": "did:example:issuer#keys-1" } }¶
This is an example presentation request.¶
GET /authorize? response_type=vp_token &client_id=https%3A%2F%2Fclient.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &presentation_definition=... &nonce=n-0S6_WzA2Mj HTTP/1.1 Host: wallet.example.com¶
The requirements regarding the credential to be presented are conveyed in the presentation_definition
parameter. It's content is is given in the following example.¶
{ "id": "example_ldp_vc", "input_descriptors": [ { "id": "id_credential", "format": { "ldp_vc": { "proof_type": [ "Ed25519Signature2018" ] } }, "constraints": { "fields": [ { "path": [ "$.type" ], "filter": { "type": "array", "contains": { "const": "IDCredential" } } } ] } } ] }¶
It contains a single input_descriptor
, which sets the desired format to LDP VC and defines a constraint over the type
parameter to select Verifiable Credentials of type IDCardCredential
.¶
An example presentation response look like this:¶
HTTP/1.1 302 Found Location: https://client.example.org/cb# presentation_submission=... &vp_token=...¶
The content of the presentation_submission
is given in the following:¶
{ "definition_id": "example_ldp_vc", "id": "example_ldp_vc_presentation_submission", "descriptor_map": [ { "id": "id_credential", "path": "$", "format": "ldp_vp", "path_nested": { "format": "ldp_vc", "path": "$.verifiableCredential[0]" } } ] }¶
It refers to the VP in the vp_token
parameter provided in the same response, which looks as follows.¶
{ "@context": [ "https://www.w3.org/2018/credentials/v1" ], "type": [ "VerifiablePresentation" ], "verifiableCredential": [ { "@context": [ "https://www.w3.org/2018/credentials/v1", "https://www.w3.org/2018/credentials/examples/v1" ], "id": "https://example.com/credentials/1872", "type": [ "VerifiableCredential", "IDCredential" ], "issuer": { "id": "did:example:issuer" }, "issuanceDate": "2010-01-01T19:23:24Z", "credentialSubject": { "given_name": "Max", "family_name": "Mustermann", "birthdate": "1998-01-11", "address": { "street_address": "Sandanger 25", "locality": "Musterstadt", "postal_code": "123456", "country": "DE" } }, "proof": { "type": "Ed25519Signature2018", "created": "2021-03-19T15:30:15Z", "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..PT8yCqVjj5ZHD0W36zsBQ47oc3El07WGPWaLUuBTOT48IgKI5HDoiFUt9idChT_Zh5s8cF_2cSRWELuD8JQdBw", "proofPurpose": "assertionMethod", "verificationMethod": "did:example:issuer#keys-1" } } ], "id": "ebc6f1c2", "holder": "did:example:holder", "proof": { "type": "Ed25519Signature2018", "created": "2021-03-19T15:30:15Z", "challenge": "n-0S6_WzA2Mj", "domain": "https://client.example.org/cb", "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..GF5Z6TamgNE8QjE3RbiDOj3n_t25_1K7NVWMUASe_OEzQV63GaKdu235MCS3hIYvepcNdQ_ZOKpGNCf0vIAoDA", "proofPurpose": "authentication", "verificationMethod": "did:example:holder#key-1" } }¶
Note: the VP's challenge
claim contains the value of the nonce
of the presentation request and the domain
claims contains the client id of the verifier. This allows the verifier to detect replay of a presentation as recommened in Section 11.2.¶
AnonCreds is a credential format defined as part of the Hyperledger Indy project [Hyperledger.Indy].¶
To be able to request AnonCreds, there needs to be a set of identifiers for Verifiable Credentials, Verifiable Pesentations ("proofs" in Indy terminology) and crypto schemes. For the purpose of this example, the following identifiers are used:¶
ac_vc
: designates a credential in AnonCreds format.¶
ac_vp
: designates a presentation in AnonCreds format.¶
CLSignature2019
: identifies the CL-signature scheme used in conjunction with AnonCreds.¶
The following is an example AnonCred credential that will be used through this section.¶
{ "schema_id": "3QowxFtwciWceMFr7WbwnM:2:BasicScheme:0.1", "cred_def_id": "CsiDLAiFkQb9N4NDJKUagd:3:CL:4687:awesome_cred", "rev_reg_id": null, "values": { "first_name": { "raw": "Alice", "encoded": "6874ecdbdb214ee888e37c8c983e2f1c9c0ed16907b519704db42bb6" }, "last_name": { "raw": "Wonderland", "encoded": "f5e16db78511f23bf2bcf0f450f20180951557cd75efe88b276988fd" }, "email": { "raw": "alice@example.com", "encoded": "0fbaa7f92a47fe3c5201e97f063983c702432e90dd7bf0c723386543" } }, "signature": { "p_credential": { "m_2": "99219524012997799443220800218760023447537107640621419137185629243278403921312", "a": "54855652574677988116650236306088516361537734570414909367032672219103444197205489674846545082012012711261249754371310495367475614729209653850720034913398482184757254920537051297936910125023613323255317515823974231493572903991640659741108603715378490408836507643191051986137793268856316333600932915078337920001692235029278931184173692694366223663131943657834349339828618978436402973046999961539444380116581314372906598415014528562207334745774098097000567515212222894771357044500544552372314335894883000614144994856702181141090905033428221403654636324918343808136750040908443212492359485782471636294013062295153997068252", "e": "259344723055062059907025491480697571938277889515152306249728583105665800713306759149981690559193987143012367913206299323899696942213235956742930239825562861075148170278284639129199", "v": "9774232256179658261610308745866736090602538333363396375105120427156273261155207775732400073422905045147609169788952804683922921383859274758479842100138659865591976937215264032734277416744113491766616076612368115891637834588143840477778776159325514034900968730327459279564615858068472282705529798808334108833124505594371791348317639533993310391511620579199112357959170076753792711700533312522910797352842323445933004238048599164039686432144165884599052061538014126710866075791210006585893465085621395503182710866197817129408546193805893321161372355187962990595781339533851533077334790530438016817333603675910702146635975282253747819810788129751055728368937483121363992748831475139233180853145906108476753713239644943541916540123456371366974874702598201796929261151925643543132170495933035112012082080893049915977209167597" }, "r_credential": null }, "signature_correctness_proof": { "se": "8986500246928105545119249693120482606913996376875337975817228090569777886100120575851444392132175485176800946276729875298747664099989412623249056022784348808658577491758644556594901203598819936532435225959211617545841036816799892165118015169512229910557670483101499028188851318984001732266955939801843049852569586066803442690248386970226324039561954050567607010646624132392374280640663854092050106203821468403658338788408023014151088931308776669398184180228869449717267624484235796469721889284094131533549692106113602342932288350356591343546227828642494647872633442330361211149649432468143339518371824496555067302935", "c": "93582993140981799598406702841334282100000866001274710165299804498679784215598" }, "rev_reg": null, "witness": null }¶
The most important parts for the purpose of this example are scheme_id
parameter and values
parameter that contains the actual End-user claims.¶
The example presentation request looks as follows:¶
GET /authorize? response_type=vp_token &client_id=https%3A%2F%2Fclient.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &presentation_definition=... &nonce=n-0S6_WzA2Mj HTTP/1.1 Host: wallet.example.com¶
The following is the content of the presentation_definition
parameter.¶
{ "id": "example_vc_ac", "input_descriptors": [ { "id": "id_credential", "format": { "ac_vc": { "proof_type": [ "CLSignature2019" ] } }, "constraints": { "fields": [ { "path": [ "$.schema_id" ], "filter": { "type": "string", "const": "did:indy:idu:test:3QowxFtwciWceMFr7WbwnM:2:BasicScheme:0\\.1" } } ] } } ] }¶
The format
object of the input_descriptor
uses the format identifier ac_vc
as defined above and sets the proof_type
to CLSignature2019
to denote this descriptor requires a credential in AnonCreds format signed with a CL signature (Camenisch-Lysyanskaya siganture). The rest of the expressions operate on the AnonCreds JSON structure.¶
The constraints
object requires the selected credential to conform with the schema definition did:indy:idu:test:3QowxFtwciWceMFr7WbwnM:2:BasicScheme:0\\.1
, which is denoted as a constraint over the AnonCred's schema_id
parameter.¶
The next example leverages the AnonCreds' capabilities for selective disclosure by requesting a subset of the claims in the credential to be disclosed to the verifier.¶
The presentation looks the same as above. The difference is in the presentation_definition
parameter as shown in the following:¶
{ "id": "example_vc_ac_sd", "input_descriptors": [ { "id": "id_credential", "format": { "ac_vc": { "proof_type": [ "CLSignature2019" ] } }, "constraints": { "limit_disclosure": "required", "fields": [ { "path": [ "$.schema_id" ], "filter": { "type": "string", "const": "did:indy:idu:test:3QowxFtwciWceMFr7WbwnM:2:BasicScheme:0\\.1" } }, { "path": [ "$.values.first_name" ] }, { "path": [ "$.values.last_name" ] } ] } } ] }¶
This example is identic to the previous one with the following exceptions: It sets the elememt limit_disclosure
of the constraint to require
and adds two more constraints for the individual claims given_name
and family_name
. Since such claims are stored underneath a values
container in an AnonCred, values
is part of the path to identify the respective claim.¶
The presentation response looks the same as fot the other examples.¶
HTTP/1.1 302 Found Location: https://client.example.org/cb# presentation_submission=... &vp_token=...¶
It contains the presentation_submission
and vp_token
parameters.¶
The presentation submission
looks like this:¶
{ "definition_id": "example_vc_ac_sd", "id": "example_vc_ac_sd_presentation_submission", "descriptor_map": [ { "id": "id_credential", "path": "$", "format": "ac_vp", "path_nested": { "path": "$.requested_proof.revealed_attr_groups.id_card_credential", "format": "ac_vc" } } ] }¶
The descriptor_map
refers to the input descriptor ref2
and tells the verifier that there is a proof of AnonCred credential (format
is ac_vp
) directly in the vp_token (path is the root designated by $
). Furthermore it indicates using nested_path
parameter that the user claims can be found embedded in the proof underneath requested_proof.revealed_attr_groups.ref2
.¶
The following is a VP Token example.¶
{ "proof": {...}, "requested_proof": { "revealed_attrs": {}, "revealed_attr_groups": { "id_credential": { "sub_proof_index": 0, "values": { "last_name": { "raw": "Wonderland", "encoded": "167908493...94017654562035" }, "first_name": { "raw": "Alice", "encoded": "270346400...99344178781507" } } } }, ... }, "identifiers": [ { "schema_id": "3QowxFtwciWceMFr7WbwnM:2:BasicScheme:0.1", "cred_def_id": "CsiDLAiFkQb9N4NDJKUagd:3:CL:4687:awesome_cred", "rev_reg_id": null, "timestamp": null } ] }¶
This section illustrates how a mobile driving licence (mDL) credential expressed using a data model and data sets defined in [ISO.18013-5] can be presented from the End-User's device directly to the RP using this specification.¶
To request an ISO/IEC 18013-5:2021 mDL, following identifiers are used for the purposes of this example:¶
mdl_iso_cbor
: designates a mobile driving licence (mDL) credential encoded as CBOR, expressed using a data model and data sets defined in [ISO.18013-5].¶
mdl_iso_json
: designates a mobile driving licence (mDL) credential encoded as JSON, expressed using a data model and data sets defined in [ISO.18013-5].¶
The presentation request looks the same as for the other examples since the difference is in the content of the presentation_definition
parameter.¶
GET /authorize? response_type=vp_token &client_id=https%3A%2F%2Fclient.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &presentation_definition=... &nonce=n-0S6_WzA2Mj HTTP/1.1 Host: wallet.example.com¶
The content of the presentation_definition
parameter is as follows:¶
{ "id": "mDL-sample-req", "input_descriptors": [ { "id": "mDL", "format": { "mdl_iso_cbor": { "alg": [ "EdDSA", "ES256" ] }, "constraints": { "limit_disclosure": "required", "fields": [ { "path": [ "$.mdoc.doctype" ], "filter": { "type": "string", "const": "org.iso.18013.5.1.mDL" } }, { "path": [ "$.mdoc.namespace" ], "filter": { "type": "string", "const": "org.iso.18013.5.1" } }, { "path": [ "$.mdoc.family_name" ], "intent_to_retain": "false" }, { "path": [ "$.mdoc.portrait" ], "intent_to_retain": "false" }, { "path": [ "$.mdoc.driving_privileges" ], "intent_to_retain": "false" } ] } } } ] }¶
To start with, the format
parameter of the input_descriptor
is set to mdl_iso_cbor
, i.e. it requests presentation of a mDL in CBOR format.¶
To request user claims in ISO/IEC 18013-5:2021 mDL, a doctype
and namespace
of the claim needs to be specified. Moreover, the verifiers needs to indicate whether it intends to retain obtained user claims or not, using intent_to_retain
property.¶
Note: intent_to_retain
is a property introduced in this example to meet requirements of [ISO.18013-5].¶
Setting limit_disclosure
property defined in [DIF.PresentationExchange] to required
enables selective release by instructing the wallet to submit only the data parameters specified in the fields array. Selective release of claims is a requirement built into an ISO/IEC 18013-5:2021 mDL data model.¶
The presentation response looks the same as for the other examples.¶
HTTP/1.1 302 Found Location: https://client.example.org/cb# presentation_submission=... &vp_token=...¶
The following shows the presentation_submission
content:¶
{ "definition_id": "mDL-sample-req", "id": "mDL-sample-res", "descriptor_map": [ { "id": "mDL", "format": "mdl_iso_cbor", "path": "$" } ] }¶
The descriptor_map
refers to the input descriptor mDL
and tells the verifier that there is an ISO/IEC 18013-5:2021 mDL (format
is mdl_iso_cbor
) in CBOR encoding directly in the vp_token
(path is the root designated by $
).¶
When ISO/IEC 18013-5:2021 mDL is expressed in CBOR the nested_path
parameter cannot be used to point to the location of the requested claims. The user claims will always be included in the issuerSigned
item. nested_path
parameter can be used, however, when a JSON-encoded ISO/IEC 18013-5:2021 mDL is returned.¶
The following is a non-normative example of an ISO/IEC 18013-5:2021 mDL encoded as CBOR in diagnostic notation (line wraps within values are for display purposes only) as conveyed in the vp_token
parameter.¶
TBD: shouldn't the vp_token parameter be base64url encoded?¶
{ "status": 0, "version": "1.0", "documents": [ { "docType": "org.iso.18013.5.1.mDL", "deviceSigned": { "deviceAuth": { "deviceMac": [ << {1: 5} >>, {}, null, h'A574C64F18902BFE18B742F17C581218F88EA279AA96D0F5888123843461A3B6' ] }, "nameSpaces": 24(h'A0') }, "issuerSigned": { "issuerAuth": [ << {1: -7} >>, { 33: h'30820215308201BCA003020102021404AD06A30C1A6DC6E93BE0E2E8F78DCAFA7907C2300A06082A8648CE3D040302305B310B3009060355040613025A45312E302C060355040A0C25465053204D6F62696C69747920616E64205472616E73706F7274206F66205A65746F706961311C301A06035504030C1349414341205A65746573436F6E666964656E73301E170D3231303932393033333034355A170D3232313130333033333034345A3050311A301806035504030C114453205A65746573436F6E666964656E7331253023060355040A0C1C5A65746F70696120436974792044657074206F662054726166666963310B3009060355040613025A453059301306072A8648CE3D020106082A8648CE3D030107034200047C5545E9A0B15F4FF3CE5015121E8AD3257C28D541C1CD0D604FC9D1E352CCC38ADEF5F7902D44B7A6FC1F99F06EEDF7B0018FD9DA716AEC2F1FFAC173356C7DA3693067301F0603551D23041830168014BBA2A53201700D3C97542EF42889556D15B7AC4630150603551D250101FF040B3009060728818C5D050102301D0603551D0E04160414CE5FD758A8E88563E625CF056BFE9F692F4296FD300E0603551D0F0101FF040403020780300A06082A8648CE3D0403020347003044022012B06A3813FFEC5679F3B8CDDB51EAA4B95B0CBB1786B09405E2000E9C46618C02202C1F778AD252285ED05D9B55469F1CB78D773671F30FE7AB815371942328317C' }, << 24(<< { "docType": "org.iso.18013.5.1.mDL", "version": "1.0", "validityInfo": { "signed": 0("2022-04-15T06:23:56Z"), "validFrom": 0("2022-04-15T06:23:56Z"), "validUntil": 0("2027-01-02T00:00:00Z") }, "valueDigests": { "org.iso.18013.5.1": { 1: h'0F1571A97FFB799CC8FCDF2BA4FC29099290AAD37AE37ACE3C3BAE85C6379AD5', 2: h'0CDFE077400432C055A2B69596C90AAA47277C9678BFFC32BBC7F0CF82713B8E', 3: h'E2382149255AE8E955AF9B8984395315F3A38427C267F910A637D3FC81F25BB4', 4: h'BBC77E6CCA981A3AD0C3E544EDF8B68F19F4DACF1AF2AA0E6436401B4539ABA2', 6: h'BB6E6C68D1B4B4EC5A2AE9206F5F976A32061FA878BD5B44476F96D35462F6B2', 8: h'F8A5966E6DAC9970E0334D8F75E24DC63832E73A56AEF21C0D4B91487FC6AB03', 9: h'EAD5E8B5E543BD31F3BE57DE4ED6CCF7BB635221725F80538165DA7DC0BF92BB', 11: h'38CE9A09DC0121E1A9C2EF3EE2456530C2183AA8326FBE13B7D19A17DF77E980', 12: h'DEFDF1AA746718016EF1B94BFE5FB7774B8665F57D48ADAB83ABE0B28C22DB59', 13: h'A8868DF71AA4FB7D0AD3459C2E75E63767FE477B5A8FDF45537E936AFAB59C44', 15: h'95B651F1BA60EF5867E63E8DB1B0328464E5B66775E213B743A1E31F8EFBD9CB', 16: h'364E3C65D46D06FEDEB0E7293A86BA45FDFA99AA1A6DA3C3289B6E073B589922', 17: h'B584E5D5EF4CFC93FDB1E4EE8F3996090EF0B1E8FD2AC594D7D8793093BB328F', 18: h'677468F3E28CAAB521337E0FEF7FFEB067D2A2704F88B5D50D84CAF17209BA25', 19: h'95501E3E769230DC945CFBDC707C45218459F1129EFD5088BDA672CEF5991598', 20: h'677FACBBCA2EB9306BD649227B9AD66DF4A9AF6A5AB7D073F1BAAC23254B6D78', 22: h'BCCFB15CB36125BF1ECBFDE32FF908BD3BAA2DC0BA949B673E96CBA26902059F', 23: h'F9EE4D36F67DBD75E23311AC1C294C563992463A30B47039D25E03B6C6EFFCA3', 25: h'AFC5A127BE44753172844B13491D880C3768691A4C9916E5257CEFA4BAA74654', 26: h'1E1DA854356D3CFB7D983B8105F8A081057D4D01E910F263143BDC9AF1EF363C' } }, "deviceKeyInfo": { "deviceKey": { 1: 2, -1: 1, -2: h'B820963964E53AF064686DD9218303494A5B23A175C34CC54AD1D9244EFD0BA5', -3: h'0A6DA0AF437E2943F1836F31C678D89298E93D7E95057FD4D04E8E3EC2BBA935' } }, "digestAlgorithm": "SHA-256" } >>) >>, h'1AD0D6A7313EFDC38FCD765852FA2BD43DEBF48BF5A516960A685162B2B8242935861329ECB54F68234FC88A0228EC5DF22CB9689EC5053C80EDC59CC99EE80D' ], "nameSpaces": { "org.iso.18013.5.1": [ 24(<< { "digestID": 1, "random": h'E0B70BCEFBD43686F345C9ED429343AA', "elementIdentifier": "expiry_date", "elementValue": 1004("2030-02-22") } >>), 24(<< { "digestID": 6, "random": h'AE84834F389EE69888665B90A3E4FCCE', "elementIdentifier": "given_name", "elementValue": "Doe" } >>), 24(<< { "digestID": 11, "random": h'960CB15A2EA9B68E5233CE902807AA95', "elementIdentifier": "issuing_country", "elementValue": "UT" } >>), 24(<< { "digestID": 13, "random": h'9D3774BD5994CCFED248674B32A4F76A', "elementIdentifier": "document_number", "elementValue": "ES24689" } >>), 24(<< { "digestID": 15, "random": h'EB12193DC66C6174530CDC29B274381F', "elementIdentifier": "portrait", "elementValue": h'89504E470D0A1A0A0000000D49484452000001F3000001F20803000000C88DD7DC0000001974455874536F6674776172650041646F626520496D616765526561647971C9653C00000180504C5445336D82D0B293417E9A4848484684A24A8CAE306A7ED1C8D144809D357085407D993F7B96B3B3B0275D718687864765734886A54A8BAC3E7A954A8AAB38738ACFA8CE4686A53C7993FEE6CF4787A74785A44584A33D7A94A18B7655555543819E3A768F498AACE4D6E339748D4B8CADAC67AA71706F74878436718845565D4545454A5F68FEF0E3395965E2C5A545748A2E5A69FDDCBCB0AA9737515A515151F1CAA33B77904C4C4C3E7B96939B986D929EB79C824783A044494BD1BDA35B899BA0A5A2466D7D4C839AFDD2A84F879F424D524C8DAF515B5FFFFFFF467E9AA458A25357594888A840778F42809C4989A94582A04583A1417F9B40748B4482A043819D4483A14888A7407C973C78913A758D3E79934889AA3B7891427F9C42809D4889A9498AAA3A758E417E994988A843809D39748CBA82B9E9E6E98E7C6CF3F3F3E6BD9E50555773685D5E5E5FFDD5AE5C5651504D4BF9F4F9F3EAF3FEFCF9675F57FEF8F14170845C7A7E38748E6A4E69487F9B467B94925591816E80534A530E2CDF5E00001E3B4944415478DAECDDEB6313C77600F031A212B13D1675E340C15EA7BAB588A41819635FD72832288A6AC55CA879A55052726FD35BD960630C01737BDDF65FAF64F9A1C7AE761E6766CE91E77C49F20556FBCB397366667796FD33C2F89BC8F8C793F8DB88F887BF0B8D3FFDE9E79F7FFEE31FFFA533FED015FFF9877F6DC6DFF7C5E5767C751447FF7AAD372E5E3F8D8B47F1E8347E3A8AA7EDD83C89E6BFCF76C7B3A3F8F3A54B977EF9E56167BC3A89C7EDB8D015BF8E76C6F3EE18EB89C9C9C9E9664C4E324F7EDEC8319A7B72B3E4D3CC939F37727CE69EDC34393A734F6E9C1C9BB927374F8ECCDC935B20C765EEC96D90A332F7E456C831997B723BE45798273F6FE42F99273F6FE468CC3DB935722CE69EDC1E3912734F6E911C87B927B7498EA26FF7E456C931987B72BBE408CC3DB96572F7E69EDC36B973734F6E9DDCB5B927B74FEED8DC933B20776BEEC95D903B35F7E44EC85D9A7B7237E40ECD3DB923F217CC939F377267E69EDC19B92B734FEE8EDC91B9277748EEC6DC93BB247762EEC99D92BB30F7E46EC91D987B72C7E4F6CD3DB96B72EBE69EDC39F9BF334F7EDEC82D9B7B7204E476CD3D390672ABE69E1C05B94D734F8E83FCF7CC939F37727BE69E1C0BB935734F8E86DC96B927C7436EC9DC932322B763EEC931915B31F7E4A8C86D987B725CE416CC3D393272F3E69E1C1BB971734F8E8EDCB4B927C7476ED8DC932324FF9A79F2F3466ED4DC93A3243769EEC971921B34F7E448C9CD997B72ACE4C6CC3D395A7253E69E1C2FB921734F8E98DC8CB927C74C6EC4DC93A3263761EEC971931B30F7E4C8C9FF839D1FF2C362259DCE35A3963F895AEB3FD3E974B1788EC8C1CD31926F36B173E57C4CD49AF8C54BE7801CDA1C1DF961A523AD05A29C4B1F1C0E37F9BFB12126FFB1129FDD51F0C5E1258735C7447E98AEE5B5A2E93E9CE4A0E678C8B5C14FDD0F878F1CD21C0BF9771518F0E3D62E5D1C3272407324E43FA6CB79E0A8158AC3440E678E83FCC742DE48D45A457E48C8C1CC51909B126F8FED0743420E658E817CD3A4783BD97F1D067220730CE49572DE7C140EE993C39823203FACE5ED44AE489DFC776C38C8D3797BD154274D0E61EE9EDC5A929FAA5326FF2F3604E45646F21EF543BAE4FAE6EEC90B79175138A44AAE6DEE9C7CB3967713E50A51725D73D7E4C58A2BF256817F40925CD3DC297931EDD0BB1D698AE47AE60EC98B85721E419CA63A21722D7367E4DF556A792451AE9023D7317745FE5DBA9C4714056AE41AE6AEC82BA8C45BF5FD392D72757347E4C55A1E5DD41E902257367743FE5D3A8F31CA4F2891AB9ABB213FACE5F378D1A9907FC9089157F268A3894E865CCDDC09F977853CE2288F9121573277435ECBA38EDA181572157327E47F454EDE9CB25121573077427E58CEA38F34117279734F1E194F68904B9BFBB17CC0904E835CD6DC930FACEE24C825CDDDCCCB73792AF18402B99CB91BF23419F27C8E02B994B95F7D8B8DF931FCE432E66EC8FF5AA6645EE663E8C925CC1D6D9ED6F2A4E2361FC34E2E6EEE883C9D27169C8F2127173677447E488DBC99E8FC9F70938B9ABB7A102A47CEBC99E8FCF7A8C905CD9D3DFB468FBC95E827E838C9C5CC9D3DE15A23685EE627E848C985CC9D3DC79ECEE789267A0B1D2BB988B9BB5717CA24CD6BFC081D2DB980B9BB179468A6793EBF7084FE2556F2787377E444D3FCB8B873FE0D52F2587387AF2156F25483F7A2A3228F3377F9B2718DACF9420F3A2EF2187397E445B2E4C75DDC293A32F26F18DA23050A74CD4F8A3BE70C21F94073A7E49B65C2E6B74FD193F8C80799BB3D2BA64298FCACB837D1D1910F30777C3C508EB2F95971EF4547401E6DEEFA4428D2E4A79D7B2F3A06F24873E78780D136BFCD3BD1AFA0228F32777ED45F9AB6799977C5154CE411E6EE0FF4ACE587A7B89FA023210F37774FBE499CBCBBB8B7D1B190879A23388F5D6538DFDF456CCEAFA0210F33C7F0A10DC9E17C3F5B1AA956AB25B4037A335E60210F3147F10525A9D9F976A97A1C25B4037A33FE8284BCDF1CC777D2C4175EF76796AB67B18DB7B8B7D05190F799E320DF5413C7841E62CE7F8782BCD71CC90730455BB8ED1E7144E8651E868E81BCC71CCB676EC53658DE8D544302CB98CE07A03B25EF3647F331EBB4629263425F0845FFC63D7997399EEF978B3C2F51AA46C5C83ED601BD195F3827EF34C7432E3055DB1FA946C79B8F78CDF917AEC93BCC1191C79B0F24AF5697117472351E85EE98FCCC1C13F9E59A1E796B50DFC7D9C41DA3BB243F3547457E599BBC39A87FC4D9C4B5CBBB4BF22F1846F23873017204F53DDA9C275D921F9B2323BFACDAB1F7A4FA3B944D5C27BA0BF2B63936F2C1E6DB55D1709BEA83CC8FD19D901F99A3231F68BE5B950897A37A8DC7A1BB216F99E3231F64BEFFA62A15EE1AF8328F417744DE344748FE15C0607E56E067D04DD68ED1BF7643FE05C348FE1550653F5996DB4669CEF9D74EC807983B24FF0AACB23B555F1043B74D1E6DEE923CDA7CA6AA182ED4E3CD5BE8D6C923CD9D92479ABF5BAE56D5D5F7314DD64ED0ED934799BB25FF0AAC81EBE9E6DEA1333F42B74B1E61EE98FC72C42390EFAABA51CA6233E77FB14D1E6EEE9AFC72CE449A1F97F812C832CDFEEECCCC4CCC68511332E75F5A260F35774E1E61FEAE0A1323DB9A35FE63E96497A7F44EDFBC13DD067998B97BF208F352152C46D4B3FDDDCC1BC125FD329745B7421E628E803CDC7C7FB90A19CB2585747FB73D22F170359744B743DE6F8E81FC5A4E6F3F4D6270DF96C8F7DD52E8C6FDB6BE791BDD12799F390AF270F391AA9918296DC7BFD1BABB5D8A2C33DBFAE62D745BE4BDE638C8AF853DDFFEB16A32DE8C9466B2BB6149BF9B9D29C53C71F9517D21EEEC24396BE43DE648C843CD4B552BF166A415CD8958A9F54FB1E5FD1100F34E74B3E4DDE658C843CDDF54F1C60C80F919BA61F22E7334E461E61FAB98E31D80F909BA69F24E733CE461E625D4E62508F336BA71F20E7344E461E66FAAF4125DD6BC856E9EFCCC1C13F9B5A2B17557AB23BAB4394F5A203F3547451E62BE8DDCFC0D8C7913DD38F989392EF210F31272F3EA4718739E344E7E6C8E8C3CC47C19BB7909C8FC14DD1879DB1C1B79BFF92E76F2D0E2AE647E8C6E8EFCC81C1DF9B5436AC37978E7AE667E846E90BC658E8FFCDA3572C379E84E8BA27913DD2479D31C23F93562B3F388015DD59CF32F0D927FC150925F24363B8FD8685137EF4407276728C9AF936BE19A016A7E860E4FCE50925F2F03BDBEE2B689D3313F413740CE50925FCF916BE1AAD55D58F336BA09728692BCD77C8482F936B0790BDD08394349DE6B4E813C649B45D39C7F69869CA124EF31FF48C2BCA4F30C64C4A16246C8194AF2EB057A6D7BC8648D1B42D7246728C9AFA7A9ADBC1A320F45D7256728C97BCC494CD5FA27E8656E045D9B9CA124EF311FA1695EE326D0F5C9194AF28B456F7EF6901C34394349DE63BE4CC37C57E9CC01397408728692BCC7BC7ABECD3BD041C8194AF28B17BD79D7863A2839C3497E91DEF4BCDF7C8103A30391339CE48F6A04CDB7CD991FA14391339CE4773ACFFEA0623E03BF24D3890E46CE5092AFB61E24DDA5B50CD76D9E2D2D571761D1C1C81956F28E4D8B1972E6BBEDE7F7CCA32B913384E47797BB77AAC8999F3EE2F1D930BA1A39C347FE68BC677B929AF9D9533D37B951744572868FFC87DE56988A79A9FF41AE1B26D155C9193AF247F73AEED9F23B2A4FC39D6EA6765D2DEC88DE8DAE4CCED0913FBAD97B1F472899F74C32B831747572868EFC51DF420725F3DEC7B83E9B42D72067E8C8EF74DFB437B4CC7BAF75959B41D72167D8C8BB86F376A21332EF6B3717B911742D72868DBC63A67692E854CC97438E211EE126D0F5C81936F2476B7D5B1754CCAB61330C6E025D8F9C6123EF371F21631EF6FA2C3782CE74C81936F2EEA95ABB6652312FD932E79C6990336CE43F55872B3E5B478F2567D8C8BDB9267A3C39C346EECDF5D099AAB943F26133AF70ABE84CD5DC25F94F3787CB9C739BE84CD5DC29F94F6BDE5C199DA99ABB257FEACD95D199AAB963F2A7E34345BEC6EDA1335573D7E44FEF0D95F908B7862E2A9E64D8C89FAE0E95F9A269F3D3C57761F25E73F7E44FEF0C95F92AB7842E4EDE638E80FCE90F7E4946015D82BCDB1C03F9D3CDA19AA057B8157419F22E731CE49BC334595BE656222943DE698E847C73981AF7118E093DD96B8E857CF38E6FE1CCA0277BCDD1906F6EFA16CE087AB2D71C11F9300DE89CA3414FF69A63221FA2017D91A3414FF69AA3221FA201FD06C7829EEC35C745FEF4E9D0CCD02B1C097AB2D71C1BF9D06CADAD718E033DD96B8E8E7C76588AFB04C7819EEC35C7473E3B3B24C53DC951A0277BCD3192CF0E47E7BEC83906F464BF3942F2D9E1D85BFBCC31A027FBCD3192CFCE0E431777937304E8C9507384E4B377FDE41C063D196A8E917C7676CDA739047A32D41C27F9104CD726B87BF46484394A72FA89EE30CD4FD19311E648C9C98FE837B873F4A4883922F2D9678BFE01193DF4A488392AF2673F905E8CAB70E7E822E6B8C89F3DA3DCC6AD728E179DA1257F46B8BAAF718E189DE125FFF325AAD57DB9C231A333C4E4977E58A669FE9973CCE80C31F9A55FEE9044BFC1396A748699FC978714D1119187A333D4E40F1FDEA136A62FA3220F4567B8C91F3EFC9E56F73E52E11C3B3A434EDE8CBBE3640AFCE2678E2F42CCB1933F2453E12B1C67F49953207FF88A42815FE39C063A2341FE8AC23AEC2A2782CE4890BFFADEAFC4C0A13312E4AF5EE17F8462997322E88C06F92BFC27882D722AE88C06F92BFC8FCDDCE054D0190DF257AFD0CFD6929C0A3A2342FE18FB6C6D8D732AE88C08F963ECB3B5094E069D11217FFC187971AF7032E88C0A39F2E2BEC639197446851C79719FE09C8C3AA342FEF8C24D5FDA61D01919F20B8BBEB403BDED4086FCC25D5FDA61829121BF80B9B8274999D321BF8077CD7D91533327428EB8B8DFA0664E85FCC205AC1BAACB9C98391D72B4C57D91983921F20B17903E005BA16E8E98FC02CE23C4D6387173CCE448BBB81BC4CD5193FF3A8A718ABE9CA46D8E9C7C74D57770D0E6D8C94747977D07076B8E9F7C14DF89CF239CB23901F2D1BBBE838334A7403E3A8A6DBA76931336A7413E8AED719909C2E644C84747D7FC440DC89C0C39B2E9DA2A276B4E877CF4F94D3F518330A744FE1C53A22F72AAE6A4C89F634AF40A557362E488129D649AB7CCA9913FFF7ED9A7B99E3939F2E7CFEFF934D73227488E26D12BA4CD49916319D189A6F9B13931F2E7777C9AEB9A5323C7614E35CD8FCCC991E330AF1036A747FE7CCCAFB46B99532447604E7143EDC49C243902F3094EDC9C1AB97BF39B9CB83939F231E70F4E7C266E4E8FDCBD39A76D4E90DC9BEB995324F7E6FA6BAFD4C8BDB9B63939F2B17BDE5CCF9C1EB937D7342748EECDF5CC29927B732D7392E4DE1CD49C04F9D81D6F0E674E83DC9B039A13219FF4E660E654C8BD39983919726F0E654E877CDA9BC39813229FBEEBCD21CC29914F4F7B7300735AE493FED1287D7362E4AECD4786C09C1AB937D73627473EEDCD35CDE9917B734D7382E4DE5CCF9C22F9F4B237D73027493EBDE6CDD5CD69927B731D739AE4DE1CC49C14B93787302745FEFD1DC76741AEDD4DD237A7447E2755AF5F756B7EB55E4FDD256E4E88FCE06DBD8EC1BCBE555BA06C4E883C9DB8D732FFD6BD797DA27C9BAE391DF2835A22F11A8B7926912099EA8C14793A914864EB58CCEB6F13098AA9CE08913F692679A25DDA71984FB4AEA746D09C0C79BADCBAC589141EF3F1A30B2A53ABEF8C0AF9EF7389766CE1314F1D5FD26D8AE6F8C90F6AC7F73751C763BE75724DB45A3946833C7D7277136FDBE675B7E69FDA17717A55E57962E6E8C94FEBFA69DBEE7851E656BDC79C547D6704C80FCA897E73A7C5FDDBE38BC8765C189DFACEF093A7138910F3FA2D77E47BF510733AA9CEB0933FC925C2CD3FB94FF31E732A5375869CBC524E4498BB1BD16FD523CC894CD5196AF207854422D2FC3747D57DEFB748731AF59D61263F9B948799D73FEDB9ADEC61E6145A3986983C5D4E0C3477D3BB7790B73659FA027F7D6768C91FE41289187317E8573BFFFED02B445FDF1956F24A39116F6E1FBD8B3CC21C7BAA339CE411497EB6DEEE08BD9BBC1E7991B7919B23240F6BDEC2CDEDA2F79067A2AF12732BC7109287CCD03AE2752FFA9E93F6AD732F9558AA3384599E1B742B8F9F99A8DB9FB2EDF5920F36C78BCE10B66F92E69616676E7DEAFB8BEF0DBCD01A6A7364F3F2817732315EEF0F0BCBB0B77EAB0F9339B635F6C1E6F742CC8D0FEA7B57C3FED62C5973743B6983CD27C2EEBEE1FA1E52D7E3CD1378CD91EF97C72CCA74D4F73D5B53B4F8E939727364E44FD2EB4B31B73202A0FEE996D524AFD75FC75C68909B5F406C8E635E5E29DC0F8220CEFC7514BA91517DEF6AE45F978AB9D0A5E68FD9C92D203547405E49AF07EDD88FB995A94884FA6F57AD25F9E92B0D83CD8FD891A53B4340FEE0205D08CE6225213F593B4BF55B6697613A6355CC1C9D3B734CFEE02CBF45CD57EB0303AEC00F28EB226D7B62BFFB77A171670EC99BE97D3FE88F38F3EC608966818751BFFA5BCC5F14C899A381676EC80F2A85F520221271ED703D2E3E5D353B908BB5ED8995A85F989B770ACFAC930FE216323F7E4BD1A8FAAD6FE3FF8E94B2F971C2BB826716C95F16D331DC62E6A97ADDACBA8878DC6A7B9CF971C6BB28F5CC0E79B35513E10E04A6E7112BEE70EA62E2C7270E689A3B8167C6C98B95F0564DDD7CA25E37A77EF593E89F9E8DBD50895F7DD4DC2DD8343743FEB258114D6E29F3B775E190ECE1F7C4C56357DB25CD2D0EF2CC0CF95831ADC02DB40C3770F5556B95662F767626D5C22998DBA9F5CC00F958A510A8878079AA2E159F84925D7418175D79ED5E8853C87893E6C0E463E9402B5612504D5C47898F5B9C934B71B1164ECBBCC5BE60CC1C98BCB81E18379FA8CBC720F5BD6F15FEC0B7A6CD9B45DEDC7A3B24B966928B9907759588ACF0F2392EB20A07601EEC983207241F2B68930702F75264254EF8A18ABD4F4A7F98400B17BAE08EA0BE3350F2F5C08E79AAAE1657C59E6705598503313782CEB0910B99AFD6A1D0AFAAFE495981CB5C0950A2336CE44B22E6D93A10BA6A96C76FA442991B4067C8C8C5CC13CAE6DDC74DED29936712B6CCE11B3906D6B1C3900B9AA794CD3F0D7AE910744506CA1C1C9DE199A4092FC3A9ACCA8456F75BEA7FCA84D06502DD939C31732DF24A60D55C7940FF90C9BC398EE5EA2775F3B736CD837943E67AAB6F50BF4E6449467E40DFCA4C4D351A731B7DD1684C4D653EC8936F25AC9A070B46CCF5D6D8EFDB36171ED03F34B537E2A2319531309C039AEF9830D7DB492B04B6CDC74575E2C1DB3137B5053E9CEB2FBE1A19D21904F9011C7920763385B759DE6F88C7FB0F5BB0C339A039E490CE20F6CBEFDB3717DD66C948983736E63E800EE790E63BC0E69A4FC500567661F34406B6B49FB0BF871CCE21CD01AB3BD32787ACEC824B32C203FAD48664342087735073B8DE9D699303ADB9CA9A4F4057F6E398021CCE2136D60C5477A6FDB8633A70622E3243FF30276FBEB105379CC39A83B5714C97FC41E0C83C053E981F4FDADE830DE7C0E63BA0E61ACFB11760CDF785CDEFC10FE6A2D55D743887DA64016EE39826793170659E3552D95B113B25081C9903B5714CF36D15E034175D861379B3A1A1481E5BDD330957E63928731D72E83497314F19A9EC02D57DDC99394CA233BD77D2D61D9AAF9AA9ECF1D53DEBCE1C24D19916792570689E3553D9E35766C42F3111604C74A6F5E629789A0712F773E053EE990DAD98D27CB2DD98790EC65C9D1C3ECDA5CC072DBFCEE9990FDA6C5975690E91E84CE74881825BF309230D5C6CA2679D9A03243AD3202F066ECD03330D5C4C1BB795706A0E90E84CE3E0100369BE247343A3F753B5D37C401B37EED85C3FD1993AB989349733BF67A6816B474A77E1157C33F53860CDE58E072A3837CF9A98A7C5ADC605AECDE721CDE5C81F04CECD23965F41D23CAA8DCB245C9BEF009A4B1E02963661BE2F673E6E629E3638D1EF3937D74E74A67CEEDB7D04E6A1B3B5D4C686C144CFBA37DF81329725AF0408CCC3666BEFE7A0CC373EA81D2962DA5C77BAC6540FF42C60300F9BAD4D8191CFA534676AA6CC7320E6D2E445233F46668B2562B60696E68DD47BDD999A29F300C25CFED8DE020EF3ACA1346FA43E00CCD48C99CFEB9BCB93BFBC8FC3BC7F6F6D4A7B723EE885C5540285F98EB6B9C2E1DC663A3805F3B0D95A66AAA158E0E7E25E505D95BCBC7D43F76941D35CE53CF60216F3C8BDB54C2AFC8DF3E899594AE075A8B748CC737AE64A47F00758CCE3DE55DCCA6404ABBDC8EB895B0924E65A5D1C53FAD0461A8DB9C8AB0D1F84CA3AE4BB89E6CDE721CCA5BEADB26EEAA748930B1D0F38A5F79084F24CCDA0F90E80B9147931C0632EF2D1868CC6D6A9C6229C49739D2E8EA97C41A980C85CE845F406CC703E8EC87C5ED75CF2A359F731998BBC88BE05F3DEF90422F31D4D7349F2830093B9D051715320C3B9FCE52D05088B3B53F81A620195B9D861EE71E82223442A81C93CA7632E4BFE32C0652E74CA4806C05C6E116E65DF20B8567167F2DF3CAD203307396544A46D7F8B855BB38B63F29FB92D203317FADCDA94FE789EC1C3AD57DC9934B9C9D2AE669E02306F00CCD45696AC796B157726FD316B93A53D58DA5F3153DCA7F4975EB331E081ED98D73197FA7E79C1F86F596ACAAF74DAAF74FFA7CA9990B1AB325AFB2B2B818BC869984B913F70F2F396564C1F2195D12AED4ED077D4CDA5C8CD96762571A17D9686F67AFB84E52325CC157726496EA1B4CB8A0BEDB368EFABC5EFAFAC5029EE4C927CEC3E3A71A17D16ED057791FD15DB7DDC0E84793CB9E5D22EF8FE5A6C717FAFFDCC84D8FE8A65F5057DF378F2B1B4CD9FB402B6CF22B0830EB5BFB28FBEB83339F2B1755C455D749F45C03C03B6BF622FD97774CD45C88B18C105F65952BA0FCA486E9DAF602EEE4C8ADCD2702EBF1697D5DD3F8F6BDC516D9D6BCED69814B985D2BEB4AFB4E6BEA56DDE00DE3AB7C29ED33117237F80ACA40B17F786E6C3CEABAAD7657A6CD7301723375DDA95C563F759445E6B807C7FC55A1F3FAF6C2E486E7A116E49FDCEC66CA28B9867204EEFB65DE073AAE6A2E4A617E174CC0717F739BD27DC57352E0CDF6C8DC9901B9FA9254C1577CDE33EDFA2355799AD310972F38B702BA68ABBDE01DE3AA5DDF44C7D5EC55C9CDCFC9E9AA9E29ED17B4B7115ED70AE54DC9904B985C7250C1577B1530229967695D91A1327B7B108973053DCC5CC33044BBB4A7167E2E436F6D456CC1477B183855260AF26E25E8A63E2E49316F6D496CC147731F3298043FAED9BEFE898C7913FB1B169A053DC75CD1B40078A581DCE15666B4C987CD2CA9E9A4E714F697E84690EBEB4DBD8539D57368F259FB4F2F4A399E22E78661CC5D2AE30A03361F2693B8FC8E8D451DDAF3065289676F9019D09935B19CEF506F494CE325C54E38EBDB4CB0FE84C947CDAD213AFFB268ABBBD03DB1D3C2B233DA03351F2694B2F332C1928EE5B82E60D8AA55D7E4067A2E4D3B65E663050DC453FD03247B2B44B2FBF3251724BC3B9DE6C6D42F3DB5B244BBBF480CE04C927ADBDC062A0B80B9FE99EA158DAA5077426483E69EFDD44F8E22E6C9E2259DA65077426483E69EF0516F8E22E6C3E45B2B4CB0EE84C90DCDA706EA2B80B7FBAA141B2B4CB0EE84C8C7CDAE6FBA8E0C55DD87C8E6469971DD09918F9B4CDA306C0D7DCC53FD142B3B44B0EE84C8C7C7A3D2092E8AFD597E1FA1B7722A55D72406762E4764F0E827E5A46F903D8444ABBE480CE84C8A7ED1E2F015CDC3F889B4FC13DFC68F5C4897915F3C1E4D3568F97802EEE12DFC66E803DFC68B5B4CB0DE84C887CDAF26951B0C55DC27C0EECB9F67DAB376C47DE3C8E7CDA2E39707197F99CE67B32CFB5AB0FE84C88FCC0F22F802DEE32E61932CFB5AB0FE84C84DCF6700EFC12938CF91491579674067426427EC5FEE18F90C5BDA1684EA8B44B0DE84C84FCE5BA7573C8375465CC1B344BBBD480CE44C89F58FF05A0C55DC67C8EC241039A033A13207FE9E22C678D1B9E555E86EB6ADCDF524A7399019D0990BF4C07B4127D4BC33CA3773C989B0E4EC73C9CFC6521A095E8E392E7FB86367113A44ABBCC360B13207FE9E227E8747159D565B84E738DFFE9F65DDCAF0525F328F20327E660C55DCEBC0150DA9DDCAF7915F328F22B1527BF01ACB8A7A4CCE7F44B3BF62FF2B078F22BE9805AA2BF555D863B6BDC03521D9CD4AA0C8B27BFB21E904BF48CBA798666699768E2583CF91547BF41E775C55575F329DDD2BEE4E8762D489A0F223F70651EC014F78682F96B7A692EDEC4B1587257C3B9DE742DA36CDED07C106EDFD5DDCA49990F24BF52080826FAAAF421135D8DFB04BD34176FE2582CB9B3164E2BD103C5A5D776E3FE9ADA444D6A4067B1E457DCFD089DE95A4AD93CA355DA1DDEAD7961F338F20387BF42A3B84FA82DC3B59BB82CC53417378F2377D8C269257AA061BE456FA226D3C4B13872972D9C56A2A754CD1B1AA5DD659A0B37712C8EDCB1F99276719F92359FD328ED4B4E6F966013C7E2C85F0401D1447FAD68BE9122D9C1890FE82C8EFCC0B1B9FA02ECB8AAF9FF124D7309F381E42F2A01D5449F505A866BC6FF114D73D1268EC590BF480764137D4BCDFC7FA8A6B96813C762C85FAC0764137D5C65E97563E3BFA9A6B96813F7FF020C008EA9ADF1AC1529080000000049454E44AE426082' } >>)), 24(<< { "digestID": 19, "random": h'DB143143538F3C8D41DC024F9CB25C9D', "elementIdentifier": "birth_date", "elementValue": 1004("1980-02-05") } >>), 24(<< { "digestID": 20, "random": h'6059FF1CE27B4997B4ADE1DE7B01DC60', "elementIdentifier": "family_name", "elementValue": "John" } >>), 24(<< { "digestID": 22, "random": h'1E69C89C81B21A1BA56ACA3E026A2A3F', "elementIdentifier": "issue_date", "elementValue": 1004("2020-02-23") } >>), 24(<< { "digestID": 25, "random": h'CAD1F6A38F603451F1FA653F81FF309D', "elementIdentifier": "driving_privileges", "elementValue": [ { "issue_date": 1004("2018-08-09"), "expiry_date": 1004("2024-10-20"), "vehicle_category_code": "A" }, { "issue_date": 1004("2017-02-20"), "expiry_date": 1004("2024-10-20"), "vehicle_category_code": "B" } ] } >>), 24(<< { "digestID": 26, "random": h'53C15C57B3B076E788795829190220B4', "elementIdentifier": "issuing_authority", "elementValue": "UTOPIA" } >>) ] } } } ] }¶
In the deviceSigned
item, deviceAuth
item includes a signature by the deviceKey the belongs to the End-User. It is used to prove legitimate possession of the crdential, since the Issuer has signed over the deviceKey during the issuance of the credential. Note that deviceKey does not have to be HW-bound.¶
In the issueSigned
item, issuerAuth
item includes Issuer's signature over the hashes of the user claims, and namespaces
items include user claims within each namespace that the End-User agreed to reveal to the verifier in that transaction.¶
Note that user claims in the deviceSigned
item correspond to self-attested claims inside a Self-Issued ID Token (none in the example below), and user claims in the issuerSigned
item correspond to the user claims included in a VP Token signed by a trusted third party.¶
Note that the reason why hashes of the user claims are included in the issuerAuth
item lies in the selective release mechanism. Selective release of the user claims in an ISO/IEC 18013-5:2021 mDL is performed by the Issuer signing over the hashes of all the user claims during the issuance, and only the actual values of the claims that the End-User has agreed to reveal to teh Verifier being included during the presentation.¶
The example in this section is also applicable to the electronic identification Verifiable Credentials expressed using data models defined in ISO/IEC TR 23220-2.¶
TBD: are nonce
and client_id
included into the mDL to detect replay?¶
This section shows how SIOP and OpenID for Verifiable Presentations can be combined to present Verifiable Credentials and pseudonymously authenticate an end-user using subject controlled key material.¶
This is an example request.¶
GET /authorize? response_type=id_token &scope=openid &id_token_type=subject_signed &client_id=https%3A%2F%2Fclient.example.org%2Fcb &redirect_uri=https%3A%2F%2Fclient.example.org%2Fcb &presentation_definition=... &nonce=n-0S6_WzA2Mj HTTP/1.1 Host: wallet.example.com¶
The differences to the example requests in the previous sections are:¶
response_type
is set to id_token
. If the request also includes a presentation_definition
parameter, the wallet is supposed to return the presentation_submission
and vp_token
parameters in the same response as the id_token
parameter.¶
The request includes the scope
parameter with value openid
making this a OpenID Connect request. Additionally, the request also contains the parameter id_token_type
with value subject_signed
requesting a Self-Issuer ID Token, i.e. the request is a SIOP request.¶
The example response looks like this.¶
HTTP/1.1 302 Found Location: https://client.example.org/cb# id_token= &presentation_submission=... &vp_token=...¶
In addition to the presentation_submission
and vp_token
, it also contains an id_token
.¶
The id_token
content is shown in the following.¶
{ "iss": "did:example:NzbLsXh8uDCcd6MNwXF4W7noWXFZAfHkxZsRGC9Xs", "sub": "did:example:NzbLsXh8uDCcd6MNwXF4W7noWXFZAfHkxZsRGC9Xs", "aud": "https://client.example.org/cb", "nonce": "n-0S6_WzA2Mj", "exp": 1311281970, "iat": 1311280970 }¶
Note: the nonce
and aud
are set to the nonce
of the request and the client id of the verifier, respectively, in the same way as for the verifier, Verifiable Presentations to prevent replay.¶
Response Type Name: vp_token
¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): https://openid.net/specs/openid-4-verifiable-presentations-1_0.html¶
Response Type Name: vp_token id_token
¶
Change Controller: OpenID Foundation Artifact Binding Working Group - openid-specs-ab@lists.openid.net¶
Specification Document(s): https://openid.net/specs/openid-4-verifiable-presentations-1_0.html¶
Note: Plan to register the following response types in the OAuth Authorization Endpoint Response Types IANA Registry.¶
We would like to thank John Bradley, Brian Campbell, David Chadwick, Giuseppe De Marco, Daniel Fett, George Fletcher, Fabian Hauck, Joseph Heenan, Alen Horvat, Andrew Hughes, Edmund Jay, Michael B. Jones, Gaurav Khot, Ronald Koenig, Kenichi Nakamura, Nat Sakimura, Arjen van Veen, and Jacob Ward for their valuable feedback and contributions that helped to evolve this specification.¶
Copyright (c) 2022 The OpenID Foundation.¶
The OpenID Foundation (OIDF) grants to any Contributor, developer, implementer, or other interested party a non-exclusive, royalty free, worldwide copyright license to reproduce, prepare derivative works from, distribute, perform and display, this Implementers Draft or Final Specification solely for the purposes of (i) developing specifications, and (ii) implementing Implementers Drafts and Final Specifications based on such documents, provided that attribution be made to the OIDF as the source of the material, but that such attribution does not indicate an endorsement by the OIDF.¶
The technology described in this specification was made available from contributions from various sources, including members of the OpenID Foundation and others. Although the OpenID Foundation has taken steps to help ensure that the technology is available for distribution, it takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this specification or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any independent effort to identify any such rights. The OpenID Foundation and the contributors to this specification make no (and hereby expressly disclaim any) warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to this specification, and the entire risk as to implementing this specification is assumed by the implementer. The OpenID Intellectual Property Rights policy requires contributors to offer a patent promise not to assert certain patent claims against other contributors and against implementers. The OpenID Foundation invites any interested party to bring to its attention any copyrights, patents, patent applications, or other proprietary rights that may cover technology that may be required to practice this specification.¶
[[ To be removed from the final specification ]]¶
-14¶
added support for signed and encrypted authorization responses based on JARM¶
clarified response encoding for authorization responses¶
moved invocation/just-in-time client metadata exchange/AS Discovery sections from siopv2 to openid4vp¶
-13¶
added scope support¶
-12¶
-11¶
-10¶
-09¶
added support for passing presentation_definition by reference¶
added description how to requset credential issued by a member of a federation¶
-08¶
reflected editorial comments received during pre-implementer's draft review period¶
-07¶
added text on other credential formats¶
fixed inconsistency in security consideration regarding nonce¶
-06¶
added additional security considerations¶
removed support for embedding Verifiable Presentations in ID Token or UserInfo response¶
migrated to Presentation Exchange 2.0¶
-05¶
moved presentation submission parameters outside of Verifiable Presentations (ID Token or UserInfo)¶
-04¶
added presentation submission support¶
cleaned up examples to use nonce
& client_id
instead of vp_hash
for replay detection¶
fixed further nits in examples¶
added and reworked references to other specifications¶
-03¶
aligned with SIOP v2 spec¶
-02¶
added presentation_definition
as sub parameter of verifiable_presentation
and VP Token¶
-01¶
adopted DIF Presentation Exchange request syntax¶
added security considerations regarding replay detection for Verifiable Credentials¶
-00¶
initial revision¶