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: JSON Profile Issues (was Re: [xacml] Thursday Meeting)



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



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