Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-02-12

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

Following are the minutes of the unofficial telecon of the XRI TC at:

Date:  Thursday, 12 February 2009 USA
Time:  2:00PM - 3:00PM Pacific Time (22:00-23:00 UTC)

ATTENDING

Peter Davis
Eran Hammer-Lahav
Nick Nicholas
Markus Sabadello
Tatsuki Sakushima 
Drummond Reed
John Bradley
Nat Sakimura
Brian Eaton


AGENDA

1) DNS DISCOVERY UPDATE

Peter expects his next update will be the middle of next week.


2) XRD 1.0 - HOST META REVIEW

Eran sent out the new draft for review:

	
http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-01.txt

Eran mentioned that the name of the file (currently /host-meta) is still
under discussion.

One other key area of feedback has been about more tightly defining the
semantics of Link fields. They need to include: 1) host name, 2) port
number, and 3) what protocol you are going to speak.

Be default, the /host-meta file is authoritative only for the host, port,
and protocol you used to obtain it. An application can then make its own
decision to treat the /host-meta file as authoritative for a greater or
lesser scope.

A second key point is that many readers have been assuming a tight binding
between a URI and the /host-meta file that describes the resource identified
by the URI. Eran said that an application must first decide, for a URI, what
context the application needs to interact with the URI (e.g., via what
protocol), and see the /host-meta that applies to that context.

A third are where Eran and Mark Nottingham are looking for more feedback is
security. We discussed HTTPS retreival of /site-meta files. John said he
hoped HTTPS retreival could be used for non-https: URIs, i.e., that you
should be able to get a /host-meta file securely even if it is for http:
URIs. Eran said that decision was application-specific. Perhaps the easiest
way to do that is for the HTTP version of the file to redirect to the HTTPS
version; that would be a clear way to delegate. Eran believes this
redirection should be to the exact same host and port for maximum security.

However, the trust models for /host-meta delegation are still
application-specific. Applications can be defined to only use HTTPS
/host-meta files, or they can be defined to use HTTPS only when HTTP
/host-meta files redirect to them, or any combination that meets the apps
security requirements.


3) XRD 1.0 - DESCRIPTOR DISCOVERY UPDATE/ISSUES

# ERAN will post a new draft of the discovery spec today.


4) XRD 1.0 - SCHEMA UPDATE/ISSUES

Eran posted the basic proposed schema. See the thread beginning:

	http://lists.oasis-open.org/archives/xri/200902/msg00020.html 

Eran would very much like a close review of the definitions of each element
(the actual element names are easier to change - what we need is consensus
on the definitions).

# DRUMMOND - wikify the email from Eran if he or others do not do it first.

# ALL - please do a close review of the definitions ASAP.


5) XRD 1.0 - TRUST TEAM UPDATE/ISSUES

Nat was completely swamped last week and Brian just got back from vacation.

Brian listed the following major action items:

a) Synonym binding trust profile.
b) Signing format (i.e., moving forward with his XML dSig profile proposal).

On (a), Brian is primarily focused on use cases where you "must find an XRD
that directly describes the identifier you are working with", and therefore
doesn't need synonym binding trust. He is skeptical about the trust
challenges with synonyms, but we need to analyze it further.

We discussed that the two current use cases we have that do need synonym
binding are OpenID delegation and XRI trusted resolution.

Brian's suggestion for moving forward on this action item is to start by
publishing a strawman synonym binding trust profile, and then look at how
that works for OpenID delegation, XRI synonym verification, etc.

# JOHN AND DRUMMOND to propose a synonym binding trust profile via the list
or wiki.

On (b) Brian noted that Gabe commented on the list on some of the downsides
of using XML dSig artifacts. Brian explained that writing it as a profile of
XML dSig was the most practical approach, because he would rather reference
their language than cut-and-paste it to create something new. 

Nat also wants to get feedback from the SAML Simple Sign editors.

# ALL - Either identify issues or provide feedback on the XML dSig profile
proposal:

	http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile 


6) XRI 3.0 - SYNTAX AND BINDINGS UPDATE

Drummond reported that he hasn't made much progress and still needs to
review Nick's initial work on the info: binding. He hopes next week will
provide more time.
 

7) NEXT CALL & SELF-SERVE AGENDA PAGE

A reminder to use the self-serve agenda page for next Tuesday's call:

	http://wiki.oasis-open.org/xri/SelfServeAgenda