[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xri] Trusted Rev Draft
Thanks Gabe. Great feedback. I'll try to have a new draft by the end of the week incorporating your comments, then respond to this mail item by item if it seems useful. Dave > -----Original Message----- > From: Wachob, Gabe [mailto:gwachob@visa.com] > Sent: Monday, March 15, 2004 11:22 AM > To: 'Dave McAlpin'; xri@lists.oasis-open.org > Subject: RE: [xri] Trusted Rev Draft > > 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]