[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [xacml] [xacml-users] REST Profile - PDP Issues
Hal, > -----Original Message----- > From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On > Behalf Of Hal Lockhart > Sent: Wednesday, May 16, 2012 11:26 PM > To: xacml@lists.oasis-open.org > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]