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