Tim Cappalli

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

There is some level of precedent for this from WebAuthn: - https://w3c.github.io/webauthn/#sctn-iframe-guidance - https://w3c.github.io/webauthn/#sctn-seccons-visibility This is also another reason to consider a [clientData](https://w3c.github.io/webauthn/#dictionary-client-data) equivalent to include things like cross-origin boolean...

> There is a new API @leecam just for completeness in the conversation, this is an app platform API, correct? (e.g. an Android OS API)

2024-06-26 call: @RByers to tweak the explainer to make this point clear.

Parking this issue for future discussion where `.create` methods are discussed.

The verifier should know its calling origin, and could include it as a parameter in the signed request. The web platform can pass the origin to the app platform and...

> Not saying things are entirely equivalent here but isn't this the assumption that WebAuthn makes? E.g if the origin is compromised, an attacker could trick a webauthn provider to...

> Can we see an example of this data structure in the context of the existing navigator APIs? ```webidl [Exposed=Window, SecureContext] interface DigitalCredential : Credential { readonly attribute DOMString protocol;...

Question for discussion in the F2F/hybrid meeting: should we put a hash of the request object into clientData? Otherwise there is nothing to correlate in clientData. In WebAuthn, the challenge...

Outcome from 2024-06-21 hybrid meeting discussion: add clientData without TLS session context and with hash of the request object. https://github.com/WICG/digital-credentials/wiki/2024-06-21-Hybrid-Meeting-Notes#spec-items-clientdata-payload-95