webauthn
webauthn copied to clipboard
w3c
Specify authenticator attachment for authentication operation
Let say RP decides to only support platform authenticator with RK.
If RP provides authentications based on the username/password-less, the authentication option includes allowCredentials as an empty list.
Then, with such options the client may check available authenticator first. If there is no credential bound to the calling RP, it will begin to search external authenticators which introduce some UIs.
RP who only cares platform authenticator would like to get an error right away if there is no registered credential on platform so that it tries to provide fallback authentication to users.
For doing so, RP needs a way to specify the authenticator attachment by specifying "platform authenticator" during get operation.
IIUC, the "If there is no credential bound to the calling RP, it will begin to search external authenticators which introduce some UIs" situation will only occur if there are no "ambient credentials" (such as cookies) identifying the user for the RP thus causing the RP to send the empty allowlist on the get() call.
otherwise (ambient creds present), the RP knows which user, and (hopefully) knows which credentialID(s) it has for that user that is/are associated with a platform authnr(s) and sends them in the allowCredentials list.
the latter case is the most common case AFAIK (?). If so, then it is not clear (to me) that we need to alter the PublicKeyCredentialRequestOptions to include an explicit notion of "use the platform authnr if available even though we are not passing in an allowCredentials list".
@equalsJeffH I think that you are right. The get call with empty allow credential is not common, but as a RP, we need to provide the concrete UXs for such cases. There are following cases where we cannot get any local information. There might be more.
- Cross browser: User registered credential with one browser and uses it with other browsers
- Cross device: User registered credential with one device and tries to authenticate with other devices
- Cross platform (Web and Native): Users registered credential with a browser and tries to use it with native application (associated) and vice versa
- Cross browser mode (normal vs incognito): Users registered credential with a browser in a normal mode and tries to use it with same browser in a incognito mode
I read that as a request for a "hint" to the browser that the user shouldn't be confused by "connect roaming authenticators now". @Kieun: Is this what your underlying use case is?
@rlin1 Yes, exactly. Since the lack of discovery mechanism for registered credential, RP is hard to handle such error cases without user intervention. So, RP would like to get the error "NotAllowedError" without any UI on the client side.
discussion on 2019-08-07 call:
-
@agl argues that restricting the user to registering platform authnrs is not wise in that platform authnrs intended use case is essentially local re-authn, not initial sign-in when there is no ambient cred(s) present.
-
@akshayku notes that an RP is able to do platform authnr-only, given how this all works....
-
@agl notes that perhaps we give users the ability to override the RPs desires and let them register roaming/external authnr in any case
-
@akshayku notes that msft allows users to register either platform or external (?)
-
@ve7jtb notes that the restrict-to-platform-RK use case is not very user-friendly and users ought to be provided more fallback opportunities eg using a roaming authnr instead
today's bottom line: we need to learn more as go along here and revisit this down the road....
This is not about the restriction to only allow the platform authenticator. If the RP is willing to support both platform and external, RP can explicitly support both by providing buttons like "Use this device" and "Use your external device" buttons. If the user selects the "use this device", then RP explicitly set "platform authenticator" as an attachment.
It doesn't make sense the reason we shouldn't do this because of the ecosystem. RP does have a way to specify authenticator attachment during registration. But, for authentication, RP cannot freely set the attachment? I think this is very weird.
What Kieun is asking is a real requirement for many RPs.
Millions of WebAuthn/FIDO consumers start their journey from mobile phones first. They are very familiar with mobile phones and they use them everyday. Unfortunately, most of those millions of consumers have no knowledge about external authenticators today. So if they see "external authenticator ....." in the dialogue, it simply confuses them a lot.
For RPs who need to support such millions of consumers by rolling out successful services, we want to provide good UX. The experience with unknown message for the consumers is a bad UX. Many consumer facing RPs will go for mobile only first and they will expand the support coverage to include external ones as the market gets mature. This is the reality. Until them those RPs wish to control what Kieun requests. This feature will accelerate WebAuthn/FIDO adoption.
While I applaud the efforts of Relying Parties'/Service Providers' desire to make the user experience as easy and pleasant as possible when using FIDO2/WebAuthn, IMHO, the technology industry is failing the larger ecosystem by continuing to indulge in users' ignorance.
The vast majority of information secucrity problems are NOT because of a dearth of solutions, but that the technology industry refuses to invest in educating the ecosystem (and that universities graduate computer science students without requiring them to take even a single course on security - but, that's another story). The combined net worth of all the companies in the FIDO Alliance and the W3C would probably exceed multiple trillions. Yet, how much is really needed to create the right level of content to educate users about FIDO2 to get them to understand keys stored on their platform device vs. keys stored on an external device, and how to differentiate between the two?
Humans have risen to the occasion to defy gravity and send other humans into space and bring them back; to drive automobiles, fly airplanes and pilot ships and to adapt to ATMs, electricity, telephones, typewriters, radios and the internet. What makes FIDO2 so complex that they cannot be educated to understand the difference between platform resident keys and roaming keys on external authenticators? What are we really solving by saving a few millions (among the trillions) in the education of an ecosystem to understand this and adapt to it?
I would encourage RPs to stop wasting their money and time dumbing down users, and actually make the effort to enlighten them with knowledge that not only enables them to simplify their lives, but actually protects them. It might seem insurmountable currently, but in the context of what humans have achieved in the past, this isn't even a blip in human adaptability.
Perhaps the conversation should be about what are the most effective ways to educate users about how to work with FIDO2?
Let me explain our situation. We, LINE have hundreds of million users and basically they are mobile phone based users. Of course, We want to protect our users by providing strong authentication by introducing FIDO2/WebAuthn. So, in order to accelerate the adoption, we would like to make the user journey as easy as possible. Our strategy is that leveraging platform authenticators is first and then allow our users to use external authenticators as well. But, we don't want to sacrifice the majority of users' journey because of the comparably small numbers of users having and enabling external authenticators (or even not supporting at the beginning).
Ki-Eun,
Your situation is not unlike that of most RPs - they ALL have a small number of users who are the outliers to the standard use-case they want to solve in the most perfect manner possible. But, if every RP takes this approach, there is a non-zero probability that the FIDO ecosystem will miss solving the problem for a significant number of "minority group" users; this is what causes new and promising technologies to fail in the market. As a technology professional who has been striving for 20 years to make public-key based strong-authentication simpler for end-users , that is unacceptable.
With all due respect to the hard work of all the people and companies in the FIDO ecosystem who are trying to make FIDO2-based authentication ubiquitous, I would encourage all of us to solve the simpler problem - educate the ecosystem and depend on their knowledge and judgement to make the right decisions. For any RP to make such broad assumptions about what is perfect for their user-community is an evolving illusion that can only lead to failure. Better to do what is right once and for all, educate EVERYBODY and let them exercise their judgement at each RP site with some standardized messages. That problem, IMO, is far simpler to address with our collective efforts than to customize every RP website for whatever the RP believes their users want to see.
@arshadnoor do you think I was asking customizing the spec for our own use cases? We are willing to support universal authentications if there is and we are going to try to make that one. This is just real problems for RPs having mobile based users. We cannot say to our users to buy external authenticators and we cannot explain what FIDO2/WebAuthn is in a very limited small screen. If they have external ones, they can use it. And, we are going to support them.
And, this issue is basically raised because of the adoption challenges and the technical soundness. Current spec does have a way for RP to set authenticator attachment during registration but there is not for authentication. Still, RP can allow platform only, external authenticators only or both. If we are saying about the ecosystem and disallow such RPs' specific approaches (In fact, I don't agree), we should not provide such option for registration as well.
To be clear you can send the transport as part of the allow list if you have some sort of identifier first flow.
In the case where you don't have any idea who the user is and do a get without an allow list, there is no transport hint that is true.
But in this case it is better for the platform and the users own preferences to sort it out. Most platforms prefer the platform authenticator.
We have made that a bit harder with cred protect in the case where there is no allow list the platform can't silently check to see if it has credentials without prompting for UV unless the credential is created at credprotect level 1 allowing the platform to check without UV first. This is the current default behavior.
In most cases the platform only prioritises external authenticators if no local credentials are located.
Also consider the case of a platform credential on Android that works as a roaming credential on desktop chrome on ChromeOS. Chrome OS has no platform authenticator (ignore the built-in U2F one on pixelbooks) it can discover and use the platform one on the users phone.
The environment on the device for selecting credentials is best left for the platforms to optimise and inovate on.
Giving RP flags that try and controll the platform when the RP doesn't know who the user is or what credentials they have seems to be a bad idea at this point.
It is better to work with the platforms to get a good experience that works for the user, and not to try and override the platform that has lots more information about authenticators and user credentials.
John B.
On Fri, Aug 9, 2019, 4:37 PM Arshad Noor [email protected] wrote:
Ki-Eun,
Your situation is not unlike that of most RPs - they ALL have a small number of users who are the outliers to the standard use-case they want to solve in the most perfect manner possible. But, if every RP takes this approach, there is a non-zero probability that the FIDO ecosystem will miss solving the problem for a significant number of "minority group" users; this is what causes new and promising technologies to fail in the market. As a technology professional who has been striving for 20 years to make public-key based strong-authentication simpler for end-users , that is unacceptable.
With all due respect to the hard work of all the people and companies in the FIDO ecosystem who are trying to make FIDO2-based authentication ubiquitous, I would encourage all of us to solve the simpler problem - educate the ecosystem and depend on their knowledge and judgement to make the right decisions. For any RP to make such broad assumptions about what is perfect for their user-community is an evolving illusion that can only lead to failure. Better to do what is right once and for all, educate EVERYBODY and let them exercise their judgement at each RP site with some standardized messages. That problem, IMO, is far simpler to address with our collective efforts than to customize every RP website for whatever the RP believes their users want to see.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/webauthn/issues/1267?email_source=notifications&email_token=AAAPQJ7OJCL7FCGCSRL5GT3QDXISBA5CNFSM4IIDYLYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD37WYHA#issuecomment-520055836, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAPQJYIJHRWXH4JOAWEPHTQDXISBANCNFSM4IIDYLYA .
Again there is a way to provide the transports for a given authenticator.
In WebAuthn level 2 there is a API way to get the transport of a given credential even if you are not getting a attestation.
There are good reasons for getting attestations bit that is another discussion.
Given the only mobile OS with a platform authenticator is Android and that is still a bit broken for Resident credentials you can't be doing a get credential without an allow list, so can send the transport for the credentialID.
So what is it that you think you don't like or won't work?
Let's talk specifically about Android. Is it the browser UI or calling the WebAuthn API from an app that is your issue?
I think your goal is probably to have the platform authenticator that is in GMS work well for you.
We should focus on that rater than jumping to the conclusion that an extra RP parameter is the best option.
John B.
On Fri, Aug 9, 2019, 4:53 PM Ki-Eun Shin [email protected] wrote:
@arshadnoor https://github.com/arshadnoor do you think I was asking customizing the spec for our own use cases? We are willing to support universal authentications if there is and we are going to try to make that one. This is just real problems for RPs having mobile based users. We cannot say to our users to buy external authenticators and we cannot explain what FIDO2/WebAuthn is in a very limited small screen. If they have external ones, they can use it. And, we are going to support them.
And, this issue is basically raised because of the adoption challenges and the technical soundness. Current spec does have a way for RP to set authenticator attachment during registration but there is not for authentication. Still, RP can allow platform only, external authenticators only or both. If we are saying about the ecosystem and disallow such RPs' specific approaches (In fact, I don't agree), we should not provide such option for registration as well.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/webauthn/issues/1267?email_source=notifications&email_token=AAAPQJY5HIVFZ4JQPLIHCQLQDXKL3A5CNFSM4IIDYLYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD37XYHQ#issuecomment-520059934, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAPQJ2HN5YZ7TE37JU2LVDQDXKL3ANCNFSM4IIDYLYA .
John, Thanks for pointing out. I basically agree with your suggestion. If the platform can handle the cases better, we should rely on it. I hope that our users do not confuse the unknown message.
Regarding the specific cases, we are considering mobile web and native app for Android. Still, Android does not support RK. But, we expect that the RK is eventually supported. Then, as I mentioned before (cross browser and cross browser and native), the cases where we haven't any credential info will happen. Maybe, if there is no credential on the platform, the Android will prompt for external authenticator?
It will give users the option of a external authenticator if you send credentials that have transports like NFC or USB.
I think it is better for you to use the API to get the transports for the credentials and then work with Google and others to optimise how the UX is presented.
The new webAuthn API can be used with get credential as well for credentials you don't have transports for.
Yes I have confidence that some of the remaining issues with resident credentials ( otherwise known as credentials that work without an allow list) will get sorted out shortly.
It sounds like you are still experimenting with flows. While you may want to use the platform authenticator, you may still have a better user flow by using the allow list and not prompting the user with the credential selector dialog.
I am happy to explore what will and won't work for you and see how to make it better. I just think it is premature to assume that adding that flag for get credential without an allow list is going to work the way you are hopeing.
Let's have a look at the flows and dialogs now without RK and what changes once no allow list is working on Android.
John B.
On Fri, Aug 9, 2019, 5:29 PM Ki-Eun Shin [email protected] wrote:
John, Thanks for pointing out. I basically agree with your suggestion. If the platform can handle the cases better, we should rely on it. I hope that our users do not confuse the unknown message.
Regarding the specific cases, we are considering mobile web and native app for Android. Still, Android does not support RK. But, we expect that the RK is eventually supported. Then, as I mentioned before (cross browser and cross browser and native), the cases where we haven't any credential info will happen. Maybe, if there is no credential on the platform, the Android will prompt for external authenticator?
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/webauthn/issues/1267?email_source=notifications&email_token=AAAPQJ27AF6Z547FNE6QOILQDXOVJA5CNFSM4IIDYLYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD372FYA#issuecomment-520069856, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAPQJ3TRPFIIOZ2YWOXZ2LQDXOVJANCNFSM4IIDYLYA .
Yeah, we are still considering the best way for providing the WebAuthn. Any suggestion for making concrete user flow would help us a lot.
Regarding the flow with an allow list is a way for solving this. But it will introduce additional user input (user id or username). Ideally, we would like to introduce one or two button saying "use your device" or "user your external device" then user click it without typing anything to trigger get credential.
I am also happy to find the better ways and work with browser and platform vendors.
On the other hand with no allow list the user may be presented with a list of credentials that they need to select from or say OK to.
I haven't seen the UI on Android but there has been a request to change CTAP so that the platform gets the user info even if only one credential is returned. That is so the platform can display it to the user for consent. So you may be trading one dialog for another.
In the native app case it can remember the credential ID so that is less of an issue.
It is still possible to cookie the email/user name allowing the user to overwrite it and return a allow list.
That may be a more familiar flow to start your users with. Clicking on a button and having all system dialogs for logging in is more of a UX change. At the moment it is only Microsoft doing the no allow list login that I have seen in the wild.
Both work quite well.
On the desktop using caBLE to access the credentials on the phone a identifier first flow is probably prefered to allow auto pairing.
There are quite a few issues to consider.
Christian is probably the one you should be talking to about the Android platform authenticator UX.
John B.
On Fri, Aug 9, 2019, 8:39 PM Ki-Eun Shin [email protected] wrote:
Yeah, we are still considering the best way for providing the WebAuthn. Any suggestion for making concrete user flow would help us a lot.
Regarding the flow with an allow list is a way for solving this. But it will introduce additional user input (user id or username). Ideally, we would like to introduce one or two button saying "use your device" or "user your external device" then user click it without typing anything to trigger get credential.
I am also happy to find the better ways and work with browser and platform vendors.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/w3c/webauthn/issues/1267?email_source=notifications&email_token=AAAPQJ2UF7PG6TYP3ZNSUJ3QDYE5LA5CNFSM4IIDYLYKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD4ACKCQ#issuecomment-520103178, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAPQJ7P6B4M3QVY6FUCAPDQDYE5LANCNFSM4IIDYLYA .
Seems like I always get the pleasure of responding to the big threads :)
This issue has come up again-and-again, and my thinking hasn't really changed on this matter much over the last two years:
-
If an RP has an "ambient" credential, they can happily pass in a credentialId (or more than one credentialId), annotate the "transport" of all of these as "internal" and no UI will be presented to attach external authenticators even if none of the credentialIds are found locally. In this particular error-case, UI will be presented to the user that says "something went wrong - no requested credentials were found locally", and upon the user dismissing the dialog, an error will be sent through to the RP so they can handle the failure. Note that it's imperative to show UI to the user and have them dismiss the prompt before sending an error to the RP, otherwise RPs would silently be able to "probe" whether credentials are available on internal authenticators without the user knowing. I think we said before that that's bad.
-
If an RP does not have any ambient credential from which to derive a credentialId (or set of credentialIds), the only option is to call Get with an empty allowlist. In this particular case, there's no way to tell the Client to restrict operation to only platform authenticators, but I believe that's by-design. In the case where credentials for this rpid IS found, an account chooser will be rendered (even if only a single credential is found) where the user can indicate consent for sending proof of this particular credential to the server. After selecting the credential, UV might be required if it was requested by the RP.
In all cases there's small text at the bottom of the account chooser telling a user that, if they're not seeing the credential they're looking for in this list, they can attach an external authenticator to enumerate it's credentials too.
In the case where NO matching credentials are found on the platform (internal) authenticator, we will STILL show an account chooser. But this time it will be empty. The message at the bottom will still be there telling the user that they can attach external security keys now if they have them. The idea is that this message is non-intrusive, and that users who know nothing about security keys won't get confused.
This "empty account chooser" solves two problems:
- It serves as a "consent" screen for letting the RP know that no credentials are found if the user dismisses it (again, we don't just want to tell the RP without any user interaction whether a given platform contains credentials for it. the user won't be able to supress the error message, but it will be indistinguishable from an error when there ARE credentials but the user chose to abort the request)
- It incentivizes RPs to support external authenticator: in a not too distant future I might be registering a platform authenticator on Android, only to try and sign in on my laptop later that night. Even if an RP said "I only want platform credentials" I want to give the user the option to "present" their phone as a "remote, platform authenticator" and need that option to do it. Without having to go back to all RPs to convince them to change their implementations.
Happy to talk more about this in person.
@timcappalli Yeah, I think #1884 helps for RPs to offer better user experience during auth.