FAQ: how much can be domain-independent?

[Anne Anderson <Anne.Anderson@sun.com>]

Q: Isn't some domain-specific code necessary when using PCL?

A: Short answer: not at the pure policy intersection and verification level.

Long answer:

Endpoint applications that have to implement policy requirements always
need domain-specific code that understands the semantics of the policy
vocabulary.  For example, if an Assertion states:

     encryption-algorithm equals "AES"

then the endpoint applications must understand what
"encryption-algorithm" and "AES Encryption" mean and how to do
encryption and decryption using AES in order to enforce this policy
Assertion.  This level of verification and enforcement has not been
handled by "policy processors" in the past, but by domain-specific
abstract "policy enforcement points".

But at the policy agreement/negotiation level, only domain-independent
code is ever needed to handle WS-PolicyConstraints Assertions.  For
example, it is possible for a completely domain-independent generic
policy processor to determine whether two Assertions stating
requirements for "encryption-algorithm" are compatible or not.  The
WS-PolicyConstraints proposal adds the functions of policy assertion
intersection to the functions of policy assertion verification that an
XACML policy processor (Policy Decision Point) already supports.  But
the Policy Decision Point is still completely domain-independent.

Some levels of policy verification can also be domain-independent:

1. If a consumer service sends a copy of the name/value pairs
(Attributes) it is using as its policy for a transaction, then these can
be submitted to a domain-independent policy processor to determine
whether the values conform to the policy of the producer service.

2. If XPath is used to identify parts of the policy vocabulary, then if
a copy of a received message is passed to the domain-independent policy
processor, that processor can verify that the actual contents of the
message conform to the policy requirements stated using XPath.

3. If a domain-specific module provides Attributes related to a message
(either by computing them from the message, or by obtaining them from a
trusted repository,etc.), then a domain-independent policy processor can
determine whether these Attributes satisfy a given policy.  These
Attributes could also be provided as part of a message so long as
domain-specific code authenticates them.

Some policy requirements can not be verified by a domain-independent
PDP.  An example is a requirement that all references to a security
token must be external references (i.e. the token must not be carried in
the message itself).  It is possible for two services to agree that they
will use only external references using a domain-independent language:

        TokenReferenceType = "External"

Verifying this requirement, however, will probably require
domain-specific code that knows what references that are NOT external
look like.

XACML follows the IETF/DMTF model of distinguishing an abstract "Policy
Enforcement Point" (PEP) from a "Policy Decision Point" (PDP).  The
Policy Enforcement Point is domain-specific, but the Policy Decision
Point is completely domain-independent.  The Policy Decision Point can
be "assisted" by a domain-specific Context Handler that knows how to
retrieve Attributes required during evaluation of a policy.  Experience
with XACML has been that domain-specific Assertions are not required at
the pure policy level.  Very complex, domain-specific policies are
expressed and verified routinely using the domain-independent XACML
policy language.

To enable maximum interoperability and composability of web services, it
is important to separate domain-independent aspects of a policy from
domain-specific aspects.  Intermediary servers and 3rd party service
brokers, for example, should be able to determine whether two policies
are compatible, but they may not have the necessary domain-specific code
for all the policies they must handle.  Final verification and
implementation of some policy Assertions must be done at the endpoint
servers that actually run the applications, and thus have the necessary
domain-specific code modules.

Another way in which a domain-independent language helps
interoperability is in its ability to handle standard types of
Attributes, such as SAML Attributes or XACML Attributes.
Domain-specific code may be needed to retrieve the Attributes related to
a message, but domain-independent policies can be written using them,
and the actual verification of the Attributes can be done with
completely domain-independent code.

Deciding on a domain-independent policy assertion language now will help
implementers design appropriate separations between the domain-specific
code and the domain-independent code, making the implementations much
more extensible and interoperable.

Regards,
Anne
-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692