[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [xacml] Re: Problem with the Example Response in the JSON Profile
I agree w you that the naming is incredibly confusing, however, I do not
think that elevating "Category" does much to solve anything.
I have been trying to promote the idea in previous emails that the XACML 3.0
spec should be updated and that the "Attributes" element be renamed to
something more appropriate, such as "Entity".
I believe that the Attributes collections in the XACML Request are consistent
w the notion of "Business Entity" or "Business Object", and that, in general,
the Business Objects in the application and platform spaces can generally
be decomposed into Attributes. In fact, this is generally already done in
the Object to Relational mapping that is often done to relate business
objects to rows in relational databases.
Therefore, conceptually, what I am proposing is that we look at the analogous
relation between business objects in the application and platform arenas and
rather than mapping them to rows in relational databases, that we map them
into some kind of attributes for serialization over the network. Such activities
are already done w technologies, such as Java RMI.
However, Java RMI, is a platform-specific representation, and what I think
is needed is an abstract representation. Also, I am not looking to solve the
general business object to serial representation, but only looking to solve
the problem as far as necessary to address the XACML authorization space,
which, in fact, when one analyzes this space, is a very large and encompassing
space that can reach almost anywhere to find an Attribute that might be
useful in a Policy.
Returning to the original point, if we view the XACML Request Attributes collections
as collections representing some "real world entity", then the use of the term
"entity" is quite natural to replace "Attributes" and also provides a conceptual
bridge to associate the entity in the request to one or more business objects
in the application and platform spaces.
While I have not kept up w all the details of the JSON spec, I view it as simply
an alternative representation of the same info that is in the XACML XML
representation of an authorization Request, and by the same reasoning,
I also view the XML as just one possible representation of the abstract
notion of a collection of collections of attributes, where the middle
layer of this abstraction corresponds to naturally to the level of
business and platform object.
The "Category" in this sense says what "kind" of "entity" is being represented
where the "entity" is now the real world object from the perspective
of the Policy authors.
On 5/16/2013 5:19 AM, David Brossard wrote: