OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


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


Hi all,

    Extending the good discussions (by Hal, Zahid, Jerry et al),  I
propose an element structure (uniform for all forms of tokens) as
follows :

<Tokens>
    <Token id="T1" URI="xxxx" type="xxxxx" purpose="xmxmxm">
    </Token>

    <Token id="T2" URI="xxxx" type="xxxxx">
    </Token>
 
    <Token id="T3" URI="xxxx" type="xxxxx">
    </Token>
</Tokens>

We would need to define the type codes and the purpose codes. I think
both can be extended for domain specific applications. Don't know if
this will affect interoperability, in that case we would need to curtail
the codes.

There are a few possible traps/issues on processing model here I can
think of :

A)	Signature inheritance rules
B)	The explicit or implicit relationship between the tokens
themselves (are they related, any ordering - for example authC -
policies - authZ, ...
C)	The explicit and implicit relationships between the tokens and
elements outside the <Tokens>
D)	Are the tokens valid outside the context and if so how so
E)	Extensibility mechanisms. As we have no idea what the different
types of tokens could be used and we want to facilitate *ALL* forms of
future tokens this might be very important.
F)	Multiple <Tokens> elements or allow only one <Tokens> element ?
	If multiple, then we need to have attributes for the <Tokens>
element as follows:
	<Tokens id="mmm" URI="mmm" purpose="cncnc">

P.S/1: Pardon me if I am out of sync. It is possible discussions have
occurred in this area. Am still traveling :o( and didn't want to lost
the thoughts.

P.S/2: If I may, I have a question to the original authors of
WS-Security. Was there any reason for not having a container like
<Tokens> for the various tokens. I assume, in the original submission,
the various tokens stand by themselves with out any implicit
relationships to each other. How were you planning to handle Token
bundles ? It is possible I missed some semantics.

cheers
-----Original Message-----
From: Ahmed, Zahid [mailto:zahid.ahmed@commerceone.com] 
Sent: Tuesday, September 24, 2002 8:19 AM
To: Hal Lockhart; wss@lists.oasis-open.org
Subject: RE: [wss] Proposal to Label Tokens to Indicate Their Semantics


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

Hal,

I agree with this proposal. However can there be multiple <Tokens>
elements within
a SOAP security header extension?

thanks,
Zahid


  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 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC