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

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

That is fine with me.

Hal

> -----Original Message-----
> From: Martin Gudgin [mailto:mgudgin@microsoft.com]
> Sent: Monday, June 19, 2006 8:55 PM
> To: Hal Lockhart; Marc Goodner; ws-sx@lists.oasis-open.org
> Subject: RE: [ws-sx] Issue 71: Guidance on Policy Application
> 
> 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
> > > > >
> > > >
> >