RE: [wss] ISSUE 70 Part 1: S:mustUnderstand, what part of mustUnderstand

Listing the token profiles in an attribute of the Security header raises a few issues:

1. profile versioning. Which version of the token profile is contained within the header?

2. partial processing. If I understand some of the token profiles listed but not all, does that constitute a failure of the mustUnderstand criteria? Does the list constitute all of the profiles represented within the header, or just those that must be understood?

If processing is driven by the subelements of the security header, versioning is handled via namespace and mustUnderstand can be handled at a more granular level (more than one token profile incorporates the notion of extension in its schema). As such, including mustUnderstand attributes on subelements of Security seems the better solution.

At first glance it would seem simpler to require semantic understanding of the entire security header to have mustUnderstand be true.

The problem is that this header is just a container and could contain any sort of profiled content, thus making it hard to understand

some token types and not others.

Thus there seem to be two solutions:

1. include an interior mustUnderstand attribute as you suggest, with the cost of requiring parsing and processing to determine if the

wsse:Security header is understood

2. Propagate to the wsse:Security header an attribute summarizing the profiles used , e.g. typing the security header.

Thus if the X.509 token profile is used then the security header might have an attribute tokenProfiles="X509Token" (e.g QName list)

Perhaps we could agree that

1. To understand a wsse:Security header, core SOAP Message Security components must always be understood, e.g. Signature, Encryption, Timestamps

2. token profiles must be listed in the wsse:Security header tokenProfiles attribute

Default without any tokenProfiles attribute is must understand all profiles defined in the token profiles.

This allows the mustUnderstand decision without parsing the header.

Is this a possibility worth considering?

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:

alternatively the former could be extended:

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)

eric@reactivity.com

wss message

4.2.3 SOAP mustUnderstand Attribute