[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
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. 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. 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 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. 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. Hal From: Steven Legg [mailto:steven.legg@viewds.com] Submitter's message
|
Attachment:
Entities Diagrams.pptx
Description: application/vnd.openxmlformats-officedocument.presentationml.presentation
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]