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

["Martin Gudgin" <mgudgin@microsoft.com>]

OK, how about adding to the last para of 2.3 so that it reads in full;

"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. A policy consumer has
enough information to construct messages that conform to the service's
policy and to process messages returned by the service. Note that a
service may choose to reject messages despite them conforming to its
policy, for example because a client certificate has expired. Note also
that a service may choose to accept messages that do not conform to its
policy."

Would that do the job?

Gudge
 

> -----Original Message-----
> From: Hal Lockhart [mailto:hlockhar@bea.com] 
> Sent: 20 June 2006 01:49
> To: Martin Gudgin; Marc Goodner; ws-sx@lists.oasis-open.org
> Subject: RE: [ws-sx] Issue 71: Guidance on Policy Application
> 
> 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
> > > >
> > >
>