Intent to implement: W3C WebAppSec credentialmanagement API

[Axel Nennker]

Summary: This API is enabling a website to request a user's credentials from a user agent, and helps the user agent to correctly store user credentials for future use. It helps the LoginManager to get rid of most of the heuristics.
Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1156047
Link to standard: https://w3c.github.io/webappsec-credential-management/
Platform coverage: Desktop first, every platform that today has LoginManager
Current code is here: https://github.com/AxelNennker/firefox_credentials/
Estimated or target release: spec is still work in progress
Preference behind which this will be implemented: not implemented yet
DevTools bug:
Suggested Additions: none, minimal viable API e.g. no password generation help by the UA. Federated Identity support is probably removed in the next version.

Intend to ship in Chrome: https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/7ouLjWzcjb0

Web designer / developer use-cases: examples are in the spec

[Ben Kelly]

Thanks for taking this on Alex!

I had some initial concerns with the API from a fetch/SW perspective, but
Mike seems open to addressing them:

https://github.com/w3c/webappsec-credential-management/issues/11

I believe Matthew Noorenberghe had some concerns about the necessity of the
API given requestAutocomplete:


https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ
https://github.com/w3c/webappsec-credential-management/issues/2

We should probably come to some consensus there before moving forward.

Thanks again.

Ben

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Martin Thomson]

On Fri, Mar 11, 2016 at 5:56 AM, Axel Nennker <ignis...@gmail.com> wrote:
> no password generation help by the UA

I agree with MattN here, not doing this eliminates much of the
advantage of having a password manager. Or do you have a plan to rely
on sites doing that with CredentialContainer.store()? That doesn't
sound optimal to me.

[Axel Nennker]

The questions is whether password generation should be part of the standard.
The login manager / Firefox can still add password generation.
I am not per se against adding password generation to the standard but there should be a PR that WebAppSec agrees on quickly. Support by major / popular sites would help. I fear that a password-complexity-and-renewal-policy-description-language is something that grows out of hand easily.
The spec should focus on simple-and-useful features.

[richard...@gmail.com]

I think the idea would be something like:

```
var pass = /* generate a long random password */;
var cred = new PasswordCredential({password: pass});
navigator.credentials.store(cred);
```

So having the API as an imperative interface to the password manager doesn't do the work for you, but (ISTM) makes it more appealing to do so, since you have more assurance that the user is never going to have to see it.

That does raise the question, however, of how such a credential differs from, say:

* A cookie
* A random nonce in localStorage/IDB
* A non-extractable WebCrypto key

By which I mean that if a website wants to verify that it is loaded in the same browser as before, it already has a variety of ways to do so, some of which offer better anti-theft properties than these Credential objects. Presumably the fact that these are not being used means that the site wants some indication that it has the right *user*, not just the right browser. In which case, generating a long random password is not so useful.

--Richard

[Anne van Kesteren]

On Fri, Mar 11, 2016 at 6:08 PM, <richard...@gmail.com> wrote:
> That does raise the question, however, of how such a credential differs from, say:
>
> * A cookie
> * A random nonce in localStorage/IDB
> * A non-extractable WebCrypto key

The idea is that these are all less persistent. When you clear
storage/cookies, you don't delete password manager entries. (Which is
also why store() requires UI, if I remember correctly.)


--
https://annevankesteren.nl/

[Anne van Kesteren]

On Sat, Mar 12, 2016 at 3:48 AM, Martin Thomson <m...@mozilla.com> wrote:
> Now that is a frightening observation. Is this creating a more persistent
> (pernicious?) tracking mechanism?

It should be identical to password manager integration.


> In that case, credentials stored by a site should last no longer than
> cookies. Credentials created by a user maybe can live longer.

How do you distinguish the two if the access is through a UI-mediated API?


If we think this API should have no more power than storage/cookies,
there's not much point in having this API. A site could then simply
remember the federation provider itself, and such, and lose it
whenever the user is done with the site (or has visited enough other
sites).


