Re: Coming back to CREDENTIAL.

As it turns out, it's a bad idea to start a thread before going on
vacation. :)

I'd like to pull back a bit and try to tease out the concrete things that
need to be done to ship a minimum viable API that solves the broad problems
I noted in
https://lists.w3.org/Archives/Public/public-webappsec/2015Jul/0201.html. In
this thread, I see some convergence on the following topics:

1. I see very little debate about password management use cases. Could we
agree that the API as defined (perhaps modulo naming) is a reasonable first
stab at solving that particular problem? Coincidentally, This is the piece
I'm most interested in shipping quickly.

2. I see agreement that the current `get()` API is robust enough to support
extension in another WG with (something like) an IdentityCredential object
which could "assert certain properties and values about an identity".

3. I didn't see any discussion about future protocols like FIDO, so I'll
simply assume that everyone agrees that the current model is extensible
enough. :)

Is that a fair summary?

There's less convergence on Federations. I see concern from Adrian and Dave
about the baby step proposed for federated credentials. In particular, the
suggestion is that the currently defined step would lock in "super
providers"'s dominance, and that we could fix that by simply tweaking the
API to focus on protocols rather than origins.

To this point:

1. Does anyone else care? :) Specifically, I'd like to get some feedback
from folks who might at some point implement the API. CCing people from
Opera, Microsoft, Mozilla, and Apple.

2. I sincerely doubt that I can find resource inside Google to implement a
reasonable UI on top of a variety of protocols in anything like the near
future. That worries me, because the "NASCAR" picker is something that I'd
like to be able to deal with in the short term, and it seems like the
current proposal does that simply, without requiring changes for either the
RP or IDP.

3. Do you have a proposal for discovery? That is, how do I know what
protocols a particular origin supports? Do all the protocols you care about
support something like `
https://accounts.google.com/.well-known/openid-configuration`? Would we
need to request X files from a server every time we save a password? (Note:
I'm a bit concerned about proposals that require the IDP to do some work,
as it doesn't appear that there's significant incentive for the IDP to do
so.)

-mike

--
Mike West <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.)

On Fri, Aug 21, 2015 at 7:11 PM, Dave Longley <dlongley@digitalbazaar.com>
wrote:

> On 08/21/2015 03:25 AM, Adrian Hope-Bailie wrote:
>
>> Dave, you are conflating support for super-provider login with support
>> for existing open protocols.
>>
>> I am advocating for support of existing open protocols, not a system
>> that allows super-providers to continue running their own proprietary
>> federation protocols.
>>
>
> I understand what you are advocating. Both at a high-level and the API
> change you've requested. I'm trying to make sure we take note that a "baby
> steps" approach has dangers -- and this isn't a message that is strictly
> for you, it's for the list in general.
>
> I'm saying that how we go about creating the first step or two of a login
> standard can have negative effects on the success of the subsequent steps.
>
> If we're going to take a long approach and build out a whole federated
> login standard that supports existing open protocols and has a mechanism
> for easily experimenting with new ones, that's great. If, to get there, we
> take "baby steps" that involve effectively supporting "all the existing
> providers really need today", then we may end up making it more difficult
> to actually ever get the other steps into the standard.
>
> I don't think it's that hard to imagine creating a "baby step" where we
> just synthesize credentials for existing providers. Then, sites just place
> the providers that people are likely to use in a list when they request
> credentials. Then, boom! It works for the super providers and the user
> experience is great. Do we really need to do anything else?
>
> You may say "Of course!" (and you have). But a company that is behind both
> a popular browser and a popular super provider may have a different
> position. Now the politics of getting a better standard done have been made
> more complicated.
>
> It *doesn't matter* if the goal is supporting open protocols, if the
> chosen steps to get there throw tar on the road or stop progress entirely.
> This is the danger of "just making incremental improvements to the status
> quo". We must reject certain "baby steps".
>
>
>> We have the same goals; not allowing this API to entrench the status quo
>> of super-providers leveraging their positions as providers of other
>> services to capture the market for identity. I also think we have the
>> same motivations; protecting the privacy and private data of users by
>> affording them other options from IdPs who do not make their money out
>> of harvesting personal information.
>>
>> My approach to this is to push that this API is open and supports open
>> protocols so that any IdP who wishes to implement these protocols get's
>> an equal chance of being used as the IdP at a RP site as any of the
>> super-providers.
>>
>
> +1
>
>
>> I recognize your concern that if is this is done in steps that future
>> integration of new privacy-enhancing protocols may never happen. I think
>> you have two options in resolving this: 1) try to ensure that the
>> protocol support is flexible enough to accommodate future protocols OR
>> 2) advocate that support for federation is not a part of the API at all
>> until more privacy enhancing protocols are standardised.
>>
>
> +1
>
>
>> To be clear, what I am asking for is a simple change to the existing API
>> that favours indexing federation options by protocol as opposed to
>> provider.
>>
>
> I understand. Your change is simple at the API level, but it's unclear how
> complex it is at the implementation level. Some might argue that it could
> considerably push out a delivery date on the first implementations of this
> API. I'd argue that it's worth it for the reasons listed above.
>
>
>> I.e. As an RP site I should be asking the browser "Does this user have
>> federated credentials that can be used under the following protocols?"
>> not "Does this user have federated credentials issued by the following
>> providers?"
>>
>
> +1
>
>
>
> --
> Dave Longley
> CTO
> Digital Bazaar, Inc.
> http://digitalbazaar.com
>