[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 70: Clarify relationship between extensibility model and policy intersection
Recorded as issue 70. Marc Goodner Technical Diplomat Microsoft Corporation Tel: (425) 703-1903 Blog: http://spaces.msn.com/mrgoodner/ -----Original Message----- From: Prateek Mishra [mailto:prateek.mishra@oracle.com] Sent: Tuesday, May 16, 2006 6:50 AM To: ws-sx@lists.oasis-open.org Cc: Marc Goodner; ashok Malhotra; ramana Turlapati Subject: [ws-sx] NEW ISSUE: Clarify relationship between extensibility model and policy intersection *PLEASE DO NOT REPLY TO THIS EMAIL OR START A DISCUSSISON THREAD UNTIL THE ISSUE IS ASSIGNED A NUMBER. * *The issues coordinators will notify the list when that has occurred.* * * Protocol: ws-sp docs.oasis-open.org/ws-sx/200512/ws-securitypolicy Artifact: policy Type: design Title: Clarify relationship between extensibility model and policy intersection Description: Section 11 of the WS-SecurityPolicy draft provides clear guidance on extending existing policy assertions or defining new ones. However, the policy assertion matching rules (Section 3.1.3) raise some questions about the use of assertions with extensions, specifically lines 364-365: [quote] An assertion with an empty nested policy does not intersect with the same assertion without nested policy. [quote] If a server offered a service with policy expression: <sp:SupportingToken> <wsp:Policy> <sp:UserNameToken/> </wsp:Policy> <sp:SupportingToken> <> and the client policy includes nested policy assertion <orcl: IncludesPassword> as in: <sp:SupportingToken> <wsp:Policy> <sp:UserNameToken> <wsp:Policy><orcl:IncludesPassword></wsp:Password> </wsp:Policy> <sp:SupportingToken> Then should not the two policy expressions match? As things stand, the two expressions will not match even though the client is fully able to satisfy the server's expectations. Related issues: Proposed Resolution: It seems to me there are two outcomes here: (1) Retain current model but add text to Section 11 explaining the relationship between extensibility amd matching. Personally I find this troubling, as it suggests that we will often have false negatives during policy matching. (2) Extend the current model to accommodate a more refined notion of policy matching. I can make a proposal but it may be better to first get a sense of the TCs position on this issue.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]