OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: wd8 multi profile comments


Chair(s):

	* Hal Lockhart affiliation and email address

Abstract:

	* change to "This document provides a profile for requesting
more than one access control decision in a single XACML Request Context,
..."

Section 1:

	* Revise opening to "The policy evaluation performed by an XACML
Policy Decision Point, or PDP, is defined in terms of a single decision
request in the XACML Specification [XACML], with the authorization
decision contained in a single <Result> element of the response context.
A Policy Enforcement Point, or PEP, however, may wish to submit a single
request context for multiple access control decisions, ..."

	* 2nd paragraph: change "can request authorization decisions for
multiple resources" to "can request multiple authorization decisions".

	* 3rd paragraph: change "mechinism" to "mechanism".

Section 2:

	* 1st paragraph: change "request for access to multiple
decisions" to "request for multiple access control decisions".

	* 2nd paragraph, 1st sentence: change "request for access to
multiple decisions" to "requests for multiple access control decisions";
change "each requesting access to exactly one of the decisions" to "each
requesting exactly one of the decisions".

	* 2nd paragraph: change "Each such decisions" to "Each such
decision".

	* 2nd paragraph: refer to section 4 for details of the model for
creating individual decision requests.

	* 3rd paragraph: change "requests for access to multiple
decisions" to "requests for multiple access control decisions".

Section 2.1:

	* The "scope" resource attribute is defined in Section 5.

Section 2.1.3

	* Remove sentence that begins "If a <Content> element was
present..." (this section does not apply to XML content).

Section 2.2.3

	* 1st paragraph: change to "Such a request context SHALL be
interpreted as a request for individual decisions regarding each of the
nodes in the nodeset selected by the XPath expression given in the
<AttributeValue> of the "multiple:content-selector" attribute."

	* 3rd paragraph: change to "If multiple <Attributes> elements in
different categories contain a "multiple:content-selector" attribute,
then the set of Individual Decision Requests will be formed from the
cross product of the nodesets selected by the
"multiple:content-selector" XPath expressions in the different
categories.  See Section 4 for detailed description of the processing
model."

Section 2.3

	* Title: consider changing to "Repeated Attributes categories"
(because "repeated" implies "multiple").

Section 2.3.3

	* 2nd paragraph: change "according to the corresponding Section
of this Profile listed in Section 5.1" to "according to the processing
model specified in Section 4".

Section 3

	Item 1 specifies that the Result must not have any Attributes.
Does the context handler ignore "IncludeInResult" requests, or is it an
error if the request context has any IncludeInResult="true"?

Section 4

	Title: consider "Conceptual model for creating Individual
Decision Requests".

	1st paragraph: it's not clear to me what "nesting" means here.
Consider changing to "This profile specifies several independent schemes
for Multiple Decision Requests in sections 2 and 3. Any combination of
features described by these schemes MAY be used in an initial request.
This section defines a normative processing model to create Individual
Decision Requests from an initial request context in which one or more
features of the multiple profile are present.  An implementation MUST
produce identical results to those that would be produced by performing
the following operations in the given order."

	Steps 2 and 3: I suggest reversing these steps.  It would be
cleaner to expand "scope" and "multiple:content-selector" first, because
the result will always yield repeated attributes categories.  These can
then be processed the same as repeated attributes categories in the
initial request context (or result of expanding MultiRequests).

	Step 5: Replace with a reference to section 3 for producing a
single combined decision.


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]