| From | Sent On | Attachments |
|---|---|---|
| Dave McAlpin | Feb 4, 2005 11:19 am | |
| Peter C Davis | Feb 4, 2005 11:39 am | |
| Dave McAlpin | Feb 4, 2005 11:43 am | |
| Peter C Davis | Feb 4, 2005 11:52 am | |
| Dave McAlpin | Feb 4, 2005 11:59 am | |
| Drummond Reed | Feb 4, 2005 3:32 pm | |
| Wachob, Gabe | Feb 6, 2005 2:23 pm | |
| Dave McAlpin | Feb 7, 2005 10:56 am | |
| Peter C Davis | Feb 7, 2005 11:28 am | |
| Drummond Reed | Feb 7, 2005 2:47 pm | |
| Wachob, Gabe | Feb 7, 2005 7:07 pm | |
| Dave McAlpin | Feb 7, 2005 7:22 pm | |
| Drummond Reed | Feb 7, 2005 7:51 pm | |
| Peter C Davis | Feb 8, 2005 5:45 am | |
| Wachob, Gabe | Feb 8, 2005 10:01 am | |
| Drummond Reed | Feb 9, 2005 9:20 am | |
| Wachob, Gabe | Feb 11, 2005 3:01 pm | |
| Dave McAlpin | Feb 11, 2005 3:03 pm |
| Subject: | RE: [xri-editors] further thinking on mustUnderstand | |
|---|---|---|
| From: | Dave McAlpin (Dave...@epok.net) | |
| Date: | Feb 4, 2005 11:59:39 am | |
| List: | org.oasis-open.lists.xri-editors | |
This is why MustUnderstand is so dangerous and so easy to misuse. Imagine that I'm resolving =Peter in order to discover your public key. I ask = for Peter and get back something like this:
<XRIDescriptors> <XRIDescriptor> <Auhthority>...</Authority> <Token MustUnderstand=true>...</Token> <ds:KeyInfo>...</ds:KeyInfo> </XRIDescriptor> <XRIDescriptors>
I have no interest in contacting the next resolution authority and I have no use for the security token. All I want to do is process the ds:KeyInfo element. But if I don't understand the Token element, I'm not allowed to consume ds:KeyInfo. Using Token and MustUnderstand in this way breaks the entire XRID.
What we really want is something like this:
<XRIDescriptors> <XRIDescriptor> <Auhthority> ... <Token MustUnderstand=true>...</Token> </Authority> <ds:KeyInfo>...</ds:KeyInfo> </XRIDescriptor> <XRIDescriptors>
I can imagine use cases where MustUnderstand might be useful, but every suggestion put forward by supporters has been a misuse of the attribute. I think at a minimum we should consider it very dangerous.
Dave
-----Original Message----- From: Peter C Davis [mailto:pete...@neustar.biz] Sent: Friday, February 04, 2005 9:53 PM To: Dave McAlpin Cc: xri-...@lists.oasis-open.org Subject: Re: [xri-editors] further thinking on mustUnderstand
well... they MAY be, or they may be XRI bound (that is, they are specific tokens for a resolver to use to resolve a specific authority-part subsegment with a specific authority).
--- peterd
On Friday 04 February 2005 02:43 pm, Dave McAlpin wrote:
I don't think so. Tokens, in your example, apply to authorities. They'd be placed in XRIDescriptors/XRIDescriptor/Authority/Token. MustUnderstand would be relative to the Authority, not the XRID.
-----Original Message----- From: Peter C Davis [mailto:pete...@neustar.biz] Sent: Friday, February 04, 2005 9:40 PM To: Dave McAlpin Cc: xri-...@lists.oasis-open.org Subject: Re: [xri-editors] further thinking on mustUnderstand
On Friday 04 February 2005 02:19 pm, Dave McAlpin wrote:
Both of these cases seem to argue for MustUnderstand semantics on an Authority element, not on the XRID which can describe multiple authorities. In the second case especially, a client shouldn't be precluded from processing Service elements just because he doesn't understand how to pass proper credentials to some resolution
authority.
Is that correct?
i suppose that depends on where the token extension points are placed... token placement is likely to be XRIDescriptors/XRIDescriptor/Token, since these are (potentially) unique for each authority, and required for processing 'next-level' resolution.... in this use case.
SO the processing would require (a) resolver to process the XRID, extract the Token, and add that to the HTTP header for the next resolution step. that seems to require modifications to the XRID.
--- peterd
-- No virus found in this incoming message. Checked by AVG Anti-Virus. Version: 7.0.302 / Virus Database: 265.8.5 - Release Date: 2/3/2005





