• XriCd02
• SynonymSemantics

Intro

This page describes a revised proposal for synonyms in XRI Resolution 2.0 Working Draft 11 ED04. It also includes comments from TC members at the end.

Status

• First version discussed on the 2007-08-16 XRI TC telecon.
• Slight revisions made after the telecon.
• Second version posted 2007—08-22 for the 2007-08-23 telecon.
• Third version posted 2007-08-23 after the telecon.
• Fourth version posted 2007-08-24 after a special telecon.
• Fifth version posted 2007-08-25 with one change (CanonicalEquivID)

Summary of the Proposal

1. For LocalID, CanonicalID, and Ref, revert to the rules in place since WD10 with only two tweak to CanonicalID.
2. For Canonical ID verification, revert from ED03 rules to ED02 rules, i.e. verification only works hierarchically (thus to verify, a CanonicalID must be issued by the parent authority for an XRD).
3. Replace Backref element with EquivID, MapToID, and MapFromID synonym elements.
4. Specify optional verification of these new elements.
5. Specify status codes for all forms of CanonicalID verification.

Motivations

• Maintain compatability with WD10 implementations.
• Reinforce that CanonicalID is intended to be a persistent global foreign key for a resource and thus should never change.
• Keep CanonicalID verification simple and fast.
• Do not change or overload Ref processing.
• Allow an authority to cleanly assert in an XRD that there are synonymous absolute identifiers for a target resource without overloading this assertion with resolution semantics.
• Allow an authority to cleanly assert synonyms expressing equivalence with and without replacement semantics.
• Allow consuming applications to easily determine which identifier in an XRD it should use for a resource.

Existing Synonym Elements

The proposal is to keep all of these consistent with WD10.

LocalID

No changes at all.

CanonicalID

The only changes from WD10 would be to specify:

• Cardinality of zero-or-one (so a CanonicalID is truly canonical).
• Strongly recommend that CanonicalID, once assigned, SHOULD NEVER change and SHOULD ALWAYS be present in the XRD.

• Verification would use the revised rules at XriCd02/CanonicalIdVerification.

With these changes, we are clarifying that a CanonicalID (if assigned) is the persistent global foreign key that can ALWAYS be used for that resource in the context of that authority. That means the final subsegment of a CanonicalID SHOULD be assigned by the parent authority (i.e., the CanonicalID is hierachical), because this is the only way in which it is verifiable.

Ref

No functional changes. The only change would be in the text to clarify that a Ref implies ONLY "resolution equivalence" and not "identification equivalence", i.e., that the XRD to which the Ref resolves MAY be used in addition to the current XRD. No other semantics are implied (because those other semantics can now be expressed using EquivID, MapToID, and/or MapFromID elements).

New Synonym Elements

Under this proposal, the Backref element would be replaced by two new synonym elements intended specifically to express identification equivalence relationships.

EquivID

Purpose: assert that there is another absolute identifier (besides the CanonicalID) that identifies the same target resource but SHOULD NOT be used to replace the CanonicalID of the target resource. EquivID carries no semantics of canonicality, no semantics of reference processing, and no semantics of replacement. It can apply to either hierarchical or polyarchical identifiers. It is a pure peer-to-peer "also known as" assertion.

• Cardinality zero-or-more.
• MUST be an absolute identifier.
• MAY be a persistent identifier.
• MAY be verified (see below).

CanonicalEquivID

Purpose: inform consuming applications that they should map the CanonicalID of the current XRD to another absolute identifier.

• Cardinality zero-or-one (same as CanonicalID).
• Must be absolute.
• The value SHOULD be verified by reference to another EquivID if needed (see below).

CanonicalEquivID informs (but does not require) consuming applications that they SHOULD map whatever current identifiers they have for a resource to the value of the CanonicalEquivID element.

CanonicalEquivID does not have resolution semantics. Those are controlled entirely by Ref elements.

Verification

EquivID

Not verified by XRI resolvers. A consuming application can verify an EquivID element by requesting resolution of the value of the element and confirming that the response XRD contains a EquivID element that references either the QXRI or the CanonicalID of the current XRD.

CanonicalEquivID

MAY be verified using the cid=true parameter. If cid=true, and CanonicalEquivID is present, a resolver will verify the CanonicalEquivID element value as well as the CanonicalID element value only on the final XRD in the resolution chain. The verification test is to resolve the CanonicalEquivID value and verify that in the resulting XRD an EquivID element exists that references either the QXRI or the CanonicalID of the current XRD.

Status Codes

To distinguish failure of CanonicalID element verification with CanonicalEquivID element verification, the following list of status codes is proposed for an XRD when cid=true:

