Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Add text and diagram for siopv2 conditional cred req flow #175

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Add text and diagram for siopv2 conditional cred req flow #175

Changes from all commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
6ca5b92
add text and diagram for siopv2 conditional cred req flow
decentralgabe May 16, 2024
6d6606b
optional wallet metadata
decentralgabe May 16, 2024
350aa85
adjust spacing
decentralgabe May 16, 2024
64d292f
rename server to verifier
decentralgabe May 16, 2024
7009961
Update openid-4-verifiable-presentations-1_0.md
decentralgabe Jun 13, 2024
9cf236e
Update openid-4-verifiable-presentations-1_0.md
decentralgabe Jun 13, 2024
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
91 changes: 90 additions & 1 deletion openid-4-verifiable-presentations-1_0.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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`.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why is this parameter needed? is it pretty much wallet indicating support for SIOPv2? if so, maybe make that clearer? tho not sure siopv2_supported makes sense..

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it indicates that the wallet may need extra capabilities to handle this optionality
I am open to removing it if you feel it is in unnecessary

* `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.

Expand Down Expand Up @@ -1769,7 +1770,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}

Expand Down Expand Up @@ -1821,6 +1822,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 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 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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

what does issuing the authentication token to the user mean..?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

how would you rephrase this? perhaps If no additional credentials are needed, the Verifier proceeds

or what is the expected action after successful presentation?

- 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.
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

but sure if it is worth mentioning, but I guess the challenge is how to get this request into the same wallet

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yeah ... should add more detail here?
a second QR code - or something else?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we might want to tackle it in this issue: #223

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.

!---
~~~ 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
Expand Down Expand Up @@ -1894,6 +1979,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
Expand Down
Loading