[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Re: WS-Policy?
On Mon, 20 Oct 2003, Anthony Nadalin wrote: > Yes I mean WS-Policy Framework and the set of family specifications. OK, I now see that there are new revs of these documents as of May 2003. I had been looking at the December 2002 versions. > I think that WS-Policy is relevant to all specifications that linger > into the Web services area, which the WSS-TC seems to be doing as some > of the Liberty Alliance ID-WSF specifications are being talked about. I'm not sure what you mean by the above. Do you mean this TC or the WSS-TC? Is someone talking about Liberty ID-WSF? I thought the submissions from Liberty to the SSTC were just the 1.1 ID-FF specs. I guess it's fair to say that SSTC work may have some relation to Web Services, though thus far the only dependency has been on SOAP. > WS-Policy by itself does not provide a policy negotiation solution for > Web services, this is provided by WS-MetadataExchange. I don't see a document called "WS-MetadataExchange among the lists of specs at either the IBM or Microsoft sites ... > WS-Policy provides a general purpose model and corresponding syntax to > describe and communicate the policies of a Web Service. It defines a base > set of constructs that can be used and extended by other Web Services > specifications to describe a broad range of service requirements, > preferences, capabilities, etc. > ... > In summary, WS-Policy provides a framework into which other policy > assertions can be inserted (i.e. XACML). I think we're probably all somewhat familiar with the WS-Policy docs and how they fit in with the rest of WS-*. The question is, what does the existence of these documents mean for the approach we take to the SSTC's list of work items? I'm not prepared to do an analysis of each item where WS-Policy (or any other WS-* document) might apply to the functionality we've discussed in our various work items, but it seems to me that for each such item, we have these options: (1) We can say that WS-Policy completely solves the problem as is, so there's no work for the SSTC for that item. Presumably this would be based on an assessment that the WS-Policy spec, or at least the part of it that covers the functionality we're interested in, and is complete, stable, and usable by us and our customers and communities. It seems to me that this is a difficult assessment to make when the specs all say "The WS-... Specification may change before final release and you are cautioned against relying on the content of this specification." I'm not aware that any information is available about the process by which these documents will reach final release, or what their disposition will be following final release. (2) We can say that WS-Policy provides a base on which to create a profile or extension that does what we want to do. This would seem to be the most likely course from a technical point of view. But beyond the stability and process concerns that make approach (1) difficult, writing a profile of WS-Policy would, it seems to me, require that the SSTC have the ability to create a derivative work based on WS-Policy. As far as I can tell the license statements in the WS-Policy documents permit copy and display, but grant no other rights. So taking this course would require that the SSTC be given this license. Then there is the consideration of whether a normative reference can be made in an OASIS standard to a document with the status of the WS-Policy documents. (3) We can say that WS-Policy provides a good technical base but requires modification to do what we want. In addition to all the concerns of (1) and (2), this would presumably require working with the maintainers of the WS-Policy documents to ensure that proposed modifications are mutually acceptable. This would more or less be taking WS-Policy as a SSTC work item, which would be a significant change in scope. Which path are you suggesting, or do you think there are other choices? - RL "Bob"