I have come across the openid4java message "ProviderID is not authoritative for the CanonicalID" a few times too. In fact, the method in question, Discovery.isProviderAuthoritative(), specifically mentions in a comment that it doesn't work with community i-names.<br>
<br>Now we could fix that method, but as Drummond points out, CanonicalID Verification is already built into XRI Resolution 2.0, so the whole Discovery.isProviderAuthoritative() method can go away.<br><br>All that openid4java has to do is check the "cid" attribute of the <Status> element of the final XRD.. It says either "verified" or "failed" or "absent".<br>
<br>Here's one example with a "good" CanonicalID, and one with a "bad" CanonicalID:<br><a href="http://alpha.xri.net/proxy/@free*earth*moon?_xrd_r=application/xrds+xml;sep=false" target="_blank">http://alpha.xri.net/proxy/@free*earth*moon?_xrd_r=application/xrds+xml;sep=false</a><br>
<a href="http://alpha.xri.net/proxy/@free*earth*badmoon?_xrd_r=application/xrds+xml;sep=false" target="_blank">http://alpha.xri.net/proxy/@free*earth*badmoon?_xrd_r=application/xrds+xml;sep=false</a><br><br>Markus<br><br>
<div class="gmail_quote">
On Wed, Mar 26, 2008 at 5:33 AM, Drummond Reed <<a href="mailto:drummond.reed@cordance.net" target="_blank">drummond.reed@cordance.net</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
<br>
> On 24-Mar-08, at 4:16 PM, Peter Williams wrote:<br>
><br>
> > At <a href="https://verify.sxip.com/email/auth/request" target="_blank">https://verify.sxip.com/email/auth/request</a> @blog*lockbox<br>
> > doesn't resolve.<br>
> ><br>
> > Can you move the site up to OpenID2 compliance?<br>
><br>
> On Tuesday, March 25, 2008 7:25 PM, Johnny Bufu wrote:<br>
><br>
> It actually is; the error that I see in the logs (which should be<br>
> better exposed in the interface) is "ProviderID is not authoritative<br>
> for the CanonicalID".<br>
><br>
> OpenID4Java performs this (quite important) verification step, while<br>
> the underlying openxri library and <a href="http://xri.net" target="_blank">xri.net</a> were not (at least the<br>
> last time I talked to the people in charge there).<br>
<br>
Good catch, Johnny. Peter, as you are probably aware, CanonicalID<br>
verification is a key XRI security feature. In section <a href="http://7.3.2.3" target="_blank">7.3.2.3</a>, OpenID 2.0<br>
specifies that:<br>
<br>
********<br>
When the Identifier is an XRI, the <xrd:XRD> element that contains the<br>
OpenID Authentication <xrd:Service> element MUST also contain a<br>
<CanonicalID> element. The content of this element MUST be used as the<br>
Claimed Identifier (see Section 11.5 (Identifying the end user)). This is a<br>
vital security consideration because a primary purpose of the <CanonicalID><br>
element is to assert a persistent identifier that will never be reassigned,<br>
thus preventing the possibility of an XRI being ("taken over") by a new<br>
registrant.<br>
<br>
The Relying Party MUST confirm that the provider of the XRD that contains<br>
the <CanonicalID> element is authoritative for that Canonical ID and that<br>
this XRDS document is authoritative for the OpenID Service Element. Relying<br>
Parties should either do this manually or ensure that their resolver does<br>
this.<br>
<br>
When using XRI resolution, the Canonical ID MUST be used as the Claimed<br>
Identifier. For an XRI to be a valid Identifier, both the <ProviderID> and<br>
<CanonicalID> MUST be present in the discovered XRDS document.<br>
*********<br>
<br>
I quote this passage in detail for three reasons:<br>
<br>
1) To explain why OpenID4Java was rejecting Peters XRDS. I don't know the<br>
specifics of that XRDS, but until very recently (see below), CanonicalID<br>
verification required the CanonicalID value of the first XRD in an XRI<br>
resolution chain to be a child of the ProviderID value. So for example, if<br>
the CanonicalID is xri://=!F83.62B1.44F.2813, the ProviderID must be<br>
xri://=. This prevents spoofing of CanonicalIDs.<br>
<br>
2) Second, to flag for the OpenID 2.0 editors that ***the coupling between<br>
ProviderID and CanonicalID changed in XRI Resolution 2.0 Committee Draft<br>
03*** (the latest draft that is just completing its second public review at<br>
OASIS - <a href="http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html" target="_blank">http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html</a>).<br>
Now the CanonicalID in each XRD is now required to be ***a child of the<br>
CanonicalID in the previous XRD***, all the way up the resolution chain back<br>
to the community root XRD. The feedback from implementers was that this: a)<br>
was easier to understand, b) simplified the verification code, and c)<br>
decoupled the ProviderID element from CanonicalID verification, which freed<br>
ProviderID to be used in a wider variety of XRDS security models.<br>
<br>
I don't know what the best/fastest method to update the OpenID 2.0 spec is<br>
about this. There's been some talk of an errata or point release -- any news<br>
about that?<br>
<br>
3) Third, to provide some notice that, as Johnny mentioned, up until now<br>
CanonicalID verification has *not* been performed automatically by XRI<br>
resolver libraries or proxy resolvers like <a href="http://xri.net" target="_blank">xri.net</a>, so OpenID libraries like<br>
OpenID4Java to handle it. However in the next two months that will change.<br>
Both the open source OpenXRI (Java) and Barx (Ruby) XRI resolvers have added<br>
XRI Resolution 2.0-compliant CanonicalID verification, and it is going into<br>
testing at the <a href="http://beta.xri.net" target="_blank">beta.xri.net</a> proxy resolver within the next 2-3 weeks. The<br>
goal is to have CanonicalID verification "built in" to XRI infrastructure<br>
(so it no longer has to be built into OpenID libraries) by completion of the<br>
XRI 2.0 vote at OASIS in early June.<br>
<br>
Those of us working with XRI infrastructure will post more details as this<br>
progresses, but I wanted to provide a general heads-up.<br>
<br>
=Drummond<br>
<br>
_______________________________________________<br>
general mailing list<br>
<a href="mailto:general@openid.net" target="_blank">general@openid.net</a><br>
<a href="http://openid.net/mailman/listinfo/general" target="_blank">http://openid.net/mailman/listinfo/general</a><br>
</blockquote></div><br>