[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-sx] Issue 46: Include BinarySecurityToken as an additionaltoken assertion in WS-SP
I see your point here. I guess the core issue are the policy matching rules in Section 7 (and WS-Policy), namely, that Qnames must match, right? In that context, having a sp:BinarySecurityToken is not that helpful as only the assertion sub-elements distinguish between one legacy token vs. another. We can close this issue and move on. I would like to see a sub-section on "Creating New Token Assertions and Token Assertion Extensibility" added to Section 5. But that deserves a new issue number and a specific proposal. It would summarize some of these discussions in a form accessible to developers and security administrators. - 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. >> >> >> > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]