Re: Expected changes in Chrome 127

Thanks Adam,

At least on Mac, if I specify authenticatorAttachment=platform, there are no “Other options” present during the create dialog such that a HSK (or hybrid flow) could be registered in that ceremony. What I actually get is an experience that goes straight to Apple iCloud Keychain if enabled, and if I cancel out of that then I get a fallback to the choice between Chrome profile and Apple iCloud Keychain (both platform options).

The question I have is … if I don’t specify authenticatorAttachment at all, is there a path (and what is it) for the user to register a security key (or the hybrid flow) during that ceremony?

Ideally it would be great if UX-changing experiences like this could be pre-released under a flag (or via some other mechanism such as canary, etc) so that folks in the know can try them out and understand any impact before it hits the general public. If this is already in Canary, or planned to be available in Canary soon, then great - please let us know such that we can go experiment. I tried Canary today (127.0.6524.0) without specifying authenticatorAttachment, and see the same behaviour as I do in GA Chrome (125.0.6422.142), which is the "mechanism selection” UI.



Cheers,
Shane.





On 7 Jun 2024, at 9:58 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-!-XFVHHmzfgJ0fR3VYSWM-8-ydSMatobLN8zYIwNDFmzwWPDS73ilKgCEcBjB28D6NNJGH8LzzeWZvE4LAr7tPsS2OjXXRo-c7uTuti5LApxhbFV8q1DvM_uKGvU$>
Report Suspicious
On Thu, Jun 6, 2024 at 4:34 PM SHANE WEEDEN <sweeden@au1.ibm.com<mailto:sweeden@au1.ibm.com>> wrote:
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?

An undefined authenticatorAttachment will start to act, in this respect, like authenticatorAttachment="platform" does today. Thus, if there's an exclude list provided and the user attempts to create a credential in a platform authenticator, the user experience will be the same as if there was no exclude list, but rather than overwriting the excluded credential, InvalidStateError is silently returned.

So it's not the case that an exclude list will cause an immediate error. The user will do the full ceremony with the platform authenticator and the site learns that the device was already registered. Some sites show a notice when that happens, but some consider it to be fine: the user wanted a credential in that platform authenticator and indeed there is one.


Cheers

AGL