Hi David,
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.
Thanks,
Rich
On 5/16/2013 5:19 AM, David Brossard
wrote:
I'm removing the Response / Result nesting. It's
unnecessary.
Also, as you suggest, we can do away w/ Request and
Response and make them the root "unnamed" element in JSON -
this makes it lighter.
Any objection from anyone?
On Tue, May 14, 2013 at 2:40 AM, Steven
Legg <>
wrote:
Hi David,
On 11/05/2013 8:32 AM, David Brossard wrote:
So the right example would be:
{
"Response": {
“Result” : [{
"Decision": "Permit"
"Status":{
"StatusCode":{
"Value" : "http://foo.bar"
}
}
}]
}
}
I am thinking that there is one depth level too many. We
could simply rewrite:
{
"Response": [{
"Decision": "Permit"
"Status":{
"StatusCode":{
"Value" : "http://foo.bar"
}
}
}]
}
whereby the response is an array of Result objects. I
believe this works. What do you think?
It would work. The <Response> element in the XML
doesn't add anything to
the result array. The only reason for keeping the extra
level is for
consistency with the XML Schema.
You have a choice between the name "Response" or "Result"
for the array.
It depends on which element you think you are suppressing.
I'm inclined to
use "Result" for the array name since we have an unbounded
list of them,
but there is only supposed to be one "Response".
If you do away with "Response", then you could equally well
do away with
"Request" on the request side and have the members of the
"Request" object
be members of the outermost JSON object.
Regards,
Steven
On Mon, Mar 4, 2013 at 1:04 AM, Steven Legg <
<mailto:>>
wrote:
Hi David,
The example Response object in section 5.2.4.1
should contain a Result
object that contains the Decision and Status. The
Result object is
missing.
Regards,
Steven
--
David Brossard, M.Eng, SCEA, CSTP
Product Manager
+46(0)760 25 85
75
Axiomatics AB
Skeppsbron 40
S-111 30 Stockholm, Sweden
http://www.linkedin.com/companies/536082
http://www.axiomatics.com
http://twitter.com/axiomatics
--
David Brossard, M.Eng, SCEA, CSTP
Product Manager
+46(0)760 25 85 75
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
