-----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.

--- peterd

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.