Minutes from F2F meeting 2009-05-22

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

Following is a copy of the wiki-formatted minutes of the face-to-face
meeting held Thursday, May 22, 2009, at the Hotel Avante in Mountain View,
CA.

These have been posted to:

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

Note that the meeting ran from 9AM PT until after 9PM PT, and many issues
and approaches around improving and simplifying our XRD signature methods
received much discussion in the latter part of the meeting that was hard to
summarize in the notes. I encourage those who attended to add their own
commentary/conclusions and those who did not attend to ask any questions
about the minutes.

Please note the consensus was to drive towards:
* Complete Working Drafts by the end of May.
* Approved Committee Drafts by June 19.
* A first public review to run during July and August.

=Drummond 

== About ==
This page contains the minutes of the 2009-05-21 face-to-face meeting of the
XRI TC.

== Attending ==
 * Peter Davis
 * Drummond Reed 
 * George Fletcher
 * Markus Sabadello
 * Tatsuki Sakushima
 * John Bradley
 * Eran Hammer-Lahav
 * Will Norris

== XRI 3.0 Syntax Working Draft 01 Review ==
Drummond reviewed the first Working Draft posted yesterday, focusing
primarily on the overall outline, the XRI-to-URI/IRI Bindings section, and
the ABNF.

'''ACTION: DRUMMOND to add examples to the Intro section.'''

=== XRI-to-URI/IRI Bindings Section ===
We discussed this section in detail. We agreed to add a mailto: binding, and
discussed the potential for a data: binding.

'''ACTION: DRUMMOND to add wording about the purpose of XRIs are to
represent the same resource regardless of binding.'''

'''ACTION: DRUMMOND to add a Security and Data Protection requirement for
binding specs.'''

=== Security and Data Protection Section ===
We agreed this section was needed for unbound XRIs, but should serve as a
"base class" for the same section in any binding specs.

== XRD 1.0 Working Draft 01 Review ==

=== Host-Meta, LRDD, and Link Headers ===
Eran ran through the key developments on the discovery front.

The most important is the shift from /host-meta as a well-known file at the
root directory of the host to .well-known as a well-known directory. This
was motivated because some sites let users register directly in the root
namespace, so the site may not be able to reserve the string "host-meta".

This means that it is no longer necessary to specify how to sign /host-meta,
because the discovery process can just request a signed XRD from the
.well-known directory, eliminating a round trip.

The second major development is in the trust mechanism. Eran explained that
neither the Link Element and Link Header discovery mechanisms support
signing. But signing is required to support trusted delegation.

SSL is currently one way to do this, but requires an IP address and cert.
This means SSL is not feasible for providers like Google who need to deploy
it for their SME customers who cannot count on SSL support. 

With /host-meta as a separate text file format, this would have required
adding signature support to /host-meta, which we very much wanted to avoid.
Now, /host-meta can simply be an XRD, which means we only need to define the
signature mechanism once.

So the LRDD (Link-Based Resource Descriptor Discovery) spec will now include
a reference to XRD as the well-known document format for a /host-meta file
in the .well-known directory. This means that LRDD will include definitions
of three discovery mechanisms:
 * HTTP link header
 * HTML link element
 * /host-meta (as an XRD file)

=== XRD Spec Structure ===
The spec will include these major sections:
 1. Schema
 1. Processing
 1. Trust and Signatures

=== Link Child Element Names ===
It was decided to have two child elements of <Link>:

 1. <TargetAuthority> identifies the signing authority for the target XRD.
 1. <TargetSubject> identifies the subject of the target XRD.

It was decided to put both of these in their own XRD-1.0-trust namespace.

We had a long discussion about XRD:Link:LocalID and finally decided to
remove it because:

 1. It is the only non-discovery and non-trust related element.
 1. Any application that will need it will need it for application-specific
reasons and thus should put it in its own namespace.
 1. It will simplify the schema and help reduce uncertaintly.

=== XRDS as a Wrapper ===
XRDS as a wrapper element is still needed for XRI resolution. This reopened
the discussion about how to represent signatures on XRD documents (see
below). We concluded that the XRI Resolution 3.0 spec will include a section
defining how to take that signature together with the original XRD and embed
this in an XRDS document so that a sequence of signed or unsigned XRDs can
be assembled into a valid XRDS that permits a consuming application to
verify all the signatures.

This means that the XRI Resolution 3.0 spec should define the following XML
elements:
 1. XRDS
 1. SignedXRD
 1. Signature
 1. Data

=== XRD Trust Section ===
The Trust section of the XRD spec will cover different methods of returning
the signature, including:
 1. Returning it as an HTTP response header.
 1. Returning it in the body of a www-form-urlencoded response (POST
response).
 1. Returning a link to it in the base-64 encoded text.

'''ACTION: WILL to write up our conclusions about these three options and
send it to the list.'''

=== Schedule/Milestones ===
 * Complete working draft between Will and Eran by end of month
 * Email to list, hold feedback cycle within one week
 * Complete stable Working Draft and first implementation(s)
 * Hold Committee Draft vote from June 12 to 19
 * Hold Public Review during July and August
 * Feedback cycle in September with second public review
 * Submission for OASIS Standard vote by October 15
 * OASIS Standard vote during month of November

'''ACTION: WILL to send an email to the list as soon as the next Working
Draft is ready, and highlight either in the email or the draft any sections
where he would like TC members to study with special scrutiny.'''

== XRI, XRD, and OpenID ==
 * We discussed the goal of how an http: or https: XRI under XRI 3.0 can
work seamlessly with OpenID as an "ordinary" URL, so that any special
treatment is reserved for UX or to take advantage of the security
characteristics of i-numbers.
 * We discussed the usability issue with the current use of i-numbers. An
analogy is displaying a URL that is supposed to include a fragment without
the fragment when needed for user presentation.
 * We agreed more work is needed to fully document the recommended best
practices when it comes to XRI 3.0 XRIs and XRD 1.0 discovery.