- From: Maryann Hondo <mhondo@us.ibm.com>
- Date: Wed, 13 Sep 2006 20:56:44 -0400
- To: "David Orchard" <dorchard@bea.com>
- Cc: public-ws-policy-eds@w3.org, public-ws-policy-eds-request@w3.org
- Message-ID: <OFE878F041.8D024359-ON872571E8.0081E80F-852571E9.00053116@us.ibm.com>
David,
so here's my latest proposal. i think we're stuck with a few [5]
"domain-specific" phrases (and one "domain-independent") , because I'm not
sure how else to disambiguate "framework" processing of assertions and the
other "domain-specific" interpretation of semantics.....does this make
sense?
Where I thought I could I dropped "domain" as you suggested and just have
"authors". If we can come up with other terms for "framework" and
"non-framework/extensions" we might be able to get rid of more.
What do you think?
Maryann
3.1 Policy Assertion
A policy assertion identifies a behavior that is a requirement (or
capability) of a policy subject. Assertions indicate domain-specific [1]
semantics (e.g., security, transactions) and are expected to be defined in
separate specifications. Assertions are strongly typed by the authors that
define them. 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 one
of its [children]. Policy expression nesting is 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 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.
4.4 Policy Intersection
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.
Because the set of behaviors indicated by a policy alternative depends on
the semantics of the collected assertions, determining whether two policy
alternatives are compatible generally involves domain-specific[2]
processing. As a first approximation, an algorithm is defined herein that
approximates compatibility in a domain-independent [A] manner;
specifically, for two policy alternatives to be compatible, they must at
least have the same 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 [3] compatibility
processing.
Two policy alternatives are compatible if each assertion in one 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.
As an example of intersection, consider two input policies in normal form:
(01) <wsp:Policy
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
xmlns:wsp="http://www.w3.org/@@@@/@@/ws-policy" >
<!-- Policy P1 -->
(02) <wsp:ExactlyOne>
(03) <wsp:All> <!-- Alternative A1 -->
(04) <sp:SignedElements>
(05) <sp:XPath>/S:Envelope/S:Body</sp:XPath>
(06) </sp:SignedElements>
(07) <sp:EncryptedElements>
(08) <sp:XPath>/S:Envelope/S:Body</sp:XPath>
(09) </sp:EncryptedElements>
(10) </wsp:All>
(11) <wsp:All> <!-- Alternative A2 -->
(12) <sp:SignedParts>
(13) <sp:Body />
(14) <sp:Header
Namespace="http://www.w3.org/2005/08/addressing" />
(15) </sp:SignedParts>
(16) <sp:EncryptedParts>
(17) <sp:Body />
(18) </sp:EncryptedParts>
(19) </wsp:All>
(20) </wsp:ExactlyOne>
(21) </wsp:Policy>
The listing above contains two policy alternatives. The first alternative,
(Lines 03-10) contains two policy assertions. One indicates which elements
should be signed (Lines 04-06); its type is sp:SignedElements (Line 04),
and its parameters include an XPath expression for the content to be
signed (Line 05). The other assertion (Lines 07-09) has a similar
structure: type (Line 07) and parameters (Line 08).
The second alternative (Lines 11-19) also contains two assertions, each
with type (Line 12 and Line 16) and parameters (Lines 13-14 and Line 17).
As this example illustrates, compatibility between two policy assertions
is based on assertion type and delegates parameter processing to
domain-specific[4] processing.
(01) <wsp:Policy
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
xmlns:wsp="http://www.w3.org/@@@@/@@/ws-policy" >
<!-- Policy P2 -->
(02) <wsp:ExactlyOne>
(03) <wsp:All> <!-- Alternative A3 -->
(04) <sp:SignedParts />
(05) <sp:EncryptedParts>
(06) <sp:Body />
(07) </sp:EncryptedParts>
(08) </wsp:All>
(09) <wsp:All> <!-- Alternative A4 -->
(10) <sp:SignedElements>
(11) <sp:XPath>/S:Envelope/S:Body</sp:XPath>
(12) </sp:SignedElements>
(13) </wsp:All>
(14) </wsp:ExactlyOne>
(15) </wsp:Policy>
Because there is only one alternative (A2) in policy P1 with the same
vocabulary ? the assertions have the same type ? as another alternative
(A3) in policy P2, the intersection is a policy with a single alternative
that contains all of the assertions in A2 and in A3.
(01) <wsp:Policy
xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"
xmlns:wsp="http://www.w3.org/@@@@/@@/ws-policy" >
<!-- Intersection of P1 and P2 -->
(02) <wsp:ExactlyOne>
(03) <wsp:All>
(04) <sp:SignedParts >
(05) <sp:Body />
(06) <sp:Header
Namespace="http://www.w3.org/2005/08/addressing" />
(07) </sp:SignedParts>
(08) <sp:EncryptedParts>
(09) <sp:Body />
(10) </sp:EncryptedParts>
(11) <sp:SignedParts />
(12) <sp:EncryptedParts>
(13) <sp:Body />
(14) </sp:EncryptedParts>
(15) </wsp:All>
(16) </wsp:ExactlyOne>
(17) </wsp:Policy>
Note that there are > 1 assertions of the type sp:SignedParts ; when the
behavior associated with sp:SignedParts is invoked, the contents of both
assertions are used to indicate the correct behavior. Whether these two
assertions are compatible depends on the domain-specific[5] semantics of
the sp:SignedParts assertion. To leverage intersection, assertion authors
are encouraged to factor assertions such that two assertions of the same
assertion type are always (or at least typically) compatible.
"David Orchard" <dorchard@bea.com>
Sent by: public-ws-policy-eds-request@w3.org
08/28/2006 07:10 PM
To
Maryann Hondo/Austin/IBM@IBMUS, <public-ws-policy-eds@w3.org>
cc
Subject
RE: proposed text for AI #15
I must admit I've always found the use of the word "domain" in these specs
confusing. That's probably because I've been a bit late to the game on
this. In general, I'm not sure why the word Domain is even used, and
defined instead of just "assertion".
For example, the 2nd paragraph of the proposed 3.1 says
WS-Policy Domain authors MAY define that an assertion contains a policy
expression as one of its [children]. Policy expression nesting is used by
WS-Policy domain authors to further qualify one or more specific aspects
of the original assertion. For example, security domain authors may
defined an WS-Policy assertion describing a set of security algorithms to
qualify the specific behavior of a security binding assertion.
Why not say instead:
WS-Policy Assertion authors MAY define that an assertion contains a policy
expression as one of its [children]. Policy expression nesting is used by
WS-Policy assertion authors to further qualify one or more specific
aspects of the original assertion. For example, security assertion authors
may defined an WS-Policy assertion describing a set of security algorithms
to qualify the specific behavior of a security binding assertion.
?
What I'd like to see is a clear case of where something is
"domain-specific" and not "assertion-specific", and vice-versa.
Now, assuming that I'm out to lunch on this, that there is a real need for
domain to be detailed as shown, I'd like to see the definitions inlined as
we've done with all the other definitions.
Cheers,
Dave
From: public-ws-policy-eds-request@w3.org
[mailto:public-ws-policy-eds-request@w3.org] On Behalf Of Maryann Hondo
Sent: Wednesday, August 02, 2006 11:23 AM
To: public-ws-policy-eds@w3.org
Subject: proposed text for AI #15
As per my actions: http://www.w3.org/2006/07/27-ws-policy-minutes.html:
<scribe> ACTION: editors to clear up 3.4 paragraphs about domain and also
define domain expression [recorded in
http://www.w3.org/2006/07/13-ws-policy-minutes.html#action15]
Although the Action Items refers to text in section 3.4 there is no
specific reference to "domain" in this section.
Here is the list of my suggested changes for "domain"
Maryann
-----------------------------------------------------------------------
Proposed new definitions:
-----------------------------------------------------------------------
Domain - The original etymological implication of the word domain carries
the idea of "something ruled". In Information Technology it commonly
refers to a machine or a host on the Internet.(
http://en.wikipedia.org/wiki/Domain)
A "WS-Policy Domain" is a logical grouping of assertions that a
particular community has agreed to define (in conformance with the
WS-Policy specifications) to facilitate the interoperability of web
services within that community of interest.
A "WS-Policy domain expression" is an XML representation of a capability
or a constraint within the context of a WS-Policy domain or community of
interest.
-----------------------------------------------------------------------
Proposed edits ( in bold and strikethrough)
-----------------------------------------------------------------------
1.1 Goals
The goal of Web Services Policy 1.5 - Framework is to provide the
mechanisms needed to enable Web services applications to specify policy
information. Specifically, this specification defines the following:
An XML Infoset called a policy expression that contains domain-specific,
Web Service policy information.
A core set of constructs to indicate how choices and/or combinations of
domain-specific policy assertions apply in a Web services environment.
....
3.1 Policy Assertion
A policy assertion identifies a behavior that is a requirement (or
capability) of a policy subject. Assertions indicate WS-Policy domain
-specific (e.g., security, transactions) semantics and are expected to be
defined in separate, WS-Policy domain-specific specifications [i.e.
WS-SecurityPolicy, WS-ReliableMessagingPolicy] .Assertions are strongly
typed by the domain authors that define them. 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.
WS-Policy Domain authors MAY define that an assertion contains a policy
expression as one of its [children]. Policy expression nesting is used by
WS-Policy domain authors to further qualify one or more specific aspects
of the original assertion. For example, security domain authors may
defined an WS-Policy 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.
WS-Policy Domain authors should be cognizant of the processing
requirements when defining complex assertions containing additional
assertion content or nested policy expressions. Specifically, WS-Policy
domain authors are encouraged to consider when the identity of the root
Element Information Item alone is enough to convey the
4.4 Policy Intersection
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.
...
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
WS-Policy domain-specific processing. As a first approximation, an
algorithm is defined herein that approximates compatibility in a WS-Policy
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).
...
Assertion parameters are not part of the compatibility determination
defined herein but may be part of other, domain-specific compatibility
processing.
...
As this example illustrates, compatibility between two policy assertions
is based on assertion type and delegates parameter processing to domain
-specific processing.
...
Note that there are > 1 assertions of the type sp:SignedParts ; when the
behavior associated with sp:SignedParts is invoked, the contents of both
assertions are used to indicate the correct behavior. Whether these two
assertions are compatible depends on the domain-specific semantics of the
sp:SignedParts assertion. To leverage intersection, assertion authors are
encouraged to factor assertions such that two assertions of the same
assertion type are always (or at least typically) compatible.
Received on Thursday, 14 September 2006 00:57:01 UTC