AW: [ws-sx] Issue 30: Need a mechanism to identify token assertions

["Dittmann, Werner" <werner.dittmann@siemens.com>]

Thanks for the better wording to make it more clear.

Yes, somthing like that. Another example would be
that a purchase order needs to be signed by two different
entities (users). In the sense of
"two different entities endorse this message".

Regards,
Werner


> -----Ursprüngliche Nachricht-----
> Von: Tony Gullotta [mailto:tony.gullotta@soa.com] 
> Gesendet: Donnerstag, 23. Februar 2006 18:55
> An: Dittmann, Werner; ws-sx@lists.oasis-open.org
> Betreff: RE: [ws-sx] Issue 30: Need a mechanism to identify 
> token assertions
> 
> Are you trying to indicate that these two tokens represent 
> different identities (users)? So you are trying to give 
> consumers an idea of which identity must sign? Maybe 
> something like an end-user vs a sponsor or application entity?
> 
> Tony
> 
> -----Original Message-----
> From: Dittmann, Werner [mailto:werner.dittmann@siemens.com] 
> Sent: Monday, February 20, 2006 4:22 AM
> To: ws-sx@lists.oasis-open.org
> Subject: AW: [ws-sx] Issue 30: Need a mechanism to identify 
> token assertions
> 
> To put an example on this issue pls have a look to the 
> attached file. It contains a WSP with several tokens at 
> different levels.
> 
> The policy defines two SignedEndorsingSupportTokens (SEST). 
> Each SEST signs a different part of the message. Because two 
> SEST are defined it is save to assume that different tokens 
> are required to sign the required parts (otherwise one SEST 
> token with two Header assertions in SignedParts would be 
> used). An implementation that creates the message according 
> to the policy needs to associate the different tokens to the 
> correct SEST. As it stands now this is not possible - the 
> implementation has no "anchor" into the policy to populate 
> the tokens. IMHO we need to have a way to identify the tokens 
> (the X.509, Username etc.).
> 
> Regards,
> Werner
> 
> > -----Ursprüngliche Nachricht-----
> > Von: Dittmann, Werner
> > Gesendet: Donnerstag, 16. Februar 2006 09:30
> > An: Martin Gudgin; Marc Goodner; ws-sx@lists.oasis-open.org
> > Betreff: AW: [ws-sx] Issue 30: Need a mechanism to identify token 
> > assertions
> > 
> > Hmm, I cannot fully agree to that. In particular  at the 
> client side 
> > we need to know which specific token to use to populate a token 
> > required by WSP.
> > 
> > For example, if there are several supporting tokens that 
> each require 
> > a different X.509 certificate then the implementation must 
> somehow be 
> > able to identify the token to associate the correct 
> certificate to the 
> > token.
> > 
> > As concrete example: a policy requires two endorsing tokens, each 
> > endorses different parts of a message. To do so the WSP 
> implementation 
> > shall be able to identify the tokens and use some method to get the 
> > correct certificates to sign the message parts. The WSP 
> method would 
> > get the token identifier, hands it to the "get certificate" 
> method to 
> > get the certificate. Agreed, how to link the token 
> identifer with the 
> > certficates is internal to the implementation (this could 
> be even some 
> > GUI that interactcts with a person to)
> > 
> > Or am I somehow off track here?
> > 
> > Regards,
> > Werner
> > 
> > > -----Ursprüngliche Nachricht-----
> > > Von: Martin Gudgin [mailto:mgudgin@microsoft.com]
> > > Gesendet: Mittwoch, 15. Februar 2006 00:25
> > > An: Marc Goodner; Dittmann, Werner; ws-sx@lists.oasis-open.org
> > > Betreff: RE: [ws-sx] Issue 30: Need a mechanism to identify token 
> > > assertions
> > > 
> > > Comments inline
> > > 
> > > Cheers
> > > 
> > > Gudge
> > > 
> > > > -----Original Message-----
> > > > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > > > Sent: 09 February 2006 20:49
> > > > To: Dittmann, Werner; ws-sx@lists.oasis-open.org
> > > > Subject: [ws-sx] Issue 30: Need a mechanism to identify token 
> > > > assertions
> > > > 
> > > > This is now logged as issue 30.
> > > > 
> > > > Marc Goodner
> > > > Technical Diplomat
> > > > Microsoft Corporation
> > > > Tel: (425) 703-1903
> > > > Blog: http://spaces.msn.com/mrgoodner/
> > > > 
> > > > 
> > > > -----Original Message-----
> > > > From: Dittmann, Werner [mailto:werner.dittmann@siemens.com]
> > > > Sent: Thursday, February 09, 2006 12:17 AM
> > > > To: ws-sx@lists.oasis-open.org
> > > > Cc: Marc Goodner
> > > > Subject: NEW Issue: Need a mechanism to identify token 
> assertions
> > > > 
> > > > PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON
> > > THREAD UNTIL
> > > > THE ISSUE IS ASSIGNED A NUMBER.
> > > > 
> > > > The issues coordinators will notify the list when that
> > has occurred.
> > > > 
> > > > Protocol:  ws-sp
> > > > ws-securitypolicy-1.2-spec-ed-01-r03-diff.pdf
> > > > 
> > > > Artifact:  spec
> > > > 
> > > > Type: design
> > > > 
> > > > Title: Need a mechanism to identify token assertions
> > > > 
> > > > Description: 
> > > > 
> > > > An implementation that uses Security Policy Language has
> > to know how
> > > > to populate the required tokens, e.g. UsernameToken or X509 
> > > > tokens. Because a policy file usually contains several token 
> > > > assertions there should be a mechanism avaliable to
> > identify a token
> > > > assertion.
> > > > 
> > > > For example if a policy requires two UsernameToken in a 
> supporting 
> > > > token the application that creates the message needs a way
> > > to link the
> > > > different UsernameToken assertions to the user data 
> records that 
> > > > contains username, password, etc. To do so the 
> application shall 
> > > > be able to identify the UsernameToken and use this 
> identifier as a
> > link to the
> > > > user data record. 
> > > > 
> > > > Simliar mechanisms are required to locate the correct X509
> > > certificate
> > > > in a keystore, for example. 
> > > 
> > > [MJG]
> > > While I agree that a service needs to be able to 
> distinguish between 
> > > such tokens and potentially locate such tokens on it's 
> side, I don't 
> > > believe WS-SecurityPolicy should specify such things. They are 
> > > internal implementation details that the client need not be aware 
> > > of.
> > > 
> > > > 
> > > > Related issues:
> > > > none
> > > > 
> > > > Proposed Resolution:
> > > > 
> > > > Add an Id or name attribute or to token assertions.  Any
> > other ideas
> > > > how to identify token in a Poliy file and associated them
> > with real
> > > > user/alias data?
> > > > 
> > > > Werner Dittmann
> > > > Siemens COM MN CC BD TO
> > > > mailto:Werner.Dittmann@siemens.com
> > > > Tel:   +49(0)89 636 50265
> > > > Mobil: +49(0)172 85 85 245
> > > > 
> > > 
> > 
>