Question on nested/related entity profile

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