What should be the data type for the response?

[samuelgoto]

What should be the WebIDL data type for the DigitalCredential.data response?

This is currently returning any (to keep Safari and Chrome's implementation interoperable), but we should probably be more specific than that.

A few options that occurred to us:

• An Uint8Array
• A DOMString (what WebOTP uses)
• An USVString (what FedCM uses -- as opposed to a DOMString it can take UTF-8, e.g. application/json, guidance from TAG here and here),
• An ArrayBuffer (what WebAuthn is using, but also apparently discouraged)
• A Blob, which has a text() and bytes() methods (thanks to Joshua Bell for bringing up this suggestion!).
• object if everything can be JSON.parse()-able

It is not clear to me what are the trade-offs between these options (mostly ergonomics? or are there security trade-offs here?) nor what the requirements are (e.g. do we need to support passing back binary or non-JSON response's data?), so this issue here is intended to try to collect requirements and help us figure out what's best to use.

@marcoscaceres FYI

[marcoscaceres]

Use of ArrayBuffer is discouraged (unless there's a good reason), so probably a Uint8Array.

See also: #93 and w3ctag/design-principles#463

However, before we settle on something, we need to make sure we fully understand what wallets are going to be returning.

There's also some overlap with #95 cc @timcappalli

[samuelgoto]

However, before we settle on something, we need to make sure we fully understand what wallets are going to be returning.

Yeah, agreed that this is the key question. The main question I have on my mind is whether wallets are going to be returning bytes or strings (e.g. text/json). I'm assuming wallets are going to be returning small payloads, so we don't need streams.

So, to narrow down the options here, I think we have to decide between a USVString (assumes text) and an Uint8Array (assumes bytes), which I think comes down to a trade-off between ergonomics (strings are easier to use) and expressivity (bytes can represent binary sequences).

We should also probably find a way to avoid cornering ourselves doing something that is forwards compatible if we wanted to change the type later.

[samuelgoto]

In the CG call today we converged as a group that object is the preferred direction, since:

• we heard from @Sakurann that everything coming back from OpenID4VP would be JSON-serializable, so doesn't have to be Uint8Array,
• If text can be assumed, object is more specific than DOMString and USVString, as JSON-parseable text

We heard from Lee that the cross-device hybrid/ctap structure also assume that the response can be JSON-parseable/stringifiable, so this aligns well.

@marcoscaceres and I will work towards patching the spec to specify that the response data is of type object.