-
-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support for "apple" attestation format #184
Comments
I was planning on adding it, but I was waiting for documentation which I thought was going to arrive a month ago. At a glance, it looks really, really simple, like easier than either of the Android formats. |
I'm wondering if it'd be over engineering to make attestation formats pluggable? If other formats do appear in future it'd be possible to package them up as separate nuget packages and easily add them to existing applications without waiting for a core library release. Format implementations could then also benefit from from dependency injection too and do smart stuff like fetch remote certificates, use caching services etc. It would also allow people to provide their own "null" implementation to unblock themselves temporarily. I'm keen to have support ready to go for when iOS 14 is released so happy to help out. |
@mackie1001 I think that's a good idea. |
@abergs I've got a long rainy weekend coming up so I'll look to have a PR raised within the next few days. I'll keep an eye on the Apple documentation and this issue: w3c/webauthn#1453 for any movement regarding how to actually implement the verification too. If it is anything like DeviceCheck/AppAttest then it looks simple like @aseigler says. |
I've been working on a refactor of the attestation verification code to make it much more closely match the WebAuthn spec, which should make this effort considerably simpler as well. |
@aseigler what is the scope of those refactorings? Are they internal to each AttestationFormat or are you making structural changes? If the latter it may be worth me branching from that refactoring branch. |
It's definitely structural, making each format verifier return an attestation type and trust path, and then handling chain validation against metadata/policy one way instead of separately per format. Hopefully that makes sense...I will get the refactor branch up soon. |
You guys are some Sherlocks *) |
@kennep @mackie1001 and @aseigler really are Sherlocks. I mean, the TPM pr they got running hurts my head... |
Format came out last night: https://pr-preview.s3.amazonaws.com/alanwaketan/webauthn/pull/1491.html#sctn-apple-anonymous-attestation Initial implementation here: 0d6410c Borrowed initial test data from webauthn4j/webauthn4j@9a7260b#diff-b16de03d04ad98253ba2011fc88e755f |
Recent blog on that part *) https://medium.com/webauthnworks/webauthn-fido2-verifying-apple-anonymous-attestation-5eaff334c849 |
This is in for V2.0 |
I notice that iOS 14 beta and beta versions of macOS use the "apple" attestation format, which does not seem to be documented anywhere.
There are some speculation on how this format would look like here:
https://github.com/sbweeden/fido2viewer/blob/master/fidotools.js#L2349
... which links to
https://developer.apple.com/documentation/devicecheck/validating_apps_that_connect_to_your_server
.. which mentions this page with root certificates
https://www.apple.com/certificateauthority/private/
... one of which is https://www.apple.com/certificateauthority/Apple_WebAuthn_Root_CA.pem
Is provisional support for the "apple" attestation format something you would be interested in having in the library, and would you welcome a PR on it? Or would you rather wait until it is officially documented?
The text was updated successfully, but these errors were encountered: