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)