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: Re: [ws-sx] Issue ER008: Applicability of TokenInclusion Valuesfor various security tokens

Agreed on the point, that WS-SecurityPolicy should be generic, and should not profile specific scenarios.
However, WS-SP does use a specific transport protocol (HTTP over SSL) for almost all the cases/examples where Transport Binding is used. It defines a specific protocol based token for this as well (HTTPSToken). Though we all know SOAP is a transport-independent mechanism for message exchange, the simple reason that WS-SP needed to have a specific transport protocol assertion, illustrates a propensity for commonly used scenarios (In this case HTTP over SSL which is a very widely used transport protocol whereas it could have kept just an SSLToken or a TLSToken).
If dug deeper, we might find more instances, where WS-SP has indirectly made some scenario specific recommendations.

I also agree to the fact, that theoretically, every token can use any of the Inclusion Values. But the point to consider here for the examples stated below, is:
Will, under the most commonly used scenarios, a recipient(lets say a service provider) send Username/passwords to a requestor(some client)? Will it not be a preferable idea for service providers to authenticate themselves using X509 certificates instead?

For this reason, I had proposed that it would be helpful to include this as a RECOMMENDATION from the WS-SP, and definitely not as a constraint. :-)


Jan Alexander wrote:
714FD339561BA646A10A9BBE148BB425307902C103@NA-EXMSG-C116.redmond.corp.microsoft.com" type="cite">

I disagree with the proposal because I don’t believe we should be profiling the use of WS-SecurityPolicy assertions for specific scenarios. I believe that this work belongs to a group that is specifically chartered to do such work for a specific usage domain of WS-SecurityPolicy. Since we are providing a generic framework for specifying the security requirements for SOAP message exchanges and we haven’t done any formal work in collecting all the possible scenarios where this framework can be used (I actually don’t think it is feasible to collect all such scenarios across all the domains), I don’t believe we should be recommending or constraining the inclusion mode values in a way that is proposed below.


On a technical level, I don’t agree with the use cases below because in some scenarios the SAML token is actually used to authenticate a recipient to an initiator in which case setting inclusion mode on the SamlToken assertion to AlwaysToInitiator is needed. In some scenario you might want to use username token to authenticate recipient to the initiator so again setting the inclusion mode to AlwaysToInitiator makes sense.





From: Greg Carpenter [mailto:gregcarp@microsoft.com]
Sent: Tuesday, June 19, 2007 10:40 AM
To: Aditya Athalye; ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: [ws-sx] Issue ER008: Applicability of TokenInclusion Values for various security tokens


Issue ER008.


From: Aditya Athalye [mailto:aditya.athalye@oracle.com]
Sent: Tuesday, June 19, 2007 4:32 AM
To: ws-sx@lists.oasis-open.org
Cc: Marc Goodner
Subject: [ws-sx] New Issue: Applicability of TokenInclusion Values for various security tokens


The issues coordinators will notify the list when that has occurred.
Protocol:   ws-sp 
Applicability of TokenInclusion Values for various security tokens
The WS-SP spec attaches a @IncludeToken for the various security tokens that are defined. The Token Inclusion values are also 
enumerated in Section 5.1.1.
However, the spec does not clearly indicate the applicability of various Inclusion Values for each token.
What I mean is: Not all TokenInclusion Values defined will be applicable/pertinent to each security token.


1.) For a UsernameToken, using TokenInclusion values of "Never", or "AlwaysToInitiator" may not be relevant. A policy cannot use  something like  "RequireKeyIdentifierReference"  for referencing  UsernameTokens, so probably a UsernameToken
will always be included, and probably always sent from Initiator to Recipient.

2.) A SAMLToken may never need to use an Inclusion value of "AlwaysToInitiator".

3.) An X509Token can use any of these values depending on the scenario.


Related Issues:
Proposed Resolution:
I propose that the spec also throw some light on this aspect in the description for @IncludeToken for each such token, so that
implementors/users get a clear idea of this.
Following quoted text could be added to the UNToken:
This optional attribute identifies the token inclusion value for this token assertion. "It is RECOMMENDED however that this 
security token uses the "Always", "AlwaysToRecipient", "Once" inclusion values".
Similar text can be added for the remaining tokens wherever applicable.
The schema can still use the "IncludeTokenType", but the documentation IMO could be a little clearer.

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