Re: Credential Management

Thanks Mark!

On Wed, May 20, 2015 at 9:53 AM, Mark Nottingham <mnot@mnot.net> wrote:

> * Has there been any discussion of defining more declarative markup to
> benefit credential managers? While this API may go a long way towards
> helping capable sites work with credential managers, there is a very long
> tail of sites that won't adapt their login mechanism to it, or even be able
> to re-engineer to use libraries that leverage it. E.g., a simple flag on
> the form to indicate whether it's logging in, creating an account or
> changing a password would make existing managers much more reliable /
> smooth.
>

This exists in the form of `autocomplete` attributes:
https://html.spec.whatwg.org/multipage/forms.html#autofilling-form-controls:-the-autocomplete-attribute.
Somewhere on my list of things to do is to put together a document
outlining exactly what Chrome would love to see; I suspect the models for
Edge, Opera, Safari, and Firefox will be similar.


> * Both declaratively and in the API, it seems like there's a need to allow
> sites to express requirements or constraints upon passwords when an account
> is generated; e.g., a whitelist / blacklist of characters, length
> requirements, etc. While many sites practices might be dodgy or annoying
> here (at best), credential managers sometimes have a significant challenge
> creating passwords that are conformant to site policies, making user
> intervention necessary.
>

This is
https://w3c.github.io/webappsec/specs/credentialmanagement/#issue-69471d6f (
https://github.com/w3c/webappsec/issues/250), which I've punted for the
moment. You're entirely correct, though, doing generation well is
difficult. I welcome suggestions for a reasonable syntax that doesn't
involve the user agent parsing regular expressions.

Johnathan added some suggestions to that bug. I'd encourage you (and
others!) to do the same. :)


> * Is the credential's name intended to correspond to the name that the
> user gives the credential in their manager, and is it available to the
> service?
>

The `id` attribute on the credential has credential-specific meaning. In
the case of `PasswordCredential` and `FederatedCredential`, the `id` is
almost certainly the username.


> * 6.2 recommends using CSP to mitigate the risk of same-origin leakage.
> Given the low adoption rates of CSP as well as the challenges of deploying
> it correctly, is this realistic? The obvious alternative is to require user
> mediation in all cases - has that been discussed?
>

CSP exists, and protects against these kinds of leakage. I don't see a good
reason not to recommend it.

More to the point, for same-origin requests, user mediation doesn't help.
There's nothing a user agent can do to differentiate a "real" request from `
bank.com` from an XSS'd request triggered by an attacker. The origin is the
same, and if a user trusts `bank.com`, then they'll click the shiny button.

Additionally, the spec somewhat intentionally leaves open the question of
when and how user mediation may be avoided. Presumably user agents have a
good understanding of how their users wish to use the browser, and how to
ask for permission to make their lives easier via features like automagical
login.


> * In 6.6, what decision is being referred to? This para is very hard to
> read…
>

`autocomplete="off"` turns off autofill in some browsers. Other browsers
(like Chrome) have decided to ignore this attribute, because it's a poor
experience for the user, and inverts the priority of constituencies. This
paragraph means to say "Don't let this API turn into a new
`autocomplete="off"` mechanism.

This was more of a concern when there was a "Hey, the login just failed!"
notification in the API. Since we've removed that method in the meantime,
it's probably a good idea to remove this section entirely.


> * 8.3 points out that browsers need to modify their extension model in
> some way to accommodate third party password managers (e.g,. 1Password).
> This puts them at an unfortunate disadvantage, in that they will rely on
> the browser exposing a non-standard API to access the standard mechanism
> we're defining. That doesn't strike me as very good for competition between
> browsers, because some people use third party extensions to avoid being
> effectively locked into their browsers by their own passwords.


It's not clear to me why this would create any additional disadvantage for
extensions, beyond the fundamental disadvantage of not being the browser.

In Chrome, I expect extensions like 1Password to simply inject script that
overwrites `navigator.connect.get()`. That's certainly possible today, and
I suspect it's possible in Firefox's add-on model as well. It would
probably be better for browsers to provide deeper hooks to make this
simpler for those types of extensions, but I'm reluctant to say much more
about it in the spec than I have already, as extensions are by their nature
proprietary and out of scope for the W3C.

As per above, declarative markup that such extensions can leverage might go
> some way towards addressing this.
>

As per above, this exists, but isn't yet well documented enough to expect
web developers to know about or use.

Thanks again!

--
Mike West <mkwst@google.com>, @mikewest

Google Germany GmbH, Dienerstrasse 12, 80331 München,
Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der
Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth
Flores
(Sorry; I'm legally required to add this exciting detail to emails. Bleh.)