Redirect-URI for OpenID4VCI

OIDF-automation commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

Imported from AB/Connect bitbucket - Original Commenter: alen_horvat

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

OIDF-automation commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 10 months ago

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 commented 9 months ago

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 commented 8 months ago

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 commented 5 months ago

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 commented 5 months ago

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:

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)
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)

selfissued commented 5 months ago

This reminds me of the post_logout_redirect_uri at https://openid.net/specs/openid-connect-rpinitiated-1_0.html#RPLogout.

jogu commented 5 months ago

Another suggestion after discussion on today's WG call - if this only makes sense in the case where a credential offer is used (which seemed to be the consensus today), then the url could be included in the credential offer.

paulbastian commented 2 months ago

Feedback from IIW#38 was that Issuers want to keep screen control, as its often important for further business interactions and would otherwise mean that they lose money

jogu commented 2 months ago

Did any of them have thoughts that might help answer questions 1 or 2 above? Or can we ask them to give some feedback on that?

paulbastian commented 2 months ago

People just stated that their customers would probably not be willing to use Openid4vci as an issuer if they could not get back the screen control afterwards

openid / OpenID4VCI