[OpenID] Interop (was: RE: Conformance and Interop...)

[Guido Sohne]

On 6/5/07, Josh Hoyt <josh at janrain.com> wrote:
> On 6/5/07, Guido Sohne <guido at sohne.net> wrote:
> > I'd rather not implement 2.0, it appears overwrought (design by
> > committee/special interest group). Here's a toast towards OpenID 1.x
> > continuing to evolve!
>
> What makes you feel that way about OpenID 2.0? It is hardly different
> from OpenID 1.1, and much better specified. I ask because I want

I agree it is much better specified. Perhaps to the point where one
missed the brevity of the 1.0 spec. That can't be a bad thing, except
for someone with a working 1.0 implementation ...

> OpenID 2.0 to be an improvement over OpenID 1.1, and I feel that it
> is. I'll do anything I can to do improve the protocol or its
> specification, but I can only do it if criticism is specific.

1) Kill XRI. Or stop using URLs as identifiers. If you decide on XRI
only, use openid:// as a prefix, maybe we should do this, in any way.
Maybe we should do a sane (no kitchen sink) variant of XRI, or maybe
better even, some clean set of conventions that can embed this into a
URL. What you want to do in XRI should probably have been better off
as conventions. Nice to have, good to follow, but not strictly
necessary. Flexible.

I don't like the schizophrenia from handling both. Suddenly there is
the hassle of reading and implementing more specs too. If we have to
make the extra effort, then we should go the whole way. That sounds
like a 2.0 ... but the bottom line is there appears to be a tough
decision to make and its better to do it now, not later. Or are all
implementations going to end up with two identifier regimes? How many
times to validate, parse etc a given identified?

The cop out in the spec is to say "This will remove the need for the
RPs to perform XRI Resolution locally."

So which is it? URLs or XRIs? Can't the XRI be an attribute on the URL
instead? Shouldn't we really be using XRIs instead of URLs? Why not do
a limited version of XRI, that fits neatly into the URL world, that
has some conventions defined to replace use of special characters in
XRI and prefix it with openid:// instead? Shouldn't the OP be
translating that into XRIs, URLs or whatever (by following the
convention?) so that those who want interop with those systems can
have it?

For now, I'm ignoring XRI, and that is what I mean by 'staying with 1.x' ...

2) Define how people should be using XRDS documents? What's the point
in providing a flexible solution that does nothing out of the box?
Surely, we can think of the simple common sense things that people
could need in these documents and define conventions that will help to
pick out what is interesting?

I think it is like how Google Base defines the common data types that
it thinks are needed and going to be able to be differentiated or
identified across different applications etc.

3) And after the pleasant experience of KV coding, now we suddenly
have to deal with some XML style parsing ? I didn't like that at all.
Yes, XML is standard, but at the same time it is awful. YAML is much
easier to read. JSON is practical and simple. I stopped reading the
2.0 spec and just completed the 1.x implementation instead. Why embed
all this extra weight?

4) Backporting nonces and 'use strict' (spec is written more carefully
to avoid gotcha etc) to 1.x as a clearer spec could be useful as well.

5) The 2.0 spec is long! Did I mention that? Maybe many of the MUSTs
should be in some unit testing library or interop conformance tool as
an Appendix or something, not part of the main spec? I find shorter
specs easier to digest. Maybe it's not just me.

6) Merge the SREG and YADIS/XRDS thingies into a simple new KV
protocol that is based on conventions and extensibility, and not based
on being expressed in a least common denominator approach, such as
with XRDS.

I first used OpenID for a very simple reason. I was really tired of
building login and user management systems for each web application
and I realized I could abstract that all away with a library call or
two ... I would like it to maintain that simplicity and practicality
rather than go the way of monstrosities like the liberty alliance or
passport stuff that emerge when one engineers for the complex corner
case, instead of for the sweet spot, the common case, to make it
hassle free and bullet proof, not to cater to all comers ...

-- G.

PS: I may have not thought all things through properly, please feel
free to correct me where I have made mistakes or where I haven't
considered other sides of the issues involved.