Minutes: XRI TC Telecon 2-3PM PT Thursday 2008-12-18

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

[My apologies for being slow to post these - once I flew back to Seattle
we've been buried in a foot of snow. =Drummond]

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

Date:  Thursday, 18 December 2008 USA
Time:  2:00PM - 3:00PM Pacific Time (22:00-23:00 UTC)

ATTENDING

Peter Davis 
Les Chasen
John Bradley
Markus Sabadello
Tatsuki Sakushima 
John Bradley
Markus Sabadello
Brian Eaton
Breno de Medeiros
Dirk Balfanz 
Bob Morgan 
George Fletcher
Nat Sakimura 
Drummond Reed
Nick Nicholas
Eran Hammer-Lahav 


AGENDA

1) XRI 3.0 - SYNTAX REPORT

Drummond reported that the XDI TC had created a series of graphs of XDI RDF
statements using the proposed XRI 3.0 syntax to illustrate why the precision
of GCS delimiters and Xref delimiters is needed.

	http://wiki.oasis-open.org/xri/XriThree/GcsDelimiter
	http://wiki.oasis-open.org/xri/XriThree/XrefDelimiter 


2) XRD 1.0 - DNS RESOLUTION PROPOSAL

Peter published a first draft proposal at:

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

Peter answered several questions; discussion will continue on the list.

# PETER to post a second draft and add an issues list.


3) XRD 1.0 - SIMPLE SIGN

Nat ran use through a new wiki page:

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

That page has a new 1.4 section that uses signatures in separate files. This
was taken from the original Simple Sign proposal. 

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

It was discussed whether the 1.4 section was compatible with XRI resolution,
i.e., whether it worked over a chain of trust.

The 1.1 and 1.2 options require only Base64 encoding for canonicalization.
The 1.3 option is backwards-compatible with with XRI Resolution 2.0, as the
signature is based entirely on the two attributes added to the XRD element.
The non-base-64 encoded XML is not authoritative, however it is still useful
for backwards compatability.

With regard to next steps, Brian summarized that currently Trust Team
disagrees about the best path forward here, and would like the opinion of
the rest of the list. This led to a discussion about a hybrid option, which
would combine both "key-by-value" and "key-by-reference". There was some
debate about whether both versions could use the same signature, and whether
an XRDS "wrapper" was needed to preserve the signature metadata in a chain
of XRDs. 

Peter talked to the requirement for supporting signatures at the Service
level. He would like the detached signature method to be able to work over
the service-level nodes, i.e., the Service element block. That's different
than signing the XRD pointed to by the Service element, because it's really
signing the reference rather than the target.

Brian suggested that the Service provider could push just a base64 encoded
version of the Service node to the XRD that needed a signed version.

The overall concensus points were:

	- Both detached and inline signature options need to be supported.
	- Aligning the XRD signature mechanism with SAML Simple Sign draft
would be good.


4) FIRST WORKING DRAFT TIMELINES

We discussed general timeframes for first working drafts, beginning with XRD
1.0.

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

Eran said he has about 70% of the schema documented. He is still working
with the <Ref> and <Redirect> elements to figure out the best way to use
them. He's also planning to define endpoint selection based on the Super
Simple SEP Selection proposal:

	http://wiki.oasis-open.org/xri/XriThree/SuperSimpleSepSelection 

He's planning to post several docs to the wiki before Xmas. Brian asked Eran
to prioritize the workflow portion. Eran said that his earlier email on that
topic was still accurate. Brian volunteered to put that up on the wiki.

# BRIAN to post workflow portion of Eran's email to the wiki.

Eran suggested that we have an introduction to authority and trust in the
document. We also discussed the general partitioning of the spec. It is
still three major buckets - workflow, schema, and trust. The workflow
section may be separated out into a different part so it can be referenced
independently; it is unclear whether schema and trust should be in different
parts.


6) NEXT CALLS / HOLIDAY CALL SCHEDULE

We agreed we did not want to have any calls during the next two weeks due to
the holiday -- instead we will concentrate on list/wiki progress and posting
first Working Drafts.