--
https://annevankesteren.nl/

[Martin Thomson]

On 12 Mar 2016 7:28 PM, "Anne van Kesteren" <ann...@annevk.nl> wrote:
> It should be identical to password manager integration.

But it is not, though I suppose that a password manager might be exploited
to store state. I hope that isn't possible... (note to self, attempt this
attack)

> > In that case, credentials stored by a site should last no longer than
> > cookies. Credentials created by a user maybe can live longer.
>
> How do you distinguish the two if the access is through a UI-mediated API?

If credentials created in response to a `get()` call are stored at the
point they are created, you could treat calls to `store()` very
differently. Maybe. If the intent is to use a password manager, see
Richard's earlier mail.

> If we think this API should have no more power than storage/cookies,
> there's not much point in having this API.

Yes, the source of my concerns, right there. Sure, the fig leaf might allow
us to convince ourselves that we aren't creating a tracker that trumps the
rest.

If we are creating something that is somehow greater out of the framework
this provides (FIDO), then that is useful. But the stepping stone we are
being offered on that path looks suspicious. Why not go straight for the
real prize?

[Martin Thomson]

Now that is a frightening observation. Is this creating a more persistent
(pernicious?) tracking mechanism?

In that case, credentials stored by a site should last no longer than
cookies. Credentials created by a user maybe can live longer.

On 12 Mar 2016 04:41, "Anne van Kesteren" <ann...@annevk.nl> wrote:

> On Fri, Mar 11, 2016 at 6:08 PM, <richard...@gmail.com> wrote:

> > That does raise the question, however, of how such a credential differs
> from, say:
> >
> > * A cookie
> > * A random nonce in localStorage/IDB
> > * A non-extractable WebCrypto key
>

> The idea is that these are all less persistent. When you clear
> storage/cookies, you don't delete password manager entries. (Which is
> also why store() requires UI, if I remember correctly.)
>
>
> --
> https://annevankesteren.nl/

[Mike West]

Hey folks! Glad to see that there's interest in this API from Mozilla. :)

On Sun, Mar 13, 2016 at 10:15 AM, Martin Thomson <m...@mozilla.com> wrote:

> On 12 Mar 2016 7:28 PM, "Anne van Kesteren" <ann...@annevk.nl> wrote:
> > It should be identical to password manager integration.
>
> But it is not, though I suppose that a password manager might be
> exploited to store state. I hope that isn't possible... (note to self,
> attempt this attack)
>

Credential managers guess at a user's username and password, and ask the
user if they'd like to persist that information. It's generally stored
outside of "site data" (cookies, localstorage, IDB, etc), and users
generally treat it differently (anecdotally: ~12.9% of Chrome's users
who've opted into sharing usage data cleared cookies in the last week;
~2.7% cleared passwords). I think this distinction is pretty much in line
with user expectation.

This API offers a few things that the status quo cannot: Imperative
certainty about the data being persisted as opposed to heuristic guessing,
XSS mitigation, federation hints, and automatic sign-in for users who have
done whatever dance the UA requires to enable such a feature.

I don't believe, however, that it offers additional tracking capability
above and beyond the (quite intentional) capabilities inherent in a
credential manager. Sites are not granted any ability to persist data
without user knowledge; they are only granted control over the timing of
the prompt, but the prompt itself is still required. Nor are sites granted
the ability to read data without user knowledge; users are either directly
involved in handing credentials over to a site, or they grant the UA
permission to hand credentials over.

As we add more credential types (FIDO, etc), we'll certainly need to ensure
that we don't introduce privacy footguns, but I think we're capable of
maintaining that dicipline.

> > > In that case, credentials stored by a site should last no longer than
> > > cookies. Credentials created by a user maybe can live longer.
> >

