Minutes: XRI TC Telecon 8-9AM PT Tuesday 2009-02-10

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

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).