Following the unofficial telecon of the XRI TC at:

Date: Tuesday, 10 February 2009 USA Time: 8:00AM - 9:00AM Pacific Time (16:00-17:00 UTC)

ATTENDING

John Bradley Markus Sabadello Drummond Reed Bob Morgan Eran Hammer-Lahav

1) ENTITY SPACE

John reported on a conversation with Steve Churchill about the XRD entity space. They discussed whether the proposed new <Link> element had the same description semantics as the former <Service> element, and also whether what was "service endpoint selection" in XRI Resolution 2.0 would still be the same basic process.

Eran said yes, the only difference was that you first select based on the <Rel> element, then you narrow it based on either <ResourceType> or <MediaType> or both. So essentially there is one more way to filter a "service" (now called a "link").

John is satisfied that there is still a clear function that maps an identifier to an XRD. The first half of that function is the XRD retreival protocol (HRDD). The second half will be link selection (what was service selection in XRI Resolution 2.0).

John and Steve also discussed how an URI could be the start of a XRI resolution chain.

We also discussed how multiple URIs can point to the same XRD. This is important for trust relationships. Different applications can have different requirements for trust. There are three "scopes" of such trust requirements, which essentially boil down to trusting (from narrowest to widest):

1) The binding between an XRD and its SubjectID. 2) The binding between an XRD and any of its Aliases. 3) The binding between an XRD and any identifier that resolves to it.

We discussed that an XRD could also serve essentially the same function as a URI redirect. The advantage is that unlike a redirect, an XRD can be signed.

John explained the difference between a <Redirect> and a <Ref> element in XRI Resolution 2.0. Both delegate from one XRD to another; the former does not change the CanonicalID/Subject, the latter does.

John also made the point that the XRDS format (a wrapper for a sequence of XRDs) may in fact be needed for certain URI-based use cases, not just XRI resolution.

2) /HOST-META AND LINK-BASED RESOURCE DESCRIPTOR DISCOVERY

Eran gave an update that he posted the updated /host-meta last night, and the new version of the discovery spec (now Link-Based Resource Descriptor Discovery) is coming out today.

# ERAN to send a link to the list (DONE for /host-meta).

# ALL - please review both of these specs since they have both been rewritten completely.

3) "PUSHING" XRDs

John brought up a new use case: being given or "pushed" an XRD versus requesting it via identifier discovery. Given the detached signature model, he pointed out that you can verify the XRD without ever needing to retreive the XRD itself. There was concensus that this worked.

He brought up the use case of including an XRD in a SAML token. If the Subject of the XRD matched the Subject of the SAML token, and the SAML token was signed, and you trust the SAML signature, then you can trust the XRD without having to retreive the detached signature.

In principal, this is the XRD equivalent of delivering endpoint references (EPRs) in a SAML token, such as those delivered via information cards.

Bob pointed out that this gets into the overlap between attributes of a resource that can be described and signed with SAML attributes and the same attributes that can be signed and asserted with an XRD. Drummond observed that from this standpoint, a signed XRD could be said to be a "discovery-centric descriptor" and a signed SAML token "assertion-centric".

John will explore this further.

4) NEXT MEETING

Regular time this Thursday, 2/12, 2-3PM PT (22:00-23:00 UTC).