[OpenID] Verifying CanonicalIDs (was RE: Weighing In on TechCrunch's "Is OpenID BeingExploited...)

[Markus Sabadello]

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.

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.

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".

Here's one example with a "good" CanonicalID, and one with a "bad"
CanonicalID:
http://alpha.xri.net/proxy/@free*earth*moon?_xrd_r=application/xrds+xml;sep=false
http://alpha.xri.net/proxy/@free*earth*badmoon?_xrd_r=application/xrds+xml;sep=false

Markus

On Wed, Mar 26, 2008 at 5:33 AM, Drummond Reed <drummond.reed at cordance.net>
wrote:

>
>
> > On 24-Mar-08, at 4:16 PM, Peter Williams wrote:
> >
> > > At https://verify.sxip.com/email/auth/request  @blog*lockbox
> > > doesn't resolve.
> > >
> > > Can you move the site up to OpenID2 compliance?
> >
> > On Tuesday, March 25, 2008 7:25 PM, Johnny Bufu wrote:
> >
> > It actually is; the error that I see in the logs (which should be
> > better exposed in the interface) is "ProviderID is not authoritative
> > for the CanonicalID".
> >
> > OpenID4Java performs this (quite important) verification step, while
> > the underlying openxri library and xri.net were not (at least the
> > last time I talked to the people in charge there).
>
> Good catch, Johnny. Peter, as you are probably aware, CanonicalID
> verification is a key XRI security feature. In section 7.3.2.3, OpenID 2.0
> specifies that:
>
> ********
> When the Identifier is an XRI, the <xrd:XRD>  element that contains the
> OpenID Authentication <xrd:Service> element MUST also contain a
> <CanonicalID> element. The content of this element MUST be used as the
> Claimed Identifier (see Section 11.5 (Identifying the end user)). This is
> a
> vital security consideration because a primary purpose of the
> <CanonicalID>
> element is to assert a persistent identifier that will never be
> reassigned,
> thus preventing the possibility of an XRI being ("taken over") by a new
> registrant.
>
> The Relying Party MUST confirm that the provider of the XRD that contains
> the <CanonicalID> element is authoritative for that Canonical ID and that
> this XRDS document is authoritative for the OpenID Service Element.
> Relying
> Parties should either do this manually or ensure that their resolver does
> this.
>
> When using XRI resolution, the Canonical ID MUST be used as the Claimed
> Identifier. For an XRI to be a valid Identifier, both the <ProviderID> and
> <CanonicalID> MUST be present in the discovered XRDS document.
> *********
>
> I quote this passage in detail for three reasons:
>
> 1) To explain why OpenID4Java was rejecting Peters XRDS. I don't know the
> specifics of that XRDS, but until very recently (see below), CanonicalID
> verification required the CanonicalID value of the first XRD in an XRI
> resolution chain to be a child of the ProviderID value. So for example, if
> the CanonicalID is xri://=!F83.62B1.44F.2813, the ProviderID must be
> xri://=. This prevents spoofing of CanonicalIDs.
>
> 2) Second, to flag for the OpenID 2.0 editors that ***the coupling between
> ProviderID and CanonicalID changed in XRI Resolution 2.0 Committee Draft
> 03*** (the latest draft that is just completing its second public review
> at
> OASIS - http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html
> ).
> Now the CanonicalID in each XRD is now required to be ***a child of the
> CanonicalID in the previous XRD***, all the way up the resolution chain
> back
> to the community root XRD. The feedback from implementers was that this:
> a)
> was easier to understand, b) simplified the verification code, and c)
> decoupled the ProviderID element from CanonicalID verification, which
> freed
> ProviderID to be used in a wider variety of XRDS security models.
>
> I don't know what the best/fastest method to update the OpenID 2.0 spec is
> about this. There's been some talk of an errata or point release -- any
> news
> about that?
>
> 3) Third, to provide some notice that, as Johnny mentioned, up until now
> CanonicalID verification has *not* been performed automatically by XRI
> resolver libraries or proxy resolvers like xri.net, so OpenID libraries
> like
> OpenID4Java to handle it. However in the next two months that will change.
> Both the open source OpenXRI (Java) and Barx (Ruby) XRI resolvers have
> added
> XRI Resolution 2.0-compliant CanonicalID verification, and it is going
> into
> testing at the beta.xri.net proxy resolver within the next 2-3 weeks. The
> goal is to have CanonicalID verification "built in" to XRI infrastructure
> (so it no longer has to be built into OpenID libraries) by completion of
> the
> XRI 2.0 vote at OASIS in early June.
>
> Those of us working with XRI infrastructure will post more details as this
> progresses, but I wanted to provide a general heads-up.
>
> =Drummond
>
> _______________________________________________
> general mailing list
> general at openid.net
> http://openid.net/mailman/listinfo/general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20080326/1eefb7b5/attachment-0002.htm>