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

[zoracon]

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.

[zoracon]

@npdoty are there any other forums to being this concern to? Or meeting?

[timcappalli]

@zoracon the contents of the request is defined by the protocol. Web Platform UI, outside of requirements for user interaction, aren't typically specified. There is currently one protocol with support for the Digital Credentials API which is OpenID4VP, which is in the OpenID Foundation. Recommend reviewing that specification and then opening an issue over there if there are questions/concerns/suggestions.

[zoracon]

@zoracon the contents of the request is defined by the protocol. Web Platform UI, outside of requirements for user interaction, aren't typically specified. There is currently one protocol with support for the Digital Credentials API which is OpenID4VP, which is in the OpenID Foundation. Recommend reviewing that specification and then opening an issue over there if there are questions/concerns/suggestions.

To be clear, I read the specification. But was told that the UI/UX aspects could be addressed here. Only to be sent back, with the assumption I didn't go over this draft spec either. I read the scope of this repo: "It does not yet encompass the issuance process for establishing a digital identity nor UI/UX considerations beyond privacy aspects related to data protection during the request process." I read "yet" as in, could be addressed here. If that is not the case, then I will go back over the other repo referencing your comment.

[zoracon]

To add, this is simply more about UX/UI tweaks. It's about the fact this API can enable anyone on the internet to ask for credentials to be sent to one's wallet, without much choice in enabling mechanisms for selective disclosure, outside of hoping the user will know to reject an over-reaching request.