> > How do you distinguish the two if the access is through a UI-mediated
> API?
>
> If credentials created in response to a `get()` call are stored at the
> point they are created, you could treat calls to `store()` very
> differently. Maybe. If the intent is to use a password manager, see
> Richard's earlier mail.
>

I'm not sure, but it sounds like this is based on some misunderstanding of
what the API offers. Does the above description ease your concerns? Or am I
missing the critique?

> > If we think this API should have no more power than storage/cookies,
> > there's not much point in having this API.
>
> Yes, the source of my concerns, right there. Sure, the fig leaf might
> allow us to convince ourselves that we aren't creating a tracker that
> trumps the rest.
>
> If we are creating something that is somehow greater out of the framework
> this provides (FIDO), then that is useful. But the stepping stone we are
> being offered on that path looks suspicious. Why not go straight for the
> real prize?
>

Websites use passwords today. While I agree that we can and should be
working on something better, I don't think that we should overlook small
improvements in the status quo. We can give users a better experience on
their favourite sites if we allow developers to bypass status quo
heuristics, and we keep users safer if we mitigate some of the XSS risks of
password managers today. I think this API does both, and is worth
experimenting with to see if it's a framework we can build upon.

-mike

[Mike West]

On Thu, Mar 10, 2016 at 9:07 PM, Ben Kelly <bke...@mozilla.com> wrote:

> Thanks for taking this on Alex!
>
> I had some initial concerns with the API from a fetch/SW perspective, but
> Mike seems open to addressing them:
>
> https://github.com/w3c/webappsec-credential-management/issues/11

In https://github.com/whatwg/fetch/pull/237, I think we've worked out a
reasonable solution to the issues you noted, Ben. Thanks! There's an
outstanding question in https://github.com/whatwg/fetch/issues/245 about
the effect of our solution on a naive approach to copying Request objects.
I personally am pretty much fine with this outcome, but I'd appreciate
other opinions on those threads. :)

I believe Matthew Noorenberghe had some concerns about the necessity of the
> API given requestAutocomplete:
>
>
> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ
> https://github.com/w3c/webappsec-credential-management/issues/2
>
> We should probably come to some consensus there before moving forward.
>

I agree with MattN that a rAc-style API is a reasonably good fit for
signing up for a new account on a website*. Sign-up forms often encompass a
variety of kinds of information, and layering something on top of existing
forms and autocomplete attributes sounds like a way of providing all of
those bits and pieces at once, rather than having 15 calls to a APIs that
hand them out piecemeal.

With some caveats around XSS protection, I think that rAc could work for
signing-in with passwords. I guess it could work for signing in with
federations, though I think it starts to break down pretty rapidly. I don't
think it would work for any other potential uses of the API. `store()`, in
particular, is more or less the opposite of rAc and seems valuable
(especially for federations, but also for passwords), and FIDO is a good
example of a set of proposals that seem to entirely require additional
interaction above and beyond filling a form. I haven't seen a
counter-proposal for those pieces.

I'm inclined to continue pursuing this more imperative proposal, as it
seems flexible enough to support the use cases we know we have today, and
those we'll discover in the future. The developers I've spoken with see the
API as an improvement and have been able to layer it on top of existing
sign-in systems with minimal change to their authentication backends
(which, as probably won't surprise you, are _always_ the oldest,
least-well-understood, and most fragile bits :) )**. I think it's worth
exploring.

-mike

* I also agree with him that sign-up is an important use-case, and that we
should do the work to support it. Anyone interested in working with me on a
draft proposal for what that might look like?

** This, of course, is unverifiable hearsay, and you'll have to trust that
I'm not just making up anecdotes... Sorry. :( The negative feedback on the
API that I've gotten from developers has been that `fetch()` is
complicated, and that the XSS mitigations and secure context restrictions
make it hard for some folks to use (because they don't use TLS, or because
they require JavaScript access to the password for reasons).

[Martin Thomson]

I don't think that there was any misunderstanding in what it is that
is being proposed, just disagreement about cost-benefit.

