Tim Cappalli

From editor's discussion: clientData would be valuable if the wallet had to sign over this data as part of their presentation. Since that is not required in OID4VP, adding this...

> Green arrows seem to be controlled by Chromium, Safari, Geko (Browsers) > > Purple arrows seem to be controlled by iOS and Android / Samsung. (Mobile OS) > >...

The OID4VP profile for the Digital Credentials API is actively being work on in the OpenID Foundation's [Digital Credentials Protocols](https://openid.net/wg/digital-credentials-protocols/) working group. Closing this issue.

Thinking about this a bit more, I'm not sure this is something that the web platform API should address. It is ultimately up to the credential selector provided by the...

2024-06-26: this would be addressed by the OID4VP layer, and is being [discussed in that WG](https://github.com/openid/OpenID4VP/issues/178) in the context of the new query language

2024-07-29 call: agreed with [conclusion](https://github.com/WICG/digital-credentials/issues/42#issuecomment-2192745138), closing issue.

Discussed on the 2024-02-26 call Raw notes: AI generated summary: > Manu raises the question of how the verifier can trust digital signatures, suggesting possibilities such as metadata discovery between...

This issue has been quiet for a year. The shape of the API and relationship to downstream protocols is largely agreed upon. Is there anything else from this issue that...

What if we called it `DigitalCredentialsPresentationRequest`? It is long but a bit better than providers IMO. ``` dictionary DigitalCredentialRequestOptions { sequence presentationRequests; }; ``` /cc @marcoscaceres @bc-pi

@marcoscaceres @samuelgoto #71 is still open, but the current spec text uses `DigitalCredentialRequestOptions`. Are we sticking with that or still considering `IdentityRequestDetails`?