RE: [xri] EquivID and CanonicalEquivID need to be dropped from spec.

Steve,

Thanks, this is productive feedback. When the other editors discussed the issue of whether a separate synonym element (besides EquivID) was necessary for the exclusive purpose of authorizing CanonicalEquivID assertions, our conclusion was that it was not. This was not because we were trying to overload EquivID semantics, rather it was simply because this usage seemed consistent with EquivID semantics. As you noted, section 5.2.3 states, “a polyarchical global synonym is asserted using the xrd:EquivID element”. The definition of a polyarchical global synonym is an absolute identifier that identifies the same target resource as the query identifier.

So our logic went like this:

1) Say that in XRD A, resolved from query identifier A, identifier authority A assigns an EquivID value of B, issued by identifier authority B, which is an assertion by identifier authority A that identifier A and identifier B identify the same target resource.

2) If (1) is true, that means that in XRD B, resolved from query identifier B, identifier authority B now has three choices:

a) Do not publish any synonym element that references A.

b) Publish an EquivID element that references A.

c) Publish a CanonicalEquivID element that references A.

Option (b) is not automatically verified by an XRI resolver but can be easily verified by a consuming application using the same backpointer mechanism as specified in the following text from section 13.5:

EquivID Verification

Although XRI resolvers do not automatically perform EquivID synonym verification, a consuming application can easily request it using the following steps:

1. First request resolution for the original query identifier with cid=true.

2. From the final XRD in the resolution chain, select the EquivID for which verification is desired.

3. Request resolution of the EquivID identifier.

4. From the final XRD in this second resolution chain, determine if there is either: a) a xrd:XRD/xrd:EquivID element, or b) a xrd:XRD/xrd:CanonicalEquivID element whose value matches the verified CanonicalID of the original query identifier. If there is a match, the EquivID is verified; otherwise it is not verified.

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

Our reasoning was that since identifier authority B already had the choice of whether or not to assert an EquivID of A – and have it verified by this backpointer process – then identifier authority B should also have the choice of whether to make that assertion an CanonicalEquivID.

You are correct that if we used different a synonym element explicitly for CanonicalEquivID verification – let’s say we called it “AllowCanonicalEquivID” – then identifier authority A would be able to assert an EquivID to identifier B without allowing identifier authority B to assert a CanonicalEquivID to identifier B.

However none of us could come up with a use case for needing to do that. Our reasoning was that if identifier authority A and identifier authority B already agreed that identifier A and identifier B represent the same resource (i.e., each publishes at least an EquivID to the other), then either identifier authority should have the ability to promote that assertion to a CanonicalEquivID, because all a CanonicalEquivID assertion does is say, “Besides the CanonicalID I am publishing here in this XRD, you (the consuming application) should use this CanonicalEquivID to identify the target resource.” If the XRI resolver can verify the backpointer, everything should be fine.

So I would propose that, instead of adding a new AllowCanonicalEquivID element, we solve the problem you raise by “tightening down” the semantics of EquivID in section 5.2.3. Following is the text I suggest for this section (the new part is the bold paragraph beginning “An EquivID element…”):

5.2.3 EquivID

In XRD documents, a polyarchical global synonym is asserted using the xrd:EquivID element. This may be used to assert either of two forms of polyarchical global synonyms:

· Other hierachical global synonyms for the target resource besides the CanonicalID. The final local synonym in all such identifiers MUST be assigned by the parent authority and SHOULD match a LocalID asserted in the same XRD.

· Polyarchical global synonyms for the target resource that are NOT assigned by the parent authority.

An EquivID MUST be an absolute identifier. For durability of the reference, it is RECOMMENDED to use a persistent identifier such as a persistent XRI [XRISyntax] or a URN [RFC2141].

An EquivID element is OPTIONAL in an XRD with one exception: it is REQUIRED to verify a CanonicalEquivID element asserted by a different parent authority in a different XRD. This verification may be performed automatically by XRI resolvers during resolution using the cid=true parameter as specified in section 13.2. IMPORTANT SECURITY CONSIDERATION: A parent authority MUST NOT assert an EquivID element if it will resolve to a different authority whom the parent authority does NOT authorize to use a CanonicalEquivID assertion.

If an EquivID is used to establish equivalence with an identifer issued by a different identifier authority in a different trust domain, it SHOULD be verified. This function is not performed automatically by XRI resolvers during resolution but may be easily performed by consuming applications using one additional XRI resolution call. See section 13.5. A parent authority SHOULD NOT permit a child authority to edit the EquivID value in an XRD without authenticating the child authority and verifying that the child authority is authorized to use this EquivID value.

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

I think that will solve the potential problem and further clarify the EquivID semantics without requiring us to add a sixth synonym element.

What do you think?

=Drummond

From: Steven Churchill [mailto:steven.churchill@xdi.org]
Sent: Monday, September 10, 2007 8:03 PM
To: xri@lists.oasis-open.org
Subject: RE: [xri] EquivID and CanonicalEquivID need to be dropped from spec.

Drummond,

I’ve extracted the text below from WD11 ED04 regarding EquivID. I don’t see anywhere any mention that this element is intended to “allow” authority B to use the CanonicalID of authority A – i.e., that this element is the backpointer construct for CanonicalEquivID.

If your intention is to allow this element to have “other semantics” (besides the “allow use CID” i.e, CanonicalEquivID backpointer semantics) then I will tell you again that you cannot overload semantics in this fashion. The resolver has no way to determine which semantics to apply.

Consider this basic security vulnerability. Authority A decides it wants to use EquivID to refer to some XRI resolvable identifier. It has some “other semantics” in mind for this pointer—that is, semantics other than the CanonicalEquivID backpointer semantics. Now say the EquivID references authority B. Authority B can now specify CanonicalEquivID back to authority A and thus trick the Resolver into verifying that authority A has allowed authority B to use its CID.

~ Steve

5.2.3 EquivID

In XRD documents, a polyarchical global synonym is asserted using the xrd:EquivID element. This may be used to assert:

· Polyarchical global synonyms for the target resource that are NOT assigned by the parent authority.

An EquivID MUST be an absolute identifier. For durability of the reference, it is RECOMMENDED to use a persistent identifier such as a persistent XRI [XRISyntax] or a URN [RFC2141].

If an EquivID will be used to establish equivalence of identity across trust domains, it SHOULD be verified. This function is not performed automatically by XRI resolvers during resolution but may be easily performed by consuming applications using one additional XRI resolution call. See section 13.5. A parent authority SHOULD NOT permit a child authority to edit the EquivID value in an XRD without authenticating the child authority and verifying that the child authority is authorized to use this EquivID value.

xri message

EquivID Verification

5.2.3 EquivID

5.2.3 EquivID