[Bug 4292] Intersection mode is neither defaulted nor specified

http://www.w3.org/Bugs/Public/show_bug.cgi?id=4292

           Summary: Intersection mode is neither defaulted nor specified
           Product: WS-Policy
           Version: FPWD
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Framework
        AssignedTo: fsasaki@w3.org
        ReportedBy: cbarreto@adobe.com
         QAContact: public-ws-policy-qa@w3.org
                CC: cbarreto@adobe.com


A potential problem exists with intersection mode selection. Intersection mode
is not defaulted in the Framework specification, and mode indication is not
specified. This leaves Framework open to implementations where a provider
requires one mode and a client may or may not interpret it, and may or may not
support that same mode. From the implementation perspective, a consumer will
not be able to talk to a provider and not be able to report why.
At present, a consumer can only detect that a service request has failed when
intersection cannot be performed. Intersection rules as specified in Framework
do not provide for a standard way of reflecting why intersection could not be
performed - intersection can fail for reasons other than the policies
incompatibility as driven by mode (e.g. a policy not being complete when
intersection is attempted). Intersection may also fail due to poorly written
policies which would not be compatible regardless of mode.

Consider:
Scenario 1:
            Entity A: Service policy requires that any intersections apply lax
mode
            Entity B: Service policy requires that any intersections apply
strict mode

In the current Framework spec
            1. Entity B attempts to use Entity A's service. Entity A's required
lax mode conflicts with Entity B's required strict mode and Entity B's request
will fail.
            2. Entity B reports that the request failed, but cannot report why.

For example, a provider of a service which handles LOB processing can provide a
number of QoS which are exposed as policies. A consumer can effectively
navigate which QoS (service interface) to use through its requirements.
However, a consumer of an LOB processing service may be required to always
apply either its own assertions or always accept the provider's base (e.g.
always accepting the provider's base assertions as a way of
certifying/validating it's interaction with the service). 

Scenario 2:
            Entity A: Service policy requires that any intersections apply
strict mode
            Entity B: Service policy accepts strict intersection but, but the
entity doesn't implement strict

In the current Framework spec
            1. Entity B attempts to use Entity A's service, but has not
implemented handling of strict mode intersection and this fails in its request.
            2. Entity B reports that the request failed, but cannot report why. 

For example, a provider has a service which, while ignorable, prioritises its
policies (strict) - for example, an internet banking service which always
requires its security and reliability policies to the exclusion of a consumer's
requirements. However, certain consumers of this service type may be required
to use their own security policies - they may not have implemented the capacity
to use the provider's service with the provider's required security policy
(thus supporting only lax). 

Either scenario highlights the fact that strict and lax mode, as ignorable is
currently specified, can be used exclusively by either consumer or provider. As
such, WS-Policy needs to address cases where they are used as such.

Received on Wednesday, 31 January 2007 16:16:38 UTC