|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:19:42 am|
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?
-----Original Message----- From: Peter C Davis [mailto:pete...@neustar.biz] Sent: Friday, February 04, 2005 9:12 PM To: xri-...@lists.oasis-open.org Subject: [xri-editors] further thinking on mustUnderstand
On todays editor's call, we (I) proposed a usecase where mustUnderstand may be relavant:
Consider the case where extension to the resolution spec require security tokens in order to process/authorize (some) portion of a resolution. These tokens may be resolver tokens, or tokens provided by Authorities, in order to allow downstream authorities to make authorization decisions for resolution response. It would be required:
- that a lookAhead resolver be able to personify the resolver for look-ahead requests (and thus MUST understand the security tokens provided by the client in order to provide proper resolution services.
- that a client MUST understand tokens provided to them from an authority, which are necessary to perform the next-level resolution to another authority (outside the 2nd level authorities normal trust boundary).
now granted this is a hypothetical (by to me at least, reasonable) scenario that provisions for mustUnderstand would need to be employed...
In protocol SOAP bindings, these relate to processing requirements of the s:Header, and we have no such 2-part messaging in XRI resolution, however, in SOAP, the sorts of tokens passed as above, are placed in the header.
In the case of XRI Res, these tokens would need to be extracted from the XRID, and placed into the HTTP(S) header. kinda odd, but that's one of the challenges with REST ;-).
WS-Trust and Liberty specs have these token profiles, and use them often... i think this design pattern is a good one to follow.
this message aims to: a] spurning further dialog on the subject, resulting in b] closure on this issue.
BTW: there may be usecases such as these in trusted resolution, but i have not thought that through just yet.
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-editors/members/leave_w orkgroup.php.
-- 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