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: Re: [wss] Comments on latest core draft






Martijn,

Error handling: Not sure that this should be part of the base but rather a
optional specification as not all service should be expect to return a
message.

General Observations: Since we have factored out the specific token types I
would look for these "profiles" to give the proper examples as the
"profiles" detail the semantics of the specific token type.

If your fault message contains sensitive information, surely you want to
protect it. There should  not be a problem in signing/encrypting fault
messages -- they are just SOAP messages.


Anthony Nadalin | work 512.436.9568 | cell 512.289.4122


|---------+---------------------------->
|         |           "De Boer,        |
|         |           Martijn"         |
|         |           <martijn.de.boer@|
|         |           sap.com>         |
|         |                            |
|         |           10/29/2002 02:25 |
|         |           AM               |
|---------+---------------------------->
  >----------------------------------------------------------------------------------------------------------------------------------------------|
  |                                                                                                                                              |
  |       To:       wss@lists.oasis-open.org                                                                                                     |
  |       cc:                                                                                                                                    |
  |       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




----------------------------------------------------------------
To subscribe or unsubscribe from this elist use the subscription
manager: <http://lists.oasis-open.org/ob/adm.pl>




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


Powered by eList eXpress LLC