digital-credentials

digital-credentials copied to clipboard

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.

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.

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;
};

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 is included in clientData. For the DC API, any nonce or state is part of the request properties.

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

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 would only be for development convenience as type is inferred based on the request, crossOrigin and topOrigin can be inferred, and origin is always provided.

Can discuss again in the future. Closing issue.