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: Comments on JSON Profile 08



Hi David,

On 7/12/2012 12:55 PM, David Brossard wrote:
Thanks Steven for this great feedback! I will make the necessary corrections.

Re. the Subject,  I willingly did not make it an array. The point is that Subject, Resource,... are for
simple requests. For everything else, there's the "normal" way. Do you think that's the best way out or
would you rather see array of Subject?

It's fine the way it is. I was just checking that it was intentional.


By the way, using Subject, Resource... brings us back to the XACML 2.0 notation :-)

Before my time :-).

Regards,
Steven


On Thu, Dec 6, 2012 at 5:11 PM, Steven Legg <steven.legg@viewds.com <mailto:steven.legg@viewds.com>> wrote:


    One more. The example in section 3.5 uses "value" instead of "Value".

    Regards,
    Steven


    On 7/12/2012 10:56 AM, Steven Legg wrote:


        Hi David,

        Here are some issues I have noted in implementing the Working Draft 08
        JSON profile (xacml-json-http-v1.0-wd08.__doc).

        Section 3.4.1 - The shorthand type codes for data-types use inconsistent
        letter case for the first letter. We have "String", "Boolean", "Integer"
        "Double", "Time" and "Date" with a leading uppercase letter, but all the
        rest, e.g., "dateTime" and "anyURI", use a leading lowercase letter. I
        think they should all have a leading lowercase letter for consistency
        with the XACML data-type URI.

        Section 3.4.3 - The special numeric values NaN, INF and -INF need to be
        represented as JSON strings, i.e., "NaN", "INF" and "-INF". The data-type
        would have to be explicit when an XACML attribute value has one of these
        values. The special value -0 is okay as a JSON number. Since 4.2.5 expects
        the array of values to all be the same JSON construct (all string or all
        number), an attribute with double values would have to be represented as
        two separate attributes if it contains some regular values and some
        special numeric values. It would be easier if 4.2.5 allowed an array of
        string and/or number for the double data-type.

        Section 4.2.2.1 - RequestDefaults should be quoted and followed by a colon.

        Section 4.2.3.1 & 4.2.3.2 - The JSON representation allows only a single
        object for each of Subject, Action, Resource and Environment. An XACML
        request may have more than one Subject, Action, Resource or Environment,
        making them arrays rather than single objects. If there are multiple
        subjects, etc., then an implementation can always put them in the
        "Attributes" array, so I'm not fussed if you leave this the way it is.
        I'm just making the point in case it's something you hadn't considered.

        Section 4.2.5 - "Array of Boolean" should be added as a possible Type
        for the Value property.

        Section 4.2.5.1 - There should be a comma at the end of the line for "Id".

        Section 4.2.5 - This section says that Datatype defaults to string if
        omitted, but section 3.4.1 says the data-type can be omitted when it
        can be inferred from the value. I assume 4.2.5 is wrong and Datatype
        is to be inferred from the value(s) when it is omitted. For most of the
        XACML data-types the data-type can be inferred from the first value.
        However, the double data-type is the odd one out because an integer
        number is also a double value. Scanning an array of number to see if
        any number is a floating point number before deciding on the data-type
        would be inconvenient. Deciding on the data-type by looking at only the
        first value is easier. It needs to be stated which way the data-type is
        inferred so that JSON encoders know when they need to explicitly output
        Datatype for values of the XACML double data-type.

        On the last TC call I agreed to write up some text for a JSON encoding
        of values of the xpathExpression data-type. I will make this a separate
        email.

        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



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