Intent to Ship: Credential Management API

[Mike West]

# Contact emails
mk...@chromium.org

# Spec
https://w3c.github.io/webappsec-credential-management/

I've discussed this spec with the TAG a few times over the last ~year: (https://github.com/w3ctag/spec-reviews/issues/49). I believe they're happy with the general structure of the API.

# Summary

This intent covers a programmatic interface to the browser's password manager. In short, an origin can request a user's credentials via `navigator.credentials.get()`, and ask the browser to save credentials via `navigator.credentials.store()`.

The API provides a few properties that I think are interesting:

1. Websites that care can bypass the proprietary hodgepodge of heuristics that each browser has piled together to detect sign-in forms, password changes, and etc. It's significantly better for a website to say "Hey, the user just signed in. Really. Would you mind prompting to save their credentials?" than for the browser to guess at the same. This is especially valuable for the kinds of sign-in operations that we're particularly bad at (XHR/Fetch-based asynchronous authentication, for instance).

2. Today, we have zero heuristics (proprietary hodgepodge or not) for federated sign-in. If you, like me, have created ~4 accounts at Stack Overflow because you couldn't remember whether you used Twitter, Google, or one of the other ~16 options they provide, the support this API provides for federation might be helpful.

3. We can streamline the sign-in process by offering automatic sign-in. You could imagine that if the right settings are toggled, there's no reason a user should ever see a sign-in form for their favorite websites ever again.

4. Some measure of XSS mitigation, as passwords provided for sign-in aren't directly script-accessible.

# Link to “Intent to Implement” blink-dev discussion

https://groups.google.com/a/chromium.org/d/msg/blink-dev/KrxJvW80yPg/-UC9370USHYJ

# Is this feature supported on all six Blink platforms?

Everything but WebView. The API is exposed there, but will always return without granting access to credentials (as WebView has no password manager).

We haven't yet implemented the bindings for iOS, but we intend to ship the API there as well.

# Demo link

https://w3c.github.io/webappsec/demos/credential-management/

# Debuggability

chrome://settings/passwords shows all the credentials available for an origin, as does the key icon in the address bar. We aren't doing anything beyond that with regard to DevTools.

# Interoperability and Compatibility Risk

This API is strictly additive; it gives developers the ability to imperatively interact with the browser's password manager, but does not provide fundamentally new capabilities. Developers will need to check that the API exists before poking at it, and will certainly need to handle the cases in which a user's browser doesn't support the API, or the user doesn't have credentials for an origin, or doesn't wish to provide them, etc. In each of these cases, we expect developers to continue to display a sign-in form of some sort, and we'll continue autofilling it.

Moreover, last year was punctuated with intense discussion in standards bodies, and the shape of the API we've ended up with is intentionally high-level, generic, and extensible in order to support the various use cases that other folks might want to pursue in this space. In particular, work in the newly-formed Web Authentication WG explicitly lists this spec as a dependency, and I've confirmed with that group's chair that the expectation is that the proposed APIs will use this framework. I think it's unlikely that we would launch this API and then fundamentally change it in ways that were backwards incompatible.

As for other vendors:

* Mozilla folks have been positive on the feature, but aren't committing resources to it at the moment (for example: "I absolutely think that we should implement this!", and "no current plans to do a focused implementation, but broadly a direction we're comfortable with"). Independent folks have started poking at an implementation, however (https://github.com/AxelNennker/firefox_credentials).

* Opera folks have reviewed several of the feature's Blink-side patches, and they see good value in the API's core functionality, but have concerns about the risks of automatic sign-in. They're happy to see it ship, however, as long as the implementation allows them to make their own UI decisions. I believe it does, as the UI implementation is fairly cleanly separated out into to //chrome with hooks from //content and //components.

* The Microsoft rep to the TAG seems interested, but it's unclear whether that interest extends to potential implementation.

* Apple has remained silent on the feature.

I've CC'd some of the specific folks I've been talking to, as an FYI.

# OWP launch tracking bug
https://crbug.com/576705

# Entry on the feature dashboard
https://www.chromestatus.com/feature/5026422640869376

Thanks!

-mike

[Anne van Kesteren]

On Thu, Feb 18, 2016 at 10:54 AM, Mike West <mk...@chromium.org> wrote:
> In particular,
> work in the newly-formed Web Authentication WG explicitly lists this spec as
> a dependency, and I've confirmed with that group's chair that the
> expectation is that the proposed APIs will use this framework. I think it's
> unlikely that we would launch this API and then fundamentally change it in
> ways that were backwards incompatible.

