Proposal to split XRD Synonym element into AbsoluteXRI and RelativeXRI

["Drummond Reed" <drummond.reed@cordance.net>]

Per the minutes on agenda item #3 of last Friday's XRI TC telecon, this is a
summary of the proposal to split the current xrd:XRD/xrd:Synonym element
into two elements: xrd:XRD/xrd:AbsoluteXRI and xrd:XRD/xrd:RelativeXRI.

The motivation is that a number of TC members have identified use cases
where a client application, when resolving a QXRI, needs as an output not
just a service endpoint URI, but also at least one absolute XRI that can be
used as the "primary key" for accessing that service at that endpoint for
that target resource. An example is a single sign-on service, where an
authentication request needs to be made and the calling application wants to
ensure this request is for an XRI registered with the SSO service and not
for some other XRI synonym of which the SSO service is not aware.

A specific case is where an individual has multiple reassignable XRIs
("i-names") which all have a persistent XRI ("i-number") synonym, and it is
this persistent XRI that is registered at the SSO service. Thus the desired
behavior is for the individual to login using any of his/her i-names, yet
have the authentication request use the individual's persistent i-number.

So the application needs to resolve the i-name and in the final XRD obtain
not just the SSO service endpoint URI, but also the absolute XRI the
application should be using to access the SSO service. (Note that in rare
cases there may be more than one absolute XRI synonym to use for this
purpose, which application logic should be prepared to deal with.)

The current XRD Ref and Synonym elements do not fulfill this requirement for
the following reasons:

1) The Ref element, though required to be an absolute XRI, may not in fact
be a reference that can or should be followed. Example: an absolute i-number
(e.g., !!1001!1234.5678) issued by XRI authority for an account that's no
longer active but which the registrant still wants to be able to use as an
absolute XRI for accessing services for which this absolute XRI was
originally registered.

2) The Synonym element cannot be relied on to contain this value because it
may contain a relative XRI (for good reasons), and relying on the resolver
client to calculate the absolute XRI may not produce the same absolute XRI
that the XRD author intends to be used as the primary key for accessing
service endpoints.

Therefore the proposal is to split the current XRD Synonym element into two
elements: AbsoluteXRI and RelativeXRI. Both would be defined as synonymous
XRIs for the target resource, and both would have a cardinality of zero to
n. The only difference is that the value of the former must be absolute and
the value of the latter must be relative to the current authority (i.e., the
authority for the current XRD).

Any comments/questions/feedback, please post ASAP, otherwise this will be
incorporated into XRI Resolution 2.0 Working Draft 10 Editor's Draft 05.

=Drummond