Re: Expected changes in Chrome 127

I see some challenges with this part:

Also, an exclude-list match for a platform authenticator will return InvalidStateError when authenticatorAttachment is undefined, as it currently does when set to "platform".


Today, we have a user self-care registration experience that has a generic “Add a passkey” capability. This results in a create ceremony with no authenticatorAttachment defined. It allows a user to register either a platform or roaming authenticator. If the user already has a platform authenticator registered, they can still add a new roaming authenticator using this method, even when the excludeCredentials list provided.  If I’m reading your message correctly, that will no longer be the case - the API will error out immediately. We would either have to:
 - remove the excludeCredentials list in our call to create
 - have a separate button for “Add a hardware security key” or similar, which results in create being called with authenticatorAttachment set to cross-platform
 - Catch the InvalidStateError, guess that it’s because of this reason, then re-invoke create with authenticatorAttachment set to cross-platform

Again, if I’m interpreting this correctly, it will have a negative impact on our current deployment.

Why can’t Chrome, when no authenticatorAttachment is supplied, upon seeing an excludeCredentials list which matches the platform authenticator, fallback to the scenario where it will prompt as if cross-platform was supplied for authenticatorAttachment?


Thanks,
Shane.











On 7 Jun 2024, at 9:02 AM, Adam Langley <agl@google.com> wrote:

This Message Is From an External Sender
This message came from outside your organization.
<https://us-phishalarm-ewt.proofpoint.com/EWT/v1/AdhS1Rd-!-XFVHHmzfgJ0fRx5B8prfJJZGB4tLoPuKfWhmJtqF7xK6T5AYs80r8pDieeNoprixOCj8egM-YTr71GRm12_AdcLSmFqNfPppmr4Pyg0-tiH_Ry9M_2pJjhUOBU$>
Report Suspicious
Dear all,

For create() requests where the authenticatorAttachment<https://w3c.github.io/webauthn/#dom-authenticatorselectioncriteria-authenticatorattachment> is undefined, Chrome has traditionally shown its "mechanism selection" UI. Several sites have said that this is confusing for users and that it's pushing them to always set "platform" attachment, even when a cross-platform authenticator would be acceptable.

Thus, in Chrome 127, we expect the UI in this case to default to a platform authenticator (where available), just as setting "platform" does. Cross-platform authenticators will still be available if the user wishes.

Also, an exclude-list match for a platform authenticator will return InvalidStateError when authenticatorAttachment is undefined, as it currently does when set to "platform".


Secondly, if Chrome is signed into a Google account that also has an Android phone on it, and a passkey has been created in Google Password Manager (GPM) on that Android phone, Chrome 127 may no longer require the user to use their phone in order to create and exercise GPM passkeys.


(This information is provided to highlight planned future changes but does not represent a commitment to ship these behaviours in the specified timeline, or at all.)


Cheers

AGL