[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-02-12
Following are the minutes of the unofficial telecon of the XRI TC at: Date: Thursday, 12 February 2009 USA Time: 2:00PM - 3:00PM Pacific Time (22:00-23:00 UTC) ATTENDING Peter Davis Eran Hammer-Lahav Nick Nicholas Markus Sabadello Tatsuki Sakushima Drummond Reed John Bradley Nat Sakimura Brian Eaton AGENDA 1) DNS DISCOVERY UPDATE Peter expects his next update will be the middle of next week. 2) XRD 1.0 - HOST META REVIEW Eran sent out the new draft for review: http://www.ietf.org/internet-drafts/draft-nottingham-site-meta-01.txt Eran mentioned that the name of the file (currently /host-meta) is still under discussion. One other key area of feedback has been about more tightly defining the semantics of Link fields. They need to include: 1) host name, 2) port number, and 3) what protocol you are going to speak. Be default, the /host-meta file is authoritative only for the host, port, and protocol you used to obtain it. An application can then make its own decision to treat the /host-meta file as authoritative for a greater or lesser scope. A second key point is that many readers have been assuming a tight binding between a URI and the /host-meta file that describes the resource identified by the URI. Eran said that an application must first decide, for a URI, what context the application needs to interact with the URI (e.g., via what protocol), and see the /host-meta that applies to that context. A third are where Eran and Mark Nottingham are looking for more feedback is security. We discussed HTTPS retreival of /site-meta files. John said he hoped HTTPS retreival could be used for non-https: URIs, i.e., that you should be able to get a /host-meta file securely even if it is for http: URIs. Eran said that decision was application-specific. Perhaps the easiest way to do that is for the HTTP version of the file to redirect to the HTTPS version; that would be a clear way to delegate. Eran believes this redirection should be to the exact same host and port for maximum security. However, the trust models for /host-meta delegation are still application-specific. Applications can be defined to only use HTTPS /host-meta files, or they can be defined to use HTTPS only when HTTP /host-meta files redirect to them, or any combination that meets the apps security requirements. 3) XRD 1.0 - DESCRIPTOR DISCOVERY UPDATE/ISSUES # ERAN will post a new draft of the discovery spec today. 4) XRD 1.0 - SCHEMA UPDATE/ISSUES Eran posted the basic proposed schema. See the thread beginning: http://lists.oasis-open.org/archives/xri/200902/msg00020.html Eran would very much like a close review of the definitions of each element (the actual element names are easier to change - what we need is consensus on the definitions). # DRUMMOND - wikify the email from Eran if he or others do not do it first. # ALL - please do a close review of the definitions ASAP. 5) XRD 1.0 - TRUST TEAM UPDATE/ISSUES Nat was completely swamped last week and Brian just got back from vacation. Brian listed the following major action items: a) Synonym binding trust profile. b) Signing format (i.e., moving forward with his XML dSig profile proposal). On (a), Brian is primarily focused on use cases where you "must find an XRD that directly describes the identifier you are working with", and therefore doesn't need synonym binding trust. He is skeptical about the trust challenges with synonyms, but we need to analyze it further. We discussed that the two current use cases we have that do need synonym binding are OpenID delegation and XRI trusted resolution. Brian's suggestion for moving forward on this action item is to start by publishing a strawman synonym binding trust profile, and then look at how that works for OpenID delegation, XRI synonym verification, etc. # JOHN AND DRUMMOND to propose a synonym binding trust profile via the list or wiki. On (b) Brian noted that Gabe commented on the list on some of the downsides of using XML dSig artifacts. Brian explained that writing it as a profile of XML dSig was the most practical approach, because he would rather reference their language than cut-and-paste it to create something new. Nat also wants to get feedback from the SAML Simple Sign editors. # ALL - Either identify issues or provide feedback on the XML dSig profile proposal: http://wiki.oasis-open.org/xri/XrdOne/XmlDsigProfile 6) XRI 3.0 - SYNTAX AND BINDINGS UPDATE Drummond reported that he hasn't made much progress and still needs to review Nick's initial work on the info: binding. He hopes next week will provide more time. 7) NEXT CALL & SELF-SERVE AGENDA PAGE A reminder to use the self-serve agenda page for next Tuesday's call: http://wiki.oasis-open.org/xri/SelfServeAgenda
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]