>
> 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".
>>>
>>
Completely agree with Dave's point. It is really important.
I saw this first hand with how OpenID failed. A major player had
implemented one version and did not want to advance the protocol to address
the issues. We had thought, "hey, let's get this out, get feedback, and
then figure out how to address the issues" -- OpenID stalled and Facebook
Connect took over.
(Sorry to join the conversation late -- but I am recently back deep in the
identity game)
-- Dick