Given that FIDO wants registrable domain scope per
https://github.com/w3ctag/spec-reviews/issues/97#issuecomment-175766580
and you are proposing an origin scoped API, how would that work?

> * Mozilla folks have been positive on the feature, but aren't committing
> resources to it at the moment (for example: "I absolutely think that we
> should implement this!", and "no current plans to do a focused
> implementation, but broadly a direction we're comfortable with").

The only public feedback I can find from a Firefox engineer is
https://github.com/w3c/webappsec-credential-management/issues/2 which
is not positive.


--
https://annevankesteren.nl/

[Mike West]

Hi Anne!

On Thu, Feb 18, 2016 at 11:22 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Thu, Feb 18, 2016 at 10:54 AM, Mike West <mk...@chromium.org> wrote:
> In particular,
> work in the newly-formed Web Authentication WG explicitly lists this spec as
> a dependency, and I've confirmed with that group's chair that the
> expectation is that the proposed APIs will use this framework. I think it's
> unlikely that we would launch this API and then fundamentally change it in
> ways that were backwards incompatible.

Given that FIDO wants registrable domain scope per
https://github.com/w3ctag/spec-reviews/issues/97#issuecomment-175766580
and you are proposing an origin scoped API, how would that work?

The kinds of credentials I want to ship are indeed origin-scoped. I know that the FIDO group wants different scoping rules for their credentials. The folks in the Credentials CG and Web Payments WG have expressed similar desire. I'm not convinced that those are good things for the platform to support, but they would certainly be free to extend the framework provided by this API in various directions to make their functionality work the way they want to, as sketched out in https://w3c.github.io/webappsec-credential-management/#implementation-extension. That's why we ended up with the somewhat strange Credential -> OriginBoundCredential -> {Password,Federated}Credential structure in the objects, and allow each credential type to define their own filtering rules for responses to `get()`.

> * Mozilla folks have been positive on the feature, but aren't committing
> resources to it at the moment (for example: "I absolutely think that we
> should implement this!", and "no current plans to do a focused
> implementation, but broadly a direction we're comfortable with").

The only public feedback I can find from a Firefox engineer is
https://github.com/w3c/webappsec-credential-management/issues/2 which
is not positive.

I linked to two public pieces of feedback (from Jonas at https://bugzilla.mozilla.org/show_bug.cgi?id=1156047#c3 and Richard at https://www.w3.org/2011/webappsec/minutes/2015-10-28-webappsec-minutes.html#item06 (where you and I also discussed the issue you quoted), both CC'd), which I read as positive. Based on conversations with you about the Fetch integration, I also got a positive feel.

I think I addressed the feedback in https://github.com/w3c/webappsec-credential-management/issues/2#issuecomment-146502158 and in our conversation at TPAC. I'm happy to revisit, of course, if y'all consider it an open question: basically, I think a model like rAc is probably a good match for an API meant to assist with account creation. I think it's a poor match for sign-in.

Thanks!

-mike

[Anne van Kesteren]

On Thu, Feb 18, 2016 at 11:44 AM, Mike West <mk...@google.com> wrote:
> The kinds of credentials I want to ship are indeed origin-scoped.

I noticed you landed a commit that changes this. At least as far as
sharing the credentials goes. So now you have OriginBoundCredential
objects that go cross-origin.


--
https://annevankesteren.nl/

[Anne van Kesteren]

On Mon, Feb 22, 2016 at 1:15 PM, Mike West <mk...@google.com> wrote:
> [...]

I think the object should have a different name from OriginBound if it
can actually go to a registrable domain in serialized form.


--
https://annevankesteren.nl/

[Mike West]

On Mon, Feb 22, 2016 at 1:30 PM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Mon, Feb 22, 2016 at 1:15 PM, Mike West <mk...@google.com> wrote:
> [...]

I think the object should have a different name from OriginBound if it
can actually go to a registrable domain in serialized form.

*shrug* From the API's perspective, the `Credential` object is origin-bound. I don't think the name is out of line with that. If you feel strongly about it, I'm happy to rename, but I don't think it's necessary.

-mike

[Anne van Kesteren]

On Mon, Feb 22, 2016 at 1:50 PM, Mike West <mk...@google.com> wrote:
> *shrug* From the API's perspective, the `Credential` object is origin-bound.
> I don't think the name is out of line with that. If you feel strongly about
> it, I'm happy to rename, but I don't think it's necessary.

I feel somewhat strong, since you pass this object to fetch(), so it's
the network API for this too and there it's suddenly registrable
domain bound. That is rather unexpected.


--
https://annevankesteren.nl/

[Mike West]

Renamed to "SiteBoundCredential" in https://github.com/w3c/webappsec-credential-management/commit/9004441387ee371c35dcad1d0eec2438fd2e2e17.

-mike

[Alex Russell]

LGTM. Excited to see this moving forward. 

Is there a plan for extending the sorts of credentials that are used in this spec over time?

[Mike West]

On Tue, Feb 23, 2016 at 4:07 AM, 'Alex Russell' via blink-dev <blin...@chromium.org> wrote:

Is there a plan for extending the sorts of credentials that are used in this spec over time?

I expect extensions to be spun up in their own specifications, as briefly sketched out at https://w3c.github.io/webappsec-credential-management/#implementation-extension. Depending on their scope, WebAppSec might or might not be the right home for them... WebAuth, for instance, will probably not end up as part of the credentials spec itself, but as a stand-alone document.

-mike

[Dimitri Glazkov]

LGTM.

:DG<

[Rick Byers]

LGTM2 to ship

On Tue, Feb 23, 2016 at 11:43 AM, Dimitri Glazkov <dgla...@chromium.org> wrote:

LGTM.

:DG<

[Jochen Eisinger]

lgtm3

[Alex Russell]

Outstanding. Thanks!

[Joe Medley]

Mike,

Was this really behind a flag in M48?

Joe

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

Outstanding. Thanks!

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.

[Mike West]

It's been behind a flag in one form or another for ~20 months. ~M48 is the first time it's been pretty close to the API we've settled on in the spec.

-mike

-mike

[Joe Medley]

I ask because we usually have an announced 'behind a flag' period. Because it was ~M48, this never got announced.

Joe Medley | Technical Writer, Chrome DevRel | jme...@google.com | 816-678-7195

If an API's not documented it doesn't exist.

[Matthew Noorenberghe]

On Thursday, February 18, 2016 at 2:44:57 AM UTC-8, Mike West wrote:

On Thu, Feb 18, 2016 at 11:22 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Thu, Feb 18, 2016 at 10:54 AM, Mike West <mk...@chromium.org> wrote:

> * Mozilla folks have been positive on the feature, but aren't committing
> resources to it at the moment (for example: "I absolutely think that we
> should implement this!", and "no current plans to do a focused
> implementation, but broadly a direction we're comfortable with").

The only public feedback I can find from a Firefox engineer is
https://github.com/w3c/webappsec-credential-management/issues/2 which
is not positive.

I think I addressed the feedback in https://github.com/w3c/webappsec-credential-management/issues/2#issuecomment-146502158 and in our conversation at TPAC. I'm happy to revisit, of course, if y'all consider it an open question: basically, I think a model like rAc is probably a good match for an API meant to assist with account creation. I think it's a poor match for sign-in.

 
I still disagree that it's a poor match for sign-in. I replied to the issue now after stumbling across this thread. It seems like an oversight that this spec doesn't help with password creation (e.g. generating strong passwords that meets site requirements). This is one of the things that the UA can help with via requestAutocomplete. I also think rAc is much simpler and is already more widely implemented in browsers so I would prefer to pursue extensions to that over starting with a new API.

I see in the FIDO Web API spec that it "may" extend this spec but it would be nice to have more clarity on that so we don't end up with another separate API for credentials.

Matthew Noorenberghe

[Ben Kelly]

FWIW, I've proposed some changes here:

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

I don't have a strong opinion on whether to implement this or not, but if we do I'd like us to go something more that route.

Thanks.

Ben

[Mike West]

Hello, blink-dev@! A brief update to the "implementation risks" section of this intent:

After some conversation with Matt, et al., I think it's fair to say that some folks at Mozilla aren't excited about the API: the core of the conversation can be found at https://github.com/w3c/webappsec-credential-management/issues/13. Based on that discussion, we've made a number of improvements to the spec's integration with Fetch and existing forms, but remain discordant on `get()`.

I would like to ship this first pass at the API despite this disagreement, as I believe it solves some real problems today and paves the road for solving more in the future. We're talking to some developers today who are excited about improving their sign-in flow, and I'd like to begin providing them with tools to do so.

Based on Mozilla's feedback, there is a greater risk than I'd hoped that this will be available in Blink and nowhere else. That's hardly a certainty, given that Axel is actively working on a Firefox implementation, but let's assume that worst case to evaluate the risk:

1. The API is not a fundamental shift in sign-in mechanism, but aims to sit on top of an existing sign-in form. Importantly, websites cannot come to rely entirely on this API, as users are in control of their credentials and may refuse any `get()` request, or may simply not use a password manager in the first place. There is very little risk that sites will be broken in browsers that do not implement the API (including Chrome, if we ship it and then decide to remove it in the future)

2. The API is small (two methods hanging off of a new `navigator` attribute, along with ~2 new object types). There is very little risk that shipping this API would lock us down in a way that either encouraged divergent implementations, or prevented us from trying new approaches in the future. In particular, shipping this API will exclude the possibility of shipping Matt's suggestions for a higher-level, declarative `requestAutocomplete`-based sign-in flow if developer feedback suggests that that would be a better fit.

So, dear API owners: this is a riskier launch than I was hoping it would be, but I don't believe that the risk is either fundamental or exclusionary. Weighing these risks against the benefits I noted in the I2S, along with the fact that iOS and Android are shipping similar APIs (SecRequestSharedWebCredential and CredentialsApi.request, respectively), I'd suggest launching and iterating. What say ye?

-mike

-mike

[Rick Byers]

Thank you for putting the effort into this discussion Mike.  Working hard to maximize agreement between vendors on API design is critical to our goal of improving the web for it's users.

If I understand the fundamental issue correctly it's that by exposing a lower level JavaScript-based primitive, there's risk that sites using this new API may not work as well on browsers without this API.  Where if we instead designed a declarative extension to forms, more graceful fallback could occur naturally.  This is a fundamental tension inherent in all the work we're doing to expose primitives, and I don't think the forward compatibility argument is strong enough to justify abandoning our goal of providing developers with more extensibility via primitives.  If

Also, this basic approach of a low-level declarative API has been the plan since before the FPWD a year ago, right?  Personally I think we'd need a pretty strong justification to reset the fundamental design of this API at such a late stage in it's development.

So still LGTM to ship.

[Rick Byers]

On Thu, Mar 31, 2016 at 9:38 AM, Rick Byers <rby...@chromium.org> wrote:

Thank you for putting the effort into this discussion Mike.  Working hard to maximize agreement between vendors on API design is critical to our goal of improving the web for it's users.

If I understand the fundamental issue correctly it's that by exposing a lower level JavaScript-based primitive, there's risk that sites using this new API may not work as well on browsers without this API.  Where if we instead designed a declarative extension to forms, more graceful fallback could occur naturally.  This is a fundamental tension inherent in all the work we're doing to expose primitives, and I don't think the forward compatibility argument is strong enough to justify abandoning our goal of providing developers with more extensibility via primitives.  If

Also, this basic approach of a low-level declarative API has been the plan since before the FPWD a year ago, right?  Personally I think we'd need a pretty strong justification to reset the fundamental design of this API at such a late stage in it's development.

So still LGTM to ship.

On Thu, Mar 31, 2016 at 4:22 AM, Mike West <mk...@google.com> wrote:

Hello, blink-dev@! A brief update to the "implementation risks" section of this intent:

After some conversation with Matt, et al., I think it's fair to say that some folks at Mozilla aren't excited about the API: the core of the conversation can be found at https://github.com/w3c/webappsec-credential-management/issues/13. Based on that discussion, we've made a number of improvements to the spec's integration with Fetch and existing forms, but remain discordant on `get()`.

I would like to ship this first pass at the API despite this disagreement, as I believe it solves some real problems today and paves the road for solving more in the future. We're talking to some developers today who are excited about improving their sign-in flow, and I'd like to begin providing them with tools to do so.

Based on Mozilla's feedback, there is a greater risk than I'd hoped that this will be available in Blink and nowhere else. That's hardly a certainty, given that Axel is actively working on a Firefox implementation, but let's assume that worst case to evaluate the risk:

1. The API is not a fundamental shift in sign-in mechanism, but aims to sit on top of an existing sign-in form. Importantly, websites cannot come to rely entirely on this API, as users are in control of their credentials and may refuse any `get()` request, or may simply not use a password manager in the first place. There is very little risk that sites will be broken in browsers that do not implement the API (including Chrome, if we ship it and then decide to remove it in the future)

2. The API is small (two methods hanging off of a new `navigator` attribute, along with ~2 new object types). There is very little risk that shipping this API would lock us down in a way that either encouraged divergent implementations, or prevented us from trying new approaches in the future. In particular, shipping this API will exclude the possibility of shipping Matt's suggestions for a higher-level, declarative `requestAutocomplete`-based sign-in flow if developer feedback suggests that that would be a better fit.

By the way, I assume the above is a typo and should read: "shipping this API will NOT exclude the possibility ..."

[Mike West]

On Thu, Mar 31, 2016 at 3:39 PM, Rick Byers <rby...@chromium.org> wrote: 

2. The API is small (two methods hanging off of a new `navigator` attribute, along with ~2 new object types). There is very little risk that shipping this API would lock us down in a way that either encouraged divergent implementations, or prevented us from trying new approaches in the future. In particular, shipping this API will exclude the possibility of shipping Matt's suggestions for a higher-level, declarative `requestAutocomplete`-based sign-in flow if developer feedback suggests that that would be a better fit.

By the way, I assume the above is a typo and should read: "shipping this API will NOT exclude the possibility ..."

Correct. Sorry for that confusion. Shipping `navigator.credentials.get()` will _not_ exclude the possibility of extending `form.requestAutocomplete()` in the future.

-mike

 

[Anne van Kesteren]

On Thu, Mar 31, 2016 at 3:38 PM, Rick Byers <rby...@chromium.org> wrote:
> If I understand the fundamental issue correctly it's that by exposing a
> lower level JavaScript-based primitive, there's risk that sites using this
> new API may not work as well on browsers without this API.

I think the concern stated by Martin Thompson and others from Mozilla
has been mostly around whether it's worthwhile doing this kind of API.
That is, they're not convinced of the merit.


--
https://annevankesteren.nl/

[Mike West]

Hrm. I think Matt and I agree that a storage mechanism is valuable (see the bottom of https://github.com/w3c/webappsec-credential-management/issues/13#issuecomment-200484349, for instance). I think Matt and I also agree that some form of imperative API would be valuable, but we disagree about its shape and layering.

-mike

[Jochen Eisinger]

Thanks for the write-up. I think another point is that similar APIs already exist on Android and iOS, so moving forward with this sgtm.

Still lgtm2

[Dimitri Glazkov]

Anne, would you be able to mediate resolving this disagreement? You have great experience with doing this. That is, if Mike's reply convinces you that this is more of a layering/bikeshape type of thing.

:DG<

[Anne van Kesteren]

On Thu, Mar 31, 2016 at 6:11 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:
> Anne, would you be able to mediate resolving this disagreement? You have
> great experience with doing this. That is, if Mike's reply convinces you
> that this is more of a layering/bikeshape type of thing.

I tried to get it sorted out, but everyone at Mozilla seems lukewarm
about the whole thing.

I think you'll have more success if you go down the <form> route and
expand on that. I recall Apple also suggesting extensions there to
make password generation and such a possibility.

And then maybe once FIDO is more mature an API can be revisited if
that indeed makes sense as a shared thing.


--
https://annevankesteren.nl/

[Dimitri Glazkov]

On Thu, Mar 31, 2016 at 9:47 AM, Anne van Kesteren <ann...@annevk.nl> wrote:

On Thu, Mar 31, 2016 at 6:11 PM, Dimitri Glazkov <dgla...@chromium.org> wrote:
> Anne, would you be able to mediate resolving this disagreement? You have
> great experience with doing this. That is, if Mike's reply convinces you
> that this is more of a layering/bikeshape type of thing.

I tried to get it sorted out, but everyone at Mozilla seems lukewarm
about the whole thing.

Got it. Thank you for giving it a shot :)

 

I think you'll have more success if you go down the <form> route and
expand on that. I recall Apple also suggesting extensions there to
make password generation and such a possibility.

And then maybe once FIDO is more mature an API can be revisited if
that indeed makes sense as a shared thing.

Okay. Seems like the choice that we need to make is whether to 1) wait some more and hope the problem space heats up enough for other vendors to care or to 2) ship now and expect that we'll have to deprecate the contentious bits later.

Pursuing the non-imperative route seems at odds with the general experience we've collected over the last few years (extensible manifesto, etc.), though I agree it seems to be the path of least resistance.

Given the current Web developer interest, I am going to go ahead LGTM3, provided that Mike continues to work with other vendors on achieving interop in the future. 

:DG<