1. 120 CID_VERIFIED

2. 121 CID_VERIFICATION_FAILED

3. 122 CID_NOT_PRESENT

4. 130 CEID_VERIFIED (means CID was also verified)

5. 131 CEID_VERIFICATION_FAILED (means CID was verified, or else 121 would be returned)

This way a consuming application knows from the status code on the final XRD in the resolution chain precisely what identifier it should use to identify the target resource:

Note that if cid=true, on all intermediate XRDs in the resolution chain the resolver MUST verify the CanonicalID element (and provide either a 120 CID_VERIFIED, a 121 CID_VERIFICATION_FAILED, or a 122 CID_NOT_PRESENT) but MUST NOT verify the CanonicalEquivID element if present.

Use Case Analysis

How this Solves the Merge Problem

The merge problem is when two resources that start as independently identified resources (e.g., two independent businesses) merge into one resource (e.g., a business merger). With these synonym elements, the two businesses, one with XRD #1 containing CanonicalID #1 and one with XRD #2 containing CanonicalID #2, have four options, in escalating order of impact on consuming applications:

1. Make no changes to either XRD #1 or XRD #2 and, from the standpoint of XRI infrastructure, simply let the businesses continue to function independently. The merger is a legal one but not an operational one.
2. Use only a Ref from one XRD #1 to CanonicalID #2 (or in both directions) so the two XRDs share service endpoints, but do not assert identification equivalence.
3. Add an EquivID element to XRD #1 pointing to CanonicalID #2 and also add an EquivID in XRD #2 pointing to CanonicalID #1. This asserts that they now identify the same resource and MAY be mapped to each other, but it does not assert that either CanonicalID SHOULD be mapped to the other.
4. Add a CanonicalEquivID to XRD #1 pointing to the CanonicalID of XRD #2, and a EquivID to XRD #2 pointing to the CanonicalID of XRD #1. This asserts not only that both XRDs now identify the same resource, but also that applications SHOULD map CanonicalID #1 to CanonicalID #2.

How this Solves the OpenID Recycling Problem

The OpenID recycling problem is the reassignable-to-persistent identifier mapping use case that originally motivated this work. It is described in detail on the OpenID wiki at

The way this proposal solves this problem is as follows:

1. For each OpenID identifier that a user may want to assert (and many users are finding that they want to use more than one), the user can if desired register their preferred CanonicalEquivID in the corresponding XRDS document.
2. For this CanonicalEquivID to be verified, the user must also register a corresponding EquivID in the XRDS document for the identifier to which they are mapping.
3. Now the user has complete control. No matter what reassignable (recyclable) OpenID identifier they wish to login to a site with (either a URL or XRI), the user can control what persistent (non-recyclable) identifier it maps to. Furthermore, with cid=true, the consuming application (an OpenID relying party) can trust that the user controls the persistent identifier to which the reassignable identifier maps. The identifier the relying party should use is indicated via the status code returned in the final XRD as explained above.

Comments

Les Chasen's Thoughts

*** Draft ****

IMHO .... the real need that this proposal highlights is the need to be able to map one identifier to multiple other identifiers. There are two types of mappings that are deemed critical.

1. Also known as (AKA). This i think is covered by the equivId tag. Consuming applications can use this tag to map alternate identifiers that the current XRD is also known as. In other words it is a claim that "i am synonymous with these other identifiers".

2. The ability to mark an identifier as my preferred identifier. This is important so that an identifier description (XRD) can declare an identifier, to a consuming application, that is 'preferred'. The consuming application should treat this as a mapped identifier that has been verified, i.e. CID (id user logged in as) maps to 'preferred id'. The consuming application can then associate the user to the correct account when he logs in using his preferred id. The consuming application should *not* replace the CID used to log in with because that is the persistent identifier used to login in the first place and because CID is strongly regarded as persistent and immutable where as 'preferred identifier' by definition can change at will. I propose that we call this tag preferredId. (An alternative would be to add a preferred attribute to equivId ... this makes it harder to enforce 0-1 cardinality)

Note: If the consuming application has not created an account yet and would like to use the 'preferred identifier' as the persistent key (the CID) it should resolve the preferred identifier and authenticate based on authentication protocols of that identifier descriptor (XRD).

Wil Tan's Thoughts

** I know I'm not making sense below, will come back to work on it again. Consider this garbage…

There are a few use-cases presented:

