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: [xacml] XPath support in the JSON profile



Hi Bill,

On 3/11/2012 1:11 AM, Bill Parducci wrote:
You cannot simply paste it into a page and view it in a browser (any better that looking at in vi) without first en-escaping it. That is tedious at best, so it requires programmatic massaging if done at any scale. As soon as you preprocess you might as well use base64. It is reliable, well understood and supported by all known languages.

Consider that any string that a JSON encoder puts out must be properly escaped.
This includes any XACML attribute values that are output as strings. Since a
JSON encoder must have a routine to output properly escaped strings, it is
trivial to use that routine when the string in question is XML from the Content
element. Using a Base64 encoding for such XML means adding processing capability
that the JSON encoder wouldn't otherwise need to have.

Similarly, a JSON decoder still needs to have a routine for parsing escaped
strings, regardless of whether we use it to parse XML Content.


Again, human readable to what end? Is someone arguing the case that Authors will be editing policy directly in JSON?

No, but admins might be looking at JSON messages through a monitoring tool
or in a log file. It helps if the reader doesn't have to resort to a Base64
decoder to get an idea of what's in the message.


Finally, what are we solving with less "bloat"? If size is an issue then XML is the wrong medium to begin with IMO.

There are some things in an authorization request where we don't have a
practical alternative to XML. Wrong or not, it's what we've got.

Regards,
Steven


b

On Nov 2, 2012, at 2:27 AM, David Brossard <david.brossard@axiomatics.com> wrote:

Hi all,

I think I can conclude from what we've just said that:

(1) Base64 is no better - it's bigger and definitely not human-readable
(2) We should allow for XML Content. I tend to agree with Danny that this will be automated anyway. One good use case for XML content is the ability to send a SAML token to the PDP or an XML medical record as someone mentioned on the list
(3) Let's use the "html" escaping technique i.e. use &gt; and &quot; and so on. Does that work? Am I missing something?

It's not human-readable but if you paste it inside an HTML page, then the browser actually displays the XML payload.

(4) Let's remove the XPath datatype. I will flag it as not supported.

On Fri, Nov 2, 2012 at 1:21 AM, Bill Parducci <bill@parducci.net> wrote:
I do not think one can reasonably refer to escaped XML wrapped in JSON as even mildly readable. Granted, it might be useful for debugging by a well versed engineer, but is that the use case we are trying to solve? I suspect in reality even debugging would be handled by some level of decoding before human eyes attempt to extract the details. If that is true, then I tend to agree with the base64 proposal.

b



On Nov 1, 2012, at 4:37 PM, Steven Legg <steven.legg@viewds.com> wrote:

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.


---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-help@lists.oasis-open.org




--
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]