Expose raw Authenticator Data bytes to library users

[ArnaudBrousseau]

The current interface for assertions has two fields returning Authenticator Data: https://github.com/Yubico/libfido2/blob/f1a74c8f2792e269a0c47f156e13e6ddb457b1d3/src/fido/types.h#L201-L202

• fido_authdata_t is parsed authenticator data (not fully: some fields are missing -- but that's not the point of this issue!)
• fido_blob_t is a CBOR-encoded blob. When decoding this blob, I found that it's simply the raw authenticator data bytes wrapped in a CBOR structure. For example, the library returns 58250FEE26D2CB710296BE673B8F4688857064EFFEEBB68A67452649B1BA0A5DCB690100000027. The byte (0x58) is "byte string" (see this), and the second (0x25) is the length (37 in decimal).

Why not return the raw authenticator data bytes? Would you accept a PR adding fido_raw_authdata to simplify the caller's job and avoid a CBOR decoding operation? Other libraries wrapping libfido2 are also waiting for this: https://github.com/keys-pub/go-libfido2/blob/2399f32e9077b2b1f651bb675505c8d6e654b833/fido2.go#L153-L161

[LDVG]

Hi,

fido_authdata_t is parsed authenticator data (not fully: some fields are missing -- but that's not the point of this issue!)

As a side note, the attested credential data and extensions are also parsed by libfido2, just not part of that particular struct. :slightly_smiling_face:

Why not return the raw authenticator data bytes? Would you accept a PR adding fido_raw_authdata to simplify the caller's job and avoid a CBOR decoding operation?

We actually have this for the fido_cred_t type, see fido_cred_authdata_raw_ptr(3). Issue #212 contains some of the rationale at the time. We'd happily accept a PR introducing a similar API for assertions!