Hal,
> -----Original Message-----
> From: [mailto:] On
> Behalf Of Hal Lockhart
> Sent: Wednesday, May 16, 2012 11:26 PM
> To:
> Subject: [xacml] [xacml-users] REST Profile - PDP Issues
>
> Section 2.2.2 is not very clear about what precisely goes into the POST
> request and response exchanged with a PDP, but the example shows XACML
> <Request> and <Response> elements being sent.
Yeah, I struggled with that a bit. Since the actual media type definitions are now outside the REST profile, I find it difficult to be precise. Any suggestions for improvement?
> (Minor point: it is customary to use a namespace qualified name and
> define the namespace tags near the beginning of the doc. Specifications
> frequently reference several XML schemas and they could contain the
> same element names. In particular, common words like Request and
> Response are likely to appear in many schemas.)
Not all formats have the concept of namespaces (e.g. JSON), so in the interest of being neutral in terms of representation, I felt I couldn't use namespaces here. I used wording like "XACML request" to address this issue. Does that sound reasonable?
> However, the current, SOAP-based wire protocol which is specified in
> section 4 of the SAML Profile of XACML wraps the request in a
> XACMLAuthzDecisionQuery request and the response is wrapped in an
> Assertion and XACMLAuthzDecisionQuery response. These wrappers add
> complexity, but provide a number of useful capabilities. I would
> suggest reviewing these to determine if any this functionality would be
> of value in this profile.
>
> One feature I believe is required is Request/Response correlation. The
> SAML-derived request/response solve this problem by means of the ID and
> InResponseTo XML Attributes.
>
> Assuming HTTP 1.1 may be used and considering that a typical PEP is a
> multithreaded server, the possibility of having more than one request
> outstanding at the same time arises. Therefore it becomes necessary to
> figure out what request the PDP has said to Permit.
Since we're using POST, which is non-idempotent (http://tools.ietf.org/html/rfc2616#section-9.1.2), we must not use HTTP pipelining (http://tools.ietf.org/html/rfc2616#section-8.1.2.2). So a request will always have to wait for the response and thus there can be no confusion as to which response belongs to which request. Or am I missing something?
Thanks,
Ray
