| EquivID allows for XRD to express synonymity between identifiers.
It is similar to rel me and needs to be verified to see if there is an equivalent back-pointer.
Perhaps the element name should be changed to reflect the parallel.
If I had two openIDs each with a separate XRD, CID and perhaps security profile could use the the EquivID element to allow social graph discovery of my other identities and services. From the spec below:
5.2.2 EquivID
In an XRD, any synonym for the current fully-qualified query identifier except a CanonicalID or a CanonicalEquivID (see below) is asserted using the xrd:EquivID element. Unlike a LocalID, an EquivID is NOT REQUIRED to be issued 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 except in two cases:
1. When it is REQUIRED as a backpointer to verify another EquivID element in a different XRD as specified in section 14.2.
2. When it is REQUIRED as a backpointer to verify a CanonicalEquivID element as specified in section 14.3.3.
EquivID dosn't affect the CanonicalID.
There is another element CanonicalEquivID this allows you to assert a CanonicalID that lives under a different authority. Say for some reason I have a XRD at MyOpenID and some openID that resolves to it, but for stability sake I want to use my Google CID. I could add a CanonicalEquivID to my MyopenID XRD and a EquivID back-pointer to my Google XRD.
We had a number of openID use cases that could potentially have taken advantage of this but OpenID 2.0 chose not to take advantage of the CID element. I don't know of this being used by anyone in the wild at the moment.
The relevant part of the spec follows:
5.2.4 CanonicalEquivID
The purpose of the xrd:CanonicalEquivID element is to assert a canonical synonym for the fully-qualified query identifier for which the parent authority MAY NOT be authoritative. A CanonicalEquivID MUST meet all the requirements of an EquivID plus the following:
1. In order for the value of the xrd:CanonicalEquivID element to be verified: a) the XRD in which it appears MUST include a CanonicalID that can be verified as specified in section 14.2, and b) the XRD to which it resolves MUST meet the rules specified in section 14.3.3. In particular, those rules require that the CanonicalID of that XRD match the asserted CanonicalEquivID.
2. For the same reasons as with a CanonicalID, it is STRONGLY RECOMMENDED to use a persistent identifier such as a persistent XRI [XRISyntax] or a URN [RFC2141].
3. Although the CanonicalEquivID associated with a CanonicalID MAY change over time, at any one point in time, every XRD from the same parent authority that asserts the same CanonicalID value MUST assert the same CanonicalEquivID value if the XRD includes a CanonicalEquivID element.
As a best practice, a parent authority SHOULD publish a CanonicalEquivID in an XRD if consuming applications SHOULD be able to persistently identify the target resource using this identifier in other contexts. Also, a CanonicalEquivID value SHOULD change very infrequently, if at all.
Regards =jbradley On 10-Dec-08, at 10:44 PM, Brian Eaton wrote:
On Wed, Dec 10, 2008 at 9:29 AM, John Bradley < jbradley@mac.com> wrote: I think the idea is that an XRD can only have one cannonical_id there may be
multiple URI that resolve to the XRD but only one can be cannonical.
I don't know what we are going to do with the EquivID element, In XRI 2.0
that would be how you would specify non-cannonical synonyms for the XRD.
What are the use cases for EquivID?
|