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

But how does WS-SP inform the client what to put in the 
usage? How does the client know that one token's usage is "manager" and the 
other token's usage is "purchaser"? Right now the only thing WS-SP says is 
there needs to be two tokens. This requires some sort of out-of-band agreement 
of what is required.

 

Tony

From: Anthony Nadalin 
[mailto:] 
Sent: Monday, February 27, 2006 4:33 
PM
To: Dittmann, Werner
Cc: Tony Gullotta; 

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

I'm referring to the usage attribute on the STR

Anthony Nadalin | Work 
512.838.0085 | Cell 512.289.4122
' 
src="gif00068.gif" width=16>"Dittmann, Werner" 
<>

  
  

    
      
        
          
            "Dittmann, Werner" 
              <> 

              
02/27/2006 01:30 AM

    
      
        
        

          

            
To

          
Anthony Nadalin/Austin/IBM@IBMUS, "Tony Gullotta" 
            <>

        

          

            
cc

          
<>

        

          

            
Subject

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

      
        
        

          
          

To which mechanism are you refering? WS Security 
defines a "role" attribute in
the 
Security header according to the SOAP actor/role definitions.

Tony and I are refering to 
assign a role to the WS SecurityPolicy token assertions to
be able to handle the use cases shown by Tony. This 
role information is required
by the 
SecurityPolicy processor to create a message according to the Security 

Policy. This is unrelated to the 
actor/role attribute in the Security header.

Regards,
Werner

Von: Anthony Nadalin [mailto:] 

Gesendet: Montag, 
27. Februar 2006 01:01
An: Tony Gullotta
Cc: Dittmann, Werner; 
Betreff: RE: [ws-sx] Issue 30: Need 
a mechanism to identify token assertions

There already exists a mechanism to do this in WS-Security, I 
don't think that this TC should create the URI that name these 
roles.

Anthony Nadalin | Work 512.838.0085 | Cell 
512.289.4122
' 
src="gif00077.gif" width=16>"Tony Gullotta" 
<>

  
  

    
      
        
          
            
              
                
                  
                    "Tony Gullotta" <> 
                      
02/24/2006 11:39 AM

    
      
        
        

          
            
To

          
"Dittmann, Werner" 
            <>, 
          <>

        

          
            
cc

          

        

          
            
Subject

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

      
        
        

          
          

We have run into the same use cases. I agree this is something that 
needs to be addressed. I don't think simply naming the tokens will do it though. 
Its more like identifying roles for the tokens. So in your example, one token 
may be for the role "purchaser" and the other for the role "manager". I guess a 
role is still just a name, but I think semantically its different.

Tony 

-----Original Message-----
From: Dittmann, Werner [mailto:] 

Sent: Friday, February 24, 2006 1:57 AM
To: Tony Gullotta; 

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

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

> > 
>