Web Authentication doesn't require a user experience to function, as authenticators (e.g., USB U2F tokens) provide their own user feedback along with the implementing website. However, it is probably a good idea to show something to indicate: 1) That the website is trying to use your authentication hardware 2) Which website is trying to do this (relevant if we're in a frame, such as a "3DSecure" credit card transaction-in-an-iframe situation) 3) What user account the website is trying to log you into -- if it's a login ("getAssertion"). It would also be good to have a "Cancel" and "Never prompt me again" mechanism as part of this. This is broadly covered in Step 6 of https://w3c.github.io/webauthn/#op-make-cred and Step 5 of https://w3c.github.io/webauthn/#op-get-assertion . (The note that it can be omitted if the authenticator has its own output mechanism would be true for all current-generation U2F tokens.) Since this is not required to ship Web Authentication, I'm not going to have this block Bug 1294514.

Here's a first try at what could be a UI when a site asks Web Authentication to "Create a Credential". The available meta-data from the calling website is: * The web origin * The Relying Party's icon URL * The Relying Party's name * The User Account's icon URL * The User Account's name The primary security desire here is to make it unambiguous what site is asking the user to register; in "3DSecure" environments, for example, the payment processor might be embedded in an iframe and trying to register, so that while the user's URL bar shows "shoppingcart.tld", the pop-up would say this is coming from "creditcard.bank". Note that this is not about phishing, as Web Authentication's public-key crypto avoids replay issues exploited by phishing -- this is mostly so that users can make good decisions if an ad network, for example, started trying to call this API for some reason.

Jacqueline: cc'ing you per this morning's meeting.

Let's handle this in bug 1430150 as well.