> > 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? > I don't see why you can explicitly call out schema and outermost XML element and specifically say you must send this or can send either this or this. > > > (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? I was thinking primarily of the examples here. <Request> is potentially ambiguous. <xs:request> with a suitable definition of xs, is not. I would still like to hear from others as to whether we need any of the other features provided by the wrappers. > > > 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 ). My reading of rfc 2616 - 9.1.2 is that POST is not REQUIRED to be idempotent. As a matter of fact, we know an XACML decision request IS idempotent. > 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? I don't see how this restriction could be acceptable in a production environment. Managing a large connection pool and scheduling requests onto available connections is complicated and may have its own performance implications. Making every request wait in line is unacceptable. Remember the DPD server may go off and do things that take a "long" time, like fetching attribute values from other repositories. I would like to hear what others think. Hal