I have a number of different kinds of comments about the REST Profile and Media
types which will post separately to allow the discussion to take place in
distinct threads.

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.

(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.)

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.

This could be done by means of the IncludeInResponse feature, but that involves
additional transmission and processing overhead. If your intention is to set a
limit of one outstanding request per TCP session, then that should be stated
explicitly. IMO the SAML InResponseTo scheme or something equivalent to it is
the easiest way to solve the problem.

For the record, the Request includes:

Issuer Signature ID Version Issue Instant Destination Consent Processing Flags InputContextOnly ReturnContext CombinePolicies AdditionalAttributes Policy PolicySet ReferencedPolicies AdditionalAttributes AssignedAttributes Holders HolderAttributes

Much of this applies only to the Admin Profile, which we could choose not to
support in this protocol, but I would like an explicit decision to that effect.

The Assertion includes:

Issuer Signature ID Version Issue Instant Validity Period

The Response includes:

Issuer Signature ID InResponseTo Version Issue Instant Destination Consent Status (covered by the HTTP Status Code)

Hal