On Mon, Mar 14, 2016 at 8:02 PM, Mike West <mk...@google.com> wrote:
> Websites use passwords today. While I agree that we can and should be
> working on something better, I don't think that we should overlook small
> improvements in the status quo. We can give users a better experience on
> their favourite sites if we allow developers to bypass status quo
> heuristics, and we keep users safer if we mitigate some of the XSS risks of
> password managers today. I think this API does both, and is worth
> experimenting with to see if it's a framework we can build upon.

Maybe it's a value thing, I don't see that gold-plating this
experience is going to make a difference commensurate with the cost.
The fetch API changes are the core of the purported benefit, and that
turns out to be a non-trivial thing, with the added cost of indefinite
support for a feature we don't really want in support of a mechanism
that isn't that great.

The actual benefit is something that is only realized once a site puts
in the effort required. That is small, yes, but we're seeing sites
actively avoid password managers, hence the aggressive heuristics, and
rAC is much more likely to work for that, since it's implemented and
deployed already.

[Matthew N.]

On 2016-03-10 12:07 PM, Ben Kelly wrote:
> I believe Matthew Noorenberghe had some concerns about the necessity of the
> API given requestAutocomplete:
>
>
> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ
> https://github.com/w3c/webappsec-credential-management/issues/2
>
> We should probably come to some consensus there before moving forward.

Axel was already on a thread about this concern before sending out the
intent to implement so I'm not sure why this intent was sent out a day
later when the concerns weren't yet addressed.

Matthew

[Matthew N.]

On 2016-03-14 2:02 AM, Mike West wrote:
> Hey folks! Glad to see that there's interest in this API from Mozilla. :)
>
> On Sun, Mar 13, 2016 at 10:15 AM, Martin Thomson <m...@mozilla.com> wrote:
>
>> On 12 Mar 2016 7:28 PM, "Anne van Kesteren" <ann...@annevk.nl> wrote:
>>> It should be identical to password manager integration.
>>
>> But it is not, though I suppose that a password manager might be
>> exploited to store state. I hope that isn't possible... (note to self,
>> attempt this attack)
>>
> Credential managers guess at a user's username and password, and ask the
> user if they'd like to persist that information.

They only guess because authors don't know about or aren't using the
HTML autocomplete values to markup this information:
https://html.spec.whatwg.org/#attr-fe-autocomplete-username

One of my criticisms of this spec is that sites can already use these
attributes and form submissions so password managers don't need to use
heuristics for identifying login credentials so why do we need another
way of doing this?

> It's generally stored
> outside of "site data" (cookies, localstorage, IDB, etc), and users
> generally treat it differently (anecdotally: ~12.9% of Chrome's users
> who've opted into sharing usage data cleared cookies in the last week;
> ~2.7% cleared passwords). I think this distinction is pretty much in line
> with user expectation.
>
> This API offers a few things that the status quo cannot: Imperative
> certainty about the data being persisted as opposed to heuristic guessing,

This could be built on top of <form> instead of creating new interfaces.
See https://github.com/w3c/webappsec-credential-management/issues/13 for
a proposal.

> XSS mitigation,

I disagree that the status quo "cannot" (it simply "does not" IMO) as
I've explained in other threads how most, if not all, of these can
mitigations can be applied to <input>/<form> mostly using your
@writeonly proposal:
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Oct/0181.html

> federation hints,

This is possible via new @autocomplete values too or could be its own
API and/or spec.

> and automatic sign-in for users who have
> done whatever dance the UA requires to enable such a feature.

This could also be implemented on top of <form>/rAc for local credentials.

