You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If this is a duplicate of another discussion, happy to carry my questions over.
My assumption after reading through and looking at the API:
This API appears to enable "anyone" to ask for your credential. And there doesn't appear to be any restrictions on who the verifier can be. If that assumption is incorrect, glad to see what solutions are currently being worked on or available.
As it stands the Relying site seems to have a lot of power around how much information it can request upfront without much restriction until of course the holder verifies after the request scope is sent directly to the wallet to confirm.
Outside of presentation_definition, where can there be better restrictions and controls in the landscape of "everyone becoming a verifier"? It would be great where at some layer that request scope is declared and the holder is given options to handle those scopes. That way some control is given to the user before the request is sent to their wallet to confirm. This would make selective disclosure a little more proactive/automated, and less burdensome to the holder.
Example for clarity of what I am thinking.
I declare somewhere in my browser I only want to use my credential for age based claims.
The presentation scope is declared, and my browser catches that the Verifier wants more than I am willing to use my credential for.
Some sort of controls and UI that allow me to have a sliding scale of options to give me an extra warning or auto-reject.
The text was updated successfully, but these errors were encountered:
zoracon
changed the title
Relying Site/Verifier Scope or Restrictions
Relying Site/Verifier Lack of Scope or Restrictions
Oct 29, 2024
Part of this may be related to #136 with information about the verifier
I am interested in what you meant by "browser profile". Maybe this is where this scope control can be implemented. The holder doesn't appear to have any way to predetermine how they want to use their credential in a world where this API is enabled and mass adoption occurs for various sites (malicious, adversarial, etc) before the prompt goes to their device to initiate selective disclosure. I want the holder to be able to be given the option to reject a scope they are not okay with from a verifier in a more automated/less invasive way.
In the case of another app on your device as well, I'd like to see scope control as well.
If this is a duplicate of another discussion, happy to carry my questions over.
My assumption after reading through and looking at the API:
This API appears to enable "anyone" to ask for your credential. And there doesn't appear to be any restrictions on who the verifier can be. If that assumption is incorrect, glad to see what solutions are currently being worked on or available.
As it stands the Relying site seems to have a lot of power around how much information it can request upfront without much restriction until of course the holder verifies after the request scope is sent directly to the wallet to confirm.
Outside of
presentation_definition
, where can there be better restrictions and controls in the landscape of "everyone becoming a verifier"? It would be great where at some layer that request scope is declared and the holder is given options to handle those scopes. That way some control is given to the user before the request is sent to their wallet to confirm. This would make selective disclosure a little more proactive/automated, and less burdensome to the holder.Example for clarity of what I am thinking.
The text was updated successfully, but these errors were encountered: