RE: [xri] Trusted Rev Draft

["Wachob, Gabe" <gwachob@visa.com>]

Dave-
	Feedback follows. I'm very happy with this document in general. 

GENERAL: 

* Would it be useful (or neccesary) to talk about how secure resolution might affect the operating relationships between authorities, and specifically talk about deployment and what sort of coordination is required? What impacts are there for deploying secure resolution data above and beyond normal resolution data. For example, not only do authorities have to get "pointed at", they also have to submit their AuthorityID's to their "upstream" authority. 

* To make processing easier, I've defined the content model of the XRIDescriptor (and its children) to allow any elements *after* the defined elements. That is, if you are going to insert new elements (in this case, the xrit: elements), they must appear after all the elements defined in the base XRIDescriptor namespace. So, for example in your first example (the examples don't have captions - they should!), the ds:KeyInfo element which is the immediate child of the XRIDescriptor should come after the last element defined by the XRI Syntax and Resolution spec - in this example, the ds:KeyInfo should come *after* LocalAccess element in this example. The idea is make it easy for "dumb" processors to detect extension elements and be able to say "OK, I'm done, I can ignore everything else". 

* Captions and figure/example numbers should be included so we can refer to them ;-)

* Shouldn't we talk about signature validity conditions? Specifically about how long the signature of a resolution result can be trusted? Keys themselves have a lifetime, typically, so that provides an "outer bounds" for signature validity lifetime, but shouldn't there be a way to constrict this span much more? In other words, express that a signature should only be trusted for a limited period of time? 

FEEDBACK ON SPECIFIC TEXT:

98-99: The tone and/or voice here should be a little more formal. For example,  "Before we look..." doesn't fit with the rest of the spec.

133: "Confidently" - while I know what you mean, need to use a more descriptive phrase - perhaps "Associating an IP address with a domain name in a trusted and secure manner..."

148: Typo - "@exmple." should be "@example."

212-233 See bullet "GENERAL" comment about extension elements appearing after "core" elements 

291-215 This example omits the ds:KeyInfo element.. If I'm interpreting this correctly, it is legal to do this, but it implies that there are no further authorities beyond =example.home.base Perhaps some verbiage saying just this would be useful, so the absence of ds:KeyInfo is better understood and by implication, the purpose of ds:KeyInfo is highlighted. 

357: Yes, a simple schematron would be useful. Put that down as an action item for Gabe.

358: Yes, definitely need to talk about the interaction with redirects. Feel free to impose further restrictions on HTTP redirects as well. 

383-384: Talking about failure to verify a resolution step - what about the ability or advisability of a client to try and alternate resolution step. For example, if two URIs are listed under and XRIAuthority element, and one fails to do "xritrusted=true", do we suggest that a client is free to try the other URI? What if the next authority gives back a signed authority, but the signature validation fails? Should there be language making this "alternate" behavior ALLOWABLE, REQUIRED, or SUGGESTED?

386: Yes, schematron++ - put it down on my todo

387-388: YES, should discuss HTTP redirects and how it interacts with the security mechanism. 

407-412: Not completely sure, but I think KeyInfo should NOT be optional. The fewer implied or unspecified sources for data the better (from an interop POV), usually. Are there good reasons in our context to allow omission of KeyInfo? What is the DigSig spec addressing with this? 

416: "the value that will appear in the xrit:AuthorityID element of an XRI Descriptor retuen dfrom the described XRI Authority" - in this context, I get confused about the term "described XRI Authority".. What exactly are we referring to? 

459: I think the Security Considerations is very important here. This is a "trusted resolution" specification after all ;-)

    -Gabe 



-----Original Message-----
From: Dave McAlpin [mailto:dave.mcalpin@epok.net]
Sent: Friday, March 12, 2004 3:21 PM
To: xri@lists.oasis-open.org
Subject: [xri] Trusted Rev Draft


I just posted a first draft of the trusted resolution spec. It's got quite a
few comments and TODOs, but I think it's complete enough to evaluate.
Feedback is very much appreciated.

Dave


To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/xri/members/leave_workgroup.php.