[spec] DigitalCredentialRequestOptions and DigitalCredential objects must be JSON serializable

[timcappalli]

In WebAuthn L3, we introduced new methods (toJSON, parseCreationOptionsFromJSON, and parseRequestOptionsFromJSON) for serializing responses and for deserializing requests.

This both improves the developer experience and also allows us to reference these methods directly in the CTAP specification for hybrid transports, instead of defining the encoding and structure there.

[timcappalli]

TPAC discussion: nice to have, but don't block for CGR-1

[leecam]

Yeah to follow up from TPAC. I think we agreed that if we update the spec to say that the DigitalCredentialRequestOptions and DigitalCredential objects must be JSON serializable (else its an error), then i think we can close this without defining explicit methods.

And to provide a bit of context on the conversion. webauthn's PublicKeyCredentialRequestOptions needs this method because it is specified in a way which isn't naturally JSON serializable, so it needs explicit methods to define how to make the conversions. We can avoid that if we just specify our objects are JSON serializable from the start

[MasterKale]

We can avoid that if we just specify our objects are JSON serializable from the start

Will it be feasible to define this behavior in the DC API spec in such a way that a typical JSON.stringify(dcAPIResponse) should work as expected? Or is there something about DigitalCredential that'd require its own .toJSON() like we did in WebAuthn?