[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] XPath support in the JSON profile
I agree that the xpath expression data type is not a high value item for JSON requests.
XML content, though, is a little more valuable. If the only thing holding back inclusion of XML content in JSON requests is aesthetics, ("lesser of uglies") I'd lean towards functional over pretty.
I realize that there are whole subcultures of developers who may write JSON-XACML requests by hand, but for myself (and my SDKs), JSON will almost always be machine generated by higher-order classes - just as with XML XACML requests in our tool chain.
So, I would lean toward including XML content in JSON with sufficient encoding (pick one, I don't care which). Ditch XPATH and xpath expression data type from JSON for now.
-Danny
Danny Thorpe
Authorization Architect
Dell | Identity & Access Management, Quest Software
Quest Software is now part of Dell.
> -----Original Message-----
> From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On
> Behalf Of Steven Legg
> Sent: Thursday, November 01, 2012 4:38 PM
> To: David Brossard
> Cc: xacml
> Subject: Re: [xacml] XPath support in the JSON profile
>
>
> 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
> > " 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
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: xacml-help@lists.oasis-open.org
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]