Re: The Credential Management API - Another approach

On 2015-04-23 10:08, Mike West wrote:
> Hi, Anders!

Hi Mike :-)

>
> On Thu, Apr 23, 2015 at 9:39 AM, Anders Rundgren <anders.rundgren.net@gmail.com <mailto:anders.rundgren.net@gmail.com>> wrote:
>
>     Regardless if the Credential Management API matches the envisioned needs of the Credentials CG or not, I doubt that this is the right path for the industry.
>
>
> It's not clear what concrete changes, if any, you're suggesting.

I will try to make this clearer below.


>
>     There are several problems with the approach taken and one of the more obvious is that "Apps" like Skype, Facebook, e-banking, etc. also rely on credentials which makes the idea building such functionality into the browser layer somewhat futile; credentials rather belong to the platform.
>
>
> The claim that "Native apps rely on credentials" doesn't seem to have much impact, given that "Web origins rely on credentials" is also true. Given that a browser interacts with a wide variety of the latter, it's not clear to me that layering an API on top of the already-built functionality at the browser layer is anything but helpful.

What I'm claiming is that there is no strong technical need for storing and managing credentials in different places, regardless if they are bound to origins, applications, or whatever.  The very same credential may be used both by an "App" and the Web.


>
>     Due to the fact above, the unknown buy-in from other browser vendors and last but not least the inherent inflexibility of the browser infrastructure with respect to updates, I'm convinced that credential management would be more suited as applications based on "The Extended Web":
>     https://lists.w3.org/Archives/Public/public-webappsec/2015Apr/0220.html
>
>
> "Unknown buy-in from other browser vendors" doesn't seem like something we'd solve by moving the spec to the CG you suggest.

Right, I'm rather suggesting browser vendors taking a fresh look on how to introduce new functionality of the kind that the Credential Management API represents.  The FIDO stuff (which is yet another credentialing system), seem to fit here as well.

"The Extended Web" CG wouldn't deal with applications/subsystems at all; it is more akin to XHR, an enabler for other stuff.


> Nor do I understand the claim of "inherent inflexibility" of browsers; isn't this spec an existence proof of the opposite?

The inflexibility of browsers with respect to timely and concerted updates is a huge problem for *user-community*.  For Google who effectively can introduce whatever they want and then push it out via Android and Chrome things may appear quite different.

Let's say (for the sake of the discussion...), that the Credential Management API wouldn't match the needs of the Credentials CG, what could they possibly do then?  AFAICT, pretty much nothing.  Well, in practice people are turning to "Apps" because these don't have this inflexibility problem.

Apparently the Microsoft folks wasn't able to hook into the Credential Management API although they said they would, which proves my thesis that there's no such thing as "the" credential management system.  These systems need to evolve "organically" which make them poor candidates for traditional standardization.  The suggested "workaround" offers a more agile path for such developments which in the end should prove beneficial even for Google.

Cheers,
Anders


> --
> Mike West <mkwst@google.com <mailto:mkwst@google.com>>, @mikewest
>
> Google Germany GmbH, Dienerstrasse 12, 80331 München, Germany, Registergericht und -nummer: Hamburg, HRB 86891, Sitz der Gesellschaft: Hamburg, Geschäftsführer: Graham Law, Christine Elizabeth Flores
> (Sorry; I'm legally required to add this exciting detail to emails. Bleh.)

Received on Thursday, 23 April 2015 09:34:59 UTC