Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-01-22

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

Date: Thursday, 22 January 2009 USA

Time: 2:00PM - 3:00PM Pacific Time (22:00-23:00 UTC)

ATTENDING

Dirk Balfanz

Breno de Medeiros

Brian Eaton

John Bradley

Markus Sabadello

Tatsuki Sakushima

Drummond Reed

Peter Davis

Nat Sakimura

Bob Morgan

REGRETS

Nick Nicholas

AGENDA

1) DNS DISCOVERY

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

Peter reported he hasn't made further progress on paper yet his thinking has progressed and he is getting closer to the writing stage.

2) XRD 1.0 SCHEMA

Eran was sick and not able to attend. He hopes to post the XRD schema draft as soon as he's feeling better.

3) XRD 1.0 - SIMPLESIGN INLINE PROPOSAL

http://lists.oasis-open.org/archives/xri/200901/msg00104.html

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

Nat's first question about this proposal was whether the base64 payload should be in an attribute or in a child element. He said NRI is checking into this but asked if anyone else has experience with it.

Nat also noted that SAML SimpleSign chose to sign over the decoded version of the base64 rather than the encoded version, because different libraries handle the base64 encoding differently. Peter and Bob noted that we should check directly with the authors, Scott Cantor and Jeff Hodges.

However Brian noted that one of the best advantages of not using XML dSig is that the same code can be reused for any way we're signing the blob. He suggested thinking about it this way: there is more than one way to encode a base64 bitstream, but they all decode to the same thing. Therefore he prefers signing the decoded version.

There was concensus that this was the best approach.

# NAT will update the wiki page to reflect this, note any other open issues, and then ping the list to advance discussion.

4) XRD 1.0 - NON-X.509 PUBLIC KEY

http://lists.oasis-open.org/archives/xri/200901/msg00105.html

Nat said this proposal was very nascent - he just wrote up his notes and sent them to the list. John replied that he had worked on an XDI implementation that used non-X.509 public keys and that this capability could be very useful.

Bob explained that SAML had cases where they could use a key without a cert (in SAML metadata, the metadata is playing largely the same role as the cert). However they ended out using certs because most libraries did not know how to handle just "plain-old keys", yet they do understand the X.509 format.

Drummond suggested using an external label to describe the cert that would establish different semantics about the use of the cert elements.

Nat asked if John would look over the SimpleSign proposal with an eye to whether it would fulfill the non-X.509 use case.

Nat also explained the concept behind the SubjectID proposal -- being able to create a unique identifier/key pair for each relationship the user instantiates. John pointed out that in OpenID, this "relationship identifier" is the responsibility of the OpenID Provider (OP). Nat said that OpenID conflates the two roles of discovery and authentication providers and that if you break it apart, the relationship identifier assignment is a discovery provider function.

We agreed on the following next steps:

# NAT to post a wiki page on this writeup.

# JOHN AND DRUMMOND to review that page once it is up and provide feedback about how it compares to PPIDs.

# ANY TC MEMBER please post further feedback on use cases for non-X.509 public keys.

5) XRI 3.0 - SYNTAX

Drummond reported that it will be at least another week (and probably two) before he can do a first draft in OASIS template format. However there are currently no blocking issues to Working Drafts of that and the two binding specs. Nick Nicholas has promised to help with the info: binding.

John mentioned that one thing that XRI 3.0 Resolution will need to cover is how CanonicalID verification and trust will work on top of XRD 1.0.

Drummond noted that the term "proxy" may not actually apply to the way that XRI 3.0 resolution works now that XRIs have URI bindings. John said that any application that only knows about XRD ought to be able to take an XRI that's bound to a URI root and be able to get back an appropriate XRD on which it can do trust validation like any other XRD.

What will be different is that XRI servers will include a redirect functionality that will typically not exist for normal XRDs. This will have to be addressed in terms of backwards compatability.

6) NEXT CALL & SELF-SERVE AGENDA PAGE

To cut down overhead and increase call productivity, we will begin using a self-serve agenda page for our Tuesday calls. The page is posted at:

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

The rule is: first come first served for listing issues for discussion. If no issues are pressing enough to be posted that week, then we won't hold the Tuesday call.

Thursday calls will continue to have a "managed agenda" so they provide a constant weekly sync point.

# DRUMMOND to extend XRI and XDI TC call dates in the OASIS calendar.

Drummond also noted that he will not be able to attend next Thursday's telecon due to travel.

xri message