Re: NEW ISSUE: (3622) Policy assertion equivalence and generality

On Aug 25, 2006, at 6:07 PM, Bijan Parsia wrote:
 >
 > On Aug 25, 2006, at 5:56 PM, Fabian Ritzmann wrote:
 >
 >  >
 >  > Hi Bijan,
 >  >
 >  > Are you aware of Anne Anderson's work? She's designed a simple 
language that is compatible with WS-Policy and seems to fit your 
requirements:
 >
 >
 > We both presented at a workshop at WWW in Japan, so we know each 
other's work :)
 >
 >  > http://research.sun.com/projects/xacml/
 >  >
 >  > I'd suggest this paper for a quick introduction:
 >  >
 >  > http://research.sun.com/projects/xacml/POLICY06_paper.pdf
 >
 >
 > As I understand it, Anne's work (and XACML) addresses how to define 
the *assertions* in a common, evaluable, language. It's not clear to  me 
that one can (easily) infer equivalence, for example, and one  certainly 
can't do that if the equivalence is "semantic", that is, in  the sense 
of saying that either of two distinct conditions "means"  the same thing.

Yes, XACML specifies a common, evaluable language for assertions as part 
of its overall policy syntax.  Assertions are of the form <AttributeId> 
<function> <AttributeValue>.  WSPL, and its WS-Policy compatible form 
WS-PolicyConstraints, take standard XACML functions and define the 
semantics for intersections of Assertions that use those functions.

1. AttributeIds must match.
2. Data types must match.
3. Following intersections are defined between two assertions over 
AttributeId "A" containing AttributeValues "a" and "b"

                 Intersection:
A=a   A=b       A=a
A=a   A>b       If a>b, A=a, else no match
A=a   A>=b      If a>=b, A=a, else no match
....
A>a   A>b       A=<max(a,b)>
....

The full matrix of intersections is defined for the various standard 
data types (integer, string, dateTime, etc.) for the functions =, >, >=, 
<, <=, time-in-range, set-equals, subset, must-be-present, 
must-not-be-present, any-constraint, and regexp-match (regexp confined 
to easily intersectable forms).  Not all functions apply to all data 
types, of course.

So WS-PolicyConstraints doesn't tell you whether AttributeId A is 
semantically the same as AttributeId B or whether AttributeId A is 
semantically a subclass of AttributeId B, but it lets you poke inside 
the assertions and fully calculate the intersections of WS-Policy 
instances between two parties (using WS-Policy normalization to get the 
sets of policy alternatives that need to be intersected).

In the initial target domains for WS-Policy - agreement on initial 
communication parameters - being able to calculate intersections of 
values seems much more useful than calculating intersections of 
Attribute classes.  For example, knowing that "AES" is a subclass of 
"EncryptionMethod" doesn't help two parties agree on which encryption 
algorithm to use: they both have to support exactly the same algorithm 
value.

This is an incredibly simplied overview; AttributeIds can be simple 
XPath expressions, multiple Assertions can be made over the same XML 
element instances, etc.

Anne

 >
 > So, I think even there, having the ability to equate or relate 
assertions can be quite useful. In the context where the truth of the 
assertion is determined entirely out of band (as in WS-Policy), then  it 
seems even more helpful.
 >
 > The big advantage is being able to reason with policies even if one 
can't poke into an assertion.
 >
 > But perhaps I'm wrong about Anne's work? I'll drop her a note 
pointing to this dicusssion.
 >
 > Cheers,
 > Bijan.

-- 
Anne H. Anderson             Email: Anne.Anderson@Sun.COM
Sun Microsystems Laboratories
1 Network Drive,UBUR02-311     Tel: 781/442-0928
Burlington, MA 01803-0902 USA  Fax: 781/442-1692

Received on Thursday, 31 August 2006 19:00:11 UTC