• XriThree
• SuperSimpleSepSelection

About

This page describes the "Super Simple SEP Selection" (SSSS) proposal for XRI Resolution 3.0.

Motivations

SEP selection is widely recognized as the most complex and difficult part of XRI Resolution 2.0. We have been challenged (specifically by Eugene Kim, who co-wrote a Perl XRI resolver implementation) to make it dramatically simpler in XRI Resolution 3.0.

This proposal is an answer to that challenge. It has three main elements.

#1: Remove the Path Element & Fold Its Function into Type

The first step is to remove the xrd:XRD/xrd:Service/xrd:Path element completely. Essentially its functionality can be replaced by the Type element. In other words, if an XRI includes a path, for SEP selection purposes an XRI proxy resolver will interpret that path as a Type parameter.

Since Path matching and Type matching were always very similar, this gives up very little functionality.

#2: Eliminate the "match" and "select" Attributes Completely

Once Path is eliminated, the need for "match" and "select" attributes drops significantly. If these attributes and all the logic associated with them are removed completely, 90% of the complexity of SEP selection would disappear.

The new SEP selection logic would be based entirely on Type and/or Mediatype. The proposed SEP selection rules are:

1. If a Type match is requested, match on Type.
   1. If a Mediatype match is ALSO supplied, narrow the Type selection based on a match on Mediatype.
2. If a Type match is not requested but a Mediatype match is requested, match on Mediatype.
3. If neither Type nor Mediatype is requested, do a default match (see below).

#3: Add a Boolean "default" Attribute

This is a super-simple solution to the problem of how to select a default SEP when there are no SEP selection parameters present (the old "triple null" use case, which originally gave birth to the "match" and "select" attributes).

If no SEP selection parameters were present, the SEP selection rules are:

1. Select the SEP where the Service element has the attribute default="true".
2. If no SEP has this attribute, error out.
3. If more than one SEP has this attribute, error out.

Use Case Analysis

Please use this space to list any XRI Resolution 2.0 use cases that can NOT be met by this SSSS proposal.

Contact service selection:

=nat/+contact will select the first Service in the example below.

<XRD version="3.0" xmlns="http://xri.net/$xrd*($v*3.0)" sigalg="RSA-SHA256" sig="fjwoIJfldksjeowjfd....">
    <LocalID>!e18c.3b56.889d.850b</LocalID>
    <CanonicalID>=!E18C.3B56.889D.850B</CanonicalID>
    <CertURI>http://mycertservice.com/mycert.pem</CertURI>
    <Service>
        <ProviderID>!!1003!103</ProviderID>
        <Type>+contact</Type>
        <URI priority="1">https://contact.gabunomi.net/contact?to=%3Dnat</URI>
    </Service>
    <Service priority="10">
        <ProviderID>!!1003!103</ProviderID>
        <Type>http://openid.net/signon/1.0</Type>
        <URI append="none" priority="1">https://linksafe.ezibroker.net/server/</URI>
    </Service>
</XRD>

ProviderID is the CanonicalID of the service provider. The service provider publishes its XRD signed by XriThree/SimpleSign . So, XRI user agent MUST mae sure that the CanonicalID in the XRD of the provider and this ProviderID MUST match and can be found in the X.509 whose location is in the provider's XRD. Of course, it MUST check the signature of the XRD as well. Do we want "append" in URI? Maybe not. I suppose the service URL should always be fed with the entire path to process. (Of course, it could simply through it away.) I guess we need priority field though.