RE: [wss] Proposal to Label Tokens to Indicate Their Semantics

["Ahmed, Zahid" <zahid.ahmed@commerceone.com>]

>However, I did not envision that a SOAP body might contain a number of
unrelated 
messages each with its own seperate set of participants. While I concede
that 
>this possibility is not prohibited by the SOAP specification, it seems a
poor and 
>inefficient application design. Is this something you see as likely? DO you
have a 
>usecase in mind?
 
No that's not what I meant. I agree it is good practice for a SOAP message 
envelope typically contains a single document instance (from application 
point of view). However, a SOAP message could also have secondary parts 
(attachments) with possibly little or no important content in the body. 
This is besides the point. 
 
When a SOAP message traverses multiple nodes over some message path, 
it is possible that certain tokens are produced and/or needed to be attached
to 
a SOAP message at each processing node. These SOAP nodes could be in 
different security domains. Should we have any relationship and/or grouping 
of these tokens that may be pertaining to different principals at each node?
 
For Example:
 
[UsernameToken#A added]                [AssertionToken#A, BinaryToken#A
added           [BinaryToken#A removed  
                                                            and
UsernameToken#A  removed]                         and AssertionTokenB added]

<Node#1>---> SOAP Message #1 ------> <Node#2>  -------------> SOAP Message#
2     <Node#N> ----> SOAP Message # N
 
Note that some tokens, e.g. Assertion Token may be carried forward, i.e., be

part of the next SOAP message.
 
 
>> 2) Since additio:nal <tokens> element may be added, wouldn't 
>> it make sense to be able to optionally encapsulate them together in some 
>> security header  child element? 
>I don't really understand this question. Do you mean added to the message
or added to 
>the schema? I have only proposed adding a single Tokens element to the
schema. Perhaps 
>this question is simply a restatement of the first one.
 
You show in your example multiple <tokens> elements possibly carried in one
SOAP wsse:Security header element. So, although I agree that we need to
be able to add a Tokens schema definition. The question is about
encapsulating
them in some type of container that provides semantics of ordering.
 
>Is "target node" a defined term? Even if I take a guess at what that means,

node is defined in section 1.4.1 of: 
http://www.w3.org/TR/2002/WD-soap12-part1-20020626/
<http://www.w3.org/TR/2002/WD-soap12-part1-20020626/>  
 
Target node here basically refers to next node in SOAP messaging path.
 
>Except that the XML tokens are "just inserted" so extending them requires
extending 
>(if possible) other schemas outside of wsse: Furthermore in the case of XML
tokens, 
>they will typically come already signed by some authority. In my proposal,
the Purpose 
>would fall outside of this signature (although within a message signature)
because the 
>same entity might take on different Purposes with respect to different
messages, while 
>being represented by the same token, e.g. a SAML assertion containing an
Attribute 
>Statement. 
 
Yes, agreed.
 
thanks,
Zahid