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
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:
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),
as well-known information about an origin,
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.
The text was updated successfully, but these errors were encountered:
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.
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.
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:
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.
The text was updated successfully, but these errors were encountered: