Re: [ws-tx] Issue 045 - WS-AT: Meaning of "wsp:Optional"

["Monica J. Martin" <Monica.Martin@Sun.COM>]

>little: Tom, required/optional/will be ignored is fine with me (via WS-P), but I don't think that's how you can read MUST/MAY/SHOULD NOT.
>Mark.
> 
>
mm1: Let's look at the crux of our challenge at this time. Here are what 
we are trying to accomplish:

   1. Support for the transactional semantics we desire
   2. The semantics supported by WS-Policy using wsp:Optional
   3. How that fits with RFC 2119 language

Let's address (2) first as it is the significant guiding factor, 
consistent with (3) and in support of (1). This is also consistent with 
Mark Little's comment today [reference 1].

2. The semantics supported by WS-Policy using wsp:Optional:
WS-Policy uses this compact shortcut for MUST and MUST NOT. With some 
changes we can define that a service interpretation of the policy 
assertion takes precedence when the requestor flows a transaction 
context it should not have flowed (i.e. the case of SHOULD NOT on the 
client/requester and MUST NOT for the target service/server). See 
[reference 2] below for relevant overall references including Section 
3.2 I provided earlier. Here is the potential mapping between policy and 
transactions:

    * wsat:ATAssertion / wsat:ATAssertion wsp:Optional=false - MUST
      (synonymous)
    * wsat:ATAssertion wsp:Optional=true - assertion is either "Present"
      or "Not-Present" (i.e. For the sake of discussion, assume MUST or
      SHOULD NOT/MUST NOT = MAY)
          o Let's concentrate on the potential impact of this usage.
            Granted, a client can normalize and choose one to use
            (reference Section 3.4 of WS-Policy). However, we can't
            assume that this is the only assertion that will be carried
            to the client, particularly when there may be other optional
            assertions such as for security. A detailed set of examples
            is provided here [reference 3] that clearly shows the
            potential processing impacts and the associated complexity.
            In real-world cases we will likely see composition of other
            policy assertions such as with WS-SX and several possible
            policy alternatives (think about encryption with several
            associated algorithms in the security domain).
    * Assertion absent: MUST NOT [reference 4]

To use MAY wsp:Optional as expected in WS-AT Section 5.2: "Presence of 
both policy alternatives indicates that the behavior indicated by the 
assertion is optional, such that an atomic transaction MAY be flowed 
inside a requester’s message," this mapping and the examples are 
particularly relevant.. These examples indicate the costs involved in 
that decision.

Another option was provided in our original proposal. Use of a local 
attribute is a simpler alternative [reference 5] and optimizes the 
examples. Joe and I are now working on those revised examples using a 
local attribute for comparison and will provide to the list for reference.

As a side note, given our decision is to continue to compose with 
WS-Policy, we should consider having policy experts involved to help 
resolve our questions (politely requested).

Thanks.

==========
[reference 1] <ml>Hold on, let's step back a second. I'd rather we agree 
*what* information we want to convey first, before jumping into *how* 
that information can be conveyed....</ml>
[reference 2] Reference: http://www.w3.org/Submission/WS-Policy/, see 
some of the sections important to this discussion:
p. 6, 3.1 Policy Assertion
"A policy assertion identifies a behavior that is a requirement (or 
capability) of a policy subject."

p. 6, 3.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."...

"An assertion whose type is part of the policy's vocabulary but is not 
included in an alternative is explicitly prohibited by the alternative."

p. 7, 3.4 Web services
"A requester may choose any alternative since each is a valid 
configuration for interaction with a 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."

p. 10, 4.3.1 Optional Policy Assertions
"To indicate that a policy assertion is optional, this specification 
defines an attribute that is a syntactic shortcut for expressing policy 
alternatives with and without the assertion." [schema for Optional follows]
"/Assertion/@wsp:Optional
If true, the expression of the assertion is semantically equivalent to 
the following:
<wsp:ExactlyOne>
<wsp:All><Assertion ...> ... </Assertion> </wsp:All>
<wsp:All />
</wsp:ExactlyOne>

If false, the expression of the assertion is semantically equivalent to 
the following:
<wsp:ExactlyOne>
<wsp:All><Assertion ...> ...</Assertion></wsp:All>

[reference 3] Four examples attached:

   1. Original policy from WS-Policy
   2. Normalized policy from WS-Policy
   3. Policy with additional optional ATAssertion
   4. Normalized policy with optional ATAssertion

[reference 4] Comments to the list by Freund and Robinson:

freund: As I understand it, the options currently supported are: required/optional/will be ignored/
maps to the policy assertions as follows: MUST/MAY/SHOULD_NOT/ -> wsat:ATAssertion/wsat:AT Assertion
optional=true/no-policy as Ian mentions an error (rejects) is indicated by returning a must_Understand fault.
...
robinson: ...For a service that does not understand transaction contexts then any
transaction context will cause a MustUnderstand fault....

[reference 5]
Issue 45 - http://www.oasis-open.org/apps/org/workgroup/ws-tx/email/archives/200603/msg00168.html

<wsp:Policy xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";
    xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"; >
 <wsp:ExactlyOne>
  wsp:All>
  wsp:RequireDerivedKeys />
  wsp:WssUsernameToken10 />
  /wsp:All>
  wsp:All>
  wsp:RequireDerivedKeys />
  wsp:WssUsernameToken11 />
  /wsp:All>
  wsp:All>
  wsp:WssUsernameToken10 />
  /wsp:All>
  wsp:All>
   wsp:WssUsernameToken11 />
  /wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<wsp:Policy xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"; xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"; >
<wsat:ATAssertion wsp:Optional="true" />
 <sp:RequireDerivedKeys wsp:Optional="true" />
 <wsp:ExactlyOne>
  wsp:WssUsernameToken10 />
  wsp:WssUsernameToken11 />
</wsp:ExactlyOne>
</wsp:Policy>
<wsp:Policy xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy";
    xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"; >
 <wsp:ExactlyOne>
  wsp:All>
   wsat:ATAssertion />
   wsp:RequireDerivedKeys />
   wsp:WssUsernameToken10 />
  /wsp:All>
  wsp:All>
   wsat:ATAssertion />
   wsp:RequireDerivedKeys />
   wsp:WssUsernameToken11 />
  /wsp:All>
  wsp:All>
   wsat:ATAssertion />
   wsp:WssUsernameToken10 />
  /wsp:All>
  wsp:All>
   wsat:ATAssertion />
   wsp:WssUsernameToken11 />
  /wsp:All>
  wsp:All>
   wsp:RequireDerivedKeys />
   wsp:WssUsernameToken10 />
  /wsp:All>
  wsp:All>
   wsp:RequireDerivedKeys />
   wsp:WssUsernameToken11 />
  /wsp:All>
  wsp:All>
   wsp:WssUsernameToken10 />
  /wsp:All>
  wsp:All>
   wsp:WssUsernameToken11 />
  /wsp:All>
</wsp:ExactlyOne>
</wsp:Policy>
<wsp:Policy xmlns:sp="http://schemas.xmlsoap.org/ws/2005/07/securitypolicy"; xmlns:wsp="http://schemas.xmlsoap.org/ws/2004/09/policy"; >
 <sp:RequireDerivedKeys wsp:Optional="true" />
 <wsp:ExactlyOne>
  wsp:WssUsernameToken10 />
  wsp:WssUsernameToken11 />
</wsp:ExactlyOne>
</wsp:Policy>