Should we add a clientData like object?

[timcappalli]

In WebAuthn, we have clientDataJSON and clientDataHash, which represent contextual bindings for both the relying party and client.

clientDataJSON is a JSON object containing properties enumerated by the WebAuthn client. This is then hashed (SHA-256), clientDataHash, and passed to the authenticator who then signs over it as part of the ceremony. The original clientDataJSON is passed back to the relying party by the client in the response.

For the Digital Credentials API, we need to get the origin from the web platform down to the app platform and over to the wallet. And as we consider cross-origin and iframe usage, topOrigin and crossOrigin become important properties. There have also been discussions around the client's TLS session context being valuable to a wallet (#46, #81). Therefore it may make sense to to have a clientData-like property in the Digital Credentials API.

Potential structure for clientDataJSON, inspired by WebAuthn:

{
  type: `${finalApiShortName}.presentation` || `${finalApiShortName}.issuance`,
  origin,
  topOrigin,
  crossOrigin,
  tlsContext: {
    subject: {},
    issuer,
    thumbprint   
  }
}

While issuance is not in scope for the initial work stream, we expect the API to also be used for invoking issuance at some point in the future, so it would be good to include type day 1.

[OR13]

Can we see an example of this data structure in the context of the existing navigator APIs?
I'd especially like to make sense of the multiple certs use case, in the context of this.

[timcappalli]

Can we see an example of this data structure in the context of the existing navigator APIs?

[Exposed=Window, SecureContext]
interface DigitalCredential : Credential {
  readonly attribute DOMString protocol;
  readonly attribute DOMString data;
  // clientDataJSON is a Base64 encoded URL String
  readonly attribute DOMString clientDataJSON;
};