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.
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.