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: RE: Context Handler (was: XACML & RDF)

Paul and others,

> -----Original Message-----
> From: Tyson, Paul H [mailto:PTyson@bellhelicopter.textron.com]
> Sent: Thursday, December 01, 2011 4:25 PM
> To: Sinnema, Remon
> Cc: xacml@lists.oasis-open.org
> Subject: RE: XACML & RDF
> Yes, the context handler would have to take on the semantic duties of
> entailment and reasoning.

These are the interesting references to Context Handler I could find in the core 3.0 spec:

30 Context handler
31 The system entity that converts decision requests in the native request format to the XACML 
32 canonical form and converts authorization decisions in the XACML canonical form to the native 
33 response format.

474 The context handler constructs an XACML request context and sends it to the PDP.
475 The PDP requests any additional subject, resource, action, environment and other categories
476 (not shown) attributes from the context handler.
477 The context handler requests the attributes from a PIP.

480 Optionally, the context handler includes the resource in the context.

3221 Attributes are represented in the request context by the context handler, regardless of whether or not
3222 they appeared in the original decision request,

3281 The PDP SHALL request the values of attributes in the request context from the context handler. The 
3282 PDP SHALL reference the attributes as if they were in a physical request context document, but the 
3283 context handler is responsible for obtaining and supplying the requested values by whatever means it 
3284 deems appropriate.

3296 Standard environment attributes are listed in Section B.7. If a value for one of these attributes is 
3297 supplied in the decision request, then the context handler SHALL use that value. Otherwise, the 
3298 context handler SHALL supply a value.

3643 Using these new attribute identifiers, the PEPs 
3644 or context handlers used by that community of users can flatten instances of the structured 
3645 data-type into a sequence of individual <Attribute> elements.

3908 The implementation MUST support the attributes associated with the following identifiers as specified by 
3909 XACML. If values for these attributes are not present in the decision request, then their values MUST 
3910 be supplied by the context handler.

The picture this paints is that the Context Handler is responsible for supplying attribute values in addition to the ones specified by the PEP. It can do so autonomously before it sends the request context to the PDP, and also while instructed to do so by the PDP while the PDP is processing the request. The latter is explicitly defined in the spec using the PIP component. I propose we make the former explicit as well by defining a new component for it.

The "inventory" above shows that there are already the following actions that would fall under the proposed new component:
- add resource to request
- add current date/time attributes to request when not supplied
- add attributes to the request based on a supplied structured attribute

Semantic entailment would be another example of this proposed new component.

We could name the new component something like Request Enhancement Point (REP). What do you think?


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