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

[Irving Reid <Irving.Reid@baltimore.com>]

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