W3C home > Mailing lists > Public > public-webauthn@w3.org > August 2019

Re: [webauthn] Specify authenticator attachment for authentication operation (#1267)

From: John Bradley via GitHub <sysbot+gh@w3.org>
Date: Fri, 09 Aug 2019 21:03:04 +0000
To: public-webauthn@w3.org
Message-ID: <issue_comment.created-520062683-1565384583-sysbot+gh@w3.org>
To be clear you can send the attachment 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 <notifications@github.com> 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>
> .
>


-- 
GitHub Notification of comment by ve7jtb
Please view or discuss this issue at https://github.com/w3c/webauthn/issues/1267#issuecomment-520062683 using your GitHub account
Received on Friday, 9 August 2019 21:03:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:59:06 UTC