OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: 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]