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