OpenID4VCI

OpenID4VCI copied to clipboard

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.

‌

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.

Imported from AB/Connect bitbucket - Original Commenter: alen_horvat

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

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?

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.

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

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?

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?

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.

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)

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)

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

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.

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

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?

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

I believe this can be added post 1.0 in a non-breaking manner, if we decide to do so?

At EIC 2025 I saw the demo from Lissi, which was quite cumbersome to run through without redirects during issuance. Coudl we revisit this topic, maybe also with new views regarding DC API?

Potentially this could be solved by DC API from my view, could you confirm @leecam Could also be solved in vanilla OpenID4VCI by the Wallet App minimizing/terminating its activity? Otherwise, what's the downside of a simple solution sending a redirect in Credential Response other than supporting only a single issuance?

WG discussion:

• is this 1.1? 1.0 conditional to implementation experience?
• options where to return completion_uri:
  1. [feels murky] response that contains a credential: credential response or deferred response. wallet is 100% free to ignore this.
  2. extend notification endpoint? by allowing to return completion_uri
  3. define a new completion endpoint in the issuer metadata
  4. [not a good option] crash a wallet app and open a previous app (browser)... does not work on iOS and maybe not always on android
  5. [not a good option] credential offer: this one is not integrity protected.
• DO NOT CALL THIS REDIRECT_URI
• wallet and issuer cannot always rely on this 100%, so this is an unreliable feature which might be helpful in certain context...
• make sure this works in deferred issuance
• common minimum denominator use-case that wg seem to agree on: continuing the session regardless whether the credential has been received or not

current preferred option seems to be 3 and maybe 2. will come back to it - ppl need time to think

I am not sure I agree with the assessment that v) is really an issue.

We are considers flows where the user is initiating by activating a url (either through a website surface, email, QR code or some other mechanism).

The phishing attack here would be to substitute the completion URL with a phishing website, so that if the user otherwise successfully completes the flow they will be redirected to the attacker surface.

However, if the attacker can do this, they already have the user navigating to a link in control of the phishing attacker. Seems more effective to simply directly attempt to phish that user than to bounce them through a wallet, hope they don't drop off, can actually complete the offer, and eventually get phished.

The advantages of it being in the credential offer:

• Easier for the initiating website to know their context
• Allows 'returning' on error cases
• Doesn't have any of the complex questions of what happens when the completion url is returned when not initiated from a credential offer, subsequent refreshes etc.
• Matches DC API semantics, providing a more consistent experience over different engagement mechanisms.

I think that, if we aren't concerned about phishing this is clearly the correct location for it, and it seems hard to justify that a redirected phishing attacker is really more effective than just directly doing so, given you've already gotten a user to click your link.

Thoughts?

chair hat on. we already marked this stretch goal, but looking at the number of PRs and the timelines, chairs are inclined to do this in 1.1, also because all proposed options are extensions and not breaking change

As mentioned on the WG call, I don't think this is a good idea for the reasons provided in the call. To name a few: session mismatch especially in deferred flows, being prone to errors where the issuer requires the wallet to continue in the browser but the wallet/user rejects/does not want to leave the wallet, reliability on certain OS' if we define a dedicated custom URI scheme (which I would object; but HTTPS links might work).