Re: Coming back to CREDENTIAL.

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

Received on Friday, 21 August 2015 17:12:06 UTC