Policy support - wsdl policy use case

Dear 
members:

 

As we embark on 
tackling policy in the context of the technical notes [1], [2] and 
[3] 
I'd like 
us to also consider and ensure that we look a set of specific modeling 
requirements which today are not directly supported by WS-PolicyAttachment IMO. 

 

I offer 
the attached WSDL and it use of WS-Policy (ignore for the moment that it 
references the 2002 version of WS-Pol) as a set of concrete requirements 
that we need to address in the context of representing this 
in registry (to make it discoverable... I'll avoid stating the other 
obvious use cases). 

 

What this WSDL does 
is simply demonstrate the need to:

  
identify whether a 
  policy is a capability or a constraint; 
  there are some that would consider configuration policy (not 
  a view that I hold). To my way of thinking, one's capability is another's 
  constraint. While the WSDL does not clearly put this out as a consideration, 
  we need to tackle this issue. 

  
As you can tell 
  from the WSDL, policy constraints (confidentiality and integrity constraints) 
  and policy capability (use of x509v3 token - you might not agree on whether 
  capability or constraint - so be it - not that important at this point other 
  than to clearly call out the need to understand both cases) need to be 
  expressed not only on the access point (i.e. the uddi:bindingTemplate) but at 
  the operation level and in this specific case the message 
  level.

  
Does this imply 
  that we have to map operations and messages to the registry and update the 
  WSDL/UDDI mapping and update ws-policyattachment? No. We surely may have to 
  review the WSDL/UDDI mapping but I would not jump to the conclusion that 
  we must map ops and msgs simply to be able to tack on a policy 
  expression. I think what is required is the means to express on the 
  uddi:bindingTemplates constraints and capabilities that apply to its messages 
  and operations. We might convince ourselves that we have to reify operations 
  in the registry, but once you do that what would be the rationale for not 
  reifying the messages (and maybe we will need to) ... ok so I digress... 
  I think you know where I'm going with this. 

Unfortunately, I can't be on the call 
tomorrow. I scheduled a TC call and a flight to the west coast at the same time. 
Oops... sorry.

 

Please review. I hope that this will help kick off out 
policy deliberations and work.

Regards, 

Luc

Luc Clément | Program Director 
| Systinet Corporation |
Co-Chair OASIS UDDI Specification Technical 
Committee
One van de Graaff Drive Burlington, MA 01803
Phone +1 
781.362.1330 | Mobile +1 978.793.2162 | Fax +1 781.362.1400 | 

 

[1] “Secure Channel for 
Trustworthiness” Technical Note - http://lists.oasis-open.org/archives/uddi-spec/200503/msg00028.html

[2] “HTTP Basic and 
Digest Authentication” Technical Note - http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/11960/uddi-spec-tc-tn-httpauth-20050321.doc

[3] “WS-Security 
Modeling” Technical Note - http://www.oasis-open.org/apps/org/workgroup/uddi-spec/download.php/12217/uddi-spec-tc-tn-wssecurity-20040328.doc

 

echo_policy.wsdl