RE: [ws-sx] Issue 71: Guidance on Policy Application

["Hal Lockhart" <hlockhar@bea.com>]

Comments inline.

> Hal,
> 
> I've managed to look at this a bit more. It seems to me that Section 2
> also contains information about how WS-SP is intended to be used,
> especially Section 2.3.
> 
> I wonder if we need to do anything more than add some text to the end
of
> Section 2.3. The final paragraph of that section currently reads;
> 
> "Together the above pieces of information, along with the assertions
> describing conditions and scope, provide enough information to secure
> messages between an initiator and a recipient."
> 
> Perhaps adding
> 
> "A policy consumer has enough information to construct messages that
> conform to the service's policy and to process messages returned by
the
> service."
> 
> is enough.

Thanks, I did not notice 2.3. Perhaps that is a better place to add
text.
> 
> I don't think that we need to say anything more here. Policy tells
> people how to construct messages ( in the case of WS-SP, much of the
> detail is in the layout/content of the wsse:Security header as noted
in
> 2.3 ). Whether the service accepts such messages or not, or whether it
> accepts messages that do not conform to the policy doesn't seem like
> something the spec needs to talk about. Or put another way, it's not
the
> fault of the spec if a service chooses to reject a correctly formed
> message for some reason.

Once again, I would like to emphasize that my main point in making this
proposal is not points 1 & 2, which are likely to be obvious to most
people, but to document points 3 & 4 which may not be. 

I believe that many people reading this spec may conclude that the
Service is required to accept any message that conforms to the
advertised policy or prohibited from accepting a message which does not.

Hal

> 
> Gudge
> 
> > -----Original Message-----
> > From: Martin Gudgin [mailto:mgudgin@microsoft.com]
> > Sent: 14 June 2006 06:43
> > To: Marc Goodner; Hal Lockhart; ws-sx@lists.oasis-open.org
> > Subject: RE: [ws-sx] Issue 71: Guidance on Policy Application
> >
> > Hal,
> >
> > I've only been able to take a short look at this and will try
> > to respond
> > more fully later this week.
> >
> > Taking your paragraph of unanswered questions;
> >
> > > Is a consumer required to use SP?
> >
> > For a service that uses WS-SP, a consumer of that service needs to
> > understand WS-SP in order to know how to correctly construct
> > messages. I
> > don't know whether that counts as 'using SP' or not.
> >
> > > Is SP suitable for expressing a Consumer's policy?
> >
> > I believe that WS-SP describes things from the point of view of the
> > service. However, if a consumer did have policy, I would view it as
> > policy that described the policies the consumer is willing to use
when
> > talking to services. Such a policy could be used to perform matching
> > against policy published by services.
> >
> > > Does an SP represent an enforceable access control policy?
> >
> > I don't believe so. Why would it?
> >
> > > Can a Web Service reject messages which conform to its policy?
> >
> > Yes. For a variety of reasons. For example, a service whose policy
> > specifies X509 certs might legitimately reject messages that
> > conform to
> > that policy because the cert has expired or been revoked.
> >
> > Looking at your specific spec text, I'm not sure I want to add
> > statements 1-4, esp. given they contain RFC2119 'keywords'. I'm
> > especially concerned about statement 2.
> >
> >
> > Gudge
> >
> >
> > > -----Original Message-----
> > > From: Marc Goodner [mailto:mgoodner@microsoft.com]
> > > Sent: 30 May 2006 13:25
> > > To: Hal Lockhart; ws-sx@lists.oasis-open.org
> > > Subject: [ws-sx] Issue 71: Guidance on Policy Application
> > >
> > > Tracked as Issue 71.
> > >
> > > Marc Goodner
> > > Technical Diplomat
> > > Microsoft Corporation
> > > Tel: (425) 703-1903
> > > Blog: http://spaces.msn.com/mrgoodner/
> > >
> > >
> > > -----Original Message-----
> > > From: Hal Lockhart [mailto:hlockhar@bea.com]
> > > Sent: Tuesday, May 30, 2006 1:12 PM
> > > To: ws-sx@lists.oasis-open.org
> > > Cc: Marc Goodner
> > > Subject: [ws-sx] NEW Issue: Guidance on Policy Application
> > >
> > >
> > > PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON
> > THREAD UNTIL
> > > THE ISSUE IS ASSIGNED A NUMBER.
> > > The issues coordinators will notify the list when that has
occurred.
> > >
> > > Protocol:  ws-sp
> > >
> > > http://www.oasis-open.org/apps/org/workgroup/ws-sx/download.ph
> > > p/17889/ws
> > > -securitypolicy-1.2-spec-ed-01-r06.pdf
> > >
> > > Artifact:  spec
> > >
> > > Type: philosophical
> > >
> > > Title:
> > >
> > > Some people are unclear on the precise role to be played by
> > > WS-SecurityPolicy.
> > >
> > > Description:
> > >
> > > The only place in WS_SecurityPolicy which seems to address
> > > exactly what
> > > WS-SP is supposed to be used for is section 1. Currently it says:
> > >
> > > "WS-Policy defines a framework for allowing web services to
express
> > > their constraints and requirements. [...] This document takes the
> > > approach of defining a base set of assertions that describe
> > > how messages
> > > are to be secured. [...] The intent is to provide enough
> > > information for
> > > compatibility and interoperability to be determined by web service
> > > participants along with all information necessary to
> > actually enable a
> > > participant to engage in a secure exchange of messages."
> > >
> > > This seems to leave a lot of questions unanswered. Is a consumer
> > > required to use SP? Is SP suitable for expressing a
> > Consumer's policy?
> > > Does an SP represent an enforceable access control policy? Can a
Web
> > > Service reject messages which conform to its policy?
> > >
> > > It seems to me desirable that the spec provide more specific
> > > guidance on
> > > what is expected.
> > >
> > >
> > > Proposed Resolution:
> > >
> > > I suggest that we add to section 1 some additional text along
these
> > > lines.
> > >
> > > ----
> > >
> > > The exact usage of security policies will depend on a variety
> > > of factors
> > > and may differ from one deployment to another. Further,
> > Consumers and
> > > Services are likely to use information from a variety of
> > sources other
> > > than security policies to determine the details of security
> > mechanisms
> > > applied to particular messages.
> > >
> > > However, in the absence of specific considerations to the
> > contrary, it
> > > is recommended that the following principles be followed.
> > >
> > > 1. The Consumer should construct messages which are
> > > consistent with the
> > > policy advertised by the Service.
> > >
> > > 2. The Service should not reject messages based on the use of
> > > mechanisms
> > > which conform to its advertised policies.
> > > 3. However, the Service may reject messages based on
> > factors which are
> > > not specified in its advertised policies.
> > > 4. The Service may also choose to accept messages which are
> > > inconsistent
> > > with its advertised policies.
> > >
> > > ----
> > >
> > > Hal
> > >
> >