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

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

Hi John,

On 23/10/2013 10:44 AM, Tolbert, John W wrote:
> Hello Steven,
>
> Thanks for assembling the draft profile.  You have put a great deal of work into this.

Thanks for reading it and providing feedback.

> Given that “domain” has fairly standard meaning in IT, would it be possible to use the term “scope” instead?  I think it would work in this context, and prevent unnecessary confusion.  “Realm” also might be a less-used and less confusing term, but I think “scope” fits best.

Domain of discourse is what it's called in the terminology of existential and
universal quantification, which I shortened to "domain". Would "domain of discourse"
or "quantifier domain" work for you ?

> In the examples in section 5.2, I see “relationship-kind”, which seems to be quite a bit like urn:oasis:names:tc:xacml:3.0:ipc:subject:subject-to-organization-relationship.

Firstly, I'd like to make sure you are clear that the profile doesn't standardize
any attributes. The attributes in the examples are in the urn:example namespace
and it would be completely bogus to use these attributes in a real XACML
deployment. If you didn't pick up on that then I need to say something about it
the terminology section.

The reasons why I didn't use subject-to-organization-relationship are that it's
a flattened attribute in the context of the IPC profile, and it's defined to be
a subject attribute but I would be using it in a relationship entity (admittedly
that's a nested entity in a subject entity, but the example could just as well
have used related entities). If I had used it, it would not be in a way that is
conformant with the IPC profile, so it would have seemed more a case of "abuse"
than "use". From the aesthetic standpoint, the attribute URI is quite long and
its values are URIs so it would have added clutter and ugly line-wrapping to the
examples.

> There is also “start-date”, which is similar to urn:oasis:names:tc:xacml:3.0:ipc:resource:effective-date

The reasons for not using effective-date are similar:
- EC-US also defines an effective-date attribute. Which one would I favour ?
- Both effective-date attributes are defined as resource attributes and I am not
  using start-date anywhere near a resource entity.
- Both effective-date attributes are flattened (from entities that aren't anything
  to do with the relationship between a subject and an organization).

> For the sake of consistency, could we use the IPC style attributes, even in the examples, so  we can keep those aligned?

I could make the URIs the same, but they would still be semantically different
attributes. I would have thought that would be counter-productive to both profiles.

> The examples in 5.3.1 regarding an “approved-export” table actually hint at the existence of behind-the-scenes attribute flattening, since in order to build such a table, the list has to be compiled from interpretation of regulations, exceptions, and individual licenses.  Is the intent to demonstrate a capability to import complex tables associated with regulations (such as the US Commerce Control List), and make the table content available to policy authors?

The main motivation was to demonstrate a way to do the dynamic template reduction
that Jean-Paul was talking about. Export control was his use case. In general, I
expect a table to be a sufficiently faithful representation of any external input.
Entities can be nested to any depth and have any cardinality so there is no
impediment to representing complex real-world structures. The example is obviously
a simplification of reality, but if it gives the impression that flattening is
going on then I need to work on the prose.

Regards,
Steven

> Thanks again for the contribution,
>
> John
>
> *From:*xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] *On Behalf Of *Steven Legg
> *Sent:* Monday, October 21, 2013 11:18 PM
> *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