• OpenID - allowing people to "redirect" identifiers
  • Presumably, the identifiers are controlled by the same real-world entity.
  • They may describe the same or different resource, but we do not and cannot enforce that. A user can map multiple identifiers as long as he/she has access to modifying the descriptors.
  • We used to be able to do it using Ref because it had synonymity semantics.

    • A contains no OpenID authentication service in its XRD but has a Ref to B

    • An OpenID RP will use the CID of B along with the OpenID authentication SEP in B.

    • B doesn't need to give permission to A for Refing to it, because essentially it is B that is logged in.

    • In a more restrictive case, an RP that does not wish to allow its users to "redirect" identifiers may choose to authenticate A's CID against B's OpenID SEP.

    • However, the reverse would open up a huge security vulnerability if the RP authenticates B's CID with A's OpenID SEP.

  • Now that Ref no longer has synonymity semantics, how do we allow users to "redirect" identifiers?

    • Well, we need to look at whether identifier redirection is appropriate in all circumstances

      • If it wasn't for the fact that B's OpenID SEP authenticated the user, would you really trust A to say that its CID is the same as that of B's?

      • It depends, if you do not store anything in A (not even the QXRI) then you're fine.

      • Or if all the functions in your system only ever maps identifiers to CID, but never the other way around, that's probably fine too.
• EquivID can be used to publish AKA, as Les has written above.

Drummond Reed's Thoughts

After the feedback on today's call and reading Les's and Wil's comments, I revised the main proposal above to:

1. Change the UseCID and AllowUseCID element names back MapToID and MapFromID to reflect the semantics Les suggests (i.e., that this is only mapping information and is not required to be interpreted as a directive to replace one identifier with another).

2. Removed the text saying the MapToID element should be interpreted as a permanent redirect.
3. Clarified that MapFromID verification is only performed on the final XRD in a resolution chain, which means that it can add at most one extra resolution call no matter how many XRDs are in a resolution chain.
4. Added OpenID Recycling to the Use Case Analysis so it was clear how this proposal cleanly solves the OpenID recycling problem that originally motivated much of this work.

What this boils down to, IMHO, is the following clean distinction between EquivID and MapToID/MapFromID:

• EquivID informs consuming applications that they MAY map two identifiers as equivalent, and establishes no precedence between them.

• MapToID/MapFromID informs consuming applications that they SHOULD map two identifiers as equivalent, and establishes the precedence between them.

I think this is all we need to do (and all we can do) because the ultimate behaviour of consuming applications is out of scope for the XRI resolution specification.

For these reasons I like the EquivID and MapToID/MapFromID proposal as it currently stands above. It:

• Solves all the use cases motivating XRD synonym semantics.
• Cleanly separates resolution control (Ref), equivalence assertion (EquivID), and mapping (MapToID/MapFromID) semantics.
• Provides a simple, fast way for resolvers to verify both QXRI-to-CanonicalID mappings and CanonicalID-to-MapToID mappings.
• Solves the OpenID recycleable-to-non-recycleable identifier mapping problem.

Markus Sabadello's Thoughts

For the record, I liked the earlier "polyarchical CanonicalID" / "GlobalID" proposal better than anything that came up since then.. In that proposal you would just have one canonical i-number for a resource/identity which you would put in all your XRDs, without so much need for additional equivalence/mapping elements.

I do not like the idea of introducing anything called "preferred ID", because that's what CanonicalID has always been described as. I am pretty sure in the earliest drafts I know of I read something like "Among all synonyms, the CanonicalID is the preferred identifier for a resource". With the current proposal as it stands on this page, the truth rather seems to be that the CanonicalID does not uniquely identify a resource (a person, company, ...) but rather an XRI authority. Which is why we have the new synonym elements EquivID and MapToID now.

I do not think either of these should explicitly instruct a consuming application to change its internal records.

I am trying to find out how consuming applications would handle all this. Ideally the application should look at all the synonym elements in order to find out if it already "knows" this resource. I think it would check identifiers in this order: MapToID, CanonicalID, LocalID, EquivID, QXRI.

Somehow I fear this will be complicated for applications to implement, but from a theoretical standpoint I'm fine with all this.

By the way, if we have both the EquivID and MapToID element, then maybe the priority attribute was a stupid idea (the motivation for that was that it could help to have just one of the additional elements).. But maybe it still makes sense. Don't know. Anyone read George Orwell? Some are more equal than others

One additional note.. I think if there were separate cid=true and mapcid=true (or usecid=true) resolution parameters, then there should also be an equivid=true. Either just one (cid=true) or three, but not two.

More Thoughts from Drummond (2007-08-25 7PM PT)

This morning I had an insight about how to make the proposal even simpler, both conceptually and functionally, by eliminating MapFromID and changing the name of MapToID to CanonicalEquivID. Now a CanonicalEquivID can be verified just by using an EquivID in the referenced XRD.

I like this best of all.