Minutes: XRI TC Telecon 8-9AM PT Monday 2008-12-08

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

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

Date:  Monday, 08 December 2008 USA
Time:  8:00AM - 9:00AM Pacific Time (17:00-18:00 UTC)

ATTENDING

Bob Morgan
Drummond Reed 
John Bradley 
Brian Eaton
Eran Hammer-Lahav
Markus Sabadello
George Fletcher
Joseph Holsten (final part)
 

AGENDA

1) MOVE MONDAY CALL TO TUESDAYS

It turns out we did not allow enough time between our Thursday afternoon
telecon and a Monday morning telecon. There was consensus that this call
would be better scheduled for the same time on Tuesday morning.

# DRUMMOND to send a message to the list proposing moving this telecon to
TUESDAYS at the same time (8-9AM PT).

The first call at this new time would be Tuesday 16 December.


2) SPECIAL XRI 3.0 SYNTAX CALL 2-3PM PT TUESDAY DECEMBER 9

See separate message Drummond sent to the list. Please join us if you are
interested in this topic.

	http://lists.oasis-open.org/archives/xri/200812/msg00060.html 


3) XRD TRUST MODEL

Our main goal was to summarize the discussion from the list and drive
towards action items/proposals/strawmen.

John explained that much of the onlist/offlist discussion has centered on
delegation. Drummond asked for to clarify what the parties to discussion
mean by "delegation", explaining that it had a very specified meaning in XRI
Resolution 2.0 - name authority delegation from parent A to child B, just
like it works in DNS name delegation.

In terms of trust delegation and keys, Drummond explained that SAML trusted
resolution under XRI Resolution 2.0 was that the XRD for parent A published
the certificate (using the ds:KeyInfo element) for child B. A resolver then
used that cert to verify the signature on an XRD from child B.

Brian explained that what he is proposing is the same model except that
instead of parent A published the cert for child B, parent A would publish a
reference to the cert for child B. 

TERMINOLOGY NOTE: This reference was also being called a "link", a "name",
and a "pointer". However we agreed the basic concept is that the XRD either
contains the cert ("key-by-value") or a reference to the cert
("key-by-reference").

Bob said that this is a classic discussion about key distribution/discovery
in trust circles. Brian asked if anyone knew of a case where using HTTPS PKI
was not sufficient to use key-by-reference. Bob pointed out that some
enterprise uses cases would not consider HTTPS PKI to be strong enough, and
that these would require key-by-value. John pointed out that
key-by-reference was not limited to HTTPS for security; other models were
possible.

Bob said we would almost certainly need both and others agreed that while
supporting both key-by-reference and key-by-value adds some complexity, it
is worth the tradeoff. 

Discussion then turned to next steps with proceeding on the trust portion of
the XRD 1.0 spec. Two options were discussed:

* Writing up a more detailed summary of the overall proposal.
* Proceeding to a first strawman "implementer's draft".

In discussion about these options, two main points were made:

	A) The sooner we get down to concrete details, the sooner we flesh
out the remaining issues. For example, specifying what parts of xmldsig we
use/don't use, how we use ds:KeyInfo for key-by-value and key-by-reference,
how we simplify canonicalization, etc. -- all these will help get the rest
of the issues on the table.

	B) George would like to see how the detailed proposal/strawman spec
addresses a set of real use cases. Specifically three were discussed:

* OpenID example (delegation by a user to the service providers they are
using)
* OAuth example (hosting a user's photos).
* Enterprise example (delegation to an employee and to a customer).

Lastly, John brought up the difference between "delegation", which involves
the XRD for one resource (representing an identity/authority) pointing to a
related resource (representing a service for that identity/authority on
which XRD discovery can be performed independently), and "substitution",
which involves the first XRD pointing to a second XRD representing the same
identity/authority in a different context. From a practical standpoint, this
is important because it determines when the XRD consuming application
should/must or should not/must not change the identifier it is using for the
resource upon which it is doing discovery.

George suggested that Eran's new view of XRD as describing the resource and
related resources may be able to accommodate this. However we ran out of
time to continue discussion.

# ALL - continue discussion on the list of both: 
a) best route to get to a "strawman implementer's draft", and 
b) best way to deal with the distinction between delegation and
substitution.


4) NEXT CALL

Thursday 2-3PM PT (22:00-23:00 UTC)