Re: [dipal-discuss] Some concerns about intersection and domainindependence

[Anne Anderson <Anne.Anderson@sun.com>]

Hi Daniel,

Thanks for entering into the conversation.  Your perspective represents
an important segment of the "policy" community that has not been heard
from on this list to date, and I have been hoping we could engage these
topics here.  I am familiar with some of your work, and appreciate
having a more formal academic perspective on some of these policy issues.

One general point is that WS-PolicyConstraints is designed to handle the
same classes of policies that WS-Policy is designed to handle.  It is
merely a more generic way of specifying the Assertions in these policies
that allows the aspects of WS-Policy Assertions related to policy
intersection to be handled by domain-independent policy engines.  The
language also allows much, but not all, instance verification against
policies to be handled using domain-independent engines.  This is a
highly useful class of policies, as evidenced by the use of XACML, which
likewise is a domain-independent policy language that has been applied
to multiple domains and to complex organizational policies.

I think it would be helpful to clarify exactly which classes of policies
WS-Policy is suited for, and which classes will require more
expressivity or more semantic context.  One limitation you touch on
below is that the WS-Policy framework seems suited only for one-step
policy negotiation, where each party is willing to reveal its entire
negotiable policy publicly.  It is not designed for incremental release
of information as increasing levels of trust are established.

Daniel Olmedilla wrote On 02/12/06 18:26,:
> Dear all,
> 
> I have been reading your posts since the beginning of the list. Sorry for the 
> late participation but other constraints kept me away from contributing.
> 
> I have been working on policy research during the last years, but mostly from 
> the academia perspective. Here there are some questions/comments/concerns I 
> hope provide some discussion:
> 
> - If I am not wrong, WS-PolicyConstraints proposes a concept of intersection 
> based on syntactic matching. That's the secret to make it domain independent. 
> However, I see semantics as a key point during web service matching. For 
> example, imagine an e-shop that accepts any credit cardit. The shop is 
> obliged to list all possible "subclasses" of credit card. Probably this is a 
> simple example where the number of assertions do not explode. However, now 
> imagine that the policy expresses the request for a valid employee id issued 
> by a partner company (all partner companies must be listed to do matching) or 
> suppose a user willing to make a transaction if it is "secured". While the 
> service provider lists only some specific protocols, the client should list 
> all possible "secure" protocols in order to be matched. See [1] and [2] for 
> some ideas about a matchmaking process taking into account hierarchies of 
> concepts. I know that then the complexity is shifted from simple set 
> containment (your "is a subset of" operator) to subsumption but my concern is 
> whether simple set containment is feasible due to the potential number of 
> constraints in real policies.

The intersection of vocabulary item *identifiers* is strictly syntactic,
as it is in WS-SecurityPolicy, WS-ReliableMessaging Policy, and other
current Assertion specifications based on the model described in
WS-Policy.  The intersection of *values* for the vocabulary items in
WS-PolicyConstraints, however, is based on the semantics of the
constraint functions over the datatypes associated with the values.
These semantics are well-understood from arithmetic, regular expressions
and FSA intersection, and from standard specifications for syntax and
semantics of particular generic data types such as X.500 names, Domain
Name Service names, and IP addresses.

Regarding more complex semantic ontologies, I have trouble envisioning
actual businesses using the types of semantic information in the
examples above.  In fact, no shop will accept *any* credit card; it will
accept only those credit cards for which it has established a business
agreement with the credit card provider.  And a client and a service
will not actually be able to support all possible "secure" protocols;
each will need to list those protocols that its implementation supports
and for which its deployment allows use.  "Partner companies" will
probably be identified using a signed SAML Attribute Assertion, X.509
Attribute Certificate, or equivalent.  Or, during policy negotiation, a
peer may claim to be a "partner company", and policy negotiation may
take place on this basis, but this claim will be verified using
domain-specific code before an actual transaction is accepted.

I think there is a role for more complex semantic ontologies in web
services policies, but perhaps not for the class of policies that are
the target for WS-Policy (whatever that class is :-).

WS-PolicyConstraints Section 6.1 discusses use of simple semantic class
hierarchies, suggesting that the linkage between a set of constraints
and the semantic hierarchy specification might be made either at the
policy framework layer or at the vocabulary specification layer.  In
either case, the policy implementation would need to be able to access
the specification of the hierarchy in order to do the matching.  I don't
know how useful such linkages would be in actual practice, however.
Semantic information may be most useful in authoring policies, so that a
user could specify high-level requirements, but these would be
translated into low-level policy vocabularies using the organization's
own semantic hierarchy.

> - Delegation. Imagine a policy that says "employees from our administration 
> department or current employees from our partner XYZ are allowed to 
> access" (see [3] for other examples). In this case, since it is unlikely that 
> XYZ is going to replicate its employee database, delegation is needed. 
> Matchmaking is not anymore domain independent, isn't it?. It requires a 
> matchmaking process for the first part and an external request for the 
> second. How would this be addressed?

