- From: Mike West <mkwst@google.com>
- Date: Fri, 12 Feb 2016 12:31:55 +0100
- To: "public-webappsec@w3.org" <public-webappsec@w3.org>
- Message-ID: <CAKXHy=e-mYF-xyOtn=P21QxitDqH+zjq0o7UChzbf3+EZdavJg@mail.gmail.com>
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 <https://github.com/mikewest/credentialmanagement/commit/a448ca13a6172d373896f01f700f240795ea0a99>, 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 https://github.com/w3c/webappsec-credential-management/commit/7c5160f2fb02b1f2ea57be9dcdab5676b322f9cc . 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. Thanks! -mike
Received on Friday, 12 February 2016 11:32:47 UTC