Expose `AuthenticatorResponse` methods?

[lgarron]

Chrome 85 is adding:

• getPublicKey()
• getPublicKeyAlgorithm()
• getAuthenticatorData()

There's also getTransports().

https://w3c.github.io/webauthn/#iface-authenticatorattestationresponse

We could:

• Not expose these.
• Expose the actual WebAuthn API response object so that the user can call anything they want on it. (We may want to expose our base64url conversion to help with this.)
• Forward the available methods without modification.
• Proxy any available methods, converting to baseurl64.
• Always call these methods, and attach the results (we do this for getClientExtensionResults() already).

The latter is the most convenient, but it results in extra data. The simple use case for @github/webauthn-json is to send the results to the server, which still has to process the response from CBOR. These methods would not really be useful for this case.

However, there are cases where you might want to do some or all processing on the client side, where this could save code.

[lgarron]

If anyone would like to be able to use these, it would help if you could leave a comment to let us know! Otherwise this might not be a priority.

[epheat]

I would love to see getTransports() exposed in the attestation response. Perhaps just as a field called "transports".

[emlun]

I agree with adding the transports field to the AuthenticatorAttestationResponse value (perhaps conditionally, if the client provides the method). The WebAuthn spec now recommends all RPs to store the getTransports() result, so I think it makes sense to support that here.

I'm also willing to contribute a PR to make that happen. :slightly_smiling_face: I was about to reference webauthn-json in the java-webauthn-server quickstart instructions - in order to get transports and extensions and all that through, but avoid the base64 (de)coding distractions - but unfortunately that won't quite work without this.

[lgarron]

I agree with adding the transports field to the AuthenticatorAttestationResponse value (perhaps conditionally, if the client provides the method). The WebAuthn spec now recommends all RPs to store the getTransports() result, so I think it makes sense to support that here.

I'm also willing to contribute a PR to make that happen. :slightly_smiling_face: I was about to reference webauthn-json in the java-webauthn-server quickstart instructions - in order to get transports and extensions and all that through, but avoid the base64 (de)coding distractions - but unfortunately that won't quite work without this.

I think a PR to add transports would be great!

[emlun]

Alright, PR is open: #44 ! :slightly_smiling_face: