OpenID4VP

OpenID4VP copied to clipboard

Currently presentation requests are statically defined and sent to the wallet/user in the auth request. This seems inefficient in the case where the user is re-authenticating using SIOPv2 and has already submitted/fulfilled the presentation request. They may have to submit the same presentation each time they authenticate.

Instead, it would be nice to support a flow like:

1. User authenticates
2. Server contextually determines whether to send a new presentation request or not before proceeding
3. [Optional] User submits presentation response
4. Auth token sent to user

I believe this means updating this section. I'm not sure how to fit this in to the current flow and could use some feedback from the group. Perhaps a user gets a preliminary access token and after presentation they get a new access token with increased scope.

how does the user know what VC to submit in step 3 if step 1 does not contain information about what VC is being requested?

I guess it would be nice to have some concept of an access token. That is of course a bit strange in a SIOP case, but would solve the above problem. Does require the RP to issue the token. If that is a JWT it would be offline verifiable by the RP or any Resource Server.

how does the user know what VC to submit in step 3 if step 1 does not contain information about what VC is being requested?

a presentation request would be included in the auth response (step 2)

@decentralgabe what is the problem you want to solve? Do you want to determine whether the user is already known with the SIOP v2 identifier and if not get one of more credentials to onboard the user?

@tlodderstedt yes exactly, avoid needing to re-request credentials depending on if they're known after authN

the wallet need to send something to the verifier so that the verifier can determine if the user has been authenticated or not, right? can verifier request SIOP in the first request and within the same browser session request credential presentation if there is credential presentation needed? the downside is that the user will have to click a URL twice or scan a QR code twice..

in step 4 you have "Auth token sent to user", why is this a requrement?

the wallet need to send something to the verifier so that the verifier can determine if the user has been authenticated or not, right?

yes

can verifier request SIOP in the first request and within the same browser session request credential presentation if there is credential presentation needed

this would be ideal - SIOP first, determine what is needed, and contextually request presentation

the downside is that the user will have to click a URL twice or scan a QR code twice..

hmm I suppose this is unavoidable unless the server was able to send a notification/callback to the client invoking the presentation flow. I don't think needing to scan twice is the worst experience, if need-be.

in step 4 you have "Auth token sent to user", why is this a requrement?

I was imaging a case where a new auth token would be useful with additional scopes, though this can be achieved through other means

there seems to be an agreement that doing SIOP (or some kind of user authentication) first and using that to determine if there is a need to request any credentials solves the problem without any changes to the spec?

I believe language in the spec would be useful to add to show this as a possibility.

would you like to do a PR? or propose something?

@Sakurann yes - if there is consensus then I am happy to self-assign and attempt a PR!