fix: add wallet_unavailable error code; fixes #191 #200
Conversation
jogu
left a comment
jogu
left a comment
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 <joseph@authlete.com>
That sounds good to me. I'll update the PR. |
|
@peppelinux @jogu I updated the PR to incorporate your requested changes. Please review again. |
|
|
||
| `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?
|
|
||
| ## 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.
|
|
||
| ## 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?
|
|
||
| `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.
Sakurann
left a comment
Sakurann
left a comment
There was a problem hiding this comment.
please add document history entry :)
Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>
Co-authored-by: Kristina <52878547+Sakurann@users.noreply.github.com>
|
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.