OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ws-sx message

[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]