I think that, in practice, role attributes distributed using signed SAML
Attribute Assertions or X.509 Attribute Certificates would be used for
this type of "delegation"; an organization delegates certain rights to
specific roles.  Users are associated with these roles and issued signed
attribute assertions by organizational processes.  Authentication of
attribute assertions can occur using trust chains rooted at a trust
anchor, as with X.509 certificate chains.

> 
> - Regarding to intersection, as an extra point of view, I would add that it is 
> not necessarily needed to be done in a one-step process. It might be that 
> policies are not public, or there are too many in order to try to match them 
> all. In such a case, there could be an iteration in which after each 
> communication process/iteration of the negotiation new policies may be 
> released and taken into account ([3], [4]). I don't see in your current 
> document anything that would not allow this kind of negotiations but I just 
> point it as a probably different scenario.

I agree that this will be an important scenario in certain types of
business negotiations.  The protocol for such an iteration process must
be handled at the policy framework level, rather than at the policy
constraint/assertion level.  Incorporation of such iterative processes
is probably not going to occur in the first generation of policies, as
evidenced by the current uses of WS-Policy, WS-PolicyAttachement,
WS-SecurityPolicy, and WS-ReliableMessaging Policy.  The WS-Policy
framework will require elaboration to be able to handle multi-stage
protocols for incremental release of policies or attribute information.

> A couple of extra questions/comments on the document WS-PolicyConstraints (24 
> October 2005):
> - Page 6 says "currently most semantic descriptions are captured only in 
> custom code modules". Could you extend a bit on this?

This refers to the current WS-Policy model for developing and
implementing support for "Assertions".  The semantics of the current
Assertions are completely domain-dependent, and can be determined only
by a close reading of the associated written specification.  The
semantics are then captured in custom code modules for each Assertion by
developers.

> - Page 6 also talks about circular dependencies being inconsistent. I just 
> would like to point that it is not necessary inconsistent. It is the case of 
> OWL (based on description logics) but not of other approaches based on Logic 
> Programming (like e.g. [4]). From a declarative point of view, cycles are 
> perfectly right and not errors or inconsistences. Furthermore, even though 
> cycles might be avoided in a centralized approach, it is not possible if 
> distributed. Imagine the following example (extracted from a currently 
> submitted paper):
> "suppose Bob wants to share his pictures with his friends. Bob protects his 
> pictures with a policy that states “only my friends may access my pictures”. 
> However, he does not only have a list of his friends but also include that 
> “all Alice’s and Frank’s friends are also my friends”. Suppose Alice and 
> Frank have a similar policy in which their friends list includes also all 
> other’s friends. Given that setup, imagine that Tom requests access to Bob’s 
> pictures. Bob’s security agent (SA) checks that Tom is not his friend but, 
> since he might be a friend of Alice or Frank, it asks their security agents. 
> Now, Alice’s SA checks locally if Tom is her friend, but some of her policies 
> say that any friend of Bob or Frank is also her friend and therefore, it asks 
> Bob’s and Frank’s SA. In parallel Frank’s SA evaluates its policies and 
> produces a similar situation asking back Bob’s and Alice’s SA, and so on. As 
> the reader can see, if not detected and handled appropriately, the evaluation 
> of this request would never terminate (see figure 1), even if answers exist."

Good point.  I am very interested in seeing how far the set of functions
and policy variable interdependencies can be extended while still
supporting efficient, deterministic, automated policy intersection.  As
you point out, the difficulties in this type of circularity arise in the
actual evaluation of the policies.  I think the evaluation of policy
intersections is likely to be even more complex, introducing constraints
in the types of variable interdependencies that can be supported while
still allowing deterministic policy intersection.

> 
> Hope that my comments do not diverge too much the focus of the mailing list 
> but I would be really interested in bringing some new requirements to 
> discussion and knowing about your opinion on them.
> 
> Best,
> 
> 	D.

Thank you very much for these comments; I am glad to see these
requirements introduced here.  I hope others will also respond to them.

Regards,
Anne

> 
> [1]  Lalana Kagal, Massimo Paoucci, Naveen Srinivasan, Grit Denker, Tim Finin, 
> and Katia Sycara, "Authorization and Privacy for Semantic Web Services", IEEE 
> Intelligent Systems (Special Issue on Semantic Web Services), 2004
> 
> [2]  Grit Denker, Lalana Kagal, Tim Finin, Katia Sycara, and Massimo Paoucci, 
> "Security for DAML Web Services: Annotation and Matchmaking", 2nd 
> International Semantic Web Conference (ISWC2003), September 2003
> 
> [3] Rita Gavriloaie, Wolfgang Nejdl, Daniel Olmedilla, Kent Seamons, Marianne 
> Winslett
> No Registration Needed: How to Use Declarative Policies and Negotiation to 
> Access Sensitive Resources on the Semantic Web
> 1st European Semantic Web Symposium, May. 2004, Heraklion, Greece
> 
> [4] Piero A. Bonatti, Daniel Olmedilla
> Driving and Monitoring Provisional Trust Negotiation with Metapolicies
> IEEE 6th International Workshop on Policies for Distributed Systems and 
> Networks (POLICY 2005), Jun. 2005, Stockholm, Sweden

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