[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ISSUE 190: SOAP MustUnderstand issue
Here is a link to the W3C TAG document on versioning which applies to understanding MustUnderstand.
http://www.w3.org/2001/tag/doc/versioning-20031003.html
In summary, the document outlines five types of extensibility point semantics:
1. Must Understand - If there is an extension at that extensibility point and you do not understand what the semantics of that extension is, you must fail by doing one of the following:
A) ignoring a part of the document containing the extension you do not understand on the grounds that you understand the semantics of one of its ancestors well enough to understand this part of the document does not apply to you.
B) ignoring a part of the document containing the extension you do not understand on the grounds that the node at the root of that part of the document is an extension at a "Must Ignore All" extensibility point or a "Configurable" extensibility point that is configured to be "Must Ignore All". (This is really just a special case of A).
C) ignoring the entire document.
2. Must Ignore Container - If there is an extension at that extensibility point and you do not understand what the semantics of that extension is, you must ignore it but still process its descendents. (This is used for things like HTML.)
3. Must Ignore (Attribute) - If there is an extension at that extensibility point and you do not understand what the semantics of that extension is, you must ignore that attribute.
4. Must Ignore All - If there is an extension at that extensibility point and you do not understand what the semantics of that extension is, you must ignore that element and all of its descendents.
5. Configurable - If there is an extension at that extensibility point and you do not understand what the semantics of that extension is, then you must look at an attribute (such as the SOAP must understand attribute, which is configurable to either 1 or 4) or some other part of the document to find out how to deal with that extension.
In general, any time there is an extensibility point, the specification should define which class that extensibility point belongs to. If this is done for all the extensibility points defined by this TC, nothing else is needed in the way of specifying what it means to "understand" the wsse:Security header.
Below, I have started a table of the extensibility points defined by this TC and what class I think each one should belong to. Please feel free to add any extensibility points I have missed or to suggest that one of them should be in a different class.
/wsse:Security/{any} - "Must Understand"
/wsse:Security/@{any} - "Must Understand"
/wsse:UsernameToken/Username/@{any} - "Must Understand"
/wsse:UsernameToken/{any} - "Must Understand"
/wsse:UsernameToken/@{any} - "Must Understand"
/wsse:BinarySecurityToken/@ValueType - "Must Ignore (Attribute)"
/wsse:BinarySecurityToken/@EncodingType - "Must Understand"
/wsse:BinarySecurityToken/@{any} - "Must Understand"
/wsse:SecurityTokenReference/@wsse:Usage - "Must Ignore (Attribute)"
/wsse:SecurityTokenReference/{any} - "Must Understand"
/wsse:SecurityTokenReference/@{any} - "Must Understand"
/wsse:SecurityTokenReference/Reference/@ValueType - "Must Ignore (Attribute)"
/wsse:SecurityTokenReference/Reference/{any} - "Must Understand"
/wsse:SecurityTokenReference/Reference/@{any} - "Must Understand"
/wsse:SecurityTokenReference/KeyIdentifier/@wsse:ValueType - "Must Ignore (Attribute)"
/wsse:SecurityTokenReference/KeyIdentifier/@wsse:EncodingType - "Must Understand"
/wsse:SecurityTokenReference/@{any} - "Must Understand"
/wsse:SecurityTokenReference/Embedded/{any} - "Must Understand"
/wsse:SecurityTokenReference/Embedded/@{any} - "Must Understand"
/wsu:Created/@ValueType - "Must Understand" (suggest renaming to EncodingType)
/wsu:Expires/@ValueType - "Must Understand" (suggest renaming to EncodingType)
/wsu:Timestamp/{any} - "Must Understand"
/wsu:Timestamp/@{any} - "Must Understand"
/wsse:UsernameToken/Password/@Type - "Must Understand"
/wsse:UsernameToken/Password/@{any} - "Must Understand"
/wsse:Nonce/@EncodingType - "Must Understand"
&Thomas.
-----Original Message-----
From: Peter Dapkus [mailto:pdapkus@bea.com]
Sent: Thu 10/30/2003 2:08 PM
To: Christopher B Ferris
Cc: Jerry Schwarz; Web Services Security
Subject: Re: [wss] ISSUE 190: text for SOAP MustUnderstand issue
Timestamp/Expires is an interesting case to consider: Expires means
that the sender wishes to invalidate the security properties of the
header after a certain time. In this case, if the receiver were to
ignore the timestamp and process the message after the expiry, they
would be incorrectly (and at their own risk) attributing those security
properties to the message.
Since we don't constrain the possible semantics of tokens and we have at
least one example of a token that negates the semantics of other tokens
(and signatures), it seems risky to allow for selective processing of
tokens in the header.
I think the point of view that mustUnderstand's meaning should be
relative to application policy has merit (have I understood this header
well enough to determine if it meets my policy?). However, it seems
like if the policy requires that the message be granted some level of
authority based on the header processing, then the bar for
mustUnderstand should be significantly higher.
-PEte
On Thu, 2003-10-30 at 11:57, Christopher B Ferris wrote:
> Jerry,
>
> Please see below.
>
> Cheers,
>
> Christopher Ferris
> STSM, Emerging e-business Industry Architecture
> email: chrisfer@us.ibm.com
> phone: +1 508 234 3624
>
> Jerry Schwarz <jerry.schwarz@oracle.com> wrote on 10/30/2003 12:30:22 PM:
>
> >
> > Indeed, I would like further clarification of your intent in some
> examples.
> >
> > A. If I can't validate a signature because it uses a digest method that
> I
> > don't implement have I understood it?
>
> Yes, but you failed Signature Validation.
>
> >
> > B. If I ignore a UsernameToken or SAML element because I'm implementing
> a
> > service that I allow anyone to use have I understood it.
>
> In the case of UsernameToken, yes. In the case of SAML, if the WSS
> implementation
> at the targetted SOAP node doesn't grok SAML, I think that the answer
> should be
> no. How would it know that the unrecognized security token was for
> authorization?
>
> >
> > C. If there is a BinarySecurityToken whose valueType I don't recognize,
> but
> > there is no reference to that BinarySecurityToken have I understood it?
>
> Yes
>
> >
> >
> >
> > >Rich,
> > >
> > >I think that you DO need the language I proposed to define what it
> means
> > >to
> > >"understand" a wsse:Security header block. Without it, there will be
> > >rampant confusion.
> > >I certainly concur with your suggestion that lines 162-3 be added to
> Goals
> > >section.
> > >
> > >Cheers,
> > >
> > >Christopher Ferris
> > >STSM, Emerging e-business Industry Architecture
> > >email: chrisfer@us.ibm.com
> > >phone: +1 508 234 3624
> > >
> > >Rich Salz <rsalz@datapower.com> wrote on 10/30/2003 10:46:50 AM:
> > >
> > > > I took another look through the spec, and it seems the only place
> that
> > > > really needs "fixing" to address soap 1.1 and (vs.?)soap 1.2 issues
> is
> > > > sec 5.
> > > >
> > > > I propose the following
> > > > Copy lines 162-163 (that say any SOAP version) into the Goals
> section
> > >
> > > > after line 121.
> > > >
> > > > Remove all mention of mustUnderstand; its semantics are defined
> by
> > > > SOAP, and we can't constrain, subclass, or further modify it (see
> lines
> > > > 455-457).
> > > >
> > > > Genericize the wording in section 5 so that it is more clearly
> > > > soap-version-neutral. It looks easy to do this; I can send a draft
> > > > later today if there's interest.
> > > >
> > > > /r$
> > > >
> > > > --
> > > > Rich Salz, Chief Security Architect
> > > > DataPower Technology http://www.datapower.com
> > > > XS40 XML Security Gateway
> http://www.datapower.com/products/xs40.html
> > > > XML Security Overview
> http://www.datapower.com/xmldev/xmlsecurity.html
> > > >
> > >
> > >
> > >To unsubscribe from this mailing list (and be removed from the roster
> of
> > >the OASIS TC), go to
> >
> >http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.
> >
> >
> > To unsubscribe from this mailing list (and be removed from the roster of
> the OASIS TC), go to
> >
> http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.
> >
>
>
> To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.
--
Peter Dapkus <pdapkus@bea.com>
To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wss/members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]