[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-06-18
Following are the minutes of the unofficial telecon of the XRI TC at: Date: Thursday, 18 June 2009 USA Time: 2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC) ATTENDING Markus Sabadello Joseph Holsten Drummond Reed Will Norris Tatsuki Sakushima John Bradley George Fletcher Nika Jones REGRETS Nat Sakimura Scott Cantor AGENDA 1) XRD SIGNATURES TAKE 3 The XRD signatures debate is summed up by several recent messages: Tatsuki on Ruby adoption challenges: http://lists.oasis-open.org/archives/xri/200906/msg00061.html Will on the practical "deliver XRD libraries case": http://lists.oasis-open.org/archives/xri/200906/msg00063.html Drummond on a strawman for making this decision: http://lists.oasis-open.org/archives/xri/200906/msg00066.html Drummond summarized the proposed decision criteria on this issue as follows: "We should adopt the XRD signing method that represents the least TOTAL EFFORT in achieving ubiquitous adoption of secure XRD libraries, then concentrate our adoption efforts on delivering those libraries everywhere they are needed." Tatsuki explained that he's had the dialog with the OpenID community, and been trying to figure out a simple way to implement a XML dSig library in Ruby. He found two techniques for doing this, thanks to the help from the list. However the current options are not easy to install with the Ruby GEM package manager, and not nearly as easy as installing an OpenID library. There is also no shared Ruby code (that works) for doing the canonicalization required by the constrained XML dSig profile. His feeling is that the key is having canonicalization code that is interoperable in the different scripting languages. Will agrees with Tatsuki about what we need. He summed it up this way: in order to get canonicalization support in any language there are two options: a) Write it in C and put a wrapper around it b) Do it natively in the language The former works but introduces significant contraints. Will feels that therefore we really need native language implementations of canonicalization in all popular languages/platforms. The fact that Tatsuki found one in Ruby that didn't work doesn't mean they can't be fixed. Will emphasized that the constrained canonicalization required in the constrained XML dSig profile in the new Working Draft is just walking a DOM tree. And this is absolutely doable in every scripting language. So what we need to do is help produce those libraries before we can really push XRD 1.0 adoption forward in the market. Tatsuki would like to see XRD signature libraries distributed together with the OpenID libraries needed on each platform, so that it is super-easy for developers. Will feels that while this can be very helpful, it's really up to the distributors of those libraries how they actually go about it. John agreed that we can encourage it, but we can't enforce it. Will said that those of us on the TC that feel strongly enough about this need to be the ones writing the code to see that it actually gets done and is properly tested so it is interoperable. George provided another example that even the "super simple signing approaches" turn out to have many finer points that present interoperability challenges. So they are not a panecea. And since we are stuck (at present) with XRD being in XML, the advantages to using a standard XML signing mechanism are significant. Joesph asked how many places we actually need to have XRD signature functionality? Will said that there are a number of existing implementations -- for example C++, Java, and PHP 5. But Will pointed out that since we don't have essentially any XRD 1.0 implementations yet, we have to write at least some of this code on every platform anyway. And that's yet another reason to just make sure the constrained XML dSig canonicalization code is written and packaged in at the same time. George added that one exemplary native implementation, in any popular platform, is enough to make them much easier on all the others, so we should concentrate on that. Will said that his Java implementation is coming along very well, so he would offer that even before his PHP implementation. The discussion went further into the needs for Rudy. Joesph, Tatsuki, and Will discussed it and agreed that doing a native Ruby implementation ASAP is a very high priority. Lastly, Drummond cited this feedback from Nat on the list last night (Nat asked for it be reported even though he could not attend): ***** QUOTE ***** What we should do here is to create such implementation for XML DSig implemented purely in each language. I would suggest GAE/Python, and Ruby (GEM installable). Once they are there and can show the compatibility, I am good to go with XML DSig. It also will show the communities that we are committed to help them. ***** ENDQUOTE ***** Drummond once again asked whether, after this discussion, there was any heartburn about proceeding with the constrained XML dSig profile as our one specific XRD signature method. No one objected, so we reaffirmed our decision of three weeks ago to proceed with this, with much greater emphasis on encouraging or abetting implementations on all major platforms and scripting languages. 2) OTHER XRD 1.0 ISSUES We talked about the <XRD:TargetAuthority> element and whether it was needed for a trust model based on a chain of XRDs. Drummond referred to section 10.2.5 of the XRI Resolution 2.0 spec (http://docs.oasis-open.org/xri/2.0/specs/xri-resolution-V2.0.html). They agreed this would need further review offline. # WILL AND DRUMMOND to review whether TargetAuthority is required for a chain of trust across XRDs and report back to the list. Will also said that there is a different model for including schema fragments in the text, based on the approach taken in SAML. He will send a message to the list. 3) NEXT XRD 1.0 WORKING DRAFT Drummond observed that we are now entering the "punchlist" phase for completing the first Committee Draft. He suggested we begin using an actual issues punchlist on the wiki. Such a page already exists at: http://wiki.oasis-open.org/xri/XrdOne/SpecHome # DRUMMOND to send a note to the list about using this page to track and close issues to reach a Committee Draft. Will said he's ready to push the next Working Draft after consolidating feedback. # WILL to review Scott's comments on the signature portion of the spec. # WILL to upload a new draft reflecting these and ping the list afterwards. 3) 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 We did not have Eran so we were not able to cover these today. # ERAN, please send an email to the list summarizing any outstanding issues, particularly as they might impact or be dependencies for the XRD 1.0 Committee Draft. 4) XRI SYNTAX 3.0 WORKING DRAFT 02 STATUS/ISSUES Drummond said he is still working on it, and hopes to have time on his trip to London next week to finish Working Draft 02, though it will not be posted until after his return June 27. 5) NEXT CALL The next call is tentatively next week at the same time. Will, Drummond, and John are all borderline as to whether they will be able to attend due to travel, so it may be cancelled - we will send email closer to the call. However we WILL have a call the normal time on the following week - Thursday July 2 - which will be the deadline for finalization of the XRD 1.0 Committee Draft so that we can begin an online vote.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]