I agree there are ways to improve the status quo but I think there are
more incremental improvements like imperative storing of credentials in
a <form> (issue #13), support for @writeonly for XSS mitigation, and
promoting/improving requestAutocomplete for login/registration that are
less complex and more backwards-compatible.

Matthew

[Matthew N.]

On 2016-03-14 2:29 AM, Mike West wrote:
> On Thu, Mar 10, 2016 at 9:07 PM, Ben Kelly <bke...@mozilla.com> wrote:
> I believe Matthew Noorenberghe had some concerns about the necessity of the
>> API given requestAutocomplete:
>>
>>
>> https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/7ouLjWzcjb0/s7aZHGnlAwAJ
>> https://github.com/w3c/webappsec-credential-management/issues/2
>>
>> We should probably come to some consensus there before moving forward.
>>
>
> I agree with MattN that a rAc-style API is a reasonably good fit for
> signing up for a new account on a website*. Sign-up forms often encompass a
> variety of kinds of information, and layering something on top of existing
> forms and autocomplete attributes sounds like a way of providing all of
> those bits and pieces at once, rather than having 15 calls to a APIs that
> hand them out piecemeal.

Given that, do you think it makes sense to have a separate API for login
when there is overlap with rAc as well?

> With some caveats around XSS protection, I think that rAc could work for
> signing-in with passwords. I guess it could work for signing in with
> federations, though I think it starts to break down pretty rapidly. I don't
> think it would work for any other potential uses of the API. `store()`, in
> particular, is more or less the opposite of rAc and seems valuable
> (especially for federations, but also for passwords), and FIDO is a good
> example of a set of proposals that seem to entirely require additional
> interaction above and beyond filling a form. I haven't seen a
> counter-proposal for those pieces.

You're convinced me that an imperative method for saving (local)
credentials is useful but I don't think we need new interfaces and
objects surrounding it when we have the autocomplete values. See
https://github.com/w3c/webappsec-credential-management/issues/13

> I'm inclined to continue pursuing this more imperative proposal, as it
> seems flexible enough to support the use cases we know we have today, and
> those we'll discover in the future. The developers I've spoken with see the
> API as an improvement and have been able to layer it on top of existing
> sign-in systems with minimal change to their authentication backends
> (which, as probably won't surprise you, are _always_ the oldest,
> least-well-understood, and most fragile bits :) )**. I think it's worth
> exploring.
>
> -mike
>
> * I also agree with him that sign-up is an important use-case, and that we
> should do the work to support it. Anyone interested in working with me on a
> draft proposal for what that might look like?

This is already specified in the requestAutocomplete[1] section of the
HTML specification so I think it's probably (close to being?) ready to
implement already. The other part for XSS protection is @writeonly[2]
which can be added to the HTML spec. I'm not sure what else you have in
mind but I can try help.

Matthew

[1] https://html.spec.whatwg.org/#dom-form-requestautocomplete
[2]
https://lists.w3.org/Archives/Public/public-whatwg-archive/2014Oct/0181.html

[Justin Dolske]

On 3/14/16 3:01 PM, Martin Thomson wrote:

> The actual benefit is something that is only realized once a site puts
> in the effort required. That is small, yes, but we're seeing sites
> actively avoid password managers, hence the aggressive heuristics, and
> rAC is much more likely to work for that, since it's implemented and
> deployed already.

This is the key issue, IMO, which makes me not interested in having
Firefox implement this API.

Far too many sites either simply don't care about user password
management (ie, they do problematic things that could easily be fixed),
or actively take steps to intentionally break password managers. In the
past we considered this an advocacy/evangelism problem, and it was
deemed the site's responsibility to play nice. That's worked poorly, and
sucks for users. We now believe that we have to assume a adversarial
environment: it's our job to serve as the user's agent and do whatever
it takes to work on a site.

If there's interest in assisting sites that want to play nice, I think
it would be better to start with documenting a set of cross-browser
"best practices" that they can follow, for the standards and
implementations that exist today.

