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

[Jerry Schwarz <jerry.schwarz@oracle.com>]

I support Hal's proposal for several reasons.  Among them is that it
can be modified to solve a problem that bothered me.  

The "Profile for XML-based Tokens" that we adopted at our
organizational meetings had to work around the problem that a
SecurityTokenReference needs to be able to reference an arbitrary
security token.  The mechanism proposed in the original WS-Security
was not adequate to reference SAML elements and so the authors of
"Profile for XML based Tokens" proposed an extension. 

If we add an ID attribute to Hal's Token element then references will
always be possible and won't have to worry whether profiles for new kinds
of security token will need to invent new mechanism's for referencing
them.

At 07:21 AM 09/17/2002, Hal Lockhart wrote:

> This is the idea I
> introduced near the end of the F2F. 
>
> Requirement 
>
> WS-Security proposes a SOAP Security Header that can contain
> tokens of various kinds which represent the identity and attributes of
> some system entity. I cannot find any explicit statement of the intended
> semantics of these tokens with respect to the particular message they
> appear in, however from the context it appears the intention is that the
> token represent the identity of the sender. It is also possible that the
> intention is that this semantic not be specified by WS-Security, but in
> some other, future specification. However, neither intention covers the
> cases where two or more system entities with different relationships to
> the message must be represented and distinguished.
>
> Some example usecases where this is applies include:
>
> 1) Patient requests his or her medical records be sent to specialist physician. Authorization decisions depends on identity and attributes of both Requester and Recipient, who are not the same entity.
>
> 2) Passive delegation requires that authorization depend on the identity and attributes of the Requester and any Intermediaries.
>
> 3) Some authorization models, e.g. Java and .Net, consider the Principal identity associated with the local or remote Codebase from which the request originates as well as that of the Requestor.
>
> Possible Approach 
>
> What is needed is some way to optionally label each token as to the Purpose of the system entity being identified. Associating the token with the Requester should remain the default, if the Purpose label is omitted.
>
> This "Purpose" should not be confused with the SOAP actor/role, which specifies who should READ various parts of the header, not the parties on whose identities and attributes authorization will be based.
>
> There is more than one way to do this given the schemas already defined or proposed. Here is one possible approach. 
>
> Add an optional new element called something like "Tokens" which can contain one or more tokens of any type (including other XML schemas such as SAML, XrML or XACML). Tokens has an attribute called "Purpose" the value of which is a URN indicating the relationship of this entity to the message. Define a set of URNs to cover the common cases including:
>
> Requester 
> Recipient 
> Intermediary 
> Codebase 
>
> Others could be added as needed. All the tokens within a given "Tokens" element would be deemed to have the same purpose, but not necessarily refer to the same system entity. (Consider multiple intermediaries, multiple codebases, etc.) If "Tokens" is not specified, Requestor would be the default Purpose.
>
> Another technical approach would be to define a Token abstract and derive UsernameToken, BinarySecurityToken and TokenReference from it. Also derive a new type NativeToken (XMLToken is illegal) to serve as a wrapper for XML tokens. The Token abstract would carry the Purpose attribute, as above. This is a more extensive change to the schema currently proposed.
>
> One difference between the two would be that in the latter approach, it would be necessary to allow duplicate Purpose values on different tokens within the same Security header. With the former approach, this could be prohibited if it was deemed desirable to do so.
>
> I am not hard over on the names Token or Purpose. Any scheme which meets the requirements is fine with me. The name Purpose was chosen mainly because the obvious choice "role" is already being used in several different ways and I did not want to add to the confusion.
>
> However, it is possible that this scheme could also be used in ways that do not involve representing an identity associated with the origin of the message. In this case, the use of a vague term such as Purpose would be an advantage.
>
>   
> For example, a response message could contain a XACML policy or XrML license which indicates the authorization rules to be applied to the content in the message body (which presumably would be encrypted) by the Recipient. In this case the Purpose might be something like "authorization policy".
>
> Hal