RE: NEW ISSUE: Semantics of successful intersection determined by domain-specific assertion content

Hi Glen,

I agree with you that we should not remove the ability to provide domain
specific intersection semantics.  For a large number of assertion types,
the standard intersection algorithm is sufficient as long as the
assertion is designed to take advantage of it.  Assertion authors can
use the assertion QName and nested policy expressions in order to allow
a generic policy processor to compute compatibility without any domain
specific knowledge.  However, there are some scenarios were standard
intersection is not enough, so we need to allow for extensibility.  The
policy framework explicitly allows for layering domain specific
intersection semantics on top of the base intersection algorithm [1].

Because the set of behaviors indicated by a policy alternative depends
on the domain-specific semantics of the collected assertions,
determining whether two policy alternatives are compatible generally
involves domain-specific processing. As a first approximation, an
algorithm is defined herein that approximates compatibility in a
domain-independent manner; specifically, for two policy alternatives to
be compatible, they must at least have the same vocabulary (see Section
3.2 Policy Alternative).

Generic processors can delegate to extensions and plug-ins based on the
assertion QName in order to handle domain specific intersection
semantics.  Policy intersection involves two policies and it is the
responsibility of party performing the compatibility test to ensure that
the necessary extensions are available if they are necessary.  Even if
the extensions are not available the framework explicitly states that
the intersection algorithm is a reasonable "approximation" for testing
compatibility (see 4.4).  In the end, it is the provider that is the
ultimate jury for compatibility.

Additional metadata identifying assertions that require domain specific
intersection semantics at best would only allow a generic tool to warn
the user that the compatibility results may be inaccurate.  These
warnings don't tell you anything useful other than the requirement that
already exists, which is that you must supply the appropriate domain
extensions.

Fortunately, the defined intersection algorithm covers most scenarios so
that assertions that require domain specific intersection semantics are
rare.  It is notable that to date there are no known standardized
assertion types that require domain specific intersection semantics,
although we should provide clear guidance to assertion authors that they
are responsible for defining how to do domain specific intersection for
their assertions if such semantics are necessary.

My preference is for option #1 (status quo) + add clear guidance for
assertion authors that they are responsible for defining how to do
domain specific intersection for their assertions if such semantics are
necessary.

[1]
http://dev.w3.org/cvsweb/~checkout~/2006/ws/policy/ws-policy-framework.h
tml?content-type=text/html;%20charset=utf-8#Policy_Intersection 

Daniel Roth

-----Original Message-----
From: public-ws-policy-request@w3.org
[mailto:public-ws-policy-request@w3.org] On Behalf Of Glen Daniels
Sent: Wednesday, July 12, 2006 7:57 PM
To: public-ws-policy@w3.org
Subject: NEW ISSUE: Semantics of successful intersection determined by
domain-specific assertion content



Description:

Section 4.4 of the WS-Policy spec [1] states that domain-specific
processing may need to be performed in order to determine the
intersection of two policies.  This means that generic Policy processors
(tools, etc) cannot have any guarantee of successfully calculating the
intersection without appropriate extensions/plugins being available for
all domain-specific assertions.

Justification:

There are potentially serious interoperability concerns here, since
building a general-purpose Policy processor which reliably computes
intersections is impossible without some indication that assertions do
(or do not) augment the semantics.

Proposal:

The solution space here seems to work out like this -

1) Leave it as-is.

2) Remove the ability for domain-specific logic to affect intersection,
and only use top-level QName matching.  This would simplify the
algorithm and allow interoperability, but at the cost of disabling some
powerful functionality for domain authors.

3) Since WS-Policy is a generic framework, it should be possible to at
least *know* when particular assertions are going to affect the
intersection semantics.  It would be fairly easy to have a "wsp:custom"
(not necessarily the best name) attribute on assertions, which when
"true" would indicate that the marked assertion does alter/augment
intersection semantics.  In that case, the processor would be able to
recognize when it has the correct plugins, and when it cannot deliver a
reliable intersection.  This is analagous to soap:mustUnderstand and
wsdl:required - an indication that an extension may change the rules in
ways that must be agreed upon for success.

I therefore propose we begin discussion, with a preference to explore
solution #3.

Thanks,
--Glen

[1] http://www.w3.org/Submission/WS-Policy/#Policy_Intersection

Received on Tuesday, 5 September 2006 17:25:32 UTC