[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Minutes:Joint XRI & XDI TC Telecon 10AM PT Thursday 2007-09-20
[My apologies for late posting of these minutes -- I was travelling and only finished them on the plane last night.] Following are the minutes for a joint unofficial telecon of the XRI and XDI TCs at: Date: Thursday, 20 September 2007 USA Time: 10:00AM - 12:00PM Pacific Time Event Description: Weekly unofficial joint call of the XRI and XDI Technical Committees. TO ACCESS THE AUDIO CONFERENCE: Dial In Number: 571-434-5750 Conference ID: 5474 PRESENT Wil Tan Drummond Reed Markus Sabadello Peter Davis Kermit Snelson Victor Grey Gabe Wachob AGENDA 1) CLARIFICATION OF REF PROCESSING Steve Churchill sent a question the list the morning that overlaps with a question from Victor Grey and Kermit Snelson. Currently the spec calls for iterative Ref processing, i.e., if XRD A has Refs A1, A2, and A3, and processing Ref A1 yields an XRD B that does not have the requested service endpoint, but has Ref B1, then is Ref B1 followed? The answer is yes, this is the correct behavior. The next question is whether, if Ref B1 is a dead-end, does the resolver try A2? This may not be explicit in the flowchart in section 8.1.2 of ED05. After a long discussion about "backtracking", it was agreed that resolvers should not do backtracking for all the reasons the TC has concluded in earlier discussions. Specifically: 1) With backtracking, an error in a ref chain may go undetected. Without backtracking, the error will be detected/reported immediately. 2) With backtracking, refs are "multidirectional", i.e., resolvers potentially need to follow multiple ref paths to different authorities, and resolution behaviour can become very hard to predict/test. Without backtracking, refs are unidirectional - once you start down a path, you stay on that path. This means all Refs in an XRD should point to the same logical authority, with the goal of providing provide redundancy. XRDS authors can still chain together refs across a set of authorities to distribute XRDS control, but the path through those refs is deterministic. (Note: for fine grained control at the service level, an XRDS author can use service refs.) 3) With backtracking, resolution could be much slower. Prohibiting backtracking encourages faster response. We clarified that if a resolver encounters any form of error that prevents it from successfully resolving a ref ((i.e., any result that is not a 1xx), then it MUST try the next ref. However as soon as the resolver successfully resolves a ref to an XRDS, it is now in a new XRDS path, and it never backs out of that XRDS path. Victor then asked if you try a URI in a Service element and it fails and you try a second one and get an XRDS but not what you are looking for, do you backtrack? Again, our consensus was no, once you successfully retreive an XRDS, you are now on a new XRDS path. # DRUMMOND to make sure this rule is clear by adding a Backtracking section to the Refs section, plus additional text and flowchart annotations in the Generic Protocol section as necessary. # WIL to respond to Steve's message to the list. 2) OTHER QUESTIONS AND FEEDBACK ON XRI RESOLUTION 2.0 WD11 ED05 Victor and Kermit have implemented CanonicalID verification and other features of ED05 in their rxripr (Ruby XRI Proxy Resolver) and compiled the question list below. Each question is followed by bullet points regarding the discussion/decision and pound signs for action items. 1. Let's assume that an authority resolution request is made with ref=false and cid=true. If there were Refs that were not followed because of that, we should return a <Status> of "101 - REF_NOT_FOLLOWED", but if we verified the CID we should return a <Status> of "110 - CID_VERIFIED". How can we indicate both? And of course, all the permutations of that scenario. * We had a long discussion about this. The conclusion was that it would be a better architecture to have 1xx status codes reflected as status attributes and not separate error codes, as this prevents "status code explosion". (Note: this was the same decision we came to regarding trust parameters. For example, instead of trust=https+saml, now each trusted resolution parameter is its own boolean, e.g., https=true;saml:true.) * So our conclusion was to add three attributes to the Status element: ** refs= is a boolean. The default is true; if absent or empty, it is true. ** cid= and ceid= both take an enumerated list of four values: absent, verified, failed, off. The default is true; and if absent or empty, it is true. - making them optional, if absent, refs=true, cid=off, ceid=off. Deprecate 101 error code. The default is off; and if absent or empty, it is off. # DRUMMOND to make this change throughout in ED06. We also agreed that section 14 should be renamed "Status Codes". # DRUMMOND to make this change throughout in ED06. 2. In https trusted resolution, we are reading the spec to say that in order to use a $res*auth type service, the Service element has to BOTH have an HTTPS URI, and contain an element exactly like this: <MediaType>application/xrds+xml;https=true</MediaType> Have we got that right? * Yes. We discussed this and there was consensus that although it appears redundant, it leads to simpler processing for consuming applications and is in keeping with the rule that new authority resolution services can be added using new media types or media type parameters. * Also, the same applies to self-describing XRDS documents, including community roots. # DRUMMOND to add a note in ED06 amplifying this rationale. 3. If we are not supporting SAML at this time, and we receive a request with saml=true, my take on it is that rather than attempting to do -any- resolution, we should immediately return an XRDS that looks like this: <XRDS xmlns="xri://$xrds" ref="xri://=example"> <XRD xmlns="xri://$xrd*($v*2.0)" version="2.0" > <Query>*example</Query> <Status code="201">NOT_IMPLEMENTED</Status> </XRD> </XRDS> * Yes, return the above. Also, is it within spec when returning a 201 to change the text message to something more informative, like "SAML_NOT_IMPLEMENTED" ? * Yes, you can and should do that. More descriptive error message text is encouraged. # DRUMMOND to ensure the text in section 14 is clear about this. 4. When attempting to satisfy an "https=true" authority resolution request, if we find no $res*auth service at all, but there is a <Ref> element, should we follow that to see if it is trusted-res compliant? * Yes. IMPORTANT: If https=true, Refs must also be https URIs. # DRUMMOND to ensure this is clear in ED06. How about if we do find a $res*auth service, but it is not trusted- res compliant, and there is a <Ref> element? Having failed trusted- res on the Service elements, do we then report a 231 error, or do we follow the Ref to see if it can provide a trusted-res resolution path? * Only if the service ref is HTTPS. # DRUMMOND to check ED06 to make sure this is clear. Also, how about if there is a $res*auth service, and it either is missing an HTTPS URI, or is missing the correct <MediaType> element, or both, and has a <Ref> inside the <Service> element. Do we follow the Ref or fail right then? * If a Service is marked with the https media type, then it MUST have at least one https URI. If the service endpoint fails this test, then the resolver should fail immediately (if there is no other service endpoint that matches). # DRUMMOND to add text to ED06 to make this clear. 5. We think the spec should say that when following Refs, the implementation SHOULD check to see that each URI it follows is unique. Otherwise there is a security vulnerability where an attacker could create a denial of service condition by putting up an XRD that produces a circular reference (i.e. an infinite loop). * Agreed. After some discussion we concluded that it would be good to have a separate status code for detecting a circular reference, so it was faster to debug. # DRUMMOND to add error for LOOP_DETECTED - one for 22x (authority resolution) and one for 24x (service selection). 6. And last but not least, having followed one or more Refs, and having put together a final XRDS that contains other XRDSes, what does that do to CID verification? I assume that CID verification should only examine the chain of XRDs relating to the original set of XRI subsegments, and not look inside the enveloped XRDS -- is that correct? * This actually involves two questions: A) does the resolver need to check all XRDs in all XRDS documents, or only the outer XRDS and not any nested XRDS? B) Is the CanonicalID chain checked inside each XRDS document, or between documents? * The answer to (A) is that CanonicalID verification is performed on all XRDs in all XRDS documents in the entire resolution cycle. However CanonicalEquivID verification is only performed on the VERY LAST XRD in the entire cycle. * The answer to (B) is that each CanonicalID verification chain applies only within a single XRDS document. So even though Ref processing can produce a nested XRDS document, if resolution continues back inside the parent XRDS document, the CanonicalID verification rules (that each CID must be a direct child of its parent) applies to the last parent *in that same XRDS*, not in the nested XRDS. The same applies for each nested XRDS. # DRUMMOND to clarify and illustrate in ED06. 3) SCHEDULE FOR COMPLETION OF WD11 Drummond reported that although he is travelling this week and will be at Digital ID World next week, he'll work as fast as possible to complete ED06. The goal is to have it complete, both with all action items on... http://www.oasis-open.org/committees/download.php/25307/xri-resolution-v2.0- wd-11-ed-05.pdf ...as well as the additional action items in these minutes. This will likely not be completed until after Digital ID World, however the good news is that this should be the final draft. After one round of final review, it should be ready for a vote the week of October 8.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]