• This section defines an abstract model for policies and for operations upon policies.
• This abstract model is independent of how it is represented as an XML Infoset.

1 Policy Assertion

• A policy assertion identifies a behavior that is a requirement (or capability) of a policy subject. Assertions indicate domain-specific (e.g., security, transactions) semantics and are expected to be defined in separate, domain-specific specifications.
• Assertions are strongly typed by the domain authors that define them. The 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.
• Domain authors MAY define that an assertion contains a policy expression as one of its [children]. Policy expression nesting is used by domain authors to further qualify one or more specific aspects of the original assertion. For example, security policy domain 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 an assertion MAY contain a non-empty [attributes] property and/or a non-empty [children] property. Such content MAY be used to parameterize the behavior indicated by the 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.
• Domain authors should be cognizant of the processing requirements when defining complex assertions containing additional assertion content or nested policy expressions. Specifically, domain authors are encouraged to consider when the identity of the root Element Information Item alone is enough to convey the requirement (capability).

2 Policy Alternative

• A policy alternative is a logical construct which represents a potentially empty collection of policy assertions. An alternative with zero assertions indicates no behaviors. An alternative with one or more assertions indicates behaviors implied by those, and only those assertions.
• The vocabulary of a policy alternative is the set of all assertion types within the alternative. The vocabulary of a policy is the set of all assertion types used in all the policy alternatives in the policy. An assertion whose type is part of the policy's vocabulary but is not included in an alternative is explicitly prohibited by the alternative.
• Assertions within an alternative are not ordered, and thus aspects such as the order in which behaviors (indicated by assertions) are applied to a subject are beyond the scope of this specification.
• A policy alternative MAY contain multiple assertions of the same type. Mechanisms for determining the aggregate behavior indicated by the assertions (and their Post-Schema-Validation Infoset (PSVI) content, if any) are specific to the assertion type and are outside the scope of this document.

3 Policy

• At the abstract level a policy is a potentially empty collection of policy alternatives. A policy with zero alternatives contains no choices; a policy with one or more alternatives indicates choice in requirements (or capabilities) within the policy.
• Alternatives are not ordered, and thus aspects such as preferences between alternatives in a given context are beyond the scope of this specification.
• Alternatives within a policy may differ significantly in terms of the behaviors they indicate. Conversely, alternatives within a policy may be very similar. In either case, the value or suitability of an alternative is generally a function of the semantics of assertions within the alternative and is therefore beyond the scope of this specification.

4 Web services

• Applied in the Web services model, policy is used to convey conditions on an interaction between two Web service endpoints. Satisfying assertions in the policy usually results in behavior that reflects these conditions. Typically, the provider of a Web service exposes a policy to convey conditions under which it provides the service. A requester might use this policy to decide whether or not to use the service. A requester may choose any alternative since each is a valid configuration for interaction with the service, but a requester MUST choose only a single alternative for an interaction with a service since each represents an alternative configuration.
• A policy assertion is supported by a requester if and only if the requester satisfies the requirement (or accommodates the capability) corresponding to the assertion. A policy alternative is supported by a requester if and only if the requester supports all the assertions in the alternative. And, a policy is supported by a requester if and only if the requester supports at least one of the alternatives in the policy. Note that although policy alternatives are meant to be mutually exclusive, it cannot be decided in general whether or not more than one alternative can be supported at the same time.
• Note that a requester may be able to support a policy even if the requester does not understand the type of each assertion in the vocabulary of the policy; the requester only has to understand the type of each assertion in the vocabulary of a policy alternative. This characteristic is crucial to versioning and incremental deployment of new assertions because this allows a provider's policy to include new assertions in new alternatives while allowing requesters to continue to use old alternatives in a backwards-compatible manner.