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

Your proposal then would be something like 
that?

 

<sp:X509Token sp:IncludeToken="xs:anyURI"? wsse:Usage="xs:string"? ... 
>

or

<sp:X509Token 
sp:IncludeToken="xs:anyURI"? wsse:Usage="xs:anyURI"? ... 
>

 

Taking a X509Token assertion (page 29 at line 870) as 
an example.

 

This way a token could be associated with a usage/role. 
IMHO this could also populate the Usage attribute

in the STR (the WSS spec does not define any Usage URI or 
how to use this attribute).

 

Regards,

Werner

 

  

  
  Von: Anthony Nadalin 
  [mailto:] 
Gesendet: Dienstag, 28. Februar 2006 
  01:33
An: Dittmann, Werner
Cc: Tony Gullotta; 
  
Betreff: 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="gif00086.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="gif00095.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
> > > > 
> > > 
  
> > 
>