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


I just realized that I am not being very consistent here.

\ should be escaped using \: \\
" should be escaped using \: \"

What do you think?


On Thu, Nov 15, 2012 at 10:10 AM, David Brossard <david.brossard@axiomatics.com> wrote:
Dear all,

Trying to wrap this up before our meeting later today.

Re. the XML encoding, we could perhaps use this: http://www.jsonml.org/

It's maybe too simple i.e. the examples do not use namespaces.

@Bill, browsers will display the XML on screen if you give them escaped XML or escaped HTML.

Example

<html><body>put your escaped XML here</body></html>

So escaping it could be easy.

@Steven, I can see how escaped content in the XML would collide with content you escape so that you can have them in the JSON string. It almost sounds like we would need a double-escape i.e. first convert all &quot; in your XML to &amp;quot; and then convert the " to &quot;

But actually if we follow JSON convention (i.e. escape using \), we could do the following:

<xmlContent value="the \ is a neat thing">foo "content" with \"" as example</xmlContent>

would become
 
<xmlContent value=\"the &#92; is a neat thing\">foo \"content\" with &#92;\"\" as example</xmlContent>

What happened?
  1. Take the XML content and replace all \ with &#92;
  2. Take the XML content and escape all double quotes using \: \"
Thoughts?
On Mon, Nov 5, 2012 at 4:28 PM, Bill Parducci <bill@parducci.net> wrote:
> 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.

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

My point is that humans make for poor de/encoders. I argue that anyone is deep enough in the bowels of the system so as to be debugging will most likely be using a tool that extracts the payload into the native format. (I also have great empathy for any sysadmin whose engineering staff would be writing such pap to the logs. :)

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

I am not arguing against the use of XML but that using size as the basis for determining a solution in this case is not convincing.

b



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




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