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] Groups - Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 uploaded

Responses inline:

> -----Original Message-----
> From: David Brossard [mailto:david.brossard@axiomatics.com]
> Sent: Wednesday, March 19, 2014 12:14 PM


> . I added comments where I wanted to ask the TC how to move forward.
> The comments / questions are:

> . Can we decide to change the profile name? Is there a process we need
> to respect? This is in line with Ray's request from a weeks back.
> o Suggested new name: JSON Profile of XACML 3.0 (as per Remon Sinnema's
> email dated March 6 2014)

The only process is the progression from wd->csd->cs->os. If you change the wd and it gets voted to csd, that is all that is required by OASIS. The usual procedure for a change of this kind is to inquire on the list and/or on a call if anyone objects.

> . In the XACML 3.0 spec, the XPathExpressionDatatype object contains an
> XPathCategory property. This property seems to be redundant since an
> XPathExpressionDatatype belongs to a parent which already indicates the
> category. Am I reading this correctly? Can we get rid of XPathCategory?

My reading of the 3.0 core spec is that XPathCategory specifies where in the Request to obtain the text, not the category of the attribute value thus obtained. Any <Attributes> element can contain a <Content> element, so you need to know which one to apply the XPath expression to. I believe this is a consequence a change from 2.0. In 2.0 selectors could pretty much point at anything. In 3.0 they (and attributes of type XPath) can only point to <Content> elements in the Request, but it does not have to be from the same Category.

Erik, did I get this right?

> . With respect to the special numerical values, and generally if input
> or output is non conformant to spec, should we throw an error or an
> INdeterminate? In other words should we delegate error throwing to the
> transport layer or should we specify w/in the XACML spec?

I vote for Indeterminate. Appendix B.8 says:

This identifier indicates that some attribute value contained a syntax error, such as a letter in a numeric field.



> Thanks,
> David.

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