Relying Site/Verifier Lack of Scope or Restrictions

[zoracon]

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.

[npdoty]

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