search

WICG / digital-credentials

Digital Credentials, like driver's licenses
https://wicg.github.io/digital-credentials/
Other
82 stars 9 forks source link

define a well-known way for a verifier to indicate registration, validation, trustmark assurances or other necessary info #136

Open npdoty opened 5 months ago

npdoty commented 5 months ago

At the last meeting, there was recognition of a requirement that may apply to EUDI cases of the wallet needing to confirm the registration/approval of the verifier and a desire to also enable other kinds of trustmarks, attestations or verifications from third-parties that could help a user/wallet know whether to provide that information. (This also came up as a recommended approach in #59.)

This could potentially be done: 1) at the protocol layer, with an additional profile of how to communicate this information in client metadata (OAuth client metadata, in this case, metadata communicated about the server/verifier), 2) as well-known information about an origin, 3) or even as an API parameter.

Requirements may include indicating what data will be requested, for what purposes and for how long, who has verified the basis of the request, and then some proof of verification or attestation (a signature, basically) from that third-party (whether a local government data protection authority or some independent organization doing reviews).

There could be other information about the verifier that the verifier should, wants to or needs to communicate, including declared privacy policy information, an endpoint to access or request deletion of credential data previously collected, or who to contact regarding complaints or abuse of the system. As noted, there might be some similarities to past attempts at machine-readable privacy policy documents, but this would be specific to a particular sensitive use case, facilitate compliance with regulations, and be deployed in contexts with more regulator involvement.

jogu commented 5 months ago

As far as I know these things are all defined at the OID4VP level already, and work fine with the draft of the OID4VP browser API profile.

I am not sure there is anything for the browser API group to do.

npdoty commented 5 months ago

I did re-read the OpenID4VP Editor's Draft and RFC 7591 again before opening this issue to confirm that while it might be possible to use those to communicate some of this information, it didn't seem to be profiled or standardized. I've looked now at the PR for a browser profile, and while that describes some subset of these uses, I still don't see the detail on how that information would actually be communicated or examples of those attestations or trustmarks. If you have pointers on something else I should look at, or if I should open issues for clarification elsewhere, let me know.

jogu commented 5 months ago

That's fair. It provides the mechanisms (in some cases reusing existing OAuth mechanisms) but not necessarily in the VP standard nor is the detail necessarily there. There are profiles of OID4VP that do provide for it (for example the Italian one at https://github.com/italia/eudi-wallet-it-docs, and trust marks from the OpenID Federation spec can be used (however I don't know if that's the same kind of trust mark that you are referring to).

I guess my main point is that if we want to discuss this in WICG we should have some concrete action that needs to be taken at the API level in mind, and I'm unclear what that would be. If there isn't one then it's better to keep the discussion in a place that's closer to were any spec changes might need to be made - there's still plenty of other work to be done at the API level so in my opinion the WICG group should focus it's limited time on that work.

timcappalli commented 1 week ago

I guess my main point is that if we want to discuss this in WICG we should have some concrete action that needs to be taken at the API level in mind, and I'm unclear what that would be.

Agree with this. I think this is a discussion for the DCP WG.