Re: [xacml] Entity... Category... Attributes - JSON profile

Hi David,

    

    Sometimes these details take a while to come into focus.

    

    In this case, since you are looking to change "Attributes" to
    something

    and have picked Category, for consistency w CategoryId, I would like

    to point out what I consider a non-trivial issue w this choice.

    (And since you are planning updates anyway, it will give another

    chance to reconsider :) )

    https://lists.oasis-open.org/archives/xacml/201307/msg00006.html

    

    The issue is that the use of CategoryId in the current spec is a

    semantic referring to how to interpret the collection of attributes.

    i.e. it says what "type" of collection it is, but it does not say

    anything about any specific instance of that collection type.

    

    Therefore, naming the collection "Category" in the top element,

    and then identifying the Category-Type using CategoryId is a bit

    unusual because id-like attributes are generally used to identify

    specific instances of the content as opposed to the type of

    content.

    

    One example that comes to mind is the SAML <Assertion>
    element,

    that has an AssertionId attribute. This attribute is used to
    identify

    the specific instance of the Assertion and is not saying anything

    about the type of assertion. I know this example is dated and

    the community is now using the xml id construct, but the point

    is that id generally refers to the content, whether appl-specific

    or xml general.

    

    Using <Category  CategoryId=xxx ...> I think is missing the
    point

    that it is the content itself that needs to be interpreted using

    the specific Category type identified in the top element.

    

    This does not to me indicate that there is any semantic value

    in calling the top level element, "Category", as category is only

    one possible metadata aspect of the collection. Possibly, we

    would one day add an "IssuerID" to the top level to identify

    the entity that created the collection as opposed to the

    individual attributes. Then we would have to choose whether

    to call the top element either Category or Issuer, neither of

    which makes particular sense to me.

    

    In any event, as indicated yesterday, I don't want to hold up

    the profile by trying to use it to correct a flaw in the core

    spec, but I think the name of the top level element could

    be anything and Category may or may not be the best

    choice given that we are only not constraining it to the

    "Attributes" choice, that unfortunately is in the core spec.

    Therefore, I will defer to your judgement as to what to do,

    but wanted to register my comment on the current state.

    

        Thanks,

        Rich

    

    

    

    
On 7/3/2013 3:53 AM, David Brossard
      wrote:

    

    
      
The last time I was on the call 3 weeks ago, I said
        I was ok with using the word entity.
        

        

        
All things considered, I don't want to do that. While I
          think it's a great idea, I don't want to deviate the JSON
          profile from XACML 3.0. It will make training and explanations
          more complicated.

        

        

        
If I decide to call the <Attributes/> element
          something else, I should call it Category since the first
          child is CategoryId and the notion of a category is well
          established in XACML 3.0

        

          

        

        
If I call it Entity then I'd have to rename CategoryId to
          EntityId or plain Id. I would then have to explain to users of
          the JSON profile what Entity is and why a different name was
          used. That just complicates things.

        

        

        
So I'll stick to the name Category.

        

        

        
Any big massive objection? I have been slow and delayed in
          this work so I now want to finish it off. This is -  I believe
          - the last detail. I've also written sample code which
          complies with the profile to verify the workability of the
          profile. It looks good so far.

        

        

        
Cheers,

        
David.
          

          

          -- 

          David Brossard, M.Eng, SCEA, CSTP

          Product Manager

            Axiomatics AB

            Skeppsbron 40

            S-111 30 Stockholm, Sweden

            http://www.linkedin.com/companies/536082

            http://www.axiomatics.com

            http://twitter.com/axiomatics
        

      

    
    

    
-- 

      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