Implement AuthenticatorAttestationResponse interface

[liuyangc3]

Description

Implement AuthenticatorAttestationResponse interface metheds:

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

Use Case

It's not easy to parse CBOR encoded data in some enviroments. It will be helpfull if implement
the methods described in spec, e.g:

getPublicKey()
This operation returns the DER SubjectPublicKeyInfo of the new credential

Documentation

https://www.w3.org/TR/webauthn-2/#authenticatorattestationresponse

[james-d-elliott]

Use Case

It's not easy to parse CBOR encoded data in some enviroments. It will be helpfull if implement the methods described in spec, e.g:

getPublicKey()
This operation returns the DER SubjectPublicKeyInfo of the new credential

Why is it helpful? What is it going to be used for?

[liuyangc3]

Why is it helpful? What is it going to be used for?

I guess this link answers your question

[james-d-elliott]

Unfortunately it doesn't. This explains user agent / client-side convenience methods to avoid the RP having to parse the COSE format as far as I read it. This is not necessary for RP's that are already capable of parsing CBOR data.

Particularly telling lines are as follows:

For those uses, user agents can do the work of parsing, expose the authenticator data directly, and translate the credential public key into a more convenient format.

Relying Parties that require this function to exist may not interoperate with older user-agents.

[liuyangc3]

Well, if a user needs to verify a signature using a public key, the first step is to convert the public key from COSE format to PKIX, ASN.1 DER format. Following that, the public key usually needs to be encoded from DER to PEM format for storage purposes, like in databases or files. Also, the specification includes helpful methods such as getAuthenticatorData(), getPublicKey(), and getPublicKeyAlgorithm().

However, while user agents can handle the parsing process, sometimes developers might not be familiar with technical aspects like COSE, DER, and so on. It would be convenient if users could directly obtain the DER public key through a method in AuthenticatorAttestationResponse.

[james-d-elliott]

The storage element is pretty unlikely to be a consideration. We expect the COSE encoded bytes to be stored and returned from storage.

What element of signature validation needs to be done manually by someone using the library that isn't currently done automatically by the library implementation?

My overall point is that these functions appear to be implementations of the WebAuthn API which are expected in the user agent in the yet to be recommended level 3. They also appear solely for convenience to handle specific simplification for implementers to ease their ability to perform all of the necessary checks rather than having to decode COSE data (which we already do internally).

[james-d-elliott]

Also maybe @nicksteele can weigh in on this one if he's not too busy.

[nicksteele]

I agree, additionally these operations could be performed on and returned from the client.