This section
defines an abstract model for policies and for operations upon policies.
The descriptions
below use XML Infoset terminology for convenience of description. However, this
abstract model itself is independent of how it is represented as an XML
Infoset.
[Definition: A policy assertion represents an
individual requirement, capability, or other property of a behavior.] A policy assertion
identifies a behavior that is a requirement or capability of a policy subject. [Definition: A policy subject is an entity
(e.g., an endpoint, message, resource, operation) with which a policy can be associated. ]
Assertions indicate domain-specific (e.g., security, transactions) semantics
and are expected to be defined in separate, domain-specific specifications.
An
assertion MAY indicate
that it is an ignorable policy assertion (see 4.4
Ignorable Policy Assertions). An
ignorable policy assertion is an assertion that may be ignored for
policy intersection (as defined in Section 4.5 Policy Intersection). By
default, an assertion is not ignorable for policy intersection.
Assertions are
typed by the authors that define them. [Definition:
A policy assertion type represents a class of policy assertions and implies a schema for the
assertion and assertion-specific semantics.] The policy assertion
type is identified only by the XML Infoset [namespace name] and [local name]
properties (that is, the qualified name or QName) of the root Element
Information Item representing the assertion. Assertions of a given type MUST be consistently interpreted independent of their policy subjects.
Authors MAY define that an assertion contains a policy expression (as
defined in 4. Policy
Expression) as one of its [children]. Nested policy
expression(s) are used by authors to further qualify one or more specific
aspects of the original assertion. For example, security policy authors may define
an assertion describing a set of security algorithms to qualify the specific
behavior of a security binding assertion.
The XML Infoset
of a policy assertion MAY contain a non-empty [attributes] property and/or a non-empty [children] property.
Such properties are policy assertion parameters and MAY be used to parameterize the behavior indicated by the
assertion. [Definition: A policy
assertion parameter qualifies the behavior indicated by a policy assertion.] For
example, an assertion identifying support for a specific reliable messaging
mechanism might include an attribute information item to indicate how long an
endpoint will wait before sending an acknowledgement.
Authors should be
cognizant of the processing requirements when defining complex assertions
containing policy assertion parameters or nested policy
expressions. Specifically, authors are encouraged to consider when the
identity of the root Element Information Item alone is enough to convey the
requirement or capability.
The wsp:MayBeIgnored attribute indicates if a policy
assertion is an ignorable policy assertion. The
schema outline for this attribute is as follows:
(01) <
The
following describes the Attribute Information Item defined in the schema
outline above:
/Assertion/@wsp:MayBeIgnored
This is an optional attribute of type xs:boolean. If the
actual value (See XML Schema Part 1 [XML Schema Structures])
is true, the assertion is an ignorable policy assertion. If the
actual value is false, the assertion is not an
ignorable policy assertion. Omitting
this attribute is semantically equivalent to including it with a value of
false.
Policy
intersection is useful when two or more parties express policy and want to limit the policy alternatives to those that are mutually
compatible. For example, when a requester and a provider express requirements
on a message exchange, intersection identifies compatible policy alternatives
(if any) included in both requester and provider policies. Intersection is a commutative,
associative function that takes two policies and returns a policy. There are
two modes for intersection: strict and lax. How the mode is indicated for the
policy intersection is outside the scope of this specification.
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. If a domain-specific intersection processing algorithm is required
will be known from the QNames of the specific assertion types involved in the policy
alternatives. 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 policy
alternative vocabulary (see Section 3.2
Policy Alternative).
·
Two policy
assertions are compatible if they have the same type and
·
If either assertion contains a nested policy expression, the two assertions are
compatible if they both have a nested policy expression and the alternative in
the nested policy expression of one is compatible with the alternative in the
nested policy expression of the other.
Assertion
parameters are not part of the compatibility determination defined herein
but may be part of other, domain-specific compatibility processing.
·
If the mode is strict Ttwo
policy alternatives
are compatible if each assertion in one is compatible with an assertion in the
other, and vice-versa. If the mode
is lax, two policy alternatives are compatible if each
assertion in one that is not an ignorable assertion is
compatible with an assertion in the other, and vice-versa. If two
alternatives are compatible, their intersection is an alternative containing
all of the assertions in both alternatives.
·
Two policies are compatible if
an alternative in one is compatible with an alternative in the other. If two
policies are compatible, their intersection is the set of the intersections
between all pairs of compatible alternatives, choosing one alternative from
each policy. If two policies are not compatible, their intersection has no
policy alternatives.
…
Part 2 – XML Schema
Declaration for the New Attribute
xs:attribute name="MayBeIgnored"
type="xs:boolean" default="false"
/>
Part 3 - Changes to
3894 Resolution
Two policy assertions are equivalent if they
have the same QName, if either policy assertion is an ignorable policy
assertion, both assertions must be ignorable policy assertions and,
if either policy assertion has a nested policy, both assertions must have a
nested policy and the nested policies must be equal.
Part 4 – Follow on
Action to Propose Text for the Primer and Guidelines Documents
Maryann to open an issue and propose text for
the Primer and Guidelines documents.