Re: potential issues for WS-Policy Primer and Guidelines

Maryann,

Thank you and the working group for the detailed responses.  I have  
included comments inline, in large part trying to clarify and re- 
emphasize my points.

In general, most of my issues are not disagreeing with what is in the  
spec but rather advocating for the need to provide guidance in wider  
areas to which the specs allude but then avoid.  The policy work is  
important as the emphasis on governance grows, and most of this  
interest goes well beyond avoiding wire-level mismatches.  I believe  
the working group would be missing a significant opportunity if it  
does not address the wider needs of its audience.

Ken


On Sep 21, 2007, at 4:32 PM, Maryann Hondo wrote:

>
> Ken,
> Thanks for your detailed comments on the Primer and Guidelines.
>
> The working group discussed these on our last call and we have  
> prepared the following replies to your specific questions
> which we hope you find useful.   Please let us know if there is  
> any  more clarification required.
>
> Policy WG [penned by Maryann Hondo]
>
> ---------------------------------------------------------------------- 
> --------------------------------Q 1a from Ken  
> ---------------------------------------------------------------------- 
> -----
>  1. [Primer, section 2.1] Web Services Policy is a machine-readable
> language for representing the capabilities and requirements of a Web
> service. These are called ‘policies’.  (Consistent text in WS-Policy
> Framework states, "A policy assertion represents a requirement,  
> capability,
>  or other property of a behavior.")
>      a. This is quite an expansion of the word “policy”.  It seems  
> to now
>      include all description that is not specifically covered by WSDL
> ---------------------------------------------------------------------- 
> ----------------------------------Response  1  
> a--------------------------------------------------------------------- 
> ------
> Policy is an overloaded term.
> There are many ways that the information not covered by WSDL can be  
> expressed.
> For example, the SAWSDL group has worked with the policy WG to try  
> to elaborate
> on the role of policy and the role of SAWSDL and we recommend you  
> take a look at section  5.3.3 of the Guidelines document
> which is titled "Self Describing Messages".  In this section we try  
> to differentiate between WSDL semantics and policy.
> The WG has done its best to clarify its description of policy  
> through clarifying our definitions of terms in
> "terminology" sections of the specifications [ i.e, Section 2.4 in  
> the Framework http://www.w3.org/TR/2007/REC-ws-policy-20070904/].
>
I concur with your guideline to use SAWSDL to attach semantics.  My  
issue is that this very expansive definition of policy, while  
welcome, is not carried through in the examples or the discussion of  
how the WS-Policy syntax would apply.  Specifying one's policies  
(where here I mean policy in that very broad sense) and ways to find  
and use the policies of others will be of primary interest to many of  
your readers.

> ---------------------------------------------------------------------- 
> ---------------------------------- Q1b  from Ken  
> ---------------------------------------------------------------------- 
> -----
>         b. The Primer later talks to policy intersection but this  
> would
>         require policy representation for non-service entities,  
> such as a
>         consumer expressing a required privacy policy not to sell  
> my contact
>         information.  The Framework and Attachment mechanisms may  
> suffice a
>         currently defined, but how is this used for non-service  
> entities?
>         [Note, there are numerous other places where this comment  
> applicable.]
>   
> ---------------------------------------------------------------------- 
> ----------------------------------Response 1b   
> ---------------------------------------------------------------------- 
> -----
> Section 3 of the Guidelines [ section cited below ]  "What is an  
> assertion?", attempts to describe what kind of metadata makes a  
> good policy assertion as well as identifying that policy represents  
> behaviors between Web service participants. We encourage you to  
> review this section.
>
> "Policy assertions representing shared and visible behaviors are  
> useful pieces of metadata to enable interoperability and tooling  
> for automation. The key to understanding when to design policy  
> assertions is to have clarity on the characteristics of a behavior  
> represented by a policy assertion. Some useful ways to discover  
> relevant behaviors are to ask questions like the following:
> Is this behavior a requirement?
> Is the behavior visible? ....."
>
Again, I concur with your discussion of what is an assertion but for  
non-service entities I have no guidance on where I would put (or to  
what I would attach) my assertions so policy intersection could occur.

> ---------------------------------------------------------------------- 
> ----------------------------------- Q 2 from Ken  
> ---------------------------------------------------------------------- 
> -----
>
> 2. [Primer, section 2.7] The wsp:Ignorable attribute allows
> providers to clearly indicate which policy assertions indicate
> behaviors that don’t manifest on the wire and may not be of concern
> to a requester when determining policy compatibility.  This is an
> example of the specs alluding to more general use and then getting
> lost in WS-Minutiae.  The policies likely to be of greatest
> consumer/business interest are the capabilities invoked by a service
> and the real world effects that result.  If WS-Policy is supposed to
> convey such information, the “user specs” (e.g. Primer and
> Guidelines) need to come at least equally from that viewpoint.
>   
> ---------------------------------------------------------------------- 
> ----------------------------------Response    
> 2--------------------------------------------------------------------- 
> -----
>
> The WG decided that in order to ground the Primer and Guidelines in  
> reality, that we would present examples from existing policy  
> domains. Unfortunately we did not have an example of this type of  
> business policy to use. If you are aware of one, we would welcome  
> any pointers, and would be willing to consider augmenting the  
> Primer examples as a last call update.
>
>
While I do not have a list of policies defined as in your examples  
(such as TransportBinding), it would not be difficult to create  
notional examples.  For example, I could identify a namespace for  
privacy policy

xmlns:privp="http://www.publicprivacy.org/individual"

and have a policy

<wsp:Policy>
   <privp:noShare/>
</wsp:Policy>

If that is the defined privacy policy to which I want other to  
comply, how/where do I make that known for policy intersection?

As another interesting example, show a WS-Policy representation for  
the W3C Patent Policy or some section of the Process Document.  How  
would we use this?

> ---------------------------------------------------------------------- 
> ----------------------------------- Q3 from Ken  
> ---------------------------------------------------------------------- 
> -----
>
> 3. [Primer, section 3.3] It is important to understand that a policy
> is a useful piece of metadata in machine-readable form that enables
> tooling, yet is not required for a successful Web service
> interaction. Why? Web service developers could use the
> documentation, talk to the service providers, or look at message
> traces to infer these conditions for an interaction. Developers
> continue to have these options, as they always had.  Again, the
> overriding perspective in tooling and not the non-developer use that
> most consumers will need of policy.  Yes, if most users see this as
> WS-Minutiae, most policy/description will remain in other  
> communications.
>
>   
> ---------------------------------------------------------------------- 
> ----------------------------------Response  3  
> ---------------------------------------------------------------------- 
> -----
> The Policy WG felt that specific details on tooling was an  
> implementation detail that implementers should provide, and was out  
> of scope of
> the Primer and Guidelines.
>
>
I agree as far as implementation details.  My point is that if a  
large portion of your likely audience does not understand the  
relevance to what they need to express as policy, then they will  
likely ignore this and the chaotic business as usual will persist.  I  
believe the use of this set of specifications could help reduce that  
chaos if the potential users can be brought along.

>
> ---------------------------------------------------------------------- 
> ---------------------------------- Q 4 from Ken  
> ---------------------------------------------------------------------- 
> -----
> 4. [Primer, section 3.4] A provider, like Company-X, and a
> requester, like the policy-aware client used in our example, may
> represent their capabilities and requirements for an interaction as
> policies...  The next section describes how to attach policies to
> service WSDLs but no where does it say where the requester policies
> go.  Note, saying you put them in a UDDI registry is great marketing
> for UDDI but otherwise unacceptable.  In addition, the Attachment
> spec addresses the “technical” rolling up of abstract (tModel) to
> concrete (bindingTemplate) but not the “business” question of how
> policies on businessEntity and businessService combine with Endpoint
> or each other to express business constraints.
>   
> ---------------------------------------------------------------------- 
> ----------------------------------Response    
> 4--------------------------------------------------------------------- 
> ------
> Again, the number and type of client requestors may vary, and  
> therefore how a client generates or stores its policy is an  
> implementation choice.
>
One could argue that the UDDI discussion is also implementation  
specific.  The issue is not how many implementations to specify but  
whether more should be said as a guideline for those reading this  
document and not knowing where a policy-aware client might  
considering looking for policy and how it would even have a clue  
where to look.  This is a serious hole when we need to consider  
policy intersection for non-WSDL bearing entities.

> ---------------------------------------------------------------------- 
> --------------------------------- Q5 from Ken  
> ---------------------------------------------------------------------- 
> -----
> 5. [Primer, section 3.4.1] A requester can decide how to process a
> provider's policy to determine if and how the requester will
> interact with the provider. The requester can have its own policy
> that expresses its own capabilities and requirements, and can make
> one or more attempts at policy intersection in order to determine a
> compatible alternative and/or isolate the cause of an empty
> intersection result. The requester can use and analyze the result(s)
> of policy intersection to select a compatible alternative or trigger
> other domain-specific processing options.  This is actually very  
> important for several reasons.
>        a. It highlights again the intent to have WS-Policy cover a  
> wide
>         range of description (e.g. what effects does the requester  
> want),
>         some boilerplate and some specific to the interaction.   
> Where are
>         Primer suggestions for requester side of interaction?
>
>         b. Once this negotiation has been done, there is a need to  
> save the
>         result for (a) documenting how the interaction occurred, (b)
>         avoiding a renegotiation every time the same requester  
> tries to use the same service.
>
>   
> ---------------------------------------------------------------------- 
> ---------------------------Response 5a & b   
> ---------------------------------------------------------------------- 
> -----
> Negotiation is out of scope for the current policy WG, and we have  
> an existing issue [ 3616 ] that is marked as a v-next topic.
> Also your case b. (b) appears to be a client side implementation  
> detail.
>
While the details of negotiation are certainly out of scope, some  
requester side guidance would be helpful.  As for (b), I agree this  
goes beyond the present scope but I find it a compelling case for  
future consideration.

> ---------------------------------------------------------------------- 
> ----------------------------------- Q  6 from Ken  
> ---------------------------------------------------------------------- 
> -----
> 6. [Primer, section 3.5] If multiple policy expressions are attached
> to WSDL elements that collectively represent a policy subject then
> the effective policy of these policy expressions applies. The
> effective policy is the combination of the policy expressions that
> are attached to the same policy subject.  Here I have a fundamental
> hurt point.  I have no argument as described, e.g. if you attach a
> policy to an abstract component, then it should apply to its
> concrete instance.  The problem is the roll up goes downward to the
> finer component rather than upward to the service itself.  Yes, the
> Framework spec [Introduction] says it “does not cover discovery of
> policy”, but how do I discover a service if the details of its
> description can be found anywhere in the lowest levels of its WSDL?
> Again, the specs imply expansive coverage but only really consider
> the lowest level nuts and bolts that are of little interest to most
> users whose domain is policies.
>   
> ---------------------------------------------------------------------- 
> ----------------------------------Response   
> 6--------------------------------------------------------------------- 
> ------
> This seems to be a question of the granularity of discovery and  
> this was again considered out of scope by the current working group  
> but could be a v-next issue. Is there any other action you suggest?
>
I do not think the effort needed to investigate this is trivial and  
so while I would like to see it included in the current documents, I  
understand a request for immediate action is probably out of the  
question.  However, possibly as part of v-next, I would suggest  
looking at a variety of discovery scenarios to investigate what might  
need to be added to the specifications to support what is likely one  
of the primary uses of policy information.

> ---------------------------------------------------------------------- 
> ------------------------------Q7 from Ken  
> ---------------------------------------------------------------------- 
> -----
> 7.  [Guidelines, section 2] A visible behavior refers to a
> requirement that manifests itself on the wire.  This is again much
> too limited to the technical perspective.  A visible behavior is one
> that the participants can see in the real world and will likely have
> nothing directly to do with the message on the wire.
> ---------------------------------------------------------------------- 
> ---------------------------------Response   
> 7--------------------------------------------------------------------- 
> ------
>
> Section 3 of the Guidelines [ section cited below ]  also includes  
> a description of visible behavior, that the WG has agreed to [ with  
> some clarification cited in bold/italic].
> Is the behavior visible?
> A visible behavior refers to a requirement that manifests itself on  
> the wire. Web services provide interoperable machine-to-machine  
> interaction among disparate systems. Web service interoperability  
> is the capability of disparate systems to exchange data using  
> common data formats and protocols supporting characteristics such  
> as messaging, security, reliability and transaction. Such data  
> formats and protocols manifest on the wire. Providers and  
> requesters rely on wire messages conforming to such formats and  
> protocols to achieve interoperability.
> If an assertion describes a behavior that does not manifest on the  
> wire then the assertion will not impact the interoperability of  
> wire messages, but may still be relevant to enabling an  
> interoperable interaction. For example, a provider may not wish to  
> interact unless a client can accept an assertion describing  
> provider behavior. An example is an assertion that describes the  
> privacy notice information of a provider and the associated  
> regulatory safeguard in place on the provider's side. For cases  
> where the provider does not intend the assertion to impact  
> interoperability it may mark it as ignorable.
> If an assertion has no wire or message-level visible behavior then  
> the interacting participants may require some sort of additional  
> mechanism to indicate compliance with the assertion and to enable  
> dispute resolution. Introducing an additional non-repudiation  
> mechanism adds unnecessary complexity to processing a policy  
> assertion.

My point is that the interest of many of the policy end users will  
not be wire-level interoperability but those you refer to as  
interoperable interaction.  I think you unnecessarily limit yourself  
when visible is only wire level.

------------------------------------------------------------------------ 
-----
Ken Laskey
MITRE Corporation, M/S H305      phone: 703-983-7934
7151 Colshire Drive                         fax:       703-983-1379
McLean VA 22102-7508