Ideal Recommendations

[akshayku]

Different platforms are at different stages of implementing the webauthn and CTAP specs.

There have been issues and solutions suggested for non-resident keys behavior on Windows. Resident keys and ClientPIN is not supported on Android. Etc etc.

However, instead of trying to fit in deployments due to current limitations, we should prepare this document for a long term webauthn standard on how to adopt FIDO for years to come.

• Creating resident keys during create() call for platform authenticators

  • Current document does not recommend creating resident keys for platform authenticators. I believe this should change as I don't see any reason for general webauthn for not creating resident keys.

  • I think I remember one use case for webpayments where non-discoverability was important. But I don't remember the full details.

• Whether or not, exclude list should be provided during create() call

  • If we provide exclude list, there may be UI differences if credential is already present. But, this option makes sure that credential is not overwritten and there are no extra platform authenticator credential ID entries on the server.
  • If we don't provide exclude list, previous created credential gets overwritten. From, users perspective, that experience may be better, but that leaves previously created credential ID list on the server which over time can become huge.

• Whether RPs should depend on local storage to remember credentialIDs.

  • My view is NO. There are two reasons
    • First, if a user creates a credential on external authenticator outside of that particular browser, like another machine, if RP is relying on local credentialID list, user will be not be able to use say that external authenticator.
    • Second, If we follow above recommendation of creating a resident credential with no exclude list, then things will get overwritten if user is coming from different browsers on same machine. In that case, the credentialID which was previously working may not work anymore.

There may be more, we need to have the discussion around it.

[christiaanbrand]

Creating resident keys during create() call for platform authenticators

Agreed with this.

Whether or not, exclude list should be provided during create() call

Yes, we should think about this. Probably makes sense to have this as you suggest.

Whether RPs should depend on local storage to remember credentialIDs.

I don't know about this. This is the exact way that RPs are used to doing things in native apps (where biometrics are strictly used for reauth). If a credential is only for reauth, I think it makes sense to use local storage to know whether it's there (it creates the cleanest experience). Yes, if the user is in "another browser" they'll need to "opt in again" (and ideally the credential shouldn't get overwritten as sbweeden and I have discussed before), but this seems like an edge case.
Having a user select from a list of accounts during re-auth sounds like subpar UX.

[balfanz]

Hi @akshayku - a couple of thoughts:

• I would like this doc to be an easy-to-use "recipe book" that can be used against current implementations. That's one of the reasons the use case that needs Level 2 features is pushed into an Appendix for now. If and when Level 2 is prevalent, and support for resident keys is everywhere, etc., then we can amend the doc.

• In terms of proposing changes to the doc, like using the exclude-list, using local storage, etc., I would like us to use this framework:

  • Is the use case you're interested in (e.g., 2FA with a password and a fob, or passwordless sign-in with a UVRA, etc.) covered in the doc? If not, propose that it be added to the doc.
  • If it's already covered, does the "recipe" listed in the doc (i.e., how to call the API, what UI to show) lead to the user experience that you think the doc should recommend? If not, propose that the doc recommend a different user experience.
  • If the user experience is what you're looking for, then does the way the doc recommends calling the API actually give us that user experience? If not, point out the problem. Maybe the doc needs to change how it recommends calling the API, or maybe we actually need to change the spec for the desired UX can be achieved.
  • If the particular way the doc recommends calling the API does already give us the UX we want, then there's no need to change the doc.

  Does that make sense?

