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

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

> -----Original Message-----
> From: Prateek Mishra [mailto:prateek.mishra@oracle.com] 
> Sent: 14 March 2006 11:36
> To: Martin Gudgin
> Cc: Marc Goodner; ws-sx@lists.oasis-open.org
> Subject: Re: [ws-sx] Issue 46: Include BinarySecurityToken as 
> an additional token 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?

Yes. That's 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.

Exactly.

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

I think that's a good idea.

Cheers

Gudge

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