OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  Groups - Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 uploaded

    Posted 07-11-2013 19:36
    Submitter's message Here is my final version. I chose Category instead of Entity. I'd like to set this version in stone now and move forward. -- Mr. David Brossard Document Name : Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 Description With the rise in popularity of APIs and its consumerization, it becomes important for XACML to be easily understood in order to increase the likelihood it will be adopted. In particular, XML is often considered to be too verbose. Developers increasingly prefer a lighter representation using JSON, the _javascript_ object notation.
    This profile aims at defining a JSON format for the XACML request and response. It also defines the transport between client (PEP) and service (PDP). Download Latest Revision Public Download Link Submitter : Mr. David Brossard Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2013-07-11 12:36:20 Revision : 11


  • 2.  RE: [xacml] Groups - Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 uploaded

    Posted 07-11-2013 21:58
    There are a few remaining references to the previous Attributes object which should be updated to the new Category object:   4.1 Class Diagram a. The diagram shows “Attributes” as the title of the center box.  Should that be “Category”? b. The diagram shows property “Category” but the table in 4.2.2 shows property “CategoryId”   4.2.6 RequestReference object                 “Each ReferenceId value must be the value of an Attributes object Id property”                 Attributes s/b Category 5.2.9 contains TODO and editor notes     One of the four ways that the multirequest profile defines how to represent a multirequest in the structure of a request object is to place multiple XML Attributes elements with the same category URN in the request.  I can see that this can be done using the JSON Category as an array of objects, each using the same CategoryId to induce a multirequest evaluation at the PDP.   Can the default category objects be arrays to induce multirequest evaluation also?  For example,   { “Request”: {                                 “Subject”: [                                                 {                                                                 “Attribute”: […]                                                 },                                                 {                                                                 “Attribute”: [..] }                                 ]                 } }   As semantically equivalent to an XML request containing two Attributes elements with the XACML subject category URN.   Apologies if this has already been discussed on the list and I missed it.   Thanks, -Danny   Danny Thorpe Authorization Architect Dell Identity & Access Management, Quest Software   Quest Software is now part of Dell.   From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of David Brossard Sent: Thursday, July 11, 2013 12:36 PM To: xacml@lists.oasis-open.org Subject: [xacml] Groups - Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 uploaded   Submitter's message Here is my final version. I chose Category instead of Entity. I'd like to set this version in stone now and move forward. -- Mr. David Brossard Document Name : Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 Description With the rise in popularity of APIs and its consumerization, it becomes important for XACML to be easily understood in order to increase the likelihood it will be adopted. In particular, XML is often considered to be too verbose. Developers increasingly prefer a lighter representation using JSON, the _javascript_ object notation. This profile aims at defining a JSON format for the XACML request and response. It also defines the transport between client (PEP) and service (PDP). Download Latest Revision Public Download Link Submitter : Mr. David Brossard Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2013-07-11 12:36:20 Revision : 11  


  • 3.  Re: [xacml] Groups - Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 uploaded

    Posted 07-11-2013 23:23
    Thanks Danny for spotting those. I'll check again. Sounds like I forgot to save some edits there... On Thu, Jul 11, 2013 at 2:57 PM, Danny Thorpe < Danny.Thorpe@software.dell.com > wrote: There are a few remaining references to the previous Attributes object which should be updated to the new Category object:   4.1 Class Diagram a. The diagram shows “Attributes” as the title of the center box.  Should that be “Category”? b. The diagram shows property “Category” but the table in 4.2.2 shows property “CategoryId”   4.2.6 RequestReference object                 “Each ReferenceId value must be the value of an Attributes object Id property”                 Attributes s/b Category 5.2.9 contains TODO and editor notes     One of the four ways that the multirequest profile defines how to represent a multirequest in the structure of a request object is to place multiple XML Attributes elements with the same category URN in the request.  I can see that this can be done using the JSON Category as an array of objects, each using the same CategoryId to induce a multirequest evaluation at the PDP.   Can the default category objects be arrays to induce multirequest evaluation also?  For example,   { “Request”: {                                 “Subject”: [                                                 {                                                                 “Attribute”: […]                                                 },                                                 {                                                                 “Attribute”: [..] }                                 ]                 } }   As semantically equivalent to an XML request containing two Attributes elements with the XACML subject category URN.   Apologies if this has already been discussed on the list and I missed it.   Thanks, -Danny   Danny Thorpe Authorization Architect Dell Identity & Access Management, Quest Software   Quest Software is now part of Dell.   From: xacml@lists.oasis-open.org [mailto: xacml@lists.oasis-open.org ] On Behalf Of David Brossard Sent: Thursday, July 11, 2013 12:36 PM To: xacml@lists.oasis-open.org Subject: [xacml] Groups - Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 uploaded   Submitter's message Here is my final version. I chose Category instead of Entity. I'd like to set this version in stone now and move forward. -- Mr. David Brossard Document Name : Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 Description With the rise in popularity of APIs and its consumerization, it becomes important for XACML to be easily understood in order to increase the likelihood it will be adopted. In particular, XML is often considered to be too verbose. Developers increasingly prefer a lighter representation using JSON, the _javascript_ object notation. This profile aims at defining a JSON format for the XACML request and response. It also defines the transport between client (PEP) and service (PDP). Download Latest Revision Public Download Link Submitter : Mr. David Brossard Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2013-07-11 12:36:20 Revision : 11   -- 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


  • 4.  Re: [xacml] Groups - Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 uploaded

    Posted 07-12-2013 18:27
    Hi Danny, Thanks for the sharp eyes. I fixed all the issues you mentioned.  With respect to your MDP idea: { “Request”: {                                 “Subject”: [                                                 {                                                                 “Attribute”: […]                                                 },                                                 {                                                                 “Attribute”: [..] }                                 ]                 } } I don't see why we should not allow it. I'll add a note to that effect. On Thu, Jul 11, 2013 at 4:23 PM, David Brossard < david.brossard@axiomatics.com > wrote: Thanks Danny for spotting those. I'll check again. Sounds like I forgot to save some edits there... On Thu, Jul 11, 2013 at 2:57 PM, Danny Thorpe < Danny.Thorpe@software.dell.com > wrote: There are a few remaining references to the previous Attributes object which should be updated to the new Category object:   4.1 Class Diagram a. The diagram shows “Attributes” as the title of the center box.  Should that be “Category”? b. The diagram shows property “Category” but the table in 4.2.2 shows property “CategoryId”   4.2.6 RequestReference object                 “Each ReferenceId value must be the value of an Attributes object Id property”                 Attributes s/b Category 5.2.9 contains TODO and editor notes     One of the four ways that the multirequest profile defines how to represent a multirequest in the structure of a request object is to place multiple XML Attributes elements with the same category URN in the request.  I can see that this can be done using the JSON Category as an array of objects, each using the same CategoryId to induce a multirequest evaluation at the PDP.   Can the default category objects be arrays to induce multirequest evaluation also?  For example,   { “Request”: {                                 “Subject”: [                                                 {                                                                 “Attribute”: […]                                                 },                                                 {                                                                 “Attribute”: [..] }                                 ]                 } }   As semantically equivalent to an XML request containing two Attributes elements with the XACML subject category URN.   Apologies if this has already been discussed on the list and I missed it.   Thanks, -Danny   Danny Thorpe Authorization Architect Dell Identity & Access Management, Quest Software   Quest Software is now part of Dell.   From: xacml@lists.oasis-open.org [mailto: xacml@lists.oasis-open.org ] On Behalf Of David Brossard Sent: Thursday, July 11, 2013 12:36 PM To: xacml@lists.oasis-open.org Subject: [xacml] Groups - Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 uploaded   Submitter's message Here is my final version. I chose Category instead of Entity. I'd like to set this version in stone now and move forward. -- Mr. David Brossard Document Name : Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 Description With the rise in popularity of APIs and its consumerization, it becomes important for XACML to be easily understood in order to increase the likelihood it will be adopted. In particular, XML is often considered to be too verbose. Developers increasingly prefer a lighter representation using JSON, the _javascript_ object notation. This profile aims at defining a JSON format for the XACML request and response. It also defines the transport between client (PEP) and service (PDP). Download Latest Revision Public Download Link Submitter : Mr. David Brossard Group : OASIS eXtensible Access Control Markup Language (XACML) TC Folder : Specifications and Working Drafts Date submitted : 2013-07-11 12:36:20 Revision : 11   -- 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