[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-02
Following are the minutes of the unofficial telecon of the XRI TC at: Date: Thursday, 02 July 2009 USA Time: 2:00PM - 3:00PM Pacific Time (21:00-22:00 UTC) ATTENDING Bill Barnhill Markus Sabadello Drummond Reed Will Norris Scott Cantor Joseph Holsten John Bradley Tatsuki Sakushima Nat Sakimura Eran Hammer-Lahav Breno de Medeiros AGENDA 1) XRD 1.0 ELEMENTS FORMERLY KNOWN AS TARGETSUBJECT AND TARGETAUTHORITY The proposal is to use just Subject and ds:KeyInfo at both the XRD and Link levels. See the writeup at: http://wiki.oasis-open.org/xri/XrdOne/TrustElements Note that this wiki page also includes a writeup of some of the basic trust verification rules. Will and Drummond explained the rational for keeping the same element names at the XRD level and the Link level, since the semantics are equivalent in both cases -- all that changes is the referent. DECISION: WD02 will use <XRD:Link:Subject> and <ds:KeyInfo> at the link level. 2) XRD 1.0 - COVERING XRD LINKING AS A SEPARATE SECTION Will has pointed out that a Link with a describedBy relation has special processing rules associated with it, so he proposes that we have a special section in the spec that explains these rules. This involves several subissues. 2A) TERMINOLOGY FOR LINKED XRDS We discussed whether the XRD 1.0 spec should use the term "XRD delegation". DECISION: There was agreement that since our fundamental term for relations between resources is "Link", we should use the neutral terms "Linked XRD" and "XRD Linking" instead of "Delegated XRD" or "XRD Delegation". There was also consensus that we should use this term consistently throughout the spec. 2B) FORMAL DEFINITION OF A LINKED XRD The second question is what formally constitutes a linked XRD. Will explained that from an LRDD perspective, it is a <XRD:Link> whose <XRD:Link:Rel> value is "describedBy" AND whose <XRD:Link:MediaType> value is "application/xrd+xml". Will suggested that the spec define a single URI that can be used as a <XRD:Link:Rel> value for the exclusive purpose of expressing the combination of both of the above statements, i.e., it would be semantically equivalent. However that would only be useful to implementers if the spec mandated that this <XRD:Link:Rel> value MUST be used for all XRD Links, which would potentially supercede the use of describedBy. This remains an open issue. # WILL AND DRUMMOND to raise this question with Eran on the list. Will: can we use a specific URI for the Rel, besides Rel of describedBy and mediatype of XRD. These two should be semantically equivalent. 2C) LINKED XRD SECTION OF THE SPEC DECISION: It was agreed that XRD Linking is so important from an XRD processing perspective that it should be covered in its own section of the spec. 3) XRD 1.0 - LINK PROCESSING RULES Drummond summarized that different link processing rules result in different behaviors. For example, under XRI Resolution 2.0, a processor looked for a Ref element (the equivalent of a Linked XRD in XRD 1.0) and followed it (in priority order) before it would look for any Service (the equivalent of a Related Resource in XRD 1.0) in that same XRD. Since in XRD 1.0, all related resources (included a delegated XRD) are described by <XRD:Link> elements, Will has proposed processing Links strictly in priority order. This means, for example, that if an XRD author wants a Link to an OpenID service to be checked *before* a Linked XRD (that may contain a different OpenID service), the author can do this simply by giving the first Link a higher priority than the second -- and vice versa if the opposite ordering is desired. (Identical priority means the choice between the two will be made at random.) Will and Drummond prefer this rule because it is simple for everyone -- XRD implementers, authors, and readers -- to understand. It also works iteratively across a chain of delegated XRDs. John agreed that it appears to offer at least the same if not greater flexibility than XRI Resolution 2.0. Another important processing rule decision is "backtracking". This is when an XRD processor follows a Link from a first XRD to a second delegated XRD, then processes the Links in the second XRD in priority order. If it still does not find what it is looking for, Will and Drummond believe the processor should "backtrack" to the first XRD and continue processing its Links in priority order. XRI Resolution 2.0 did not allow backtracking. But that was largely because it used a more complicated schema and processing model, so backtracking would have introduced too much complexity. In XRD 1.0, the schema is so simple, and the delegation rules so simple, that backtracking should be relatively straightforward (though probably relatively rare in practice). DECISION: WD02 will: a) use Link priority to govern link processing order, b) follow linked XRDs in priority order if the desired Related Resource has not been found, and c) backtrack back "up" to the source XRD if the linked XRD does not contain the desired Related Resource. 4) ROOT XRD SIGNING Scott asked if there was an answer to his question on the list about signing the "root XRD", i.e., the first XRD in any chain of XRDs. Drummond explained that there are two overall trust models: 1) The "third-party CA model" (or "conventional PKI model"), where the certificate for the signer of the root XRD and each linked XRD is signed by a CA that the XRD processor trusts. 2) The "XRD chaining model", where the root XRD is either signed by a third-party CA, or the root of its own trust federation, or for any other reason can serve as a trust anchor, and then each linked XRD is verified using ds:KeyInfo supplied by or referenced by the previous XRD in the chain. Drummond emphasized that in the second model, any trust model can be applied to the first XRD in the chain; the XRD 1.0 spec should not constrain that aspect, only how trust chains across all the lower XRDs in the chain. Scott summarized that the second model was similar to the traditional CA certificate model but instead applied directly to XML signing. He believes that is a very useful model that XRD should support. For example, any trust federation can serve as a trusted root, and could sign the XRDs of members of the federation. There was consensus that both trust models -- and the steps necessary to verify an XRD using either of them -- must be described very clearly in the XRD Trust section of the spec. Nat pointed out this is likely to take us longer than we planned, but it is critically important to successful adoption. 5) OTHER XRD 1.0 ISSUES/WORKING DRAFT 02 PLAN Will plans to push out Working Draft 02 by the end of the week so we can begin reviewing the new text and begin suggesting text for the XRD Trust section. 6) LRDD - SUBJECT OF A HOST-META XRD Eran has requested feedback on this issue. See this thread: http://lists.oasis-open.org/archives/xri/200907/msg00007.html Eran summarized the three options: 1) Keep host-meta as an XRD, and use a different URI scheme for the Subject. 2) Create a URI set mechanism. 3) Use a different schema (not XRD) for host-meta. The first option has the challenge of establishing a new URI scheme. The second option gives us the necessary functionality but adds complexity for developers. The third option requires a new schema. Breno pointed out that option #2 seems to be the one with the greatest precision and least risk. Scott asked the question: is the goal to define an XRD for the host, or for all the resources on the host? Eran responded that the current use cases only require the latter (more specifically, the requirement is for all resources under a domain and port number.) He also said that the latter makes it easier to define Link behavior, because a Link on a resource set is an assertion that the link applies to all the resources in the set. Following is an example of what this might look like. <SubjectSet> <Scheme> </Scheme> <Authority> </Authority> <Suffix> </Suffix> </SubjectSet> Scheme would be a space-delimited list. Authority would be a valid authority identifier. Suffix could be a regex at the most complex (similar to NAPTR), or a string plus wildcards. Scott pointed out that if we use a regex, we need to specify it very precisely due to the subtle differences between implementations. Joesph and Scott both agreed that we should look at the DDDS specs because they use regex, and we may be able to adopt their approach. Joesph suggested another option: use the POWDER syntax for what they call an "IRI set". This series of XML elements compiles down to a regex. Scott said that we should either: A) Use a very simple model, or B) Properly define a general model. The mistake we should not make is either "hack up" a general model to try to simplify it, or profiling a general model and yet leave it open for extensibility. Either one is a recipe for disaster. Better to either just define a very simple model, or a clean general model, and stick to it. Breno asked whether the same mechanism defined for URITemplate could work for this (call this the "SubjectTemplate" approach). He thought the mechanism defined for URITemplate was supposed to be sufficiently generic that it could be used for email addresses, for example, so it should work here. Will pointed out that URITemplate is designed primarily for replacement, vs. matching. The same applies to NAPTR. So he's not sure whether the same mechanism will work. This is an open question to Eran. 7) NEXT CALL The next call is next Thursday at the regular time. Drummond reported that due to summer travel he most likely will not be able to be on next week's telecon. He will work with Will, Eran, and Peter to make sure it is covered.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]