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

["Eric Gravengaard" <eric@reactivity.com>]

Thomas:

I think that there will be extensions to the protocol that do other
useful things other than just decrypt. For example, in the receipt token
profile that I proposed, we wanted the responding server to fault if it
did not understand how to process the <ReceiptRequest> token. And this
is where we got into trouble because it wasn't clear how to use
mustUnderstand to get the desired effect. I think that any solution we
come up with to this problem should be general enough to be used by
other profile documents that may come along in the future and require
processing.

-Eric


-----Original Message-----
From: DeMartini, Thomas [mailto:Thomas.DeMartini@CONTENTGUARD.COM]
Sent: Tuesday, May 20, 2003 3:16 PM
To: Irving Reid; wss@lists.oasis-open.org
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?

Thanks,
Thomas.

-----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
are
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
they
have a separate indicator that makes the enclosed element non-critical
(for
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
developers
of WSS infrastructure.

If we can come up with a use case where the added profile ID is the
cleanest
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
right
element) that basically says "Unless you subscribe to the usage policy
identified by [some URI], rely on the contents of this assertion at your
own
risk". There is some overlap between that and profile ID, but they're
not
identical.

Frankly, my biggest concern is that every gratuitous "this string must
be
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
put
them in.

 - irving -


------------------------------------------------------------------------
-----------------------------------------
The information contained in this message is confidential and is
intended
for the addressee(s) only.  If you have received this message in error
or
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
being 
passed on.
 
This footnote confirms that this email message has been swept for
Content Security threats, including
computer viruses.

http://www.baltimore.com

 
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
http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup
.php


You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup
.php