OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  Thursday Meeting

    Posted 02-05-2013 10:50
    All, I made a single change to the REST profile (added section on media types and content negotiation). I've seen no discussion on the list, and this change was based on a comment posted a while ago that attracted no discussion either, so I assume that everybody agrees with the change. I therefore propose the TC vote the REST profile back up to CSD and public review at the next meeting. Unfortunately, I won't be able to attend this call due to travel, so I won't be able to move any motions myself. I'm hoping that someone else will do the honors. Thanks, Ray


  • 2.  Re: [xacml] Thursday Meeting

    Posted 02-05-2013 11:35
    Dear all, I'd like to piggy-back ride on Ray's email. I've also implemented changes on the JSON profile based on old feedback from Steven (back in December) and on feedback from the interop list (typos). I also fixed the IANA registration section. I also therefore propose the TC vote the JSON profile back up to CSD and public review at the upcoming meeting. Cheers, David. On Tue, Feb 5, 2013 at 11:49 AM, Sinnema, Remon < remon.sinnema@emc.com > wrote: All, I made a single change to the REST profile (added section on media types and content negotiation). I've seen no discussion on the list, and this change was based on a comment posted a while ago that attracted no discussion either, so I assume that everybody agrees with the change. I therefore propose the TC vote the REST profile back up to CSD and public review at the next meeting. Unfortunately, I won't be able to attend this call due to travel, so I won't be able to move any motions myself. I'm hoping that someone else will do the honors. Thanks, Ray --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- 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


  • 3.  JSON Profile Issues (was Re: [xacml] Thursday Meeting)

    Posted 02-06-2013 05:39
    Hi David, I've uncovered further issues during implementation. The examples show instances where what is described as an array in the text is shown instead as a single value (noting that an object is a JSON value). I think it would be useful to make a statement somewhere early in the profile that an array with a single JSON value MAY, or MUST if that is your intent, be encoded directly as that value rather than as an array of one value (although the profile would be easier to implement if an array is always an array, even if it has only one value). Section 5.2.5: I found the wording "It is simply an array of ..." misleading, suggesting something like this: Obligations:[{ Id:"urn:oasis:names:tc:xacml:3.0:ipc:obligation:encrypt" }, { Id:"urn:oasis:names:tc:xacml:3.0:ipc:obligation:marking", AttributeAssignment:{ AttributeId:"urn:oasis:names:tc:xacml:3.0:example:attribute:text", DataType:" http://www.w3.org/2001/XMLSchema#string" ; } }] rather than this: Obligations:{ ObligationsOrAdvice:[{ Id:"urn:oasis:names:tc:xacml:3.0:ipc:obligation:encrypt" }, { Id:"urn:oasis:names:tc:xacml:3.0:ipc:obligation:marking", AttributeAssignment:{ AttributeId:"urn:oasis:names:tc:xacml:3.0:example:attribute:text", DataType:" http://www.w3.org/2001/XMLSchema#string" ; } }] } Assuming the latter is correct, then it would be better to say "It simply contains an array of ...". An example in the profile would help in this case. The same goes for the AssociatedAdvice object in section 5.2.6. Section 5.2.6 refers to an array of Advice objects, but it should be an array of ObligationOrAdvice objects. Section 5.2.8: AttributeAssignmentType inherits the DataType XML attribute from the AttributeValueType where it is mandatory, so the DataType property should be mandatory for the AttributeAssignment object. Section 5.2.2 refers to a PolicyIdentifierList object that isn't described, while section 5.2.10 describes a PolicyIdentifier object. I have assumed that section 5.2.10 is actually describing the PolicyIdentifierList object. Section 5.2.11: Version should be a string. The IdReference object needs a Value property to hold the URI of the referenced policy or policy set. An IdReference in an XACML response must have a Version and must not have a LatestVersion or EarliestVersion. For consistency with any future profile that defines a JSON representation for policies and policy sets, I suggest that you keep the properties as they are, but add a note that Version is required and EarliestVersion and LatestVersion must be absent in a response. A more extensive example of a Response would be helpful, including Obligations, AssociatedAdvice, Attributes and PolicyIdentifierList. Regards, Steven On 5/02/2013 10:34 PM, David Brossard wrote: Dear all, I'd like to piggy-back ride on Ray's email. I've also implemented changes on the JSON profile based on old feedback from Steven (back in December) and on feedback from the interop list (typos). I also fixed the IANA registration section. I also therefore propose the TC vote the JSON profile back up to CSD and public review at the upcoming meeting. Cheers, David. On Tue, Feb 5, 2013 at 11:49 AM, Sinnema, Remon <remon.sinnema@emc.com < mailto:remon.sinnema@emc.com >> wrote: All, I made a single change to the REST profile (added section on media types and content negotiation). I've seen no discussion on the list, and this change was based on a comment posted a while ago that attracted no discussion either, so I assume that everybody agrees with the change. I therefore propose the TC vote the REST profile back up to CSD and public review at the next meeting. Unfortunately, I won't be able to attend this call due to travel, so I won't be able to move any motions myself. I'm hoping that someone else will do the honors. Thanks, Ray --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail. Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- 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: JSON Profile Issues (was Re: [xacml] Thursday Meeting)

    Posted 02-06-2013 06:32
    Hi David, On 6/02/2013 4:38 PM, Steven Legg wrote: Section 5.2.8: AttributeAssignmentType inherits the DataType XML attribute from the AttributeValueType where it is mandatory, so the DataType property should be mandatory for the AttributeAssignment object. Please disregard this point. Data-type inference applies here too of course. Regards, Steven


  • 5.  The Policy Machine: A mechanism for the specification and enforcement of arbitrary attribute-based access control policies

    Posted 02-06-2013 20:26


  • 6.  Re: JSON Profile Issues (was Re: [xacml] Thursday Meeting)

    Posted 05-10-2013 23:21
    Regarding the following The examples show instances where what is described as an array in the text is shown instead as a single value (noting that an object is a JSON value). I think it would be useful to make a statement somewhere early in the profile that an array with a single JSON value MAY, or MUST if that is your intent, be encoded directly as that value rather than as an array of one value (although the profile would be easier to implement if an array is always an array, even if it has only one value). Section 5.2.5: I found the wording "It is simply an array of ..." misleading, suggesting something like this:   Obligations:[{    Id:"urn:oasis:names:tc:xacml: 3.0:ipc:obligation:encrypt"   },   {    Id:"urn:oasis:names:tc:xacml: 3.0:ipc:obligation:marking",    AttributeAssignment:{     AttributeId:"urn:oasis:names: tc:xacml:3.0:example: attribute:text",     DataType:" http://www.w3.org/ 2001/XMLSchema#string "    }   }] rather than this:   Obligations:{    ObligationsOrAdvice:[{     Id:"urn:oasis:names:tc:xacml: 3.0:ipc:obligation:encrypt"    },    {     Id:"urn:oasis:names:tc:xacml: 3.0:ipc:obligation:marking",     AttributeAssignment:{      AttributeId:"urn:oasis:names: tc:xacml:3.0:example: attribute:text",      DataType:" http://www.w3.org/ 2001/XMLSchema#string "     }    }]   } Assuming the latter is correct, then it would be better to say "It simply contains an array of ...". I don't actually see the point in a double-nesting. So I would rather have "Obligations": [{"Id":"",.......],{}] rather than "Obligations": {"ObligationOrAdvice" :  [{"Id":"",.......],{}] } It also applies to Advice as you pointed out and to Response / Result. Am I missing a JSON subtlety here?


  • 7.  Re: JSON Profile Issues (was Re: [xacml] Thursday Meeting)

    Posted 05-14-2013 00:10
    Hi David, On 11/05/2013 9:20 AM, David Brossard wrote: Regarding the following The examples show instances where what is described as an array in the text is shown instead as a single value (noting that an object is a JSON value). I think it would be useful to make a statement somewhere early in the profile that an array with a single JSON value MAY, or MUST if that is your intent, be encoded directly as that value rather than as an array of one value (although the profile would be easier to implement if an array is always an array, even if it has only one value). Section 5.2.5: I found the wording "It is simply an array of ..." misleading, suggesting something like this: Obligations:[{ Id:"urn:oasis:names:tc:xacml:__3.0:ipc:obligation:encrypt" }, { Id:"urn:oasis:names:tc:xacml:__3.0:ipc:obligation:marking", AttributeAssignment:{ AttributeId:"urn:oasis:names:__tc:xacml:3.0:example:__attribute:text", DataType:" http://www.w3.org/__2001/XMLSchema#string < http://www.w3.org/2001/XMLSchema#string >" } }] rather than this: Obligations:{ ObligationsOrAdvice:[{ Id:"urn:oasis:names:tc:xacml:__3.0:ipc:obligation:encrypt" }, { Id:"urn:oasis:names:tc:xacml:__3.0:ipc:obligation:marking", AttributeAssignment:{ AttributeId:"urn:oasis:names:__tc:xacml:3.0:example:__attribute:text", DataType:" http://www.w3.org/__2001/XMLSchema#string < http://www.w3.org/2001/XMLSchema#string >" } }] } Assuming the latter is correct, then it would be better to say "It simply contains an array of ...". I don't actually see the point in a double-nesting. There is no reason for it in this case, apart from consistency with the XML Schema. So I would rather have "Obligations": [{"Id":"",.......],{}] rather than "Obligations": {"ObligationOrAdvice" : [{"Id":"",.......],{}] } I'm okay with such a change. You could equally well use the names "Obligation" and "Advice" instead of "Obligations" and "AssociatedAdvice". It just depends on which element layer in the XML Schema we believe we are stripping out. It also applies to Advice as you pointed out and to Response / Result. Am I missing a JSON subtlety here? None that I'm aware of. Regards, Steven


  • 8.  Re: JSON Profile Issues (was Re: [xacml] Thursday Meeting)

    Posted 05-14-2013 14:36
    Great, then I'll change the spec accordingly. On Tue, May 14, 2013 at 2:10 AM, Steven Legg < steven.legg@viewds.com > wrote: Hi David, On 11/05/2013 9:20 AM, David Brossard wrote: Regarding the following     The examples show instances where what is described as an array in the     text is shown instead as a single value (noting that an object is a JSON     value). I think it would be useful to make a statement somewhere early in     the profile that an array with a single JSON value MAY, or MUST if that is     your intent, be encoded directly as that value rather than as an array     of one value (although the profile would be easier to implement if an     array is always an array, even if it has only one value).     Section 5.2.5: I found the wording "It is simply an array of ..." misleading,     suggesting something like this:        Obligations:[{         Id:"urn:oasis:names:tc:xacml:_ _3.0:ipc:obligation:encrypt"        },        {         Id:"urn:oasis:names:tc:xacml:_ _3.0:ipc:obligation:marking",         AttributeAssignment:{          AttributeId:"urn:oasis:names:_ _tc:xacml:3.0:example:__ attribute:text",          DataType:" http://www.w3.org/__ 2001/XMLSchema#string < http://www.w3.org/2001/ XMLSchema#string >"         }        }]     rather than this:        Obligations:{         ObligationsOrAdvice:[{          Id:"urn:oasis:names:tc:xacml:_ _3.0:ipc:obligation:encrypt"         },         {          Id:"urn:oasis:names:tc:xacml:_ _3.0:ipc:obligation:marking",          AttributeAssignment:{           AttributeId:"urn:oasis:names:_ _tc:xacml:3.0:example:__ attribute:text",           DataType:" http://www.w3.org/__ 2001/XMLSchema#string < http://www.w3.org/2001/ XMLSchema#string >"          }         }]        }     Assuming the latter is correct, then it would be better to say "It simply     contains an array of ...". I don't actually see the point in a double-nesting. There is no reason for it in this case, apart from consistency with the XML Schema. So I would rather have "Obligations": [{"Id":"",.......],{}] rather than "Obligations": {"ObligationOrAdvice" :  [{"Id":"",.......],{}] } I'm okay with such a change. You could equally well use the names "Obligation" and "Advice" instead of "Obligations" and "AssociatedAdvice". It just depends on which element layer in the XML Schema we believe we are stripping out. It also applies to Advice as you pointed out and to Response / Result. Am I missing a JSON subtlety here? None that I'm aware of. 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