Re: Credential Management

Hey,

[ I'm going to start inserting a standard disclaimer that I find gmail quoting conventions VERY annoying :) ]

> On 20 May 2015, at 6:11 pm, Mike West <mkwst@google.com> wrote:
> 
> 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.

Ah, interesting; good stuff.

BTW, the spec refers to this for 'autocomplete':
  http://www.w3.org/TR/html5/forms.html#attr-form-autocomplete
when IMO this would be a much friendlier ref:
  http://www.w3.org/TR/html5/forms.html#autofilling-form-controls:-the-autocomplete-attribute


> * 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. :)

Will have a look, thanks.


>  * 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.

I was referring to the `name` attribute on LocallyStoredCredential.


>  * 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.

I'm not saying we shouldn't recommend it; I'm wondering whether we can rely upon 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.

*sigh* true. I'm concerned about attacks where the user doesn't even know that their password has been compromised - Navigate to the wrong link and it's all over. However, being same-origin does help.

> 
> 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.

OK. If it stays, it might benefit from some editorial love.

 
> * 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.

OK, that makes me feel somewhat better about it.


Thanks!


--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 20 May 2015 11:49:20 UTC