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

[Steven Legg <steven.legg@viewds.com>]

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