Hacker News Reader

Comment by Jsharm | Hacker News Reader

Wow this is really cool. I just tried the example on the homepage, that's magic! No email, username or password. Can someone explain what is happening?

View on HN

On iOS this seems to use the iCloud Keychain which is slick but how would I then login to sites using Firefox or any computer that doesn’t have access to my keychain? The reason I use a 3rd party manager is precisely this reason.

Sites should likely let you enroll multiple such passkeys from different vendors (add a Microsoft Account passkey from your PC, a Google one from your Chromebook, etc).

Apple already supports Keychain sync with Edge on Windows and I believe that already supports Passkey access.

Also, I believe I heard rumor that "Sign in with Apple" (their existing OpenID Connect account system) will also eventually support helping you enroll non-Apple devices to Passkeys in apps that support both Passkeys and "Sign in with Apple", though I don't know if there is yet a timeframe on that sort of support.

> Sites should likely let you enroll multiple such passkeys from different vendors (add a Microsoft Account passkey from your PC, a Google one from your Chromebook, etc).

This sounds good, except how would it actually work?

I register in on my iPhone, it uses a key kept on that phone/iCloud. I log in via Safari on MacOS and it works because of iCloud sync.

Now I go to login using Edge on Windows. How can the website find out that I'm the same user as the iPhone/Safari user since I can't sync my key, and I can't enroll my MS Hello ID (or whatever Windows uses) on my Mac or iPhone?

There is a cross-device system to sign in, using QR and proximity checks.

Once the user has signed in, a modality check shows that they logged in with another device, while a capability check shows that they _could_ have authenticated with the local device if it had been registered. This may trigger the site to prompt them to register the local device as a second mechanism (or they may just go to the self-service account management tab to do it themselves).

Typically for web authentication the websites rely on the browsers which by default will back into the platform.

But any level of that may take responsibility - for instance, 1Password and Dashlane replace the browser/platform support by default by altering the implementation of the javascript API via their Web Extensions.

There are ramifications to this approach, such as having to fall back to the browser/platform UX to support hardware security keyfobs.

The platforms (and browsers using their API) also support or plan to support a cross-device option, where you should be able authenticate within a desktop browser using your cellphone via QR code and radio proximity checks. The vision is that some websites will see that the location browser _could_ have supported authentication directly, and offer to help the user register it as a second (more convenient) option.

A new private-public key pair is generated, the public key is your user identifier (sort of), and the private key is stored on your device (browser or phone). You're logging in by proving you have the private key for the associated public key. I think the device may also be storing a mapping from key to service or something? Not sure.

Please correct me if I'm wrong on any of this.

From my loose skim, this seems to be more for UX than anything else: no-clicks account creation and no-clicks login, but there's still account creation and login happening, presumably with a key provided by BitWarden. But websites can start removing the login prompt as an entity to be interacted with.

Reply on news.ycombinator.com