[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XRI TC Telecon 10-11AM PT Thursday 2008-01-24
Following are the minutes for the unofficial telecon of the XRI TC at: Date: Thursday, 24 January 2008 USA Time: 10:00AM - 11:00PM Pacific Time Event Description: Weekly unofficial call of the XRI Technical Committee. ATTENDING Gabe Wachob Markus Sabadello John Bradley Marty Schleiff Drummond Reed Les Chasen AGENDA 1) UPDATE ON TIMING OF OASIS STANDARD VOTE After checking with Mary McRae, who coordinates specification votes for OASIS, it turns out the timeline we proposed last week was just a little too tight to comfortably fit within OASIS SLAs for turnaround times. So we need to hold the vote in May rather than April. We reviewed the new proposed timeline: - Feb 1: Public review of CD02 ends - Feb 15: First draft CD03 reflecting feedback (Type element reuse) - Feb 22: Final draft CD03, vote begins - Feb 25: Vote on CD03 begins - Feb 29: Vote on CD03 ends - Mar 10: Begin second public review (15 days) - Mar 25: End second public review - Mar 26: Begin Committee Specification vote - Apr 2: End Committee Specification vote - Apr 7: Submit for OASIS Standard vote - May 1: Begin OASIS Standard vote - May 31: End OASIS Standard vote There was consensus to move forward with this, pending receipt of additional comments from the current public review. 2) COMMENTS RECEIVED ON XRI RESOLUTION 2.0 COMMITTEE DRAFT 02 We have received two comments from Eran Hammer-Lahav. The first one cover the points he raised with us on an earlier telecon, and the second regarding improved wording in section 12. * Drummond explained that Eran has also informally suggested that in Section 4 (XRDS Documents), we explicitly call out the attributes that apply to each element. There was general consensus that would be easier to read. * So far we have not seen any other comments or specific discussions. Marty explained that the W3C URI mailing list is currently having an extensive discussion about, "What does the URI represent?" Gabe explained that if a URI returns a 303, then the identifier is abstract, whereas if the URI directly returns the resource, then it is concrete. He pointed out that this requires deferencing the identifier in order to know whether it is abstract or concrete, vs. the XRI approach of having a uniform syntax and resolution protocol for abstract identifiers. 4) DISCUSSION ABOUT OPENID IMPLEMENTATIONS OF XRI John Bradley explained that he's been working extensively on integrating XRI into OpenID implementations. He's been seeing very uneven implementations by OpenID relying parties (RPs), largely due to their limited understanding of the CanonicalID element and full XRDS processing rules. In particular, RPs who follow the OpenID 2.0 specification (http://openid.net/specs/openid-authentication-2_0.html) will send the value of the CanonicalID element (typically an i-number) to an OP for authentication, which is technically fine, but which introduces the problem that the OP does not know which i-name the user entered at the RP. John learned that several XRI i-brokers supporting OpenID worked out the "append solution" to this problem, where the i-broker added the append attribute value "qxri" to the <xrd:URI> element in their OpenID SEP. This means the i-name entered at the RP should appear on the service endpoint URI received by the OP. The OP can detect this and display the correct i-name to the user. While this approach works, it requires RPs to understand the processing of the append attribute. And alternate solution John has implemented is for the RP to simply send the OP whatever XRI was entered by the user (presumably the i-name), and the OP authenticates that. John pointed out that it makes no difference whether the RP sends the i-name or i-number to the OP, as the RP is responsible for verifying that the i-number is a valid synonym anyway. And the RP still persists the i-number. There was consensus that both approaches work, and the latter required less on the part of RPs. However there is still the issue of RPs processing XRDS documents correctly if they go beyond simple "Yadis" usage, e.g., use Redirects or Refs or non-trivial SEP selection. Drummond suggested that the TC publish a document entitled, "Best Practices for Using XRI and XRDS with OpenID" that can be widely referenced by OPs, RPs, and developers. John agreed to spearhead this effort. Les volunteered Wil to help with review. Drummond also agreed to help. # DRUMMOND to create a "cover page" for this new document on the wiki. # JOHN to proceed with a first draft of the document.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]