feat: Android Key attestation format support #126
Conversation
bdewater
force-pushed
the
android-key-attestation
branch
2 times, most recently
from
f0ca8aa
to
8595746
Compare
| credential_creation_options: { | ||
| challenge: 'v2h1c2VybmFtZXQ0aV9ObTRobjFDeEkwSGc3OHhzTWljaGFsbGVuZ2VQtubEDC4OSpGHebHLLNerFf8' | ||
| }, | ||
| authenticator_attestation_response: { |
There was a problem hiding this comment.
Generated by https://fidoalliance.org/certification/functional-certification/conformance/ and these certificates have a expiry set in the far future.
|
Might want to hold off until #127 is merged so I can add a AAGUID test here too. |
|
Awesome! Thank you! I'll try code review sometime this week. |
bdewater
force-pushed
the
android-key-attestation
branch
from
8595746
to
35a78ca
Compare
|
I added an AAGUID test here but the tests broke because |
|
Yeah, |
bdewater
force-pushed
the
android-key-attestation
branch
from
35a78ca
to
c92468a
Compare
| valid_attestation_challenge?(client_data_hash) && | ||
| all_applications_field_not_present? && | ||
| valid_authorization_list_origin? && | ||
| valid_authorization_list_purpose? && |
There was a problem hiding this comment.
I wonder if we could create an abstraction for what's called in the spec "attestation certificate extension data", and call valid? on that, moving these 3 from the above inside there, to divide a bit the complexity into separate objects.
There was a problem hiding this comment.
Not blocking the merge because of this one.
If we like the idea we can do it as a follow up PR.
|
Released in |
This implements https://www.w3.org/TR/webauthn/#android-key-attestation and fixes #84
Since the certificates in the payload do not contain a root certificate, we'll need to implement the metadata service to assess trustworthiness of the attestation. See #66 for tracking this feature.