Redirect-URI for OpenID4VCI

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/2048

Original Reporter: @paulbastian

Analogous to OpenID4VP, it might make sense to add an OPTIONAL redirect-uri parameter in the body of Credential Response (or similar to Batch/Deferred endpoints) to give the issuer the possibility to get back screen control and proceed in the UX in a same-device flow.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: pwlb

The most common scenario for this is issuer initiated issuance flows with credential offer,

e.g. The user is on a website and the website optionally offers to issue a membership credential from the settings page, after the issuance the wallet wouldn’t know how to continue and the user would expect to continue form the settings page.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: alen_horvat

This would be a nice addition for the same-device flow.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

usually, the issuer can refresh the UI on the device where the issuance flow has started after it sends a credential response (or a callback from the wallet if PR #608 goes in). This is not possible only when it is pre-authorized code flow where credential offer is communicated using means other than a website. but since the issuer already has a way to send credential offer to a user, can it send next steps using the same channel after issuance of a first credential?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: alen_horvat

Here the user is already in the wallet and the wallet just fetched the VCs from the server.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: pwlb

exactly, in same-device flow the UX ends in the wallet screen and the user does not recognize the refreshed issuer UI unless he will switches apps which the average user might not do

[tlodderstedt]

I think this feature is useful if the flow started with the issuer. What I would like to understand is, when this URL should be sent in the issuance response. I'm asking since a certain offer and the resulting tokens can be good for issuing a lot of credentials. Shall the credential issuance endpoint return the url in any response? We might also take into account that it is the issuer, that sends the offer and also the credential response. I think if we just extend the credential response with the ability to return a redirect URI, that could be sufficient. Simply because why should the issuer talk to itself through a parameter the wallet understands and passes onwards?

[Sakurann]

I think if we just extend the credential response with the ability to return a redirect URI, that could be sufficient. Simply because why should the issuer talk to itself through a parameter the wallet understands and passes onwards?

What are the alternatives (if any)?

Is issue #79 relevant here as I think the user_session I mention in the issue is equivalent to the request_id sent as state and then included as a response_code with the redirect_uri as described in OID4VP section 11.5?

[svenstucki]

This would be a useful addition to the protocol for the same-device flow.

Adding it to the credential response would make sense.

The wording in OpenID4VP is quite strong:

When the redirect parameter is used the Wallet MUST send the User Agent to this redirect URI.

If this is taken over 1:1, the issuer needs to be careful about using it during multi-credential issuance (as it interrupts the process in the wallet). But relaxing it is tricky as well, e.g. allowing the wallet to only redirect the user after the last expected credential issuance call. The strong version would already be very useful and simple though.

[paulbastian]

Discussion with Bundesdruckerei and Lissi:

Option 1: Send redirect_url in (Batch) Credential Response Parameter (after optionally sending notification request first)

• a) wallet opens redirect in any case -> easy, but no information about the success, landing page has no feedback whether credential was successfully issued if the issuer did not receive notification yet
• b) wallet opens redirect in any case -> issuer waits for notification -> seems complicated, notification endpoint is optional, landing page can display success/failure
• c) wallet appends simplified query parameter failure=true

Option 2: Send redirect_url in Notification Endpoint Response Parameter

• easy, but notification endpoint is optional and the concepts do different things and should not be entangled

Conclusion: we slightly prefer Option 1 c)

[jogu]

Are you suggesting this is mandatory to implement? That seems like it might trigger the same objections that resulted in the notification endpoint being optional to implement.

"1c" is inevitably tangling together notification, and raises a new question of what happens if there's multiple credentials and some succeed and some fail.

I'm not clear what is the expected behaviour of the wallet when there are multiple credentials, in particular:

1. What happens if a redirect url is returned from a credential response before the wallet has finished fetching all credentials (the wallet won't want to lose control immediately so the implication is the url would only be launched after all credentials reached a final state)
2. What happens if each credential returns a different redirect url? (the wallet can only launch one of them; I think we should at least say something about this)