Hi Mohammad, On 30/10/2013 3:59 PM, Mohammad Jafari wrote: 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. Terminating at the "first" value is actually more specific than necessary, so I think I'll change this to: Evaluation of the expression MAY terminate when the iterant expression evaluates to "true". Likewise for the other quantified expressions. 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. I think the empty domain case is adequately covered by the final "otherwise" in the specification of the evaluation of the expressions, but I'll add an explicit statement anyway. Something like this for ForAny: Note that the ForAny expression evaluates to "false" if the domain is an empty bag. Likewise for the other quantified expressions. 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. I assume you meant PIP rather than PAP. I expect the context handler and the PIP(s) to do most of the work of fetching entities in a typical deployment. It is more efficient to deal with it once on the context handler side than to impose extra duties on every one of the PEPs. The SAML profile describes an AttributeQuery, which is the basic functionality that a PIP needs to provide, but it seems like no one supports it and the boundary between context handler and PIP is rather fuzzy in practice. What that means is that implementations are free to make their PIP handlers smarter in whatever way they see fit. Standardizing an efficient, entity-aware exchange between context handler and PIP seems a bit pointless if everyone is ignoring the standard we already have. When it comes to communicating to a PEP about missing attributes, the MissingAttributeDetail element is adequate for reporting a missing attribute in a related entity, but can't describe a missing attribute in a nested entity. Adding an otherwise unnecessary URI identifier to nested entities, or creating an extended missing attribute detail element, would fix that deficiency, but I haven't given the issue much attention because I don't expect the average PEP to have the ability to conjure up the attributes of an arbitrary entity in response to a missing attribute error. Rather I expect that a comprehensive application profile would describe the different kinds of entities, the entity attributes (including link attributes), which entities are nested and which attributes and entities the PEP is expected to provide (with a distinct bias towards as little as possible). If a PEP sends everything it is expected to, then a missing attribute error is not something it needs to followup on. A PEP strategy of leaving out some expected information on the assumption that it can satisfy missing attribute errors in a followup is likely to be counter-productive. Describing a sufficient set of attribute values would not be trivial either, especially trying to do it in one go. For instance, the missing attribute detail could indicate that "only friends over 18" are required, but what if another policy wants to count the total number of friends ? And the PEPs would have to be as accomplished at evaluating expressions as the PDP. -There should be some sort of discussion about the completeness of the set of operators defined in the profile. Completeness with respect to what criteria ? 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-…), I specifically excluded doing anything about transitive closure because I figure getting acceptance of the profile is hard enough without adding transitive closure into the mix. If I were to do something about transitive closure it would need a better motivating example than the transitive closure of the "friends-of" relation, which would likely include everybody except new users who hadn't yet built a network of friends. From the perspective of authorization that isn't a particularly interesting result. > “cardinality” (number of related entities that satisfy a predicate), Applying the type-bag-size function to the result of a Select expression gives a number that can be compared. Did you have anything more exotic in mind ? or inverse relations? There's nothing stopping an application profile from defining reciprocating links between entities, though following links leading away from the access subject and resource entities will generally lead to simpler, more efficient expressions, which is why all the examples are structured that way. I would not want to make reverse links mandatory, or define the means to use any forward link as a backward link, because it means adding extra support in PIP handlers or PEPs for attributes that would rarely, if ever, be used in policies. Regards, Steven Regards, 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 <
https://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=51130 > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- *Description* 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 <
https://www.oasis-open.org/apps/org/workgroup/xacml/download.php/51130/latest/xacml-3.0-related-entities-v1.0-wd01.doc > Public Download Link <
https://www.oasis-open.org/committees/document.php?document_id=51130&wg_abbrev=xacml > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- -- *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