#692: Credential Management: Conditional Mediation

Visit on Github.

Opened Nov 25, 2021

Nyanpasu~ TAG!

I'm requesting a TAG review of Credential Management: Conditional Mediation.

A new kind of mediation in credential management that instructs the user agent not to display UI unless the user has credentials. Designed to solve the bootstrapping problem when replacing passwords by WebAuthn credentials: websites should be able to fire a WebAuthn call while showing a regular password prompt without worrying about showing a modal dialog error if the device lacks appropriate credentials.

Conditional Mediation is built on top of credential management to allow integration with other credential types.

Further details:

  • I have reviewed the TAG's Web Platform Design Principles
  • Relevant time constraints or deadlines: N/A
  • The group where the work on this specification is currently being done: Web Authentication
  • Major unresolved issues with or opposition to this specification: None.
  • This work is being funded by: Google

You should also know that this feature has two parts: adding "Conditional Mediation" to Credential Management and the particular utilization of it by the WebAuthn spec. We would like to have TAG review the first part here. The second part is included in #686.

We'd prefer the TAG provide feedback as (please delete all but the desired option):

💬 leave review feedback as a comment in this issue and @-notify nsatragno@ equalsjeffh@

Discussions

Discussed Dec 1, 2021 (See Github)

Summarizing: we discussed the user flow of webauthn as documented in the explainer for this issue and for #686. We went through the design from a privacy & security perspective - looking at how authn credentials are not exposed to the web app unless and until the user completes the user flow. Also

Hi @nsatragno - we're looking at this (and the general topic of making webauthn more friendly) at our virtual f2f this week.  A couple of questions: if the user *does* have an appropriate credential but they don't want to use it - for example, they want to log in as another identity - then what information does the web app know about the user's choice?  If the web page displays a username and password dialog at the same time that the browser surfaces a webauthn UI of some kind to pick a credential, isn't that going to be confusing to the user?  Since the web page won't know that the browser is supplying this UI (which seems important from a privacy & security standpoint) how is that expected to work? We can see the screenshot in the explainer under Conditional UI, but it isn't clear if this is the current status quo or if this is the aspirational UI.

Also: can you please bring the (well written!) explainer over to a markdown file in the appropriate webauthn repo? Also can we suggest that you link to [this document](https://github.com/w3c/webauthn/wiki/Explainer:-broadening-the-user-base-of-WebAuthn) from the explainer in order to help put this one in context?
Comment by @torgo Dec 9, 2021 (See Github)

Hi @nsatragno - we're looking at this (and the general topic of making webauthn more friendly) at our virtual f2f this week. A couple of questions: if the user does have an appropriate credential but they don't want to use it - for example, they want to log in as another identity - then what information does the web app know about the user's choice? If the web page displays a username and password dialog at the same time that the browser surfaces a webauthn UI of some kind to pick a credential, isn't that going to be confusing to the user? Since the web page won't know that the browser is supplying this UI (which seems important from a privacy & security standpoint) how is that expected to work? We can see the screenshot in the explainer under Conditional UI, but it isn't clear if this is the current status quo or if this is the aspirational UI.

Also: can you please bring the (well written!) explainer over to a markdown file in the appropriate webauthn repo? Also can we suggest that you link to this document from the explainer in order to help put this one in context?

Comment by @nsatragno Dec 9, 2021 (See Github)

Hi @torgo, thank you for looking into this! I have ported the explainer to a wiki file written in markdown on the WebAuthn repository.

I'll try to answer all the questions below:

if the user does have an appropriate credential but they don't want to use it - for example, they want to log in as another identity - then what information does the web app know about the user's choice?

The user agent will disclose a credential if and only if the user selects that webauthn credential and passes the local user verification challenge. For any other case, the user agent won't disclose anything at all. In other words, if they want to log-in with a different identity, the website will get no information at all through WebAuthn/Conditional UI. I have updated the explainer's privacy considerations to make this more clear.

If the web page displays a username and password dialog at the same time that the browser surfaces a webauthn UI of some kind to pick a credential, isn't that going to be confusing to the user?

Conditional UI is designed to integrate with the browser's existing autofill UI surface to address this, i.e. it should be no more confusing that the website offering to autofill a password

Since the web page won't know that the browser is supplying this UI (which seems important from a privacy & security standpoint) how is that expected to work?

Autofill surfaces and sign-in forms already deal with this UI dynamic, which we are leveraging for Conditional UI.

Discussed Jan 31, 2022 (See Github)

Sangwhan: curious about other stakeholders / web authn in general.. Is any other browser interested in webautn in the first place?

Dan: I was starting to see so many things about webauthn so I bought a yubikey.. I found it working with safari on mac and iOS, and on samsung internet (behind a flag) and I found it surprisingly easy to get it to work with the nfc mode and the usb mode. It looked like twitter and github are supporting it from a UI perspective, I know google is, lots of other websites do. Looks like it's a thing. The other issue we discussed in breakout A was about expanding the use of non hardware key based solutions for storing key material to encourage greater adoption so you could really use it as a replacement for passwords, eg. if you have sync between different devices, and how does that play into this secure side of it because then you have to trust a sync provider in order to .. It' sspecifically about how the web ui can lead a user into an experience where they're more likely to adopt webauthn. The main issue we raised before was more a privacy related issue. Does this conditional UI provide additional information to the website about whether or not the user already has what type of key they have or what type of credentials they already have, and I think the answers we got are pretty good. And they've updated their explainer privacy considerations. I'm happy with these responses.

Amy: looks good to me

Sangwhan: seems sensible

Dan: [leaves comment]

closed

Comment by @torgo Feb 1, 2022 (See Github)

Hu @nsatragno - thanks for these responses and the updates. This looks good to us. We're excited to see WebAuthN enjoy enjoy more adoption (which we are also discussing in #686).