Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Relying Site/Verifier Lack of Scope or Restrictions #187

Open
zoracon opened this issue Oct 29, 2024 · 2 comments
Open

Relying Site/Verifier Lack of Scope or Restrictions #187

zoracon opened this issue Oct 29, 2024 · 2 comments

Comments

@zoracon
Copy link

zoracon commented Oct 29, 2024

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.
@zoracon zoracon changed the title Relying Site/Verifier Scope or Restrictions Relying Site/Verifier Lack of Scope or Restrictions Oct 29, 2024
@npdoty
Copy link

npdoty commented Nov 13, 2024

Part of this may be related to #136 with information about the verifier

@zoracon
Copy link
Author

zoracon commented Nov 16, 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants