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

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

Hi Hal,

Thanks for the feedback and detailed proposals.

Comments below.

On 10/12/2013 4:32 AM, Hal Lockhart wrote:
> Steven,
>
> Let me first congratulate you on an excellent piece of work. I consider this to be one of only two or three significant extensions of the XACML processing model since its inception. (The others being the delegation profile and perhaps the schema generalization on which it depends and builds.) Like the others, it provides valuable new functionality in a way that is consistent with both the mechanisms and style of the original. I am particularly pleased that this profile will tend to make policy intent clearer than other alternatives considered and I believe will preserve the properties of the language which enable semantic analysis.
>
> You have not only solved the recently discussed problem of representing entities which do not fall cleanly into the traditional Subject, Resource, Action & Environment Categories, and showed how the solution can meet the requirements for which Policy Templates were proposed by TSCP in 2012, but your solution will also enable better handling of various longstanding issues with the policy model. For example, the case of multiple Intermediary Subjects can be handled by making each Intermediary’s Attributes a Nested Entity under the Intermediary Subject.
>
> I think the main opportunity for improvement is to make the Profile a little more accessible to those who may be new to the problem space. Refactoring the Introduction will help. Adding a couple of diagrams may also help. I also found that after trying to grasp the details, I lost the forest for the trees. I suggest a brief, high level summary which shows how the new functions and expressions relate to the entities.
>
> I have attached some ideas for diagrams, please treat them as no more than a suggestion. It might also be good to have a diagram which suggests how the nested and related abstractions relate to the physical layout of the request context.

Turning the diagrams on their side (with the attribute names running down
the left side) will make them relate more directly to the layout in the
request context. Presenting the same information in both a diagram and XML,
with boxes around the entities and highlighted attribute names and values,
should make the correspondence clear.

> Here is some draft language which might appear at the beginning or the end of the introduction. Again please take it as only a suggestion.
>
> In summary, this profile defines a way of representing Nested and Related Entities in the Request Context and alternatives to existing XACML 3.0 mechanisms to access and traverse these Entities. Nested Entities are represented by a new datatype (…:data-type:entity) which carries all the attributes of the entity as its value. The Nested Entity appears in the Request Context as a sub-element of the containing Entity. Related Entities are represented by means of an Attribute of type URI which acts as a pointer to the Related Entity. The Related Entity appears elsewhere in the Request Context as a Peer Entity with a Category of the corresponding URI value. In both cases, the policy author does not need any knowledge of the Entity’s Category in order to reference it.
>
> The Profile also defines Designator and Selector functions which do the same thing as the corresponding elements in XACML 3.0, but understand Nested and Related Entities. The Profile also defines Quantified expressions which perform the same role as the higher-order bag functions of XACML 3.0, of manipulating bags of values without the need for an explicit looping construct. However by declaring an explicit Quantified variable, the Quantified expressions may be nested without ambiguity.

Also taking into account Erik's comments about the introduction, I see two possibilities.
I could add something like the suggested text to the end of the introduction after pulling
out the normative bits into an immediately following section, or I could rework the text
into a sort of executive summary of the profile as the new introduction followed by some
background discussion (essentially, the current introduction minus the normative bits) and
then the normative bits. I'm leaning towards the latter.

> With regard to the comments made by others:
>
> I think Domain is the right word and I don’t think anyone will confuse it with Security Domain or Policy Domain. If you think of a bag as a function, with the independent variable being the member of the bag and the value of the function being the value of the corresponding member, then in standard mathematical terminology the set of all values of the independent variable is the Range and the collection of all values of the function is the Domain. I think calling the Domain the Range would be particularly unfortunate. Calling it the quantifier Domain is acceptable, but seems unnecessarily verbose.

I think that means "domain" is slightly ahead of "range" as the preferred term.

> I think keeping to details of the examples distinct from any other Profile is a good idea.
>
> With respect to including the Schema or fragments of it, I note the following. XACML has traditionally inserted schema fragments into the text at the point where the elements are discussed and provided the entire schema as a separate file.

I'm going to do that.

> Other TCs provide only the separate file or provide the schema as an appendix. I am happy with any of these. In particular, it is not clear to me how helpful the schema fragments are to readers. Finally note that OASIS TC process requires:
> Computer Language Definitions. All normative computer language definitions that are part of the Work Product, such as XML instances, schemas and Java(TM) code, including fragments of such, must be well formed and valid.
>
> I agree we should stick with “primitive” datatype to indicate scalar types. Non-primitive types include not only multi-value attributes (represented as bags) but also attributes represented as complex types in XML. The term comes from *XML Schema Part 2: Datatypes***Section 2.5.2, although I admit that in cases like X.500Name and URI we have stretched it a bit.**

I was thinking of changing to "bags of values" instead of "bags of a primitive data-type"
to avoid the anachronism where possible.

Thanks,
Steven

> Hal
>
> *From:*Steven Legg [mailto:steven.legg@viewds.com]
> *Sent:* Tuesday, October 22, 2013 2: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