Credential Management

Hey Mike,

> On 18 May 2015, at 7:14 pm, Mike West <mkwst@google.com> wrote:
> 
> On Mon, May 18, 2015 at 11:01 AM, Daniel Appelquist <appelquist@gmail.com> wrote:
> Call Agenda[1]
> 
>         • Credentials API review: https://github.com/w3ctag/spec-reviews/issues/49
> 
> If it would be helpful for me to join the call to answer questions about the Credential Management API, I'd be happy to do so.

I see that Domenic and Alex have already given feedback about the JS API, so I won't go deeply into that — their feedback is undoubtably much more valuable than mine would be regarding it.

More generally, then, a few questions / observations come to mind:

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

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

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

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

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

* 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. As per above, declarative markup that such extensions can leverage might go some way towards addressing this.

Cheers,

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

Received on Wednesday, 20 May 2015 07:53:31 UTC