• Finally, I realize there are some edge cases that are currently not well supported by the recipes listed in the doc, like Opting into FIDO-based Reauthentication in one browser, and then switching to another browser on the same device and expecting that the FIDO credential that was created inside the platform authenticator be usable from there. I believe @sbweeden has tried using the exclude list to address that problem, but ran into issues. (I don't remember the details now.) To the best of my knowledge, those edge cases can't be addressed well with the current webauthn implementations, so I kept the recommendation in the doc to not use the exclude list for FIDO-based Reauthentication. (Of course the exclude-list is used for other use cases.)

[sbweeden]

The problem with using the excludeCredentials list during UVPA registration is that the user agent cannot locally detect ahead of time whether or not the platform authenticator already has a credential for this userid/rpid combination (such as one created by another user agent on the same platform). If a credential already exists, the user experience is poor (an error). To deliver a great user experience you are therefore forced to not use the excludeCredentials list.

After that an RP then has to deal with the subsequent nuances of different platform authenticator behaviour that happens when setting rk=false during credential creation. Currently Microsoft (and more recently Apple) have one set of behaviours, and Google (Chrome on Mac and Android) have a different set of behaviours. These differences break the consistency of the pattern.

[akshayku]

Hi @balfanz

I would like this doc to be an easy-to-use "recipe book" that can be used against current implementations. That's one of the reasons the use case that needs Level 2 features is pushed into an Appendix for now. If and when Level 2 is prevalent, and support for resident keys is everywhere, etc., then we can amend the doc.

Resident keys is in Level 1 and not a Level 2 thing. I was expecting that we are developing the document with future in mind and how things will play once we have compatibility in terms of implementation so that RP only have to follow one guide.

If we want this document to be used against current implementations, there cannot be a single recommendation as no single recommendation fully works across all the platforms.

I am OK splitting the document into platform specific recommendations we you are thinking very short term.

In terms of proposing changes to the doc, like using the exclude-list, using local storage, etc., I would like us to use this framework:

I am OK proposing the changes. On Windows, I don't want to recommend non-resident keys behavior as moving them in the future to usernameless flows is not easy. Problem is asking RPs to redevelop the solution in say 6 months when you support resident keys. Many RPs are not that fast.

As noted above, my version of single recommendation will not work on Android and I don't see a way around that problem apart from platform specific recommendations.

I am OK making the PRs with the changes. Let me know.

[christiaanbrand]

Akshay, can you help by spelling out the user journey for RPs who want to use platform based resident credentials on Windows today? Since the credentials will only remain "on device" I'm not sure there's much value beyond the re-authentication use case right now. Once you're logged in and create the credentials, the RP doesn't need FIDO to do usernameless. The user is already logged in. They can just store the username in a cookie. Google accounts work this way today. Once you "sign out" you still see a list of all your previously signed in accounts and can sign back in instantly, without needing to enter a username. None of this needs FIDO, right? And it works on all platforms.

[akshayku]

My vision is to have cross-browser usernameless, passwordless logins. Reauth as well as bootstrapping using platform credentials.

Here is the flow for first time login on browser 1

• User opens up the page to login to the RP
• User logins the first time.
  • Typically with username and password.
  • However, it can also be external security keys - UVRA as you call it.
    • By clicking on "Login with FIDO" link or similar. More on this below.
• RP calls IUVPAA, which returns true.
• RP promotes and creates the platform credential.
  • Want to create a resident key so that I can achieve usernameless flows across all the browsers on this machine at later stage.
• There is no need to remember credentialIDs
  • If we are using with username flows, you can always get credential IDs from the server.
  • If user deletes a credential from the server, going back to the server always gives you a fresh credential ID list
  • If user adds an external security key from someplace else, that credential ID also will be in the list and user can use that external devices, if it wishes to.
• Remember a bit flag if RP wishes to remember whether this platform has been upgraded.

Subsequent Logins on different browser

• Same as if cookies gets removed from browser 1. (I do it all the time)
• User opens up the page to login to the RP.
  • There are no cookies now in the browser and RP does not know if a credential exists.
• RP has a link to login with FIDO text.
  • RP typically provides such link for external security keys - UVRA.
  • But that does not mean that user SHOULD NOT be able to use platform authenticator if it chooses to.
    • And this is one of the reasons I want to create a discoverable/resident key.
    • RP sometimes believe that user will be confused if no such credential is found. But having the ability to login with any browser is a cool scenario for me as a user.
  • RP can be platform specific here or be generic.
    • Like "Login with Windows Hello or security keys"
    • Or "Login with Touch ID or FaceID or Security Keys"
    • Or "Login with FIDO"
• User clicks on that link and as platform authenticator has already been configured via previous steps, user can login.

Challenges vs benefits

• I know that UI challenges when you try to first time login into a RP with no cookies. If credential is already there, things work well. But if credential is not present, user cannot login. We plan to guide show the benefits and ask user to login.
  • Above UI drawback is evaluated by the user's ability to use the same credential in a usernameless way across browsers. That is a compelling case for me.
• I call Bootstrapping as first time login and I think platform authenticators also has a place for this.

[christiaanbrand]

So, if I understand correctly, you're addressing two shortcomings of the current proposal (which boils down to the same technical issue: no cookie present).

• The first one is a user that wants to move between browsers (I think this is more of an edge case, but okay).
• The second one is a user that deleted cookies.

What you're proposing makes sense, but I still have a hard time recommending this as a solution as the user will inevitably move to another machine at some point, and they won't be able to log in there at all (unless they had a backup mechanism to get into their account, which they could have used also in the case where the cookies weren't present).

Therefore, unless the user also has a security key (with resident credentials) or another form of x-platform credential (maybe using PaaSK/caBLE) I don't think we should be recommending this use case today as RPs are likely to just completely shoot themselves in the foot.

Does this make sense?

[akshayku]

Yes. Kind of.

The problem is once we create a platform credential as non-resident/non-discoverable, we cannot change that at later stage when we want to have a usernameless flows.

RPs will eventually want to go for usernameless passwordless scenarios for external security keys. More so for using phone as external authenticator via caBLE. So if I want to use phone for usernameless cross platform scenarios eventually, you should think about creating those credentials as discoverable.

[sbweeden]

So, if I understand correctly, you're addressing two shortcomings of the current proposal (which boils down to the same technical issue: no cookie present).

• The first one is a user that wants to move between browsers (I think this is more of an edge case, but okay).

Hey @christiaanbrand what about the use case of a browser based app and a native mobile app from the same RP on the same device that want to share a single credential registration. Do you think that is also an edge case?

[christiaanbrand]

Good point. I'm happy to say that RPs should probably create platform keys as "discoverable" for forward-compatibility (even though it won't make much of a difference today). Will someone kick off a PR for that?

[Kieun]

@sbweeden As far as remember, Android has been supporting sharing credentials between the web app and native app (which is associated to the same rpId) by leveraging the digital asset link.
My thoughts about usernameless (without any ambient credential) flow is still the same. It's better for us to provide authentication flow without any user identification first from usability perspective.

[maxhata]

Concerning the use case of same device/different clients , I am
wondering how such a use case like the following be handled based on the
reauthentication-cookie model.

Use Case:

A user has bootstrapped login for RP1 and RP2 on a browser based on the
reauthentication model using the UVPA on the device (thereby cookies are
stored in the browser). The user has logged in to RP1 first using FIDO
and by clicking a button in the RP1's site, the user is directed to the
RP2 application on the same device that runs a web component of the
browser (e.g., Chrome --> Android System WebView). The user needs to
login to RP2 from the application.

Question:

I am wondering how the reauthentication model works for such a web
component from the application.

Will the cookies stored in Chrome be shared with Android System WebView
so that the reauthentication model will work for FIDO ? Or will the user
need to use an already-registered-to-RP2 security key to bootstrap
signing in for the application? Or, will the the digital asset link
solve the problem?

At any rate, this is one of the main use cases for mobile service
deployments and many RPs want to know how to do it.

[Kieun]

One thing I want to mention about platform authenticator is that the credentials should be discoverable to all browsers (webview or others) supporting Webauthn on the same machine.
Thus, such credential can be used from cross-browsers or cross-browser modes whether the credential is discoverable or not. Some platforms are supporting this and some are not.

If FIDO community's ultimate goal is to go username-less flow and platforms eventually support PaaK, we should create resident key for platform authenticator from now. If not, RP will suffer hard time to provide great UX for the transition.
And this will solve such edge cases like cross-browsers or cross-browser modes.