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

[ronald monzillo <ronald.monzillo@Sun.COM>]

It was proposed in today's teleconf, that the resoltion of this issue, 
issue 3 in the issues
list, is related to the resolution of issues 4 and 5 in the issues list.

3 Technical  Open Proposal to Label Tokens to Indicate Their Semantics 
http://lists.oasis-open.org/archives/wss/200209/msg00036.html. 
<http://lists.oasis-open.org/archives/wss/200209/msg00036.html>  There 
are various active threads underway. Hal Lockhart
4 Technical  Proposed resolution Why is the token in the header, and not 
a child of KeyInfo? Membership should review the merged documents and 
compare to the four security profile documents.
  TC
5 Technical  Proposed resolution Within the KeyInfo, why not use a 
ds:RetrievalMethod? Phillip Hallam-Baker and Anthony Nadalin to propose 
solution.


I agree that the these issues are related, and that it is important to 
come up with a proposal that
addresses them together.

Hal Lockhart wrote:

> I can live with this, however I must point out that this does not 
> permit the possibility of grouping several tokens to indicate that 
> they refer to the same system entity.
>
> On a slightly different topic, when I started this thread I should 
> have pointed out that merely having the labels does not assure that 
> they can be believed. Specific uses of signatures or other protocol 
> exchanges will be required to securely verify that the parties in 
> question are actually originators, intermediaries, codebases on the 
> call path and so forth. I would be willing to help develop specific 
> specifications along these lines as an effort separate from the 
> current specifications, either in this TC or elsewhere.
>
I'm not exactly sure how to interpret what Hal said above, but it may 
relate to my motives for
raising issues 19 and 23 which I believe to also be related to isues 
1,3,4,5.

19 Technical Open Core: Why is it necessary to special case a 
Username/Password POP token? 
http://lists.oasis-open.org/archives/wss/200209/msg00095.html
Ronald Monzillo

23 Technical Open Core: Make Proof-of-Possession a fundamental type or 
relationship within [sic] within the ws-security model? 
http://lists.oasis-open.org/archives/wss/200209/msg00095.html
Ronald Monzillo


That is, signatures, and username password tokens are proofs, and I am 
proposing that we
encapsulate such proofs within an extensible and suitably attributed 
token such that we can:

1. indicate what claims are being proved based on more flexible 
relationships between
    proofs and security tokens. For example one signature should be 
suffcient to prove
    access to all the security tokens that require the sender to 
demonstrate knowledge of
    the same key.
2. add additional semantic labels to indicate what is being proved, or 
to indicate the
    intended role of the proof. For example, we might want to be able to 
differentiate
    an proposed proof of authorship, from a proof intended to establish that
    the author and the sender are the same entity (or at least both knew 
some secret).
3. decouple key retrieval from the token containing the claims, for 
cases where the proof
    is not based on proving knowledge of the key in the security token.
4. allow for the unification of various forms of proof within an 
extensible wrapping token,
    (this is related to issue 1 in that it could allow for signature 
mechanisms extensibility)

Ron

> Hal
>
> > -----Original Message-----
> > From: John Shewchuk [mailto:johnshew@microsoft.com]
> > Sent: Monday, October 07, 2002 8:47 PM
> > To: Krishna Sankar; wss@lists.oasis-open.org
> > Subject: RE: [wss] Proposal to Label Tokens to Indicate Their
> > Semantics
> >
> >
> > Perhaps we might consider taking the proposed attribute and make it a
> > global attribute. Perhaps something like wss:Purpose. 
> >
> > This global attribute could then be applied to any security token
> > format. 
> >
> > Also, is the purpose a QName or a URI?  Which is preferred?
> >
> > -John
> >
> >
> > -----Original Message-----
> > From: Krishna Sankar [mailto:ksankar@cisco.com]
> > Sent: Friday, September 27, 2002 9:33 PM
> > To: wss@lists.oasis-open.org
> > 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
> >
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
> > ----------------------------------------------------------------
> > To subscribe or unsubscribe from this elist use the subscription
> > manager: <http://lists.oasis-open.org/ob/adm.pl>
> >
>