Re: [xacml] Groups - Request / Response Interface based on JSON and HTTP

Subject: Re: [xacml] Groups - Request / Response Interface based on JSON and HTTP for XACML 3.0 Version 1.0 uploaded

Hi David, hi Hal -

Just one nuance you may want to consider.

Changing the title of the work is no problem.

If you want to change the filename and URL to remove the -http (currently http://docs.oasis-open.org/xacml/xacml-json-http/v1.0/csprd02/xacml-json-http-v1.0-csprd02.html) then it becomes a new work product. E.g. http://docs.oasis-open.org/xacml/xacml-json/v1.0/csd01/xacml-json-v1.0-csd01.html and etc.

If the URL/filename is not important to you and you just want to change the title of the work - which is really how everyone will know it anyway - that's fine. We'll handle that in the next round.

Let me know if you have any questions on it.

/chet

On Thu, Mar 20, 2014 at 11:51 AM, Hal Lockhart <hal.lockhart@oracle.com> wrote:

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.

urn:oasis:names:tc:xacml:1.0:status:syntax-error
----

Hal

> Thanks,
> David.

--

/chet
----------------
Chet Ensign
Director of Standards Development and TC Administration
OASIS: Advancing open standards for the information society
http://www.oasis-open.org

Primary: +1 973-996-2298
Mobile: +1 201-341-1393

Check your work using the Support Request Submission Checklist at http://www.oasis-open.org/committees/download.php/47248/tc-admin-submission-checklist.html

TC Administration information and support is available at http://www.oasis-open.org/resources/tcadmin

Follow OASIS on:
LinkedIn: http://linkd.in/OASISopen
Twitter: http://twitter.com/OASISopen
Facebook: http://facebook.com/oasis.open

xacml message