The basic questions is in XRI resolved XRDS documents is there always a CanonicalID element?
Short Answer:
Yes for XRI resolution you MUST ALWAYS have a CanonicalID element at the XRD level.
Long Answer:
I think there is confusion between the Canonical ID element assigned by the XRDs parent authority, and the LocalID in the Service end point that is under end user control.
Lets look at doing service selection on my iname =thread-safe
For those of you following along at home the query to the proxy resolver is:
http://beta.xri.net/=thread-safe?_x
The result returned is:
<?xml version="1.0" encoding="UTF-8"?> <XRD xmlns="xri://$xrd*($v*2.0)"> <Query>*thread-safe</Query> <Status code="100"/> <Expires>2008-02-21T16:33:03.000Z</Expires> <ProviderID>xri://=</ProviderID> <LocalID priority="10">!BF81.FD97.C81B.B4E5</LocalID> <CanonicalID priority="10">=!BF81.FD97.C81B.B4E5</CanonicalID> <Service priority="10"> <Type select="true">http://openid.net/signon/1.0</Type> <ProviderID>xri://!!1003!103</ProviderID> <URI append="none" priority="1">https://linksafe.ezibroker.net/server/</URI> </Service> </XRD>
This is XML and needs to be read as such.
The LocalID is the LocalID of the XRD not the LocalID of the openID service.
I would only have a localID in my SEP if I were doing openID delegation.
If I were do ing delegation the SEP would look like:
<Service priority="10">
<Type select="true">http://openid.net/signon/1.0
<ProviderID>xri://!!1003!103</Provider
<LocalID>https://ve7jtb.myopenid.com/<
<URI append="none" priority="1">https://www.myopenid.com/s
</Service>
The XML for LocalID in the sep is:
xrd:XRD/xrd:Service/xrd:LocalID
(See XRI 2.0 sec 4.2.4)
The value of xrd:XRD/xrd:LocalID is intended as a local synonym for the xrd:Query element.
Its a resolver thing ignore it.
My CanonicalID is =!BF81.FD97.C81B.B4E5.
This is irrespective of whether or not I have used delegation.
CID/CannonicalIDs MUST ALWAYS be persistent non-reassignable identifiers these are iNumbers in the form above. In an XRI the bang/exclamation mark is used for persistent identifiers.
If you were attempting to use regex rather than XMP SAX parsing you are looking for the LocalID afrer the <Service> not before it.
The CanonicalID element =!BF81.FD97.C81B.B4E5 becomes my clamed_ID.
(openID 2.0 sec 7.3.2.3)
You need to verify that CanonicalID however, you can do it in the RP by re-resolving the CanonicalID.
ie
http://beta.xri.net/=!BF81.FD97.C81B.B4
You would now use the SEP returnd by this query.
The preferred way to verify the CanonicalID in XRI 2.0 is by adding cid=true to the proxy resolver request.
This unfortunately is ignored at the moment by the xri.net proxy resolver as it is still at an older version of XRI.
The 2.0 resolver supporting CID validation will be available shortly.
The other question is what happens when two inames point to the same XRDS?
As it happens I have four iNames which are synonyms @wingaa*jbradley , =jbradley , =thread-safe and =ve7jtb (my ham call-sign).
Three of them are in the same authority and directly resolve to the same CID the @wingaa*jbradley is in a different XRI authority. It uses a XRD level ref to establish the synonym.
All 4 resolve to the same CanonicalID and that is the "Claimed Identifier" and is passed as the "openid.claimed_id" to the OP as this is an XRI and not a URL the OP must return the same value.
The value passed must match the value returned or you must re-resolve the "Claimed Identifier"
to make sure that the URI for the authority match.(this is vague in the spec if its not directed identity)
If the "Claimed Identifier" validates that is what becomes the primary key.
My contention is still that the correct thing to send as the openid.identity is the "OP-Local Identifier" if there is a xrd:XRD/xrd:Service/xrd:LocalID element, or if not then the QXRI otherwise known as the "User-Supplied Identifier". I don't recommend sending the CanonicalID in both elements.
Note that if you resolve @wingaa*jbradley without doing service selection you will not follow the ref and not find the openID service endpoint.
The query:
http://beta.xri.net/@wingaa*jbradley?_x
Returns: <?xml version="1.0" encoding="UTF-8"?> <XRD xmlns="xri://$xrd*($v*2.0)"> <Query>!BF81.FD97.C81B.B4E5</Query> <Status code="100"/> <Expires>2008-02-21T22:36:27.000Z</Expires> <ProviderID>xri://=</ProviderID> <LocalID priority="10">!BF81.FD97.C81B.B4E5</LocalID> <CanonicalID priority="10">=!BF81.FD97.C81B.B4E5</CanonicalID> <Service priority="10"> <Type select="true">http://openid.net/signon/1.0</Type> <ProviderID>xri://!!1003!103</ProviderID> <URI append="none" priority="1">https://linksafe.ezibroker.net/server/</URI> </Service> </XRD>
This results in following the ref and the correct service being selected.
=jbradley
Joseph Smarr has added openID 2.0 support to Plaxo with the help of Michael Krelen who has updated his libokkeke C++ library (http://kin.klever.net/)
Joseph's blog entry http://josephsmarr.com/2008/01/14/openi
ooTao contributed reference code testing and other resources over the last several months to help the project come together.
One of the many new and exciting openID 2.0 features is iName support. My =theread-safe iname now works, Community iNames like @ooTao*jbradley are also working.
A small number of us are now testing openID services with Plaxo as the provider.
I now have @plaxo*jbradley and jbradley.myplaxo.com as openID's the nice thing is that my Plaxo contact page with all of its microformated contact info.
I have to say that Plaxo is one of the most progressive companies in the Identity community with the help of Joseph.
We have ideas for building many exciting IIdentify related services together. I look forward to people getting to see them in the near future.
Test your iNames get a Plaxo account. Less especially you, no excuses any more.
=jbradley
Profile
![[info]](http://l-stat.livejournal.com/img/userinfo.gif)
thread_safe- John Bradley
