Hi Steven,
Thanks for the work on this. It looks to me to solve the issues it
is designed to solve.
Here are a few small comments:
- Did you intend the whole introduction section to be normative? I
guess it's ok as it is, but one could perhaps split of some of the
exposition into a non-normative section so that this material does
not clutter the normative content with potential ambiguities or
mistakes.
- I think it should say that the schema fragments in the document
are non-normative. Word can easily auto-suggest and break technical
content in the document and we don't want to specify the same thing
twice (once in the fragment and once in the full schema)
- In section 2, in the first paragraph after the
QuantifiedExpressionType schema fragment, it says that the domain
evaluates to a bag of a "primitive data-type". Shouldn't this be
"atomic data-type"? I read primitive data type to mean a non-entity
data type, but what I believe you mean is that the value must not be
a bag.
- I think the schema file should be split out from the word
document. Word can easily auto-suggest and break technical content
and it is more convenient for implementers and others to have an
official schema file to use directly.
- Are there any concerns to worry about when we define additional
content into the existing XACML 3.0 namespace and schema? I am not
well enough knowledgeable in XML schema best practices, so I am just
asking. ;-)
Best regards,
Erik
On 2013-10-22 08:17, Steven Legg wrote:
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
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
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
