[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-07-16
Following are the minutes of the unofficial telecon of the XRI TC at: Date: Thursday, 16 July 2009 USA Time: 2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC) ATTENDING Eran Hammer-Lahav Scott Cantor Nika Jones Joseph Holsten Breno de Medeiros John Bradley Nat Sakimura George Fletcher Drummond Reed REGRETS Will Norris (on vacation) 1) XRD 1.0 - LINK PROCESSING RULES See this thread: http://lists.oasis-open.org/archives/xri/200907/msg00075.html Eran's proposal is "best match", i.e.: * Once an XRD is retrieved, the processor looks for a link match. * If it finds exactly one, it is done. * If it finds more than one, it selects based on priority (identical priority = random selection) * If it finds none, it looks for linked XRDs. * It it finds exactly one, it follows it. * If it finds more than one, it selects based on priority (identical priority = random selection) We didn't discuss backtracking in the case of multiple XRD links. This is still an open issue. We discussed that if XRD link behavior is application specific, that makes it hard/impossible to develop a generic XRD library. So standardizing XRD linking has real advantages. We discussed using a dedicated XRD element for linked XRDs vs. a regular link. The consensus was that XRD links needed all the same processing as regular links, so we should just use a link. # ACTION: ERAN to post to the wiki/email the list with several options for how best to structure XRD links. 2) XRD 1.0 KEY MANAGEMENT The next topic was key management and how ds:KeyInfo was going to be used, as discussed by Scott and Nat on the list. Scott clarified this by saying there are three places ds:KeyInfo can appear: 1) Inside a signature. 2) Inside a link. 3) At the XRD level. The first two uses are clear: when ds:KeyInfo is inside a signature, it is the key info for the signer. When inside a link, it is key info for the signer of the target XRD. The third case is new. There was concensus that ds:KeyInfo at the XRD level should represent the key info of the XRD Subject, even if the subject is not the signer of the XRD. Scott also explained that SAML found that in some cases ds:KeyInfo was not enough, and that it needed to be wrapped in another element. John said that a rising requirement is the need to transition from XRD discovery/trust to SAML metadata discovery/trust. Breno said that there are two trust phases: a boostrapping phase, and a chaining phase. XRD must define the XRD bootstrapping phase, and then the XRD chaining phase, but could transition over into other signing protocols such as PKIX. Scott said that we should not duplicate what PKIX does. # ACTION: Scott to send a proposal to the list on what should be included in the XRD trust section. 3) LRDD - SUBJECT OF A HOST-META XRD See: http://lists.oasis-open.org/archives/xri/200907/msg00007.html Eran said he had not heard any opinions back about this. The consensus on the call was to just go with Eran's proposal for describing a "SubjectSet" with a very simple XML structure, and to NOT make it extensible. We then discussed if this should be defined in LRDD or XRD. The consensus was XRD. # ACTION: ERAN to proceed with a writeup of the proposed SubjectSet element. 4) XRD 1.0 SPEC STATUS/IMPLEMENTATIONS Joesph asked how close we were. Eran said the XRD 1.0 schema is done, and we just need to decide about the trust section, and the remaining open issues on LRDD. Eran also said Mark Nottingham has just posted his Link Header spec (revision 06) for IETF last call. This is our last dependency. # ACTION: ERAN and WILL to coordinate on the next draft. # ACTION: ERAN to determine if the XRI TC can provide any support for Mark's draft at IETF. 5) XRI SYNTAX 3.0 WORKING DRAFT 02 STATUS/ISSUES No change since the last report: Drummond is making progress but will not have this ready until early August due to travel/vacation time. 6) NEXT CALL Next week, standard time. Note: Drummond will be on vacation next week so he will not be able to attend; someone else will need to send an agenda and take notes.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]