[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xri] Minutes: XRI TC Telecon 2-3PM PT Thursday 2009-07-16
Fulfilling my action items: On 7/19/09 8:03 PM, "Drummond Reed" <drummond.reed@cordance.net> wrote: > 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. Backtracking is required here since multiple linked XRDs must be examined in priority order, and each follows the same selection process. > # ACTION: ERAN to post to the wiki/email the list with several options for > how best to structure XRD links. There is an interesting development in the Link spec that will probably allow custom link extension to mandate a media type: http://lists.w3.org/Archives/Public/ietf-http-wg/2009JulSep/0159.html If Link ends up going in that direction, I would suggest we simply define a URI relation type (not register it as short name) under the XRD namespace prefix that means Linked XRD. For parsing purposes, you look for a Link element with this child Rel and use its URI(s). Any other Rel or MediaType are ignored, while any URITemplate is left undefined. I will let Will pick a relation type URI. > 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. So... I have a question to the security folks: since we don't really need a Subject for host-meta, only a place to stick the trust subject, can we just have a Subject-less document with an XRD-level <ds:KeyInfo>? But it does require being able to put the hostname, port number, and protocol details inside the ds:KeyInfo element which I am not sure is possible. If not, my (super simple) proposal is: <XRD> <SubjectPrefix>http://example.com/path</SubjectPrefix> You can only have one of <subject> or <subjectPrefix> (or neither). <SubjectPrefix> must be a valid, absolute URI. For trust purposes, it is used exactly the same as Subject. It matches any URI with the same prefix, following URI comparison rules (we need to find a good reference). No domain wildcards allowed. We can also turn this into an attribute of <Subject>, something like 'set="prefix"' which will allow other rules in the future (such as 'set="regex"'). > 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. Will is back from vacation, still catching up. > # ACTION: ERAN to determine if the XRI TC can provide any support for Mark's > draft at IETF. Mark indicated feedback is desired, as long as it is "short and sweet". If you want to make a statement of support for making Link a Standards Track RFC, please follow the instructions on the Last Call: http://www.ietf.org/mail-archive/web/apps-discuss/current/msg00844.html EHL
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]