Closed Molyna closed 4 months ago
Perhaps this would make sense for metadata that is not yet publicly available to account for potential changes during development, before certification is issued.
Since this is more of an MDS3 domain than conformance tools, I'll ask if this is something they are interested in implementing.
Would at least have them consider not doing a 500 response but 400. There is also consideration if the tool should display the message body of the response as well as only way to know what happened was through inspecting network traffic.
There is also consideration if the tool should display the message body of the response as well
This will be addressed in the next release.
By submitting this issue you are acknowledging that any information regarding this issue will be publicly available.
If you have privacy concerns, please email conformance-tools@fidoalliance.org
FIRST PRE CHECK
What protocol are you implementing?
NOTE: UAF 1.0 certification have been officially sunset. U2F 1.2 only supported version of U2F.
What is your implementation class?
If you are platform authenticator vendor, please email conformance-tools@fidoalliance.org
What is the version of the tool are you using?
1.7.19
What is the OS and the version are you running?
For desktop tools
For UAF mobile tools
Issue description
Hitting submit results with a metadata that has the same AAGUID as a previously verified authenticator results in a 500 error response with a body stating that the AAGUID already exists.
Given WebAuthn states that " The AAGUID MUST be chosen by the manufacturer to be identical across all substantially identical authenticators made by that manufacturer" the expectation would be that the submit would work on the same AAGUID given that
firmwareVersion
andauthenticatorVersion
have been incremented from the currently stored version.