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


> 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


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