Describe trust signals in protocol registry

[npdoty]

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]

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]

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]

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]

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.

[RByers]

Discussed in the call today (after @npdoty had to drop off, sorry Nick). I think we agree that this API isn't at the right layer to be able to "define a well known way ...", but instead we can and should point to the trust systems used in practice under each protocol. Probably our protocol registry is the best place to do that - though a given protocol will itself probably only link to definitions higher in the stack (eg. there will be an EUDIW trust framework on top of OpenID4VP, but other OpenID4VP use cases will operate without any such framework).

Then once we're able to point to at least one existing trust framework, our security and privacy considerations section should encourage implementations to leverage knowledge of those frameworks in their UI somehow.

So there's a bit of work for us to track here, while all the real detailed work will be done higher up in the identity stack.

Sound reasonable to you Nick?

[npdoty]

It sounds like one option is for us to punt this question to the protocol and then for the protocol to punt this question to some vague set of trust decisions that's a further layer of abstraction higher.

That's possible, but it seems to me that the likely outcome is that widescale deployment includes no indicators of registration, validation or trust and that to the extent that trustmarks are defined somewhere, that it will be largely disconnected from the origin or the web content initiating the request using the digital-credentials API.

Will implementations that plan to pass on protocol strings directly to wallets subsequently choose to introspect those requests, identify and consume trustmark information and then use that information in their UI? Or do we expect only wallets that parse protocol requests to use that information?