JSON parsing should be on top of Infra primitives

[annevk]

I suspect that most can be replaced by https://infra.spec.whatwg.org/#parse-json-bytes-to-an-infra-value. This will also require some changes to the following steps as they now have an Infra value. This should also allow for the removal of the notes as now this is all well-defined instead of somewhat hand-wavy.

[timcappalli]

This will also require some changes to the following steps

@annevk which steps are you referring to?

[annevk]

For instance in https://w3c.github.io/webauthn/#sctn-registering-a-new-credential steps 5/6 would be combined by instead calling into Infra. Then step 7 and such can no longer use the C.type syntax to refer to members. Instead you'll have to use

C["type"]

which will make it more consistent with other specifications.

[emlun]

While I somewhat agree in principle, I'm not sure that using parse JSON bytes to an Infra value is better. It indirectly references invoking %JSON.parse% from ECMAScript, which may be appropriate if this verification step happens to be running in a browser, but these steps often run on a backend server that's not JavaScript, so it seems awkward to (indirectly) refer to ECMAScript procedures in those cases. While yes, describing these RP operations as operating on JavaScript values is a bit of a fantasy as they've most likely been transformed to and from network representations along the way, I'm not sure that using Infra values really adds much.

I would leave this as is for L3 and maybe reconsider for L4.

[annevk]

The browser doesn't always implement that step in terms of a JS engine either. What's important is that the outcome is the same and does not deviate from that operation. Historically at least there have been differences and specifications should avoid causing more of those to come up.