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:]
> Gesendet: Donnerstag, 23. Februar 2006 18:55
> An: Dittmann, Werner;
> 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:]
> Sent: Monday, February 20, 2006 4:22 AM
> To:
> 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;
> > 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:]
> > > Gesendet: Mittwoch, 15. Februar 2006 00:25
> > > An: Marc Goodner; Dittmann, Werner;
> > > Betreff: RE: [ws-sx] Issue 30: Need a mechanism to identify token
> > > assertions
> > >
> > > Comments inline
> > >
> > > Cheers
> > >
> > > Gudge
> > >
> > > > -----Original Message-----
> > > > From: Marc Goodner [mailto:]
> > > > Sent: 09 February 2006 20:49
> > > > To: Dittmann, Werner;
> > > > 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:]
> > > > Sent: Thursday, February 09, 2006 12:17 AM
> > > > To:
> > > > 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:
> > > > Tel: +49(0)89 636 50265
> > > > Mobil: +49(0)172 85 85 245
> > > >
> > >
> >
>
