Error code if the wallet is not installed

[awoie]

We have a use case where a wallet backend handles HTTPS Deep Links (e.g., https://wallet.example.com) if the mobile platform does not invoke the user's wallet on the mobile device.

Expected flow:

• The user visits the RP in their mobile browser.
• The user taps a button containing a HTTPS Deep Link on the RP website.
• The mobile browser checks with the mobile platform if the intent can be handled by an app.
• In this case, it cannot be handled because the wallet is not installed.
• The mobile browser redirects to the wallet backend (e.g., https://wallet.example.com). Note, this is standard behaviour on mobile platforms.
• The wallet backend generates an error and redirects the user back with a wallet_unavailable error.
• The RP can now respond to the wallet_unavailable error with an alternative flow that does not require a wallet.

To improve UX, the wallet backend could redirect the user back to the RP with an error code, but we have not defined one for this case. I couldn't find a suitable error code in OAuth either. Defining a custom error code is not an option since it would be wallet vendor specific and this information should not be disclosed to the RP.

My suggestion is to define a new error code, wallet_unavailable, that MAY be returned in such cases. Note that, as with many OAuth implementations, it is at the AS's discretion to return an error code at all.

[jogu]

I think this sounds reasonable, but we should consider what to say to avoid falling into any of the traps mentioned in https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-29.html#section-4.11.2 - e.g. the backend should likely validate that the request is valid and the redirect uri belongs to the client.

Automatic redirects back of the user will also potentially get stopped by the browser, in some cases (particularly iOS) you usually need a page that the user has to click a button/link on for the redirect back to work. (This stops people discovering, for example, if a wallet is installed or not without the user being involved in the process - which is something the privacy / browser folks are concerned about.)

[awoie]

I think this sounds reasonable, but we should consider what to say to avoid falling into any of the traps mentioned in https://www.ietf.org/archive/id/draft-ietf-oauth-security-topics-29.html#section-4.11.2 - e.g. the backend should likely validate that the request is valid and the redirect uri belongs to the client.

Exactly, that is what we do in one of our use cases.

Automatic redirects back of the user will also potentially get stopped by the browser, in some cases (particularly iOS) you usually need a page that the user has to click a button/link on for the redirect back to work. (This stops people discovering, for example, if a wallet is installed or not without the user being involved in the process - which is something the privacy / browser folks are concerned about.)

Good point, yes, this is definitely also something we considered in this particular case.

[Sakurann]

WG discussion, no objection to the direction being discussed by Oliver/Joseph