Should there be a fido_cred_authdata_raw_ptr?

[JackOfMostTrades]

I've been working on a project that creates credentials with libfido2 and sends the result to a Java service that will verify the credential attestation. I was getting stuck for a little while before I found the clarifying docs. I gather there is a good reason for this being CBOR-encoded, but it feels inconsistent since other raw bytearray values from the attestation statement (like the sig and x5c values) get fully decoded and aren't returned as CBOR-wrapped bytearrays.

Since any external code is likely to want expect and parse the raw authenticator data structure, would it make sense to expose a "raw" getter (similar to the "raw" setter added in #62)?

[JackOfMostTrades]

Updating to mention that it's especially valuable to have the raw authenticator data structure since, besides wanting to parse the structure, it's the raw authenticator data that's part of the hash for verification. Basically I can't imagine any case where someone would want "fido_cred_authdata_ptr" rather than the raw value.

[martelletto]

Sure, makes sense to me. I will look into it tomorrow, as it is a bit late here.

If I recall correctly, the rationale behind fido_cred_authdata_ptr() returning a CBOR-encoded byte string (in juxtaposition to related functions returning decoded values) was that the caller was likely interested in parsing the structure as it was received from the authenticator, and thus had access to a CBOR library.

That does not detract from the need of a fido_cred_authdata_raw_ptr(), particularly when a corresponding fido_cred_set_authdata_raw() already exists.

[martelletto]

Implemented in 01dc0d7; thanks!

[JackOfMostTrades]

Awesome stuff. Thanks for incorporating and for the quick turnaround!