fix: add wallet_unavailable error code; fixes #191 #200
Conversation
There was a problem hiding this comment.
I think we probably need some more explanation in the specification text; it's not intuitive how this code is used and I think we need to mention the privacy/security concerns (as discussed on the issue) that the error code mustn't be returned without consent from the user.
Co-authored-by: Joseph Heenan <[email protected]>
That sounds good to me. I'll update the PR. |
|
@peppelinux @jogu I updated the PR to incorporate your requested changes. Please review again. |
| @@ -791,6 +791,10 @@ This document also defines the following additional error codes and error descri | |||
|
|
|||
| - The value of the `request_uri_method` request parameter is neither `get` nor `post` (case-sensitive). | |||
|
|
|||
| `wallet_unavailable`: | |||
|
|
|||
| - The Wallet appears to be unavailable and therefore unable to respond to the request. This can be useful in situations where the user agent cannot invoke the Wallet and another component receives the request while the user still controls the user experience and wishes to continue the journey on the Verifier website. For example, this applies when using claimed HTTPS URIs handled by the Wallet provider in case the platform cannot or does not translate the URI into a platform intent to invoke the Wallet. | |||
There was a problem hiding this comment.
I would use the term user-agent to clarify that's a specialized entity
There was a problem hiding this comment.
I'm not sure I'm following, could you expand on your suggestion please Guiseppe? Maybe suggest alternative text?
| @@ -1205,6 +1209,10 @@ Mandatory user interaction before sending the request, like clicking a button, u | |||
|
|
|||
| Requests from the Wallet to the Verifier SHOULD be sent with the minimal amount of information possible, and in particular, without any HTTP headers identifying the software used for the request (e.g., HTTP libraries or their versions). The Wallet MUST NOT send PII or any other data that could be used for fingerprinting to the Request URI in order to prevent user tracking. | |||
|
|
|||
| ## Authorization Error Response with Wallet unavailable error code | |||
|
|
|||
| In the event that another component is invoked instead of the Wallet while the user still controls the user experience, the user MUST be informed and give consent before returning the `wallet_unavailable` Authorization Error Response to the Verifier. | |||
There was a problem hiding this comment.
I'm not sure I follow the 'while the user still controls the user experience' part. What is an example of where the user isn't in control?
There was a problem hiding this comment.
I think I can remove that by-sentence because we are already saying the user MUST be informed. I updated the PR.
| @@ -1205,6 +1209,10 @@ Mandatory user interaction before sending the request, like clicking a button, u | |||
|
|
|||
| Requests from the Wallet to the Verifier SHOULD be sent with the minimal amount of information possible, and in particular, without any HTTP headers identifying the software used for the request (e.g., HTTP libraries or their versions). The Wallet MUST NOT send PII or any other data that could be used for fingerprinting to the Request URI in order to prevent user tracking. | |||
|
|
|||
| ## Authorization Error Response with Wallet unavailable error code | |||
|
|
|||
| In the event that another component is invoked instead of the Wallet, the user MUST be informed and give consent before returning the `wallet_unavailable` Authorization Error Response to the Verifier. | |||
There was a problem hiding this comment.
so we are relying on this another component that is invoked to return this error, right?
There was a problem hiding this comment.
@Sakurann I updated the PR.
| @@ -791,6 +791,10 @@ This document also defines the following additional error codes and error descri | |||
|
|
|||
| - The value of the `request_uri_method` request parameter is neither `get` nor `post` (case-sensitive). | |||
|
|
|||
| `wallet_unavailable`: | |||
|
|
|||
| - The Wallet appears to be unavailable and therefore unable to respond to the request. This can be useful in situations where the user agent cannot invoke the Wallet and another component receives the request while and the user wishes to continue the journey on the Verifier website. For example, this applies when using claimed HTTPS URIs handled by the Wallet provider in case the platform cannot or does not translate the URI into a platform intent to invoke the Wallet. | |||
There was a problem hiding this comment.
If my understanding is correct, I would add something to clarify that it is not the wallet, but the wrong component invoked instead of a correct wallet that return this error?
There was a problem hiding this comment.
Yes, that is correct. I can add this.
There was a problem hiding this comment.
@Sakurann I updated the PR.
Co-authored-by: Kristina <[email protected]>
Co-authored-by: Kristina <[email protected]>
|
Now has 3 reviews (many thanks @ssanchocanela!), all outstanding comments resolved and has been open for over a week - merging! |
This PR adds an optional error code
wallet_unavailable; fixes #191.