Unwanted Browser Dependencies

[cyberphone]

Bear with me, I have limited insights in how FIDO and Browsers cooperate with the exception of the WebAuthn API.

Anyway, based on public information and practical tests, it appears hard/impossible avoiding separate enrollments for each browser. This will most certainly affect the interest using "alternative" browsers.

In case Google's SPC pans out, this problem gets worse.

Some kind of workaround seems to be required.

---

In an alternative to SPC, FIDO Web Pay (FWP), the intent is that the "wallet" eventually becomes a part of the client platform rather than the browser. This arrangement offers some benefits including:

• Making it easier for alternative browser vendors adopting the FWP system since they would not have to build a copy of FWP themselves; a thin wrapper would suffice.
• Relieving users from having to enroll payment credentials for each browser they want to use.
• Limiting the number of systems to certify in the case certification becomes a requirement.
• Opens the door to usage by native applications which may be needed for enabling reuse of payment credentials at Point-of-Sale (PoS) terminals.

@dveditz @jcjones

[MasterKale]

...it appears hard/impossible avoiding separate enrollments for each browser.

What has been an experience with WebAuthn that has left you with this impression?

In my experience it's true that Touch ID on macOS must be registered per browser in lieu of an OS-level broker like Windows Hello. However security keys can be used cross-browser with just a single registration no problem. And on Windows, the Hello platform authenticator offers cross-browser authentication after just a single registration.

[cyberphone]

Hi @MasterKale, I may surely lack some understanding but the OS-level broker in Windows, leaves a lot to be desired since it doesn't know which keys are active or not. #1612 A persistent cookie solved this particular problem but of course created another, browser-specific credentials.

For SPC which may need additional meta-data (the spec is currently up in the air), it will be interesting to see how the cross-browser issue is dealt with.

[agl]

There are two issues here that lead to problems.

On macOS, Safari and Chrome have different credential stores. This will hopefully be fixed in time when Chrome is able to integrate with the macOS system platform authenticator. This is not a problem on Windows, Chrome OS, Android, nor iOS. There are unified credential stores on those platforms.

Second, in cases where the platform only creates discoverable credentials (Windows is such a platform) then creating a credential can cause unintended credential overwrites since there can only be a single credential with a given (RP ID, user ID) pair. This can be addressed on Windows today by following the practices from “Preventing unintended credential overwrites” in #1637. It's not a cross-platform solution but, if the WG agrees that it's a good one, I hope that all platforms will align on it.

[dwaite]

Hi @MasterKale, I may surely lack some understanding but the OS-level broker in Windows, leaves a lot to be desired since it doesn't know which keys are active or not. #1612 A persistent cookie solved this particular problem but of course created another, browser-specific credentials.

This is an issue with discoverable credentials, and mostly when a demo creates multiple credentials with different user handles. An authenticator is expected to only store one discoverable credential per (user handle, RP) tuple - registration of a new credential should delete the old one. Some authenticators only support one discoverable credential per RPID period, replacing any old credential on new creation. This would effectively auto-clean up a demo with the user handle issue.

There may be additional implementation issues at play as well, e.g. windows hello might create discoverable credentials when non-discoverable credentials were requested. I believe this was a UX issue previously, and do not know if behavior has been enhanced or if there is a timeline.

For SPC which may need additional meta-data (the spec is currently up in the air), it will be interesting to see how the cross-browser issue is dealt with.

SPC is using non-discoverable credentials last I checked, so there should not be any sort of user key management at the browser/platform level (barring the previous point of implementations choosing to create discoverable credentials)

[akshayku]

Based on above comments and #1637 proposals, this issue is somewhat addressed. Closing it.