further thinking on mustUnderstand

[Peter C Davis <peter.davis@neustar.biz>]

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.