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] | [List Home]

Subject: RE: [wss] ISSUE 70 Part 1: S:mustUnderstand, what part of mustUnderstand don't we understand

         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.
-----Original Message-----
From: Frederick.Hirsch@nokia.com [mailto:Frederick.Hirsch@nokia.com]
Sent: Tuesday, May 20, 2003 12:18 PM
To: Eric Gravengaard; wss@lists.oasis-open.org
Subject: RE: [wss] ISSUE 70 Part 1: S:mustUnderstand, what part of mustUnderstand don't we understand

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?

regards, Frederick

Frederick Hirsch
Nokia Mobile Phones

-----Original Message-----
From: ext Eric Gravengaard [mailto:eric@reactivity.com]
Sent: Tuesday, May 20, 2003 2:04 PM
To: [wss oasis] (E-mail)
Subject: [wss] ISSUE 70 Part 1: S:mustUnderstand, what part of mustUnderstand don't we understand

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
617-256-0328 (mobile)
650-551-7891 (office)

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