[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ws-tx] Issue 045 - WS-AT: Meaning of "wsp:Optional"
>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>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]