[OpenID] Exchange could be a strategic error -- if done now rather than later...
dick at sxip.com
Mon Jan 15 22:29:16 UTC 2007
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
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
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.
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
More information about the general