Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-06-18

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

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

Date:  Thursday, 25 June 2009 USA
Time:  2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC)

ATTENDING

Will Norris
Eran Hammer-Lahav
Drummond Reed
Peter Davis
George Fletcher
Scott Cantor
Breno de Medeiros
Nat Sakimura
John Bradley


1) LINK HEADER/HOST META/LRDD STATUS/ISSUES

	http://tools.ietf.org/html/draft-nottingham-http-link-header
	http://tools.ietf.org/html/draft-nottingham-site-meta 
	http://tools.ietf.org/html/draft-hammer-discovery 

Eran sent an email today to the IETF list with the two proposed changes to
LRDD - switching to .well-known and making host-meta an XRD. Eran says that
Mark Nottingham promised to deliver a draft of .well-known this week.

There is an open issue about what the Subject of a host-meta XRD document
should be. If anyone has opinions about this, please join the list
apps-discuss@ietf.org. This is the new list instead of www-talk, which is
mostly about protocols and formats.

Now Eran cannot push a new LRDD spec are a new .well-known spec and first
Committee Draft of XRD so both can be referenced in LRDD. So the
dependencies are now in the opposite direction.


2) XRD 1.0 ELEMENT ORDERING

See this thread:

	http://lists.oasis-open.org/archives/xri/200906/msg00099.html 

Both RelaxNG and XSD require order by default. Removing it is fairly easy in
RelaxNG, harder in XSD.

Eran's input was that because XSD is so widely used, we need the XRD schema
to be relatively easy in XSD, and thus we shouldn't do something that's easy
in RelaxNG and either not possible or very difficult in XSD.

DECISION: Put the elements with strict cardinality (Expires and Subject) up
front, and then put the rest in a "bag", i.e., provide a Choice.

# WILL to add this to the next Working Draft.


3) EXPIRES ELEMENT

Eran feels pretty strongly that the bar for changes should be very high, so
this should not be changed unless it is very important.

DECISION: We will keep this as an element.


4) XRD 1.0 TARGETSUBJECT AND TARGETAUTHORITY ELEMENTS

See this thread:

	http://lists.oasis-open.org/archives/xri/200906/msg00107.html 

We started with TargetSubject. 

Eran explained that the basic security check on a signed XRD is that the
subject of the signed XRD must be within the domain of the subject of the
certificate used to sign the XRD.

TargetSubject represents an additional check on verifying the target XRD
when one XRD is linking to ("delegating to") another. The proposed rule is:
if TargetSubject is present as a child of a Link element, then the value of
the TargetSubject element must match the Subject of the target XRD. If
TargetSubject is not present, then this check is not made.

Drummond sent an email to the list summarizing his and John's analysis of
how this protects against an "XRD substitution attack".

Will is not sure this type of protection will work for delegating an entire
domain, vs. a single XRD subject - his analysis is written up at the end of:

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

If that is still an issue, we need to figure out another solution.

Will also pointed out that because TargetAuthority delegates signing
authority, it must be used with care because the target XRD will only
validate it when it is obtained via following the XRD trust chain. However
we further discussed this and arrived at the following rule:

	If a signed XRD does not verify using a certificate that matches the
value of the Subject of the XRD, then XRD discovery MUST be performed on the
value of the Subject to determine if there is a TargetAuthority element that
authorizes a different Subject to sign the XRD. If so, the XRD signature
MUST be verified against a certificate whose subject is the value of the
TargetAuthority element pointing at the XRD.

We then discussed whether TargetAuthority wasn't more appropriately named
TargetKeyInfo.

# DRUMMOND to post a separate message to the list regarding this question.


5) XRD 1.0 NEXT WORKING DRAFT

Will said that these are the last remaining issues besides one editorial
question about how much if any discovery process information would be
included (Eran said little or none).

# WILL to ping the mailing list when he has pushed an HTML version of
Working Draft 02.

# ALL to review this as soon as it is out, as our goal is for the next call
to be a decision about whether it is ready for a Committee Draft vote.


6) NEXT CALL

The next call is at the regular time next week. The main topic will be final
comments on XRD 1.0 Working Draft 02 so we can commence a Committee Draft
vote.