OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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

Hi Steven,

Ok, I guess "primitive" does not mean what I thought, so we can let it be like that. Or you could perhaps change it to "non-bag values"?

Best regards,

On 2013-11-21 08:36, Steven Legg wrote:

Hi Erik,

On 21/11/2013 1:47 AM, Erik Rissanen wrote:
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?

Not really.

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.

The normative bits are about URI references to related entities. I'll see what I can do about separating that out, perhaps into a new section before Section 3.

- 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 define the entity data-type to be "primitive" in Section 3, basically to be
aligned with the core specification that talks about primitive values and
bags of primitive values. If the entity data-type isn't "primitive", then parts of the core specification would need to be redefined to accommodate the concept of a bag of entities. If we choose to clean up the terminology in the core with
errata, then I'm happy to align with any revised terminology.

By the way, I don't consider x500Name to be all that "primitive" either, but it
is described as such in the core.

As far as Section 2 is concerned, the domain (to be renamed "range") is a bag of values. Those values can be of any data-type. I could simply say "a bag of values of any data-type", but the issue of alignment with the core would still remain.

- 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.

I intend to do that, once I work out the naming conventions and packaging requirements. I stuck the full schema in an appendix as a temporary measure. Appendix B will go away.

- 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. ;-)

XML Schema seems to allow it by the include mechanism, but whether all commonly used XML tools can handle it is another matter. I would be interested in any feedback from
implementors as to whether or not it proves troublesome.


Best regards,

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 <https://www.oasis-open.org/apps/org/workgroup/xacml/document.php?document_id=51130> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]