Cannot unmarshal fido2 metadata blob

[rackward]

Version

0.13.3

Description

When attempting to unmarshal the fido2 metadata blob into metadata.PayloadJSON I receive this error:

json: cannot unmarshal number 34359738368 into Go struct field PatternAccuracyDescriptor.PayloadJSON.entries.metadataStatement.userVerificationDetails.paDesc.minComplexity of type uint32

The docs clearly describe that this should be an unsigned long. However, given that the payload will not unmarshal because of this, it might be that the documentation is incorrect in this case.

Reproduction

1. Download the fido2 metadata blob
2. baes64 decode the object
3. attempt to unmarshal claims into metadata.PayloadJSON object

Expectations

No response

Documentation

pattern accuracy descriptor docs: https://fidoalliance.org/specs/mds/fido-metadata-statement-v3.0-ps-20210518.html#patternaccuracydescriptor-dictionary

unsigned long definition: https://webidl.spec.whatwg.org/#idl-unsigned-long

blob available at: https://mds3.fidoalliance.org/

[james-d-elliott]

As per the IDL (linked in MDS3.0) an unsigned long is a 32 bit unsigned integer, a 64 bit unsigned integer is an unsigned long long. This makes the uint32 the correct type for this data structure.

https://webidl.spec.whatwg.org/#idl-unsigned-long

The unsigned long type corresponds to 32-bit unsigned integers.

A 32-bit unsigned integer is an integer in the range 0 to 4294967295 (0 to 232 − 1), inclusive.

https://webidl.spec.whatwg.org/#idl-unsigned-long-long

The unsigned long long type corresponds to 64-bit unsigned integers.

A 64-bit unsigned integer is an integer in the range 0 to 18446744073709551615 (0 to 264 − 1), inclusive.

[james-d-elliott]

The docs clearly describe that this should be an unsigned long. However, given that the payload will not unmarshal because of this, it might be that the documentation is incorrect in this case.

I evidently misread this. Every other org that's submitted it abides by the data type requirements. The existence of a single malformed statement in the blob is not evidence of anything really other than the third party (i.e. org that isn't the FIDO Alliance) who created the statement didn't follow either the 2.0, 3.0, or 3.1 specs.

This either needs to be addressed:

1. By the org (i.e. third party) who submitted the statement (which the MDS team can help coordinate).
2. By the FIDO Alliance who need to release a spec minor revision which addresses this which would be a feature release on our end.

It should also be noted we provide tooling on our end to ignore invalid statements.

[rackward]

Yes I am submitting an issue to FIDO to attempt to fix it from their end 🙏 Thanks for the info on ignoring invalid statements.