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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded

Thanks Steven for the well-written document.


I had some minor comments and some issues to discuss:


S2.1P4: "Evaluation of the _expression_ MAY terminate at the first value from the domain for which the iterant _expression_ evaluates to “true”."

I think the meaning of "first" here is ambiguous and might be misleading as according to the spec, bags are unordered. I suggest either editing this to remove the word “first” or adding a sentence to emphasize that the implementation must not assume any particular order for processing of bags, and first means the first entity encountered regardless of the order of processing.


S2.1P4 and S2.2:  I suggest that, since there is no formal definition of these quantifiers, we explicitly clarify the value of ForAny and ForAll for an empty Domain.


There are also two issues for discussion:


-        As someone said before on the list, in case of large data sets, there should be a mechanism to notify the PEP or PAP to include in the request only part of the related entities that are consequential in the PDP’s decision. For example, if the policy is to allow access “if the resource owner has a friend who is over 18”, this will require including all of the resource owner’s friends in the request. Finding some way to communicate what is sufficient to be included in the request is at least worth mentioning as an implementation issue.

-        There should be some sort of discussion about the completeness of the set of operators defined in the profile. Right now, it appears that the supported operators are similar to those of description logic, but can/should we support more operators? For example, operators for “reflexive transitive closure” (e.g. friend-of-friend-of-friend-…), “cardinality” (number of related entities that satisfy a predicate), or inverse relations?



Mohammad Jafari, Ph.D.

Security Architect, Edmond Scientific Company




From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Steven Legg
Sent: Tuesday, October 22, 2013 12:18 AM
To: xacml@lists.oasis-open.org
Subject: [xacml] Groups - XACML v3.0 Related and Nested Entities Profile Version 1.0 uploaded


Submitter's message
This is the initial draft for the Related and Nested Entities Profile - my response to the "Attributes of Relations" email thread. I changed from "Embedded" to "Nested" in the title because it better suggests the idea that entities can be embedded in other entities to any depth. A nested entity is what I have previously called a compound attribute. As well as the ForAny and ForAll expressions that I have discussed on the mailing list I have defined a Select _expression_ as a convenience to policy writers who like to think in SQL terms. The examples go beyond simply addressing the "Attributes of Relations" concerns.
-- Dr. Steven Legg

Document Name: XACML v3.0 Related and Nested Entities Profile Version 1.0

It is not unusual for access control policy to be dependent on attributes
that are not naturally properties of the access subject or resource, but
rather are properties of entities that are related to the access subject or
resource. This profile defines the means to reference such attributes from
within XACML policies for processing by a policy decision point.
Download Latest Revision
Public Download Link

Submitter: Dr. Steven Legg
Group: OASIS eXtensible Access Control Markup Language (XACML) TC
Folder: Specifications and Working Drafts
Date submitted: 2013-10-21 23:17:29


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]