Bug 217945 – [WebAuthn] Determine an AAGUID for the platform authenticators

• Status: RESOLVED
• Resolution: FIXED
• Component: WebCore Misc.

[Frederic Jahn]

Our implementation (and surely some others) to allow-list certain authenticators is based on them being present in the FIDO Metadata Service.
To add Apple Authenticators to the list we would have to hard code a separate code path.
If you would generate a uuid and serve them in your attestation plus adding the Apple Authenticators to
https://mymds2.fidoalliance.org/ would definitely ensure better interoperability and make the life of developers easier.

[Smoley]

Thanks for filing, I'll Cc a few folks here for consideration.

[Radar WebKit Bug Importer]

<rdar://problem/70588322>

[Jiewen Tan]

<rdar://problem/70811618>

[Jiewen Tan]

Created attachment 413150 [details]
Patch

[Brent Fulgham]

Comment on attachment 413150 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=413150&action=review

This looks good to me, but I'd like you to double-check the none-attestation case before we land.

> Source/WebKit/ChangeLog:9
> +        The AAGUID is randomly generated by CCRandomGenerateBytes.

I think we should say:

"Relying parties use the AAGUID to recognize supported authenticators. Using a NULL AAGUID blocks them from recognizing Apple products as valid WebAuthentication targets. We need to assign ourselves a GUID representing Apple authenticators, then publish with our attestation certificate and with the FIDO Alliance."

It would also be good to reference the communication to the FIDO alliance documenting this GUID (not sure if this would be a pull request, or how that works).

> Source/WebKit/UIProcess/WebAuthentication/Cocoa/LocalAuthenticator.mm:373
> +        auto authData = buildAuthData(creationOptions.rp.id, makeCredentialFlags, counter, buildAttestedCredentialData(Vector<uint8_t>(aaguidLength, 0), credentialId, cosePublicKey));

Do we not want to indicate that we are an Apple authenticator for the none-attestation case? From Frederic Jahn's bug report, it sounds like this is needed to decide whether they allow our authenticator at all.

If you aren't sure, can you check with Frederic?

[Jiewen Tan]

Comment on attachment 413150 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=413150&action=review

Thanks Brent for r+ this patch.

>> Source/WebKit/ChangeLog:9
>> +        The AAGUID is randomly generated by CCRandomGenerateBytes.
> 
> I think we should say:
> 
> "Relying parties use the AAGUID to recognize supported authenticators. Using a NULL AAGUID blocks them from recognizing Apple products as valid WebAuthentication targets. We need to assign ourselves a GUID representing Apple authenticators, then publish with our attestation certificate and with the FIDO Alliance."
> 
> It would also be good to reference the communication to the FIDO alliance documenting this GUID (not sure if this would be a pull request, or how that works).

Sure. Fixed.

>> Source/WebKit/UIProcess/WebAuthentication/Cocoa/LocalAuthenticator.mm:373
>> +        auto authData = buildAuthData(creationOptions.rp.id, makeCredentialFlags, counter, buildAttestedCredentialData(Vector<uint8_t>(aaguidLength, 0), credentialId, cosePublicKey));
> 
> Do we not want to indicate that we are an Apple authenticator for the none-attestation case? From Frederic Jahn's bug report, it sounds like this is needed to decide whether they allow our authenticator at all.
> 
> If you aren't sure, can you check with Frederic?

For none attestation, the AAGUID is required to be all zero.

[Jiewen Tan]

Created attachment 413262 [details]
Patch for landing

[EWS]

Committed r269420: <https://trac.webkit.org/changeset/269420>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 413262 [details].