incubator-heraldry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From andy.d...@ootao.com
Subject thought on OpenID Authentication 2.0 - Draft 08
Date Thu, 10 Aug 2006 14:38:19 GMT
I'm just browsing the spec but this jumped out at me so I though I would 
share it:

At the end of section 4.2.3.2.1.  XRI and the CanonicalID Element, it 
says: 

"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 
together.
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
http://xri.net/=andy.dale

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

   http://www.ezibroker.net/partners.html

***************************************************************************

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message