I'd also note that Mozilla Labs tried going down a similar path in the
past, with Account Manager -- see
https://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/.
The team involved in that did a _lot_ of outreach with sites and web
developers. I remember it as having a somewhat tepid reception...
Especially around sites not wanting to cede any UX control to the
browser in the signup/login/logout experience, and some industries being
very disinterested doing anything beyond what was mandated by
regulations (ie, they saw doing anything outside their rulebook as
adding legal risk).

Justin

[Mike West]

On Thu, Mar 17, 2016 at 10:04 PM, Justin Dolske <dol...@mozilla.com> wrote:

> On 3/14/16 3:01 PM, Martin Thomson wrote:
>
> The actual benefit is something that is only realized once a site puts
>> in the effort required. That is small, yes, but we're seeing sites
>> actively avoid password managers, hence the aggressive heuristics, and
>> rAC is much more likely to work for that, since it's implemented and
>> deployed already.
>>
>
> This is the key issue, IMO, which makes me not interested in having
> Firefox implement this API.
>

My understanding of the objections Martin and Matt have outlined are that
they're not interested in _this spelling_ of the API, and would prefer that
it be spelled using `requestAutocomplete`.

> Far too many sites either simply don't care about user password management
> (ie, they do problematic things that could easily be fixed), or actively
> take steps to intentionally break password managers. In the past we
> considered this an advocacy/evangelism problem, and it was deemed the
> site's responsibility to play nice. That's worked poorly, and sucks for
> users. We now believe that we have to assume a adversarial environment:
> it's our job to serve as the user's agent and do whatever it takes to work
> on a site.
>

Sure. Heuristics should continue to work, and I agree 100% that they should
be aggressive enough to trigger on sites that are actively disinterested in
allowing password managers. I don't see that as being at odds with allowing
a site to explicitly integrate with the user's password manager if they
decide to do so.

With the explicit understanding that I don't work at Mozilla, and that
y'all's prioritization is very much yours to set, this sounds like a good
argument for investing effort in those heuristics. It doesn't sound like an
argument against accepting the contribution that Axel is offering.

> If there's interest in assisting sites that want to play nice, I think it
> would be better to start with documenting a set of cross-browser "best
> practices" that they can follow, for the standards and implementations that
> exist today.
>

I agree that we should do this regardless.
https://www.chromium.org/developers/design-documents/form-styles-that-chromium-understands
exists, for instance, and I'm sure Mozilla has a similar page somewhere.
Perhaps it would be worthwhile to collaborate on something more visible?

> I'd also note that Mozilla Labs tried going down a similar path in the
> past, with Account Manager -- see
> https://hacks.mozilla.org/2010/04/account-manager-coming-to-firefox/. The
> team involved in that did a _lot_ of outreach with sites and web
> developers. I remember it as having a somewhat tepid reception...
> Especially around sites not wanting to cede any UX control to the browser
> in the signup/login/logout experience, and some industries being very
> disinterested doing anything beyond what was mandated by regulations (ie,
> they saw doing anything outside their rulebook as adding legal risk).

Interesting! Thanks for the link.

I think there are some relevant differences between Account Manager and the
API proposal on the table today. Account Manager looks more like a
replacement for the existing mechanisms, and has some really interesting
properties that result from interjecting itself between the page and the
user. The CM API is more narrowly scoped, and my (biased) impression is
that it seems simpler to understand how to use it as a layer on top of an
existing sign-in system.

It's also been ~6 years, and while I agree that there are many sites that
intentionally break password managers, there also seems to be more
mindshare for managers like LastPass/1Password/Dashlane/etc today than
there was in 2010. I'd suggest that trying again seems reasonable to
attempt.

Thanks!

-mike

[Matthew N.]

Coupled with what Justin and Martin said above about adoption (which I
also expressed), I don't see how it makes sense for us to add more
complexity to that system. If this was a replacement or alternative to
the heuristics (like it would be if built on rAc) then it makes more
sense (rAc is mostly independent of the password manager heuristics) to
pursue but that's not how I see the interaction with the current spec
and password manager.