[OpenID] Exchange could be a strategic error -- if done now rather than later...

[Dick Hardt]

Hi Bob

I hear and agree with your point on keeping OpenID from getting  
overly complex. That was one of the reasons for keeping the 2.0 spec  
focused on authentication and being OpenID Authentication 2.0 and  
having Attribute Exchange be a separate spec. Even with that, it has  
taken quite a while to get OpenID Authentication 2.0 done (real-soon- 
now I hope!)

Having an extension mechanism allows many people with ideas to create  
new specs, similar to how Perl blossomed when 5.0 introduced the idea  
of modules and then CPAN was created. Everyone was not trying to cram  
their functionality into core, and the market could decide what was  
useful and what was not.

So I think having separate specs and having a discovery mechanism to  
learn the capabilities of an OP keep the core from getting too heavy,  
and allow "a thousand flower to bloom" allowing innovation to happen.

With respect to Attribute Exchange itself, the Simple Registration  
spec was created in direct response to the requirements by many sites  
that they wanted to get basic registration data. While OpenID is  
convenient for the user, sites are really motivated by increasing the  
conversion rate and data quality on their registration pages, hence  
Attribute Exchange makes OpenID much more interesting to many, many  
more sites.

I agree that if significant time is spent disagreeing about how to do  
Attribute Exchange, then that will hamper adoption of OpenID, but I  
believe that will because there will not be agreement on a critical  
function.

Do you have any feedback on the Attribute Exchange specification?  
 From threads on the ID Gang list, it would seem you are supportive  
of the URL based attribute schema approach.

-- Dick

On 15-Jan-07, at 2:08 PM, Bob Wyman wrote:

> I know this will sound like heresy... However, I would like to say  
> that I'm very concerned that OpenID may get more complex than is  
> good for it before it is widely accepted. The initial  
> implementations of OpenID (LiveJournal, etc.) have done one thing  
> -- support login to multiple sites with a single identity -- and  
> done it reasonably well. Thus, as all identity systems must, OpenID  
> has started with means to establish and assert numerical identity  
> ( i.e. the property that distinguishes one entity from all others  
> and permits "counting."). In providing portable numerical identity,  
> OpenID has accomplished a great deal and provides something (like  
> SSO) that will be valued by many users.
>
> However, we've already seen that bringing in XRI and i-names (which  
> is much concerned with qualitative, not numerical, identity) has  
> caused some confusion and complexity that is hard to justify given  
> the precarious degree of market acceptance at this time. Pushing  
> ahead to support exchange of qualitative attributes as a core  
> feature of OpenID is likely to cause even more confusion as well as  
> expose the inevitable unintended attack points. Just as OpenID is  
> somewhat sullied by debate over aspects of i-names, we'll find that  
> the basic "identity" portion of OpenID is weakened by debates over  
> attribute exchange and other capabilities that should properly  
> layer on the simple base. Debate over "higher layers" may weaken  
> acceptance of the lower layers.
>
> I suggest (although I'm not sure I have much hope that the  
> suggestion will be taken up) that the "OpenID Community" should do  
> its best to resist the temptation to add new capabilities to what  
> is already there until after there is substantial acceptance of  
> what is there now. We've waited too long to get a decent identity  
> system in place and I'm sure we're all frustrated and anxious to  
> deploy as much technology as we can as fast as we can. But, the  
> reality is that going slow, one step at a time, is probably more  
> likely to be the path to success. Others have tried -- and failed  
> -- to deliver "complete" solutions to the identity problem in the  
> past. Let's not follow that well trod path.
>
> I think we should be putting 100% of our efforts into talking every  
> significant online property to accept OpenID for "login identity"  
> and on working out solutions to the various phishing, spoofing,  
> etc. issues. The goal should be to reduce, as much as possible,  
> objections to adopting the base capabilities so that we can have a  
> solid, widely deployed base on which to build other capabilities.  
> Once we get to the point where the base is broadly known to the  
> general user (even your grandmother), that is the time to push  
> ahead with more stuff. Let's build on a solid foundation... Let's  
> not move too much faster than the market.
>
> bob wyman
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general