Separating request and content

["Daniel Engovatov" <dengovatov@bea.com>]

When looking at the request schema I could not find a good place for the existing ResourceContent context element. Adding schema restrictions for a particular context attribute category seems to be not a very elegant solution.In any case – existing way to provide an arbitrary XML context document inside an element of “any” type does not seem to be optimal.

 

What I want to suggest, and to discuss tomorrow:

 

1. Modify XACML processing model to allow a single arbitrary XML document to be submitted along with the Request in an implementation defined way.
2. Modify the AttributeSelectorType and add an optional “ContentURI” attribute, of type xs:anyURI with a default value of urn:oasis:names:tc:xacml:3.0:requesturn
3. This attribute will be used in the following way
1. It identifies document node for the path expression in AttributeSelector
2. Default value is the URI for the request document – default behavior would be exactly as it is now
3. If an additional document is present in the request this URI resolves to that document, so the path expression in the selector applies to it.

                                                    i.     In this case you can not use the AttributeSelector to select individual attribute values, but that would be redundant to AttributeDesignator anyway.   An alternative would be to have two reserved URI – for the request, and for the submitted document.

4. If any other URI is used in the policy, it should be resolved in an implementation dependent way.  That may allow to use an AttributeSelector to extract values from different documents.

 

So the main point is to replace the existing ResourceContent with a separate document, and to allow AttributeSelector to identify document uri, with default behavior remaining the same it is now.

 

Could this be added to tomorrow’s agenda?

 

Daniel;

_______________________________________________________________________
Notice:  This email message, together with any attachments, may contain
information  of  BEA Systems,  Inc.,  its subsidiaries  and  affiliated
entities,  that may be confidential,  proprietary,  copyrighted  and/or
legally privileged, and is intended solely for the use of the individual
or entity named in this message. If you are not the intended recipient,
and have received this message in error, please immediately return this
by email and then delete it.