No subject

Thu Jan 11 23:01:28 UTC 2007

HTTP request [1].  Other identifier schemes could be resolved in a similar
manner if someone deployed such resolution infrastructure
(<socialsecuritynumber> - Lets hope not!). In any case, you
get back a descriptor document. 

To the extent that it's more complicated, it is something that's either an
implementation problem on the proxy side [2], or something the
inames community should address to make it easy for OpenID developers.  

Using HTTP as a resolution protocol and getting back an XML document with
some basic semantics about a service endpoint is what's new (this is what
XRI early on - YADIS is expansion of that concept with HTTP URLs) - I think
that's mostly the extent to which an OpenID RP developer should be saddled
w/r/t new identifiers.

For what its worth, we (the XRI & inames communities) are trying to bridge
this understanding/complexity "gap" - I've begun (was derailed for a while
by wiki hiccups) a busy developer's guide: 


[1] The one wrinkle is the concept of canonical IDs - but as Steve Churchill
said, the mechanics of discovering and confirming these IDs is something the
proxy resolver ( should be doing. 

[2] BTW, is based entirely on the OpenXRI codebase - you can run
your own proxy - nothing special about the instance except that its
well known and run as a bootstrapping mechanism by the same folks who run
the root registry.

> -----Original Message-----
> From: general-bounces at [mailto:general-bounces at] On
> Behalf Of Robert Yates
> Sent: Friday, February 09, 2007 6:01 AM
> To: Recordon, David
> Cc: general at
> Subject: Re: [OpenID] is openid 2.0 a lightweight identity system?
> On 2/9/07, Recordon, David <drecordon at> wrote:
> >
> > As you can see in the wild by OpenID 1.1 implementations taking
> advantage of
> > Yadis (XRDS) based discovery.
> >
> Just to be clear, I do believe that the introduction of Yadis adds
> real value.  My real concern is mandatory support for i-names in the
> core, this adds a LOT of complexity.  Could i-names support, instead,
> be done as an extension and the core modified so that alternative
> valid openid URI schemes can be defined later?
> I don't think a modification to the core spec. allowing for future
> alternative URI scheme definition would be that hard to do. Extensions
> defining alternative URI schemes simply need to define discovery rules
> and possibly some different verification steps. It could add real
> flexibility to the spec as it seems fairly limiting, in my mind, to
> restrict openid URI schemes to only http/https or xri.
> Rob
> _______________________________________________
> general mailing list
> general at

More information about the general mailing list