Pre-Registration Discovery #503
Comments
|
I think this is mainly relevant in the case of roaming authenticators as bound authenticator would always be responsive (to a create call). But even without actively advertising the support for access to a roaming Authenticator on the platform to the RP JS Code, the Browser could remember that it has seen a roaming Authenticator before and could ask the user whether to use/insert it or to say no authenticator available (when encountering a create call for a WebAuthn credential). So this could potentially be addressed by implementation guidance (even without an API change). |
|
Even for a bound authenticator, how do I know if a given person arriving at
my service in a browser actually has an authenticator available? My request
is that:
1) Be able to determine if a given person has an authenticator available
they want to use, so that we can promote the setup flow non-intrusively.
(e.g. put an install banner across the top of the screen) I don't want to
just randomly call create credential and trigger some kind of modal
experience if that's not what the person is in the context of doing at the
time. People very rarely visit their security settings without some kind
of soft prompting.
2) Be able, when the user is in the context of setting up their
authenticator and starting the registration process, to understand enough
about the characteristics to present appropriate instructions.
…On Fri, Jul 7, 2017 at 9:22 AM Rolf Lindemann ***@***.***> wrote:
I think this is mainly relevant in the case of roaming authenticators as
bound authenticator would always be responsive (to a create call).
But even without actively advertising the support for access to a roaming
Authenticator on the platform to the RP JS Code, the Browser could remember
that it has seen a roaming Authenticator before and could ask the user
whether to use/insert it or to say no authenticator available (when
encountering a create call for a WebAuthn credential).
So this could potentially be addressed by implementation guidance (even
without an API change).
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#503 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ACFbcBXClZCllMY0NZSKc2kAWuvOBi_1ks5sLls9gaJpZM4OQW-f>
.
|
|
To add to @equalsJeffH's point, we saw similar issues at MS when we were talking to our partners at different websites. The amount of devices available to perform the authentication requirements are such a small number compared to the backdrop of the web. Especially since web devs are trying to write once and work everywhere, they have to have a way for figure out if the user's device is capable. Also, webauthn covers a bigger device range than U2F. The issue becomes more complicated. |
|
Since Github, apparently, does not automatically include comments submitted through public-webauthn@w3.org, I was requested to post them here for the record. Sorry for the duplicate e-mail that goes out on this. Hi Brad, I'm not going to discuss the merits/demerits of "advertising" that I have a FIDO U2F Authenticator (its bad enough that business models are so skewed already to profit on users' private information without users What prevents the world's most well-known websites that support FIDO from displaying, on their home-page or login page, that they support strong-authentication? And, making it the first choice for sign-ups? Let's see how many well-known sites advertise that they use strong-authentication to protect users on their home-page? https://www.facebook.com/ - Nope; only has password. Now, lets see what an obscure small business that builds an open-source FIDO Certified server does with a couple of FIDO-enabled applications it builds: https://fsodemo.strongauth.com/fso/#/ - Hmmmm.. Where's the password? Brad, I'm not trying to ridicule your efforts at helping people use strong-authentication; I applaud your efforts - and that of all these companies who have invested time and money to integrate FIDO into their sites. But, that's just NOT enough!! Its not enough to claim on blogs, PR and mailing lists that a site supports strong-authentication for users. You need to "shove it into their faces" that this is what you have now, and this is for their benefit. While I recognize that the business models of these companies depend very much on making the sign-up and login process as painless as possible, I can only imagine the amount of money that is wasted in protecting these sites from constant attacks because of passwords. I don't have the data, but I am willing to make a small wager that FIDO-enabled sites that do not make strong-authentication the first and default choice for sign-ups and logins, are reducing their overall profits by not educating people about FIDO when they first land on these home pages. IMHO, it is not enough to silently protect users - it is imperative you educate them first. Its the same old story about "giving someone a fish to eat, or teaching them how to fish". Keep up the good work though; every little bit helps. Arshad Noor |
|
adding a note from the Dropbox side, I do think this will tremendously help us too. Not sure the PR #379 solves the problem Brad is pointing out though: if I am reading the top level comment right, there will be a permission prompt? |
|
@devd the PR is structured in a way to give flexibility to the browser vendors as to how they want the experience to look like. Browsers can decide whether to give a prompt or add something in setting or other UX when they give the information to the RP. There are concerns that without the permission prompt, it'd be fingerprinting. That's why the PR mentions the permission prompt. |
|
Closing as the related PR is merged: #379 |
Greetings, WebAuthN folks.
Facebook has now had U2F available as a second-factor authentication technology for not quite six months. I'd like to share some challenges we have and are encountering with our deployment in hopes that these might be addressed by the WebAuthN work.
Specifically, I want to raise the issue that the lack of pre-registration discovery presents a major obstacle to both reach and usability.
In terms of reach, only a small number of people actually have U2F devices. We would like to be able to enroll as many active users of these devices as possible, and expect that most people who are both U2F and Facebook users would like to use their devices with us. And yet, many people who use U2F don't know that Facebook supports it. If this is the case for the highly technical segment of people using U2F today at one of the world's most well-known websites, imagine how difficult this will be in the tail of services that may support Web AuthN.
It would be very helpful if, the first time a Web AuthN capability is used in a user agent, the individual was presented with the option to advertise that they have and use this capability, so that other services that support it can promote it to the user or prompt them to set it up.
A closely related problem is that giving good instructions to an individual registering their authenticator is very difficult with no information about how that authenticator is exposed or what ceremony is necessary to use it. Facebook currently generically instructs people to insert their authenticator into the USB port of their computer, but those instructions are flatly wrong for a BTLE attached device, or a U2F capability integrated into the chipset of their device but exposed over the USB bus. Some of this information appears to become available as selectors in the WebAuthN API after an authenticator has already been registered, but not at the most critical time - when the person is first setting it up.
Again, it would be nice if there was an opt-in possible to let people advertise that they have an authenticator, and its basic capabilities, so that services which support it can present an appropriate registration experience.
The text was updated successfully, but these errors were encountered: