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

[Hal Lockhart <hal.lockhart@entegrity.com>]

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

Zahid,

I could not make out your "ASCII art" (below following "For Example:") and I am having a little trouble understanding what you have in mind. My understanding is the following:

The current document provides for security headers, which can be labeled with an actor/role indicating who is supposed to read them.

I have proposed a way that one or more security tokens be labeled to indicate their purpose.

I have further proposed that it might be desirable to allow the grouping of tokens to convey the semantic that they refer to the same system entity.

Also note that generally speaking, the security tokens in question contain information which associates the identity with some security domain or at least issuing party. Even the username token may do this, in the case of it being of the form: "fred@example.com."

As I understand it, you want to associate some further information with the tokens. I think it is the identity of the party who put them in the header, but I am not sure. If this is the case, it is not clear what the information would be used for. When signatures are used as a Subject Confirmation Method, it seems to me that what you want to know is what parties generated various signatures, but who or when or where a token came to be in the message does not seem to me to be important for security purposes.

Perhaps I am misunderstanding what you are proposing. As usual, some usecases would help clarify the requirements.

Hal

> -----Original Message-----
> From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com]
> Sent: Wednesday, October 02, 2002 9:54 PM
> To: 'Hal Lockhart'; 'wss@lists.oasis-open.org'
> Subject: RE: [wss] Proposal to Label Tokens to Indicate Their
> Semantics
>
>
> >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
>
> 
>