Question on nested/related entity profile

[rich levinson <rich.levinson@oracle.com>]

Hi Steven,

I have finally been able to allocate a little time to review your
"Related and Nested Entities Profile" proposal, and it looks to
me like a really well designed piece of work, with a rich set
of capabilities, that open up some really interesting possibilities
for policy design, such as the examples given in section 5.

Actually, my interest was triggered by the emails that suggested
relating it to the hierarchical profile, and I think I can see the
motivation behind that was possibly the nested entities could
presumably be used to construct a resource hierarchy that
could be used as input to a request, possibly enabling the
pdp to produce a "combined decision" by iterating thru
entities in the resource hierarchy and applying expressions
to each resource, while using ForAny or ForAll as a means
of producing the combined decision.

But that's not what my question is about at this moment.

My question is about the comparison between the use
of nested and related entities in section 3.1, Fig 1, and
section 5.2, Fig 6.

As I was reading the spec, I was wondering if nested and
related entities were effectively equivalent, and whether
in some sense it was simply a choice of which technique
to use.

So, looking at these 2 figures, I noticed that in Fig 1, there
is 2 levels of nesting (just my luck that neither of these figs
have line numbering ':)' ):

• Attribute/AttributeValue is data-type:entity level 1
• Attribute/AttributeValue/Attribute@AttributeId="...organization"/AttributeValue
   is data-type:entity level 2

So, in Fig 1, the organization entity, Acme Inc., is a "nested entity",
nested 2 levels down in an Attribute/@AttributeId="...relationship",
which could appear in a "stand-alone entity" such as category:access-subject.

And, in fact, in fig 6. this is exactly what is done.

However, fig 6 has an interesting difference from fig 1, which is
that in fig 6, the organization entity, Acme Inc., is now a "related entity",
which was facilitated by having the organization Attribute contain
an Attribute with data-type:...anyURI instead of data-type:entity, as
was done in fig 1.

So, my question is, for example, could we now equally as well in fig 6,
push the two attribute:relationship nested entities out as related
entities using the same technique, by changing the data-type from
entity to anyURI and providing a dummy URI?

Would this have any impact on the Policy?

One other question, along similar lines:

By contrast, could we similarly collapse the Request element
into a single set of nested entities, where the Request element
could be replaced by a single Attribute element, which would
contain an AttributeValue of data-type: entity, where the entity
would contain one Attribute each for Subject, Resource, Action, etc.,
each of which would contain their own AttributeValue of
data-type:entity that would contain the collection of Attributes,
for each of the current top level Attributes collections.

At this point I am not suggesting we do anything, but I am simply
trying to understand the capabilities that appear to me to be
inherent in the spec in its current form.

    Thanks,
    Rich

--
Thanks, Rich

Rich Levinson | Internet Standards Security Architect
Mobile: +1 978 5055017
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803
Oracle is committed to developing practices and products that help protect the environment