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

Irving brings up good points.  Not only is adding a profile id attribute
undesirable, but also, in general, I wonder if we are getting carried
away with mustUnderstand and losing sight of why we need it.

Perhaps a good way to begin thinking about this is what would be wrong
with requiring mustUnderstand = 0 on the Security header?  The thing
that first springs to mind for me is if the Security header has some
encryption things in it that need to be decrypted.  In that case we need
to have mustUnderstand = 1 so that intermediaries will decrypt the
respective parts properly and not just process the message completely
oblivious to the fact it has a decryption job to do.

Are there any other scenarios where the recipient absolutely *MUST*
understand the security header?  It seems to me that everything else
(signatures, time stamps, tokens, etc.) are placed in the security
header only on the off chance that they might be useful to the recipient
-- in other words, if the recipient doesn't find them useful, no big
deal.  It seems what we really care about here is a way for the
recipient to tell the sender the sender must include a signature, a
token, a timestamp, etc.

So, in summary, I think this problem simply boils down to saying that if
mustUnderstand = 1 on a Security header that the recipient must decrypt
any encryption things inside of it.

Have I oversimplified?


-----Original Message-----
From: Irving Reid [mailto:Irving.Reid@baltimore.com] 
Sent: Tuesday, May 20, 2003 2:28 PM
To: wss@lists.oasis-open.org
Subject: RE: [wss] ISSUE 70 Part 1: S:mustUnderstand, what part of
mustUnderstand don't we understand

> From: Eric Gravengaard [mailto:eric@reactivity.com]

> 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.

Is there ever a case where a single <wsse:Security> header contains
semantically unrelated information? If all the elements in a Security
intended to be taken together, then MustUnderstand="true" on the
Security is
sufficient, since it's only safe to disregard part of the contents if
have a separate indicator that makes the enclosed element non-critical
example, it's nested in a SAML Advice element)

I strongly dislike adding at "profile ID" attribute to the schema; this
strikes me as a huge opportunity for interoperability failures in
deployments, while simultaneously making life more difficult for
of WSS infrastructure.

If we can come up with a use case where the added profile ID is the
solution to the problem, OK, but I don't think we really need it to get
MustUnderstand right.

In SAML we added an <AudienceRestrictionCondition> (I think that's the
element) that basically says "Unless you subscribe to the usage policy
identified by [some URI], rely on the contents of this assertion at your
risk". There is some overlap between that and profile ID, but they're

Frankly, my biggest concern is that every gratuitous "this string must
the same at both ends" we add to the protocol makes deployment UIs
harder to
design and document, so we need to be really sure they'll help before we
them in.

 - irving -

The information contained in this message is confidential and is
for the addressee(s) only.  If you have received this message in error
there are any problems please notify the originator immediately.  The 
unauthorised use, disclosure, copying or alteration of this message is 
strictly forbidden. Baltimore Technologies plc will not be liable for
direct, special, indirect or consequential damages arising from
alteration of the
contents of this message by a third party or as a result of any virus
passed on.
This footnote confirms that this email message has been swept for
Content Security threats, including
computer viruses.


This footnote confirms that this email message has been swept by 
Baltimore MIMEsweeper for Content Security threats, including
computer viruses.

You may leave a Technical Committee at any time by visiting

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