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

 


Help: OASIS Mailing Lists Help | MarkMail Help

wss message

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


Subject: [wss] Comments on latest core draft


Hi all,

Here my comments to the WSS core working draft-01:

Technical Issues
============	
	Error Handling: The error handling as it is proposed by the SOAP specification contains two mandatory (Code, Reason) and two optional (Detail, Node) elements within the Fault element. The way the SOAP error handling is leveraged by WSS is by specifying different fault codes (see line 1382-1383 of the core spec.) and making use of the fault element. For security reasons, the core spec recommends only to use the fault codes defined in the core spec (denial of service attacks). WSS security will also be used in many intranet scenarios, which have a very low risk of denial of service attacks. To allow a better fault handling, I'd like to propose using the optional detail node in trusted environments (i.e. intranet) in a way, that profiles may add an xml-element giving detailed error information. This xml-element should be standardized by the profiles and be in the namespace of the profile. This element is optional, a server MAY wish to send it, but as it is optional, a web service client should not rely on it.

	Error Declaration: Errors that are caused by WSS should be declared in the WSDL, so ws clients can handle them. This is rather an issue for the WSDL community and needs to be discussed with them. Example: a web service client should know how to handle SAML exceptions. To to this, an appropriate fault message must be defined in the WSDL document.

	Line 409: It needs to be clarified what this line means: "All compliant implementations MUST be able to process a <wsse:Security> element" in the context of profiles. Profiles are extensions to WSS in a way, that they define additional security tokens. These additional security token are not part of WSS, but are embedded in the wsse:Security element so it only makes sense to specify "this implementations supports the security tokens declared by WSS and additionally the security tokens defined by profiles A,B,C". I'd propose to change the line to "All compliant implementations must declare which profiles they support and MUST be able to process a <wsse:Security> element including any sub-elements which may be defined by profile." 

Question: Is there a need to discuss about interoperability of the WSS profiles?


General Observations: 
================
	Line 176: When giving example, two different examples should be given, a binary token and an XML token instead of two binary tokens. Replace "e.g. an X.509 certificate or a Kerberos ticket" to read "e.g. an UserNamePassword element or a Kerberos ticket"

	XML dsig/XML encryption.: currently, the wss spec states that any part of the SOAP envelope MAY be signed/encrypted. Is there a common agreement, that this means that also SOAP faults may be signed/encrypted?

Best Regards,

Martijn
__________________________

Dr. Martijn de Boer

SAP AG
Development Security & Directory Services 
GBU Server Technology
Neurottstraße 16 
69190 Walldorf
T   +49/62 27/7-6 83 92
F   +49/62 27/7-83 91 13
E   martijn.de.boer@sap.com
http://www.sap.com





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


Powered by eList eXpress LLC