[xacml-users] REST Profile - PDP Issues

[Hal Lockhart <hal.lockhart@oracle.com>]

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

---------------------------------------------------------------------
To unsubscribe, e-mail: xacml-users-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: xacml-users-help@lists.oasis-open.org