Re: [webauthn] Provide request deserialization, response serialization (#1683)

Thanks for the proposal! I recently toyed with this in Chromium, and I have a couple suggestions.

For the response case, wouldn't it be simpler to define a toJSON() method that can be called on the respective PublicKeyCredential instance that the WebAuthn call returns, rather than have a static PublicKeyCredential method that effectively receives the instance plus 'method' as arguments? IMHO that'd be easier to use and it's what the [Web IDL spec](https://webidl.spec.whatwg.org/#idl-tojson-operation) suggests here.

(Obviously, that's not possible for the request objects, since they're just dictionaries, rather than interface types.)

For either response examples, the top-level PublicKeyCredential-ish object should include an `authenticatorAttachment` field, I think? 

For the create response example, why does `transports` appear in the top-level dictionary? I believe that information comes from `AuthenticatorAttestationResponse.getTransports()`, so shouldn't it appear in the object under the `response` key?

Also for the create response example, I believe the `response` key dictionary should include the data from the `getAuthenticatorData()`, `getPublicKey()`, and `getPublicKeyAlgorithm()` helpers. I believe those methods were added specifically to aid RPs that wish not to carry a CBOR parsing dependency, so omitting that data would make the `toJSON()` helper less useful IMHO.

> That said - I believe browsers are all currently white-listing extensions, which means that they can ignore the formatting/validity of requested extensions they do not understand.

I think it's a fair assumption that browsers will not pass authenticator extensions in either direction that they don't understand. It's true for Chromium, and likely the case for the remaining WebAuthn implementers as well.

-- 
GitHub Notification of comment by kreichgauer
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1683#issuecomment-1013539384 using your GitHub account


-- 
Sent via github-notify-ml as configured in https://github.com/w3c/github-notify-ml-config

Received on Friday, 14 January 2022 23:25:56 UTC