Re: [xacml] XPath support in the JSON profile

[Steven Legg <steven.legg@viewds.com>]

Hi David,

On 2/11/2012 8:11 AM, David Brossard wrote:
> Hi Steven,
>
> Thanks for the feedback. I'll update the profile to fix the XPathCategory part.
>
> As for the XML escaping, Erik suggested I resort to Base 64 encoding to avoid having to escape XML.

That's mostly right. The Base64 encoding would still need to be in a JSON string and
Base64 strings can include '/', which has an escape sequence in JSON. The good news
is that '/' isn't a character that must be escaped, so it would seem to be okay for
a sender to just wrap the Base64 in double quotes. To be safe, receivers should be
prepared to handle an escaped '/' in the Base64 encoding.

> The
> issue is that if JSON is meant to be for easier XACML request authoring and human readability, Base 64 goes
> against that.

The Base64 encoding is automatically 33% longer than the original XML. I would
expect that the JSON character escapes would bloat a typical XML document by less
than that, and the result would still be semi-readable. So I lean towards using
the JSON character escapes.

> So maybe the intent to have XML support in the JSON profile is wishful but not necessarily interesting or
> useful.

I could live without XML support in the JSON profile, but it also seems like
we have a complete solution: an object encoding for xpathExpression values and
we choose one of Base64 or JSON character escapes for embedded XML. Is there
anything more needed ?

If in the future we JSON-ify the XML and XPath, we can readily provide them
as alternative representations.

Regards,
Steven

> Thoughts?
>
> David.
>
> On Wed, Oct 31, 2012 at 1:39 AM, Steven Legg <steven.legg@viewds.com <mailto:steven.legg@viewds.com>> wrote:
>
>
>     Hi David,
>
>
>     On 30/10/2012 3:00 AM, David Brossard wrote:
>
>         Hi,
>
>         Although the JSON profile does support the XPath features of XACML, I just wanted to point out that
>         it will
>         not be trivial and that any scenario involving XPath should probably use the "normal" XML
>         representation of
>         a XACML request/response.
>
>         As an example, Erik pointed out that I would struggle to serialize the datatype values of type
>         urn:oasis:names:tc:xacml:3.0:__data-type:xpathExpression into a string because of the namespace
>         definitions.
>
>
>     There's a further problem in that xpathExpression values also have an XPathCategory
>     XML attribute. Unlike values of the other data-types, values of the xpathExpression
>     data-type are not primitive values and would need to be represented as a JSON object.
>     For example:
>
>          "Attribute": {
>              "Id" : "urn:oasis:names:tc:xacml:3.0:__content-selector",
>              "DataType" : "xpathExpression",
>              "value" : {
>                  "XPathCategory" : "urn:oasis:names:tc:xacml:3.0:__attribute-category:resource",
>                  "namespaces" : [{
>                      "namespace-prefix" : "md",
>                      "namespace-name" : "urn:example:med:schemas:__record"
>                  }],
>                  "cdata" : "md:record/md:patient/md:__patientDoB"
>
>              }
>          }
>
>
>         Also, in section 5.2.4, I escape XML content making it quite unreadable. That's definitely not
>         user-friendly
>         which tends to make me think this profile is not for use cases with XML content.
>
>
>     The escaping you describe in section 4.2.4 is problematic. The character sequence
>     &quot; can appear in XML attribute values, where replacing it with a literal
>     double quote character would cause the XML to become invalid. The escape sequence
>     would need to be something that cannot occur in a valid XML document. In any case,
>     JSON strings use backslash escapes ( see http://www.json.org/ ) which solves the
>     problem of double quotes in an XML payload, but has other implications. At the very
>     least, any \ or " characters in the XML payload would have to be escaped. However,
>     JSON seems to require us to escape whitespace control characters. That would be
>     really ugly.
>
>     You haven't always comma separated name/value pairs in objects in the examples.
>     Otherwise, I have no other issues with the JSON draft.
>
>     Regards,
>     Steven
>
>
>
>         David.
>         --
>         David Brossard, M.Eng, SCEA, CSTP
>         Product Manager
>         +46(0)760 25 85 75 <tel:%2B46%280%29760%2025%2085%2075>
>         Axiomatics AB
>         Skeppsbron 40
>         S-111 30 Stockholm, Sweden
>         http://www.linkedin.com/__companies/536082 <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