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

[Drummond Reed]

> 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