From 6ca5b92753e8ac4c4f6e541102be78fe7290ff76 Mon Sep 17 00:00:00 2001 From: gabe Date: Wed, 15 May 2024 17:53:13 -0700 Subject: [PATCH 1/6] add text and diagram for siopv2 conditional cred req flow --- openid-4-verifiable-presentations-1_0.md | 90 +++++++++++++++++++++++- 1 file changed, 89 insertions(+), 1 deletion(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 3c8a0ddc..85c1956d 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -1769,7 +1769,7 @@ Note: The Key Binding JWT `nonce` claim contains the value of the `nonce` from t ## Combining this specification with SIOPv2 -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 section shows how [@!SIOPv2] and OpenID for Verifiable Presentations can be combined to present Verifiable Credentials and pseudonymously authenticate an end-user using subject controlled key material. ### Request {#siop_request} @@ -1821,6 +1821,90 @@ The following is a non-normative example of the payload of a Self-Issued ID Toke Note: The `nonce` and `aud` are set to the `nonce` of the request and the Client Identifier of the Verifier, respectively, in the same way as for the Verifier, Verifiable Presentations to prevent replay. +### Conditional Credential Request Flow + +When combining OpenID for Verifiable Presentations with [@!SIOPv2], the server has the flexibility to determine whether to request credentials based on the authenticated user's context. The aforementioned flow can be modified as follows: + +1. The user initiates the authentication process with the server. +2. The server starts the [@!SIOPv2] flow and sends an Authentication Request to the user's Wallet, omitting the `presentation_definition` and `presentation_definition_uri` parameters. +3. The Wallet processes the Authentication Request and performs user authentication using the [@!SIOPv2] mechanism. +4. Upon successful authentication, the Wallet sends the Authentication Response back to the server, including the `id_token`. +5. The server validates the `id_token` and extracts the necessary information to identify the user. +6. Based on the user's identity and the server's context, the server determines whether additional credentials are required. + - If no additional credentials are needed, the server proceeds with issuing the authentication token to the user. + - If additional credentials are required, the server initiates the OpenID for Verifiable Presentations flow by sending a new Authorization Request with the `presentation_definition` or `presentation_definition_uri` parameter. +7. The Wallet processes the Authorization Request, requests the necessary presentation from the user, and sends the Authorization Response back to the server. +8. The server validates the presentation and issues the authentication token to the user. + +This flow allows the server to make an informed decision about requesting credentials based on the authenticated user's context. + +!--- +~~~ ascii-art ++------+ +----------+ +--------+ +| User | | Verifier | | Wallet | ++------+ +----------+ +--------+ + | | | + | 1. Initiate Authentication | | + |-------------------------------->| | + | | | + | | 2. Start SIOPv2 Flow | + | | (Authentication Request) | + | |----------------------------------------->| + | | | + | | | 3. Perform User + | | | Authentication + | | | (SIOPv2 Mechanism) + | | |-------+ + | | | | + | | |<------+ + | | | + | | 4. Send Authentication Response | + | | (id_token) | + | |<-----------------------------------------| + | 5. Validate id_token and | | + | identify user | | + | +-------| | + | | | | + | +------>| | + | | | + | 6. Determine if additional | | + | credentials are required | | + | +-------| | + | | | | + | +------>| | + | | | + | | 6a. If no additional credentials needed, | + | | issue access token | + | |----------------------------------------->| + | | | + | | | + | | 6b. If additional credentials required, | + | | send Authorization Request | + | | (presentation_definition or | + | | presentation_definition_uri) | + | |----------------------------------------->| + | | | + | | | 7. Process Authorization + | | | Request and request + | | | presentation from user + | | |-------+ + | | | | + |<---------------------------------------------------------------------------|-------+ + | | | + | | 7. Send Authorization Response | + | | (VP Token) | + | |<-----------------------------------------| + | | | + | 8. Validate presentation | | + | and issue access token | | + | +-------| | + | | | | + | +-------|----------------------------------------->| + | | | +~~~ +!--- +Figure: Reference Design for SIOPv2 Conditional Credential Request Flow + # IANA Considerations ## Response Types @@ -1894,6 +1978,10 @@ The technology described in this specification was made available from contribut [[ To be removed from the final specification ]] + -22 + + * added conditional credential request flow when using SIOPv2 + -21 * added references to ISO/IEC 23220 and 18013 documents From 6d6606b6ecb40127cd1efcafce477a43a10c32de Mon Sep 17 00:00:00 2001 From: gabe Date: Wed, 15 May 2024 17:54:44 -0700 Subject: [PATCH 2/6] optional wallet metadata --- openid-4-verifiable-presentations-1_0.md | 1 + 1 file changed, 1 insertion(+) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 85c1956d..d12c25d0 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -823,6 +823,7 @@ This specification defines how the Verifier can determine Credential formats, pr This specification defines new metadata parameters according to [@!RFC8414]. * `presentation_definition_uri_supported`: OPTIONAL. Boolean value specifying whether the Wallet supports the transfer of `presentation_definition` by reference, with true indicating support. If omitted, the default value is true. +* `conditional_credential_request_supported`: OPTIONAL. Boolean value specifying whether the Wallet supports the conditional credential request flow when combined with SIOPv2. If omitted, the default value is `false`. * `vp_formats_supported`: REQUIRED. An object containing a list of name/value pairs, where the name is a string identifying a Credential format supported by the Wallet. Valid Credential format identifier values are defined in Appendix A of [@!OpenID.VCI]. Other values may be used when defined in the profiles of this specification. The value is an object containing a parameter defined below: * `alg_values_supported`: OPTIONAL. An object where the value is an array of case sensitive strings that identify the cryptographic suites that are supported. Parties will need to agree upon the meanings of the values used, which may be context-specific. For specific values that can be used depending on the Credential format, see (#alternative_credential_formats). If `alg_values_supported` is omitted, it is unknown what cryptographic suites the wallet supports. From 350aa8505627767bf61a43d59f55c4d016e6df27 Mon Sep 17 00:00:00 2001 From: gabe Date: Wed, 15 May 2024 18:01:15 -0700 Subject: [PATCH 3/6] adjust spacing --- openid-4-verifiable-presentations-1_0.md | 122 +++++++++++------------ 1 file changed, 61 insertions(+), 61 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index d12c25d0..f23e9e80 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -1841,67 +1841,67 @@ This flow allows the server to make an informed decision about requesting creden !--- ~~~ ascii-art -+------+ +----------+ +--------+ -| User | | Verifier | | Wallet | -+------+ +----------+ +--------+ - | | | - | 1. Initiate Authentication | | - |-------------------------------->| | - | | | - | | 2. Start SIOPv2 Flow | - | | (Authentication Request) | - | |----------------------------------------->| - | | | - | | | 3. Perform User - | | | Authentication - | | | (SIOPv2 Mechanism) - | | |-------+ - | | | | - | | |<------+ - | | | - | | 4. Send Authentication Response | - | | (id_token) | - | |<-----------------------------------------| - | 5. Validate id_token and | | - | identify user | | - | +-------| | - | | | | - | +------>| | - | | | - | 6. Determine if additional | | - | credentials are required | | - | +-------| | - | | | | - | +------>| | - | | | - | | 6a. If no additional credentials needed, | - | | issue access token | - | |----------------------------------------->| - | | | - | | | - | | 6b. If additional credentials required, | - | | send Authorization Request | - | | (presentation_definition or | - | | presentation_definition_uri) | - | |----------------------------------------->| - | | | - | | | 7. Process Authorization - | | | Request and request - | | | presentation from user - | | |-------+ - | | | | - |<---------------------------------------------------------------------------|-------+ - | | | - | | 7. Send Authorization Response | - | | (VP Token) | - | |<-----------------------------------------| - | | | - | 8. Validate presentation | | - | and issue access token | | - | +-------| | - | | | | - | +-------|----------------------------------------->| - | | | ++------+ +----------+ +--------+ +| User | | Verifier | | Wallet | ++------+ +----------+ +--------+ + | | | + | 1. Initiate Authentication | | + |------------------------------>| | + | | | + | | 2. Start SIOPv2 Flow | + | | (Authentication Request) | + | |------------------------------------->| + | | | + | | | 3. Perform User + | | | Authentication + | | | (SIOPv2 Mechanism) + | | |-------+ + | | | | + | | |<------+ + | | | + | | 4. Send Authentication Response | + | | (id_token) | + | |<-------------------------------------| + | 5. Validate id_token and | | + | identify user | | + | +-------| | + | | | | + | +------>| | + | | | + | 6. Determine if additional | | + | credentials are required | | + | +-------| | + | | | | + | +------>| | + | | | + | | 6a. If no additional credentials | + | | needed, issue access token | + | |------------------------------------->| + | | | + | | | + | | 6b. If additional credentials | + | | required, send Authorization Request | + | | (presentation_definition or | + | | presentation_definition_uri) | + | |------------------------------------->| + | | | + | | | 7. Process Authorization + | | | Request and request + | | | presentation from user + | | |-------+ + | | | | + |<---------------------------------------------------------------------|-------+ + | | | + | | 7. Send Authorization Response | + | | (VP Token) | + | |<-------------------------------------| + | | | + | 8. Validate presentation | | + | and issue access token | | + | +-------| | + | | | | + | +-------|------------------------------------->| + | | | ~~~ !--- Figure: Reference Design for SIOPv2 Conditional Credential Request Flow From 64d292ff9b695c1fce0e5276f8cd021c1ac9fb69 Mon Sep 17 00:00:00 2001 From: gabe Date: Wed, 15 May 2024 21:09:25 -0700 Subject: [PATCH 4/6] rename server to verifier --- openid-4-verifiable-presentations-1_0.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index f23e9e80..52d38fdd 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -1824,20 +1824,20 @@ Note: The `nonce` and `aud` are set to the `nonce` of the request and the Client ### Conditional Credential Request Flow -When combining OpenID for Verifiable Presentations with [@!SIOPv2], the server has the flexibility to determine whether to request credentials based on the authenticated user's context. The aforementioned flow can be modified as follows: +When combining OpenID for Verifiable Presentations with [@!SIOPv2], the Verifier has the flexibility to determine whether to request credentials based on the authenticated user's context. The aforementioned flow can be modified as follows: -1. The user initiates the authentication process with the server. -2. The server starts the [@!SIOPv2] flow and sends an Authentication Request to the user's Wallet, omitting the `presentation_definition` and `presentation_definition_uri` parameters. +1. The user initiates the authentication process with the Verifier. +2. The Verifier starts the [@!SIOPv2] flow and sends an Authentication Request to the user's Wallet, omitting the `presentation_definition` and `presentation_definition_uri` parameters. 3. The Wallet processes the Authentication Request and performs user authentication using the [@!SIOPv2] mechanism. -4. Upon successful authentication, the Wallet sends the Authentication Response back to the server, including the `id_token`. -5. The server validates the `id_token` and extracts the necessary information to identify the user. -6. Based on the user's identity and the server's context, the server determines whether additional credentials are required. - - If no additional credentials are needed, the server proceeds with issuing the authentication token to the user. - - If additional credentials are required, the server initiates the OpenID for Verifiable Presentations flow by sending a new Authorization Request with the `presentation_definition` or `presentation_definition_uri` parameter. -7. The Wallet processes the Authorization Request, requests the necessary presentation from the user, and sends the Authorization Response back to the server. -8. The server validates the presentation and issues the authentication token to the user. - -This flow allows the server to make an informed decision about requesting credentials based on the authenticated user's context. +4. Upon successful authentication, the Wallet sends the Authentication Response back to the Verifier, including the `id_token`. +5. The Verifier validates the `id_token` and extracts the necessary information to identify the user. +6. Based on the user's identity and the Verifier's context, the Verifier determines whether additional credentials are required. + - If no additional credentials are needed, the Verifier proceeds with issuing the authentication token to the user. + - If additional credentials are required, the Verifier initiates the OpenID for Verifiable Presentations flow by sending a new Authorization Request with the `presentation_definition` or `presentation_definition_uri` parameter. +7. The Wallet processes the Authorization Request, requests the necessary presentation from the user, and sends the Authorization Response back to the Verifier. +8. The Verifier validates the presentation and issues the authentication token to the user. + +This flow allows the Verifier to make an informed decision about requesting credentials based on the authenticated user's context. !--- ~~~ ascii-art From 70099610c01f3f91a9322718966c69c8b9b27dff Mon Sep 17 00:00:00 2001 From: Gabe <7622243+decentralgabe@users.noreply.github.com> Date: Thu, 13 Jun 2024 11:28:18 -0700 Subject: [PATCH 5/6] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- openid-4-verifiable-presentations-1_0.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 52d38fdd..372b2b7b 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -1827,9 +1827,9 @@ Note: The `nonce` and `aud` are set to the `nonce` of the request and the Client When combining OpenID for Verifiable Presentations with [@!SIOPv2], the Verifier has the flexibility to determine whether to request credentials based on the authenticated user's context. The aforementioned flow can be modified as follows: 1. The user initiates the authentication process with the Verifier. -2. The Verifier starts the [@!SIOPv2] flow and sends an Authentication Request to the user's Wallet, omitting the `presentation_definition` and `presentation_definition_uri` parameters. -3. The Wallet processes the Authentication Request and performs user authentication using the [@!SIOPv2] mechanism. -4. Upon successful authentication, the Wallet sends the Authentication Response back to the Verifier, including the `id_token`. +2. The Verifier starts the [@!SIOPv2] flow and sends an Authorization Request to the user's Wallet, omitting the `presentation_definition` and `presentation_definition_uri` parameters. +3. The Wallet processes the Authorization Request and performs user authentication using the [@!SIOPv2] mechanism. +4. Upon successful authentication, the Wallet sends the Authorization Response back to the Verifier, including the `id_token`. 5. The Verifier validates the `id_token` and extracts the necessary information to identify the user. 6. Based on the user's identity and the Verifier's context, the Verifier determines whether additional credentials are required. - If no additional credentials are needed, the Verifier proceeds with issuing the authentication token to the user. From 9cf236e41a2ae1100085cd2b16e1cd938c5b5d0c Mon Sep 17 00:00:00 2001 From: Gabe <7622243+decentralgabe@users.noreply.github.com> Date: Thu, 13 Jun 2024 11:31:57 -0700 Subject: [PATCH 6/6] Update openid-4-verifiable-presentations-1_0.md Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com> --- openid-4-verifiable-presentations-1_0.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/openid-4-verifiable-presentations-1_0.md b/openid-4-verifiable-presentations-1_0.md index 372b2b7b..b68336ba 100644 --- a/openid-4-verifiable-presentations-1_0.md +++ b/openid-4-verifiable-presentations-1_0.md @@ -1834,7 +1834,7 @@ When combining OpenID for Verifiable Presentations with [@!SIOPv2], the Verifier 6. Based on the user's identity and the Verifier's context, the Verifier determines whether additional credentials are required. - If no additional credentials are needed, the Verifier proceeds with issuing the authentication token to the user. - If additional credentials are required, the Verifier initiates the OpenID for Verifiable Presentations flow by sending a new Authorization Request with the `presentation_definition` or `presentation_definition_uri` parameter. -7. The Wallet processes the Authorization Request, requests the necessary presentation from the user, and sends the Authorization Response back to the Verifier. +7. The Wallet processes the Authorization Request, obtains the necessary consent from the user, and sends the Authorization Response back to the Verifier. 8. The Verifier validates the presentation and issues the authentication token to the user. This flow allows the Verifier to make an informed decision about requesting credentials based on the authenticated user's context.