incubator-heraldry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Drummond Reed" <>
Subject RE: thought on OpenID Authentication 2.0 - Draft 08
Date Thu, 10 Aug 2006 19:31:35 GMT
+1 to Andy's suggestion. For those new to XRDS documents (the XML format
used by Yadis service discovery), the design includes explicit support for
identifier synonyms in the form of the LocalID, CanonicalID, and Ref
elements. Of these, CanonicalID is specifically for solving the problems of:
a) identifier persistence, and b) many-to-one synonym mapping.

The CanonicalID element provides a simple, standardized mechanism for
mapping the identifier used to retreive the XRDS document -- whether an XRI
or an URL -- to the identifier intended by the issuing authority to be used
as the persistent key for referencing the identified resource. Note that the
CanonicalID value is not required to be a persistent XRI (i-number) -- it
can be any XRI or IRI or URI or URL -- but it is strongly recommended that
it be a persistent and not a reassignable identifier.

Kevin Turner of JanRain has pointed out, in an extensive thread over the
past few days with myself and several of the XRI Resolution spec editors,
that to prevent spoofing of a CanonicalID, there are simple CanonicalID
trust verification rules (separate from XRDS trusted resolution rules) that
relying parties should follow when processing XRDS documents. We intend to
add these rules to Working Draft 11 (the current spec is Working Draft 10, 

Net net: having uniform support for synonym-to-CanonicalID mapping
throughout the OpenID platform is, IMHO, a very good thing, and something
important to get right now, early in the game, because future "higher stack"
applications like reputation systems that need persistent identification can
build on this solid foundation. Also, this is a key feature that Boeing and
other Network Application Consortium (NAC) members who are part of the Core
Identifier Workgroup (which also includes Open Group and DMTF) want from
XRIs and XRI resolution (it's something they can't get from DNS-based naming
today), and would have a lot to do with their adopting OpenID.

=Drummond ( 

-----Original Message-----
From: [] 
Sent: Thursday, August 10, 2006 7:38 AM
Subject: thought on OpenID Authentication 2.0 - Draft 08

I'm just browsing the spec but this jumped out at me so I though I would 
share it:

At the end of section  XRI and the CanonicalID Element, it 

"When using URL-based identifiers, the CanonicalID element SHOULD be 
ignored. "

It strikes me that i-name and url identifier mechanisms can be brought 
closer together here. Or maybe my ignorance of OpenID is showing... but...

If I'm reading it right; 'delegating authentication' (section 4.2.1) is 
analogous with XRI 'refs' as a mechanism to delegate, and ultimately 
associate (many urls can delegate to the same place) authorities. In both 
cases, as you say in section 4.2.2, we need to end up with an idp 
endpoint, a claimed ID and a delegated ID.  In the XRI case I think you 
can map the claimed ID to the i-name entered and the canonicalID 
represents the delegated ID, the result is the same if there is delegation 
or not. 

The spec for the url based identifiers could also call for the CanonicalID 
element of the XRDS to be completed; CanonicalID MUST resolve to the same 
XRDS (this is the same requirement in with i-name CanonicalIDs). If this 
was the case I _think_ we get 2 benefits:

1) The mechanisms for processing xri and uri in the clients get closer 
2) We add a level of abstraction in the url based scheme that could 
ultimately be very useful. for all the reasons abstractions become useful. 

Just a thought.

Wish I could be with you all today. see you this evening.

Andy Dale
ooTao, Inc.

Phone: 877-213-7935
Fax: 877-213-7935

i-name: =Andy.Dale

If you don't have an i-name yet use this link to visit one of our partners 
and buy one:


View raw message