Minutes: Joint XRI & XDI TC Telecon Thursday 2007-03-08

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

Following are the minutes of the joint unofficial telecon of the XRI and XDI
TCs at:

Date:  Thursday, 8 March 2007 USA
Time:  10:00AM - 11:30AM Pacific Time

Event Description:
Weekly unofficial joint call of the XRI and XDI Technical Committees.

ATTENDING

Gabe Wachob
Les Chasen
Drummond Reed
Giovanni Bartolomeo
Wil Tan
Andy Dale
Marty Schieff (second half)


AGENDA

1) REMINDER TO REGISTER FOR THE OASIS SYMPOSIUM AND XRI/XDI F2F MEETING
Hotel and registration discount deadlines are approaching. See

	http://www.oasis-open.org/events/symposium/2007/index.php 


2) IDENTITY SELECTOR SUPPORT FOR XRI

Andy was able to join us to discuss integration points between CardSpace and
XRI. He sees four integration points overall. The first two are
Higgins-centric:

* Rather than having your cardstore on your local machine, your cardstore is
in the clouds. In this scenario, you can login to any machine with your XRI,
which is resolved to your i-card service endpoint so you can access your
card.

* The second integration point is Higgins IdAS -- a framework for accessing
identity-related data. Andy likens this to JDBC drivers, where you have to
instantiate a concrete instance of a JDBC driver that works with a specific
store, and once you have done that, you have a standard set of calls for
getting/setting data from that source. Higgins calls these drivers "context
providers", and they serve as the concrete connector classes for interacting
with any data source (RDBMS, LDAP, file store, etc). From this standpoint,
Higgins is using XRIs as a way to identify context providers.

The others are more XRI-centric

* We need to establish the URI (or XRI?) that can be used in CardSpace to
identify an XRI as an claim inside an information card (i-card). It is an
open issue as to whether there should be separate claims for reassignable
XRIs (i-names) and persistent XRIs (i-numbers).

* Another use case is providing an XRI as the value of *other* claims when
the claim author wants to provide a dereferenceable pointer to the value
rather than the value itself. (As Andy puts it, "classic XDI delivered via
an i-card".)

* Publishing an XRI as a claim in an i-card raises the issue of how one can
verify this assertion. Of course one way to do that is with OpenID
authentication (if the XRI supports an OpenID authentication service) or
SAML authentication (if the XRI supports a SAML authentication service).
Andy pointed out that there is another option of providing a signed
third-party claim from the XRI registrar (i-broker) authoritative for
registration of the XRI.

The TC members discussed this last option and generally agreed that the
issue of verification of a third-party claim about XRI authority may be out
of scope for the TC and in scope for XRI registries and registrars such as
XDI.org.

# DRUMMOND to contact Kim Cameron, Mike Jones, and the CardSpace team to set
up a meeting/telecon for the XRI TC to discuss with them the use of XRIs
with CardSpace.

Andy also noted that ooTao is bringing up an instance of the Higgins token
service by the end of the week.

# ANDY to send a notice to the XRI/XDI TC lists with a pointer when this is
ready.

Giovanni mentioned that he and his team are following the Higgins activity
closely and is very interested in XRI and Higgins integration.


3) XRI SYNTAX 2.1 ABNF (MAIN TOPIC)

The proposed ABNF is now the key gating item for XRI Syntax 2.1, on
which both XRI Syntax 2.0 and XRI $ Dictionary 2.0 have a dependency. We
reviewed the following wiki pages:

	http://wiki.oasis-open.org/xri/XriCd02/XriAbnf2dot1 

	http://wiki.oasis-open.org/xri/XriCd02/GlobalRefs

The discussion included the following points:

* Per Steve's and Drummond's messages to the list yesterday, one of the most
important aspects of drafting the 2.1 syntax is gaining agreement on the
"abstract syntax" upon which the ABNF is based. Drummond's proposal about
the abstract syntax has been posted to the
http://wiki.oasis-open.org/xri/XriCd02/XriAbnf2dot1 wiki page. The key
recommendation is that whereas in 2.0 syntax we had assumed the abstract
syntax was that a segment is a sequence of subsegments where in special
cases delimiters are optional, in 2.1 it is proposed that a segment is a
sequence of subsegments where delimiters are always required, preceeded by
an optional starting value that is not delimited (and thus is not formally a
subsegment). Drummond's view is that this explicit recognition of an
optional starting value in the abstract syntax can eliminate a host of
special rules in the 2.0 ABNF.

* We also had a long discussion about the use of parentheses, parentheses
normalization, and equivalence. We discussed the following examples (now
listed on the http://wiki.oasis-open.org/xri/XriCd02/GlobalRefs page). 

#1A $(http://example.com)=gmb
#1B $(http://example.com)*(=gmb)
#1C $(http://example.com)!(=gmb)

#2A $(http://example.com)=gmb*sub1
#2B $(http://example.com)*(=gmb*sub1)
#2C $(http://example.com)!(=gmb*sub1)

#3A $(http://example.com)*(=gmb)*sub1
#3B $(http://example.com)*(=gmb)!sub1

#4A $(http://example.com)*((=gmb))
#4B $(http://example.com)*(((=gmb)))

In examples #1A/B/C and #2A/B/C, the XRIs would logically make sense to
identify the same resource. The question is whether they should normalize to
the same XRI. The current proposal is that all parentheses and delimiters
are significant, and thus synonymity between any of these XRIs may only be
established via local policy or resolution.

# DRUMMOND to send an email to the list summarizing a proposal that all
delimiters and parentheses be considered syntactically significant.

Marty mentioned the idea of not considering ! syntactically significant,
i.e., not a namespace. Drummond pointed out as long as ! is a namespace, XRI
authorities can choose by local policy whether to make it synonymous with
other local namespaces (i.e., whether examples #1A/B/C above would all be
synonyms), but that losing this capability would prevent any XRI authorities
from using ! as a namespace.


4) TOPICS FOR NEXT CALL
We agreed to schedule two topics for the next call:

* Next steps to closure on 2.1 abstract syntax, ABNF, and normalization
rules for parentheses.

* XRI Resolution 2.O WD 11 - Service Ref issue (#37) and any others.