Add redirect_uri to (Deferred) Credential (Error) Response to continue interaction with end user

[mickrau]

closes #61

[paulbastian]

Some suggestions, but generally looks good to me.

[fkj]

I have some editorial suggestions, but the direction look good to me.

[c2bo]

General question ons redirect_uri from a security perspective:

• Should this be restricted to the same origin of the issuer / issuance flow? Imho a good idea
• Restrict to only https
• We should probably add wording along the lines, that the wallet should display the URI when asking for user consent?

[fkj]

Maybe not display the whole URI (which could be long), but at least the origin? I agree we should restrict to https, and probably to issuer origin.

[mickrau]

I think a restriction to the same origin (as credential_issuer) is too restrictive and does not really improve security.
If the legitimate issuer wants to redirect the user to a non‑same‑origin URL, they could do so anyway via a browser redirect.
If an attacker is able to tamper with TLS‑protected traffic, then fixing the origin of redirect_uri would probably not provide a significant security gain.

If we restrict it to https, could this prevent some legitimate app‑to‑app scenarios?

Showing the origin to the user seems fine to me.

[paulbastian]

I agree with @mickrau , we assume that redirect_uri cannot be tampered with, otherwise we have much bigger problems, so I believe restricting to origin of credential_issuer_url doesn't provide benefits.

Restricting to https, would enforce issuers that want to to redirect to a native app to use claimed URLs, correct? Should be okay though..

[fkj]

Claimed URLs are safer since they provide more protection against spoofed apps through assetlinks.json/apple-app-site-association. One thing that we should probably allow from a UX perspective is for the wallet to either display the origin or the app that is going to open the link (i.e. the associated app). I'm not up to date on what's possible on the platforms here wrt. getting this info up front.

After more consideration, I agree that restricting to issuer origin is does not provide any security and might be a bit annoying in some cases.

[mickrau]

• ok, i think we all agree to restrict to https (i will update the PR)

Regarding the points related to the origin, there isn’t a compelling argument yet.

[GarethCOliver]

In my opinion this doesn't make any sense and shows the problem with the current proposal.

There should be sufficient semantic information included with the redirect_uri for the Wallet to understand the purpose. Without this, it is impossible to reasonably render this to the user. Overloading a single 'redirect_uri' parameter provides none of that context and will lead to broken user experiences (or it being simply ignored).

To give some examples:

Error case:

• Is this a url relevant to a transient error message?
• Is this a url relevant to the state of the credential?

Deferred:
This is the most well defined, but being explicit that this is about the status of the deferred credential request. But knowing what this means when the user has existing successfully provisioned credentials is necessary.

Success:
Is this a one-off warm welcome? Does it get shown once to the user then never again? What about subsequent responses? In general, this would better belong in well-defined field in per-instance credential metadata rather than in the credential response.

Regarding the problem of credential datasets and whether this is the same or different: if we provided more semantic structure we could include an indicator in the response as to whether this is a 'top-level' usable redirect (applying to the access token and applicable to all credentials) or if it is specific to this instance. Making the user go through multiple issuance processes to allow for granular issuer redirects seems pretty broken.

[fkj]

Just to clarify, do you see problems only when there are multiple credentials issued in one process or also when it's just a single credential being issued? My thinking is that this is only a problem for issuing multiple credentials at once, and I agree that the semantics of that are weird here.
Though I think the current text in this PR is still an improvement, and I think issuers could intelligently provide a single redirect_uri for the entire process, even though it is strange that it would need to repeat it in each credential response.

[GarethCOliver]

It's less problematic in a single, one-shot credential use case though it is still unclear what exactly it should mean in the case of success. What context should I, as a wallet, provide to the user as to why they should navigate to this URL?

In general I think most these use cases are probably better covered putting these urls into credential display data, that way they can have the actual semantic information for a wallet to know how to use them (especially now we have per-credential display data).

If we do have transient urls, they should be tightly coupled to their meaning in the response (e.g. a url specifically for more information on an error), again so that Wallets can actually properly know how to use them.

[fkj]

Thanks. I agree that it would be useful to have some context for the wallet. But I'm not sure we will be able to enumerate all of the options, which would IMO be necessary for interoperability. Obviously there's "success" and "error", but anything beyond that seems less likely to be taxonomizable.

[Sakurann]

APAC wg call

• problem is well understood, but needs more discussion if this technical mechanism solves the problem.
• need clarity what to do when there are multiple credentials are being issued.

[Sakurann]

WG discussion: @GarethCOliver to propose alternative design

[GarethCOliver]

There are two problems attempting to be solved with redirect_uri:

1. In a 'add to wallet' flow, upon completion of the task at hand, redirect back to the initiating surface.
2. In deferred or successful flows, provide a mechanism to link to the issuer for more information.

While these are both 'redirecting to the issuer', they are substantially different problems, and should have different solutions.

For 1) I propose the following:

Add an 'redirect_uri' to credential offer. To prevent phishing attacks, add 'supported_redirect_origins' which the redirect_uri MUST conform to else the Wallet MUST ignore.

Pros:

• Has the same lifecycle as what we are trying to match (1 redirect_uri per issuer-iniation)
• Support redirecting before credential response (e.g. auth failure, user cancel etc)
• Clear semantic meaning

Cons:

• supported_redirect_origins is a bit awkward, and may be error prone

For 2) I propose the following

to 'display' credential metadata add the following optional properties:

• 'deferred_status_url': URL linking to information about the deferred status of the credential
• 'warm_welcome_url': URL linking to information describing how the credential is used, displayed to the user after first successful issuance

Pros

• Follows the same lifecycle as other display data about a credential, including per instance and (in the future) credential sets
• Clear semantic meaning so the Wallet knows how to use it (e.g. only show deferred if there are no longer valid credentials)
• Works beyond initial credential issuance
• Extensible pattern for communicating more issuer-controlled display data