Observations on WS-Policy Ashok Malhotra Oracle Corporation

Based on Developer Experience and Interactions with Customers

Operators allow assertions from disparate domains WS-Policy allows operations to combine assertions from disparate domains Like saying -- add (5, hello.world) -- > type error Problems not detected early at policy syntax checking time but later at policy execution time Suggestion: operators can only combine assertions from a single domain e.g. messageProtection

Embedded policies too general WS-SecurityPolicy allows embedded policies to further qualify an assertion Idea of qualifying assertions is good But embedded too general as anything can go in a policy Again, the problem is that nonsense policies can be authored and will not be caught until policy deployment time. Suggestion: allow only specific qualifying child elements for each assertion

What Policy Does a Message Follow? How do we figure out what policies a message adheres to? There is an assumption that the message header indicates the policies being followed. Not always possible because some policies are not reflected in message content such as auditing, logging, privacy. Suggestion: allow messages to point to the policy the adhere to

Allow messages to refer to policy expressions Useful if policy intent not reflected in message content For example, informational policies such as privacy, logging, auditing For long-running conversations, assert policy has not changed

Allow messages to refer to policy expressions Policy usage model -- client and server intersect policies and decide on what policy alternative to follow Assumes all messages in sequence follow the same policies If some messages, e.g. first message deviate from agreed-upon policy they should be able to say so Extension: allow messages to indicate the policy they follow as well as the policy they want the response to follow

Matching Policy Assertions WS-Policy says that the semantics of matching policy assertions depends on the specific assertion type No guidance from the specification If each implementation can define matching semantics for an assertion type independently then clients and servers may have trouble coordinating policies if they define different assertion semantics for the same assertion type

Matching Policy Assertions Assertion without embedded policy does not match same assertion with embedded policy Thus: does not match Should assertion without embedded policies match same assertion with all embedded policies? Issue before WS-SX

Policy Versioning Some customers wants to store policies in a repository and manage them actively – Policies will change over time – Some global policies will override local policies What we need: – Carefully spelt out overriding semantics – Some sort of versioning attribute – perhaps start-dateTime, end-dateTime – Ability to refer to policy artifacts by QName