[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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 > > > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]