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

Tue Jan 16 17:58:41 UTC 2007

This conversation is very interesting to me and very important.

I keep going back, personally, to the notion of salience -- and doing
a gut check on a lot of the extra stuff going into OpenID2. I agree
with Bob that OpenID ought be known as the "simple authentication
protocol". The stuff "enabled by", "layered on" or "compatible with"
is gravy so long as we get the fundamentals right and implemented in
the wild.

To Dick's point about PERL, note that we're talking about PERL
*Five*... Thus it took a number of generations to get where we are.
Firefox inherits a similarly lengthy genealogy -- where it took 10
years to figure out what parts weren't core-necessary -- and had to
reincarnate itself before it found popular community adoption and the
construction of various add-ons (previously "extensions") and themes.
Drupal, again, demonstrates a different model, breaking backwards
compatilibility with every major release and yet still having an array
of extended functionality, lastly WordPress, which offers a strong
core "engine" around which you can build any number of services,
plugins, themes and the like. I would be remiss not to mention Rails,
too, since perhaps it represents a closer analogy to OpenID, since
it's something that you use to build *other* things, as opposed to
being something you install, run and extend.

Anyway, my point on this is that, from a branding and "how do we talk
about", there's a lot of well known behavior in the wild already. We
just need to pick the example that's closest to us.

But, perhaps more importantly, we also should not get ahead of
ourselves and promote the idea of building on a solid core before we
know what functionality people require in real world scenarios (in
order for them to adopt OpenID). If we do not go through a proper
gestation cycle, we could end up alienating developers and potential
adopters by not given them something robust and stable to build on
(this is what happened at Flock and why I resisted offering an add-ons
site -- our internal APIs weren't stable enough and so we constantly
broke addons to the annoyance of our small-but-growing community).

So, this is a little scattered now, but we do need to focus, know
where OpenID and OpenID non-essentials begin and end, how to message
to end users of OpenID what level of service to expect and, for
implementors, make it clear to them what OpenID end users will expect
of them.

Chris

On 1/15/07, Dick Hardt <dick at sxip.com> wrote:
>
> On 15-Jan-07, at 10:55 PM, Bob Wyman wrote:
>
> > On 1/16/07, Johannes Ernst <jernst+openid.net at netmesh.us> wrote:
> > > What about we communicate that "two-tier structure" with respect to
> > > OpenID branding ... more clearly?
> >
> > +1, Yes. Differentiating between the core and the myriad of layered
> > capabilities would be make it vastly simpler to clearly communicate
> > what OpenID is all about. We should be very careful to make sure
> > that the "core" is as light, simple, secure, and as easy to
> > implement as possible. Fortunately, it seems to be pretty close to
> > that today.
>
> This what was done with Perl 5. There was the standard distribution
> that included very popular modules, and then CPAN for innovation to
> flourish. Of course deciding what was in the standard distribution
> was somewhat political. :-)
>
> >
> > > the foundation of everything OpenID -- Yadis -- was
> > > created for the specific purpose to let everybody
> > > plug in whatever services they like to.
> >
> > Yes, of course. To my way of thinking, there are two essential
> > things that OpenID provides:
> > A method for providing site-independent, distributed numerical
> > identity
> > A framework for building a wide variety of layered capabilities
> > I believe it would be best, when we speak of OpenID, to focus on
> > just these two things. All else should be spoken of as "layered
> > on", "enabled by" or "compatible with" OpenID. Thus, we should NOT
> > have "OpenId Attribute Exchange" rather, we should have "OpenID
> > Layered Attribute Exchange" or "Attribute Exchange enabled by OpenID".
>
> There are numerous use cases where the RP does not want to
> authenticate the user, but wants to get Attributes. Their reason for
> using OpenID is to get information about  the user. This is why the
> openid.identity and openid.claimed_id are optional in OpenID
> Authentication. Most of the OpenID Authentication spec is discovery
> and moving a message. The actual request and response of the the
> identifier is simple. Similarly, Attribute Exchange is a simple
> extension to OpenID Authentication.
>
> >
> > Keep the core of OpenID simple and clean. Otherwise, it will be too
> > hard to talk about this stuff. If this stuff gets too complicated
> > we may have good technology, but we'll lose the marketing war.
> > Let's not let this become like WS* which could have been very
> > simple, yet became comically complicated before anyone even had a
> > chance to begin implementing it.
>
> Bob, just curious, have you looked at Attribute Exchange? OpenID AX
> is 35K of HTML with lots of formatting tags, and you can read it in a
> few minutes.
>
> 	http://openid.net/specs/openid-attribute-exchange-1_0-04.html
>
> We have implemented the draft in the Java libraries we have at
>
> 	http://code.sxip.com/openid4java/
>
>
>
>

-- 
Chris Messina
Citizen Provocateur &
  Open Source Ambassador-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412 225-1051
Skype: factoryjoe
This email is:   [ ] bloggable    [X] ask first   [ ] private