Require JSON serialization checks "in and out"

[timcappalli]

Closes #125

The following tasks have been completed:

• Modified Web platform tests (link)

Implementation commitment:

• WebKit (link to issue)
• Chromium (link to issue)
• Gecko (link to issue)

Documentation and checks

• Affects privacy
• Affects security
• Pinged MDN
• Updated Explainer

---

Preview | Diff

[marcoscaceres]

This is not right here... you need to:

1. [=List/for each=] |request| of |requests|:
   1.1. [=serialize a JavaScript value to a JSON string|Serialize=] |request| a to a JSON string. Rethrow any exceptions.

[marcoscaceres]

@timcappalli, we also would need this on the way out, when readonly attribute object data; is set... though there might not be enough spec text in the current spec to add this right now. However, it would be good to add something.

[samuelgoto]

readonly attribute object data

The benefit of also doing this on the way back is that we could make this integrate well with fetch() ... arguably, we could also this in a separate PR ...

This is not right here... you need to:

Yeah, we'd still want to do this, I think.

[timcappalli]

we also would need this on the way out, when readonly attribute object data; is set... though there might not be enough spec text in the current spec to add this right now. However, it would be good to add something.

@marcoscaceres @samuelgoto isn't this already covered by using the default toJSON() method?

[marcoscaceres]

No. This is because if the wallet returns some bogus value that is not a JSON object (e.g., a string, or a number, will TypeError at this point), then that can't map to .data (because it's required to be an object). Thus you need to JSON parse the response before it is stored in .data... then the developer calling .toJSON() walks both the DigitalCredential instance and the . data. structure.

Make sense?

[marcoscaceres]

Couple of small things...

[marcoscaceres]

@timcappalli, see also #179 (comment)