Re: [security-services] Re: WS-Policy?

["RL 'Bob' Morgan" <rlmorgan@washington.edu>]

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"