W3C home > Mailing lists > Public > public-webappsec@w3.org > February 2016

Towards a minimum-viable credential management API.

From: Mike West <mkwst@google.com>
Date: Fri, 12 Feb 2016 12:31:55 +0100
Message-ID: <CAKXHy=e-mYF-xyOtn=P21QxitDqH+zjq0o7UChzbf3+EZdavJg@mail.gmail.com>
To: "public-webappsec@w3.org" <public-webappsec@w3.org>
Hello, folks!

So, there's this Credential Management API that is lying around. We've gone
back and forth on much of it over the last ~18 months
and I'd like to ship what I consider a minimum-viable subset of what we've
been talking about in Chrome to see if it actually solves the problems we
expect it to solve. To that end, I've sliced out the synthesis pieces
(including `registerAsProvider()`) that seem like they need substantially
more work in

Based on our experimentation in Chrome, I'm not at all confident in our
ability to accurately surface synthesized federated credentials for our
users based on the data we have at the moment. This leads to some exciting
situations where the user has actually logged into a site with Funky
Federation, but hasn't saved that credential locally. They have saved
Intersting Identity Provider, however, and since Exciting Example supports
both, we'll pop up a chooser that only contains the latter. This is fairly
clearly harmful, and until we have significantly better heuristics, it's
unlikely that we'd ship it. The kinds of credentials that we believe we
could reasonably ship support "sign-in" as opposed to "sign-up". The latter
turns out to be hard. :)

With that in mind, I'd appreciate folks taking another look at the spec, in
particular with an eye towards the work going on in the newly-formed web
authentication group. It would be lovely indeed if the generic framework
that we've created here can clearly support the use cases that group is
working towards.


Received on Friday, 12 February 2016 11:32:47 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:54:54 UTC