OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[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


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 <steven.legg@viewds.com> 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 <steven.legg@viewds.com <mailto:steven.legg@viewds.com>> 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

Oracle
Rich Levinson | Internet Standards Security Architect
Mobile: +1 978 5055017
Oracle Identity Management
45 Network Drive | Burlington, Massachusetts 01803

Green
            Oracle Oracle is committed to developing practices and products that help protect the environment



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]