RE: [ws-sx] Issue 46: Include BinarySecurityToken as an additional token assertion in WS-SP

["Martin Gudgin" <mgudgin@microsoft.com>]

Prateek,

I'm not entirely sure why defining a sp:BinarySecurityToken assertion is
necessary. Wouldn't having the two parties agree on a
customsp:LegacyFooToken assertion make more sense. Such an assertion
could carry semantics specific to the actual token type and also reduce
false positives when performing policy intersection. False positives
would occur with sp:BinarySecurityToken at any point where two parties
supported different binary security tokens; they wouldn't be able to
tell by looking at the policy whether they could interoperate or not.
Whereas if both policies contain customsp:LegacyFooToken then it is
clear that they can interoperate (assuming the rest of the policy
matches).

Gudge

> -----Original Message-----
> From: Marc Goodner [mailto:mgoodner@microsoft.com] 
> Sent: 08 March 2006 10:25
> To: Prateek Mishra; ws-sx@lists.oasis-open.org
> Subject: [ws-sx] Issue 46: Include BinarySecurityToken as an 
> additional token assertion in WS-SP
> 
> This is now logged as issue 46.
> 
> Marc Goodner
> Technical Diplomat
> Microsoft Corporation
> Tel: (425) 703-1903
> Blog: http://spaces.msn.com/mrgoodner/ 
> 
> 
> -----Original Message-----
> From: Prateek Mishra [mailto:prateek.mishra@oracle.com] 
> Sent: Wednesday, March 08, 2006 9:21 AM
> To: ws-sx@lists.oasis-open.org
> Cc: Marc Goodner
> Subject: NEW ISSUE: Include BinarySecurityToken as an additional token
> assertion in WS-SP
> 
> *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
> 
> Artifact: spec / schema /
> 
> Type:
> 
> design
> 
> Title:
> 
> Include BinarySecurityToken as an additional token assertion in WS-SP
> 
> Description:
> 
> The WSS 1.x specifications defines <wsse:BinarySecurityToken> as a 
> container for carrying legacy or non-XML security tokens.
> WS-SP includes assertions for X.509 certificates and 
> Keberberos tickets 
> as specific instances of binary security tokens but does not
> include any way of referencing a generic binary security token of an 
> arbitrary valuetype.
> 
> The enterprise use-case of interest is a situation where a legacy 
> requestor generates a SOAP message with a binary security token
> with value type set by prior agreement (e.g., 
> LegacyFooToken). There is 
> a corresponding use-case for a legacy responder, where the
> responder requires some form of pre-existing security token.
> 
> In each case, it would aid interoperability if WS-SP supported 
> expression of BinarySecurityToken with a certain value type. No other
> semantics would be associated with tokens conforming to this 
> assertion.
> 
> Related issues:
> 
> None.
> 
> Proposed Resolution:
> 
> Include a new token type in Section 5.3
> 
> Section 5.3.11
> 
> This element represents a requirement to include an arbitrary binary 
> security token in the security header.
> The assertion includes information about the URI that must be 
> provided 
> by the security token's ValueType attribute.
> 
> 
> /sp:BinarySecurityToken
> This identifies a Binary Security Token assertion
> 
> /sp:BinarySecurityToken/ValueType
> This required element specifies the URI that must be provided by the 
> corresponding security token's ValueType attribute.
> 
> /sp:BinarySecurityToken/Policy
> This optional element specifies additional requirements for 
> the use of 
> the sp:BinarySecurityToken assertion
> 
> /------------------------------------/
> 
> I will pick the issue up and give it a number (in sequence), 
> assigning 
> the individual who submitted the email as owner of the issue. I will 
> send an email to the list with the issue number once it is assigned. 
> Subsequent mail threads should use the Issue xxx: format in 
> the subject 
> line, where 'xxx' is the issue number.
> 
> Please include only one issue per email and do not engage in 
> discussing 
> the issue until it is assigned a number so we don't have multiple 
> impossible to distinguish 'NEW Issue' threads on the list.
> 
>