Thu Jan 11 23:01:28 UTC 2007
HTTP request . Other identifier schemes could be resolved in a similar
manner if someone deployed such resolution infrastructure
(http://ssn.net/<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 xri.net proxy side , 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:
 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 (xri.net) should be doing.
 BTW, xri.net is based entirely on the OpenXRI codebase - you can run
your own proxy - nothing special about the xri.net 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 openid.net [mailto:general-bounces at openid.net] On
> Behalf Of Robert Yates
> Sent: Friday, February 09, 2007 6:01 AM
> To: Recordon, David
> Cc: general at openid.net
> Subject: Re: [OpenID] is openid 2.0 a lightweight identity system?
> On 2/9/07, Recordon, David <drecordon at verisign.com> 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.
> general mailing list
> general at openid.net
More information about the general