I think we should be explicit about what processing must be performed
with a default that it is ok to not understand tokens that aren't needed
by the service.
For example, we might say
All ds:enc elements
All ds:sig elements
All elements that themselves have a
MustUnderstand attribute (with appropriate value)
In other words, I think the default should be that it is ok to ignore
elements if you don't care about them or you aren't explicitly requested
to process them.
In general the contents of <Security> are intended to provide
information, not request processing and if the service doesn't need that
information there is no reason it needs to understand that information.
At 11:03 AM 5/20/2003, Eric Gravengaard wrote:
Per our
discussion on the call today I am again raising this issue for discussion
on the list. What I originally wanted clarified was the processing that
was required to definitively know if my implementation was capable of
understanding a <Security> element that was tagged mustUnderstand.
This is important since wsse has an open schema that allows for future
token types to be defined.
There were several opinions on the call about
what we might define as "understanding" including one that
would create the following rule:
To process a <wsse:Security> header
element with a S:mustUnderstand attribute equal to "1", the
implementation MUST know how to process all of the child elements.
alternatively the former could be extended:
...unless such child elements are
explicitly tagged with S:mustUnderstand attribute equal to
"0".
This is particularly important when implementing tokens that are not
specified in the core specification and the requestor wants the responder
to fail if it does not understand the special token type. For example,
the proposed Receipt Token Profile.
The SOAP 1.1 specification defines the
attribute as such:
4.2.3 SOAP mustUnderstand
Attribute
The SOAP mustUnderstand global attribute can be used to indicate whether
a header entry is mandatory or optional for the recipient to process. The
recipient of a header entry is defined by the SOAP actor attribute (see
section
4.2.2). The value of the mustUnderstand attribute is either
"1" or "0". The absence of the SOAP mustUnderstand
attribute is semantically equivalent to its presence with the value
"0".
If a header element is tagged with a SOAP mustUnderstand attribute with a
value of "1", the recipient of that header entry either MUST
obey the semantics (as conveyed by the fully qualified name of the
element) and process correctly to those semantics, or MUST fail
processing the message (see
section
4.4).
The SOAP mustUnderstand attribute allows for robust evolution. Elements
tagged with the SOAP mustUnderstand attribute with a value of
"1" MUST be presumed to somehow modify the semantics of their
parent or peer elements. Tagging elements in this manner assures that
this change in semantics will not be silently (and, presumably,
erroneously) ignored by those who may not fully understand it.
This attribute MUST appear in the instance in order to be effective (see
section
3
and 4.2.1).
Eric Gravengaard
Reactivity
617-256-0328 (mobile)
650-551-7891 (office)
