OASIS eXtensible Access Control Markup Language (XACML) TC

 View Only
  • 1.  Minutes for XACML TC Meeting 23 Fenruary 2012

    Posted 02-23-2012 19:29
    I. Roll Call & Approve Minutes: Voting Members Crystal Hayes Richard Hill Rich Levinson Hal Lockhart (Chair) Bill Parducci (Co-Chair/Minutes) Remon Sinnema Danny Thorpe John Tolbert Paul Tyson Members Erik Rissanen Quorum met: (90% per Oasis) Minutes from 9 February 2012 TC meeting voted on. APPROVED UNANIMOUSLY. II. Administrivia RSA InterOp Status RSA next week. Everything is ready to go. John has added some slides, looking for feedback. ITU and XACML Abbie Barbir had posted a notification a presentation to ITU re: XACML v3.0 Media types Ray got doc started, Robin from Oasis offered to help. Need to get types defined to move forward. Ray asked if there were XACML version dependencies on the types. Hal noted this was not necessary for XML but noted that we need to mechanism for JSON is separate, Ray's initial types should cover these cases. RuleML Paul noted that this upload was mostly a "shell" document to frame the conversation. IPC Profile John stated that it is in a "frozen" state, until after the interop at RSA. Rich suggested that the typo would affect the sample. Richard noted that this has been corrected in WD-08. WD-07 will be used for the interop. XACML v3.0 Open Items Issue #3: Combining Algorithm Hal summarized the general consensus that the TC proceed this new algorithm as a separate Profile and leave open the option to take a more detailed look at incorporating this into the core specification at a later date. Issue #4 Context Handler Ray will make a proposal for updating the flow-model and clarify Attribute retrieval in section 7.3.5 by the next meeting. Paul offered that additional verbiage that effectively notes that all attributes are available "as-is" at the time of evaluation, noting that is possible for attribute variation may occur during attribute retrieval. Paul will explore how to address this descriptively. Issue #5: Higher Order Function Generalization Erik noted that no new work has been done on this. Hal suggested that the new identifiers be added, leaving the older identifiers. Erik offered that only the 3.0 identifiers be listed and the old identifiers be listed as future deprecation. Paul agreed. Issue 6: Section 5.29 AttributeDesignator missing xs:element line Erik will correct this typo. Issue 7: URI equality Hal suggested that there be two distinct matching mechanisms for URIs. Erik offered that a code point by code point match is sufficient. Hal asked if there is general consensus that the spec will not address all cases of URI matching, rather Erik's approach will be specified for name space matches and general matching is outside of the scope of the spec. Rich asked that a distinct proposal be made to the list before making a decision. Paul raised a concern that this will create ambiguity on matching. Erik, Hal noted that there is a lot ambiguity in this function generally. XPath has dropped it's definition in v2.0. Paul suggested that we refer to the XACML definition in all cases. Code point matching (effectively string matching with allowance for conversion) will be explored further as it pertains to the spec. Erik will address this in the next WD and post it to the list for review. Issue #8 Schema Anomalies Hal observed that you can define Policies with no Rules. Paul noted that this doesn't effect the output of a Policy evaluation because the new combining algorithms allow for this. Hal asked how this is handled. Erik noted that a Policy without any Rules will invoke and algorithm without any Rules. Depending upon the algorithm, the appropriate Permit Deny Not Applicable answer will be returned based upon the nature of the algorithm. Erik referred to the TC list from last year as the original discussion. Rich offered that further clarity is necessary for implementation. Erik responded that it is not impractical that special cases be called out in the spec. Hal suggested that "no rule" is unique enough to merit a comprehensive statement. Paul suggested that this is something that should be defined in a developer's notes. This issue is held until the next call. meeting adjourned.


  • 2.  Media types: version parameter?

    Posted 02-24-2012 14:08
    All, >


  • 3.  Re: [xacml] Media types: version parameter?

    Posted 02-24-2012 14:47
    Agreed. Similarly I don't see a downside to accounting for this. b On Feb 24, 2012, at 6:08 AM, <remon.sinnema@emc.com> wrote: > All, > > >>


  • 4.  Issue #4: Context Handler - Proposal

    Posted 02-24-2012 15:32
    All,   Current text 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   Proposal Context handler The system entity that converts decision requests in the native request format to the XACML canonical form , coordinates with Policy Information Points to add attribute values to the request context, and converts authorization decisions in the XACML canonical form to the native response format.     Current text 474 4. The context handler constructs an XACML request context and sends it to the PDP.   Proposal 4. The context handler constructs an XACML request context , optionally adds attributes, and sends it to the PDP.     Current text 3280 7.3.5 Attribute Retrieval 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.   Proposal 7.3.5 Attribute Retrieval The PDP SHALL request the values of attributes in the request context from the context handler. The context handler MAY also add attributes to the request context without the PDP requesting them. The PDP SHALL reference the attributes as if they were in a physical request context document, but the context handler is responsible for obtaining and supplying the requested values by whatever means it deems appropriate , including by retrieving them from one or more Policy Information Points .     Thanks, Ray  


  • 5.  AW: Issue #4: Context Handler - Proposal

    Posted 02-27-2012 09:23
    Hi Ray, all,   I like your edits and I think that they point out the flexibilities of XACML Context Handlers’ behavior. I would even go one step further and add some text blocks in these sentences, that highlight the option, that Context Handlers can also call Obligation Handlers. I have seen many use cases/requirements where XACML Context Handlers need to call Obligation Handlers to discharge the obligations included in an XACML authorization decision. Note that in these scenarios it was not possible/appropriate to discharge the obligations in the PEP (assuming that the Context Handler is not included in the PEP), as the Obligations had an effect on the representation of intercepted Web Service messages included in the XACML authorization decision request (which is only available in the Context Handler and not in the PEP).   Some background information on these use cases: The underlying requirement of these use cases is to enforce rewrite effects on intercepted Web Service requests (or responses). Enforcing rewrite effects is needed in cases where you need to apply access restrictions on intercepted Web Service requests that shall e.g. limit read requests to certain objects (e.g. rewrite the query “select * from person” to the authorized query “select * from person WHERE person.id = dereferenced-subject-id-attr ”). The concepts behind this is a more general and DBMS independent form of what can e.g. be done through Oracle’s VPD mechanism. The attached word document describes the details how to use the XACML obligation mechanism to achieve a XACML policy controlled rewriting of intercepted Web Service messages. Feel free to contact me if you need further explanations. One more note: a very similar approach can be taken to generate sub-requests that will be forwarded to the PIP and tell him how to retrieve more data in order to avoid/solve indeterminate responses.   Best regards Jan   PS: regrets that I can only irregularly attend the teleconferences but they take place during our family dinner time.   Siemens AG Corporate Technology Corporate Research and Technologies CT T DE IT1 Otto-Hahn-Ring 6 81739 Munich, Germany Tel.: +49 89 636-40612 Fax: +49 89 636-48000 mailto:jan.herrmann@siemens.com Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 Important notice: This e-mail and any attachment thereof contain corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank you.       Von: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] Im Auftrag von remon.sinnema@emc.com Gesendet: Freitag , 24. Februar 2012 16:31 An: xacml@lists.oasis-open.org Betreff: [xacml] Issue #4: Context Handler - Proposal   All,   Current text 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   Proposal Context handler The system entity that converts decision requests in the native request format to the XACML canonical form , coordinates with Policy Information Points to add attribute values to the request context, and converts authorization decisions in the XACML canonical form to the native response format.     Current text 474 4. The context handler constructs an XACML request context and sends it to the PDP.   Proposal 4. The context handler constructs an XACML request context , optionally adds attributes, and sends it to the PDP.     Current text 3280 7.3.5 Attribute Retrieval 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.   Proposal 7.3.5 Attribute Retrieval The PDP SHALL request the values of attributes in the request context from the context handler. The context handler MAY also add attributes to the request context without the PDP requesting them. The PDP SHALL reference the attributes as if they were in a physical request context document, but the context handler is responsible for obtaining and supplying the requested values by whatever means it deems appropriate , including by retrieving them from one or more Policy Information Points .     Thanks, Ray   Attachment: example_rewrite-rule.pdf Description: example_rewrite-rule.pdf Attachment: Details on how to use the XACML obligation mechanism to achieve a rewriting of intercepted Web Service messages.pdf Description: Details on how to use the XACML obligation mechanism to achieve a rewriting of intercepted Web Service messages.pdf


  • 6.  Re: [xacml] AW: Issue #4: Context Handler - Proposal

    Posted 02-28-2012 10:23
    Hi Jan, I think adding obligation handling to the PDP side would be a too big change to the current architecture at this point. It opens up questions such as whether obligations which were processed by the PDP, should they be sent to the PEP as well? If not, is that safe? If so, should the PEP know which ones were already handled? Just a couple from the top of my head. Best regards, Erik On 2012-02-27 10:22, Herrmann, Jan wrote: Hi Ray, all,   I like your edits and I think that they point out the flexibilities of XACML Context Handlers’ behavior. I would even go one step further and add some text blocks in these sentences, that highlight the option, that Context Handlers can also call Obligation Handlers. I have seen many use cases/requirements where XACML Context Handlers need to call Obligation Handlers to discharge the obligations included in an XACML authorization decision. Note that in these scenarios it was not possible/appropriate to discharge the obligations in the PEP (assuming that the Context Handler is not included in the PEP), as the Obligations had an effect on the representation of intercepted Web Service messages included in the XACML authorization decision request (which is only available in the Context Handler and not in the PEP).   Some background information on these use cases: The underlying requirement of these use cases is to enforce rewrite effects on intercepted Web Service requests (or responses). Enforcing rewrite effects is needed in cases where you need to apply access restrictions on intercepted Web Service requests that shall e.g. limit read requests to certain objects (e.g. rewrite the query “select * from person” to the authorized query “select * from person WHERE person.id = dereferenced-subject-id-attr ”). The concepts behind this is a more general and DBMS independent form of what can e.g. be done through Oracle’s VPD mechanism. The attached word document describes the details how to use the XACML obligation mechanism to achieve a XACML policy controlled rewriting of intercepted Web Service messages. Feel free to contact me if you need further explanations. One more note: a very similar approach can be taken to generate sub-requests that will be forwarded to the PIP and tell him how to retrieve more data in order to avoid/solve indeterminate responses.   Best regards Jan   PS: regrets that I can only irregularly attend the teleconferences but they take place during our family dinner time.   Siemens AG Corporate Technology Corporate Research and Technologies CT T DE IT1 Otto-Hahn-Ring 6 81739 Munich, Germany Tel.: +49 89 636-40612 Fax: +49 89 636-48000 mailto:jan.herrmann@siemens.com Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 Important notice: This e-mail and any attachment thereof contain corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank you.       Von: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] Im Auftrag von remon.sinnema@emc.com Gesendet: Freitag , 24. Februar 2012 16:31 An: xacml@lists.oasis-open.org Betreff: [xacml] Issue #4: Context Handler - Proposal   All,   Current text 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   Proposal Context handler The system entity that converts decision requests in the native request format to the XACML canonical form , coordinates with Policy Information Points to add attribute values to the request context, and converts authorization decisions in the XACML canonical form to the native response format.     Current text 474 4. The context handler constructs an XACML request context and sends it to the PDP.   Proposal 4. The context handler constructs an XACML request context , optionally adds attributes, and sends it to the PDP.     Current text 3280 7.3.5 Attribute Retrieval 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.   Proposal 7.3.5 Attribute Retrieval The PDP SHALL request the values of attributes in the request context from the context handler. The context handler MAY also add attributes to the request context without the PDP requesting them. The PDP SHALL reference the attributes as if they were in a physical request context document, but the context handler is responsible for obtaining and supplying the requested values by whatever means it deems appropriate , including by retrieving them from one or more Policy Information Points .     Thanks, Ray   --------------------------------------------------------------------- To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xacml-help@lists.oasis-open.org


  • 7.  AW: [xacml] AW: Issue #4: Context Handler - Proposal

    Posted 02-28-2012 11:45
    Hi Erik, thanks for your feedback. The current version of the spec leaves it open where the XACML Context Handler is placed. It could be part of the PEP, a separate SW-component or might even be integrated in the PDP (which I never thought about so far). Ideally the mandatory guidelines in the spec should be applicable to all these different cases as they only describe different logical aggregations of code. So far I encountered the first two cases only and the spec supports both cases without posing any inconsistent requirements. The questions you mentioned are of course valid but address the scenario of chains of XACML Context Handlers. From my point of view, the core XACML spec should only address the handling of  XACML authorization requests and responses. The mapping of the application domain specifics to and from XACML  authorization requests and responses should be out of scope – as far as possible. This aspect points out another advantage of triggering the obligation handling in the context Handler. Assume e.g. that the XACML Context Handler and the PEP do not speak XACML. Transforming XACML obligations into another language might be the source of various problems and might further imply the risk of loosing interoperability (assume e.g. that you agreed on certain types of XACML obligations like e.g. rewrite-obligations in an use case specific XACML profile).   Best regards Jan   Siemens AG Corporate Technology Corporate Research and Technologies CT T DE IT1 Otto-Hahn-Ring 6 81739 Munich, Germany Tel.: +49 89 636-40612 Fax: +49 89 636-48000 mailto:jan.herrmann@siemens.com Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 Important notice: This e-mail and any attachment thereof contain corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank you.       Von: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] Im Auftrag von Erik Rissanen Gesendet: Dienstag, 28. Februar 2012 11:23 An: xacml@lists.oasis-open.org Betreff: Re: [xacml] AW: Issue #4: Context Handler - Proposal   Hi Jan, I think adding obligation handling to the PDP side would be a too big change to the current architecture at this point. It opens up questions such as whether obligations which were processed by the PDP, should they be sent to the PEP as well? If not, is that safe? If so, should the PEP know which ones were already handled? Just a couple from the top of my head. Best regards, Erik On 2012-02-27 10:22, Herrmann, Jan wrote: Hi Ray, all,   I like your edits and I think that they point out the flexibilities of XACML Context Handlers’ behavior. I would even go one step further and add some text blocks in these sentences, that highlight the option, that Context Handlers can also call Obligation Handlers. I have seen many use cases/requirements where XACML Context Handlers need to call Obligation Handlers to discharge the obligations included in an XACML authorization decision. Note that in these scenarios it was not possible/appropriate to discharge the obligations in the PEP (assuming that the Context Handler is not included in the PEP), as the Obligations had an effect on the representation of intercepted Web Service messages included in the XACML authorization decision request (which is only available in the Context Handler and not in the PEP).   Some background information on these use cases: The underlying requirement of these use cases is to enforce rewrite effects on intercepted Web Service requests (or responses). Enforcing rewrite effects is needed in cases where you need to apply access restrictions on intercepted Web Service requests that shall e.g. limit read requests to certain objects (e.g. rewrite the query “select * from person” to the authorized query “select * from person WHERE person.id = dereferenced-subject-id-attr ”). The concepts behind this is a more general and DBMS independent form of what can e.g. be done through Oracle’s VPD mechanism. The attached word document describes the details how to use the XACML obligation mechanism to achieve a XACML policy controlled rewriting of intercepted Web Service messages. Feel free to contact me if you need further explanations. One more note: a very similar approach can be taken to generate sub-requests that will be forwarded to the PIP and tell him how to retrieve more data in order to avoid/solve indeterminate responses.   Best regards Jan   PS: regrets that I can only irregularly attend the teleconferences but they take place during our family dinner time.   Siemens AG Corporate Technology Corporate Research and Technologies CT T DE IT1 Otto-Hahn-Ring 6 81739 Munich, Germany Tel.: +49 89 636-40612 Fax: +49 89 636-48000 mailto:jan.herrmann@siemens.com Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Peter Loescher, Chairman, President and Chief Executive Officer; Roland Busch, Brigitte Ederer, Klaus Helmrich, Joe Kaeser, Barbara Kux, Hermann Requardt, Siegfried Russwurm, Peter Y. Solmssen, Michael Suess; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 Important notice: This e-mail and any attachment thereof contain corporate proprietary information. If you have received it by mistake, please notify us immediately by reply e-mail and delete this e-mail and its attachments from your system. Thank you.       Von: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] Im Auftrag von remon.sinnema@emc.com Gesendet: Freitag , 24. Februar 2012 16:31 An: xacml@lists.oasis-open.org Betreff: [xacml] Issue #4: Context Handler - Proposal   All,   Current text 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   Proposal Context handler The system entity that converts decision requests in the native request format to the XACML canonical form , coordinates with Policy Information Points to add attribute values to the request context, and converts authorization decisions in the XACML canonical form to the native response format.     Current text 474 4. The context handler constructs an XACML request context and sends it to the PDP.   Proposal 4. The context handler constructs an XACML request context , optionally adds attributes, and sends it to the PDP.     Current text 3280 7.3.5 Attribute Retrieval 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.   Proposal 7.3.5 Attribute Retrieval The PDP SHALL request the values of attributes in the request context from the context handler. The context handler MAY also add attributes to the request context without the PDP requesting them. The PDP SHALL reference the attributes as if they were in a physical request context document, but the context handler is responsible for obtaining and supplying the requested values by whatever means it deems appropriate , including by retrieving them from one or more Policy Information Points .     Thanks, Ray     --------------------------------------------------------------------- To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xacml-help@lists.oasis-open.org  


  • 8.  RE: Issue #4: Context Handler - Proposal

    Posted 02-27-2012 21:07
    I agree with these changes.   I would also add under 7.3.5 Attribute Retrieval something like:   “Regardless of any dynamic modifications of the request context during policy evaluation, the PDP SHALL behave as if each bag of attribute values is fully populated in the context before it is first tested, and is thereafter immutable during evaluation. (That is, every subsequent test of that attribute shall use the same bag of values that was initially tested.)”   This seems like an obvious requirement, but I don’t see anything in the spec that requires a conformant PDP to act this way. It’s even hard to imagine such an ill-behaved context handler, but if it were especially lazy and there were many attribute sources (perhaps even different sources could contribute to the same multi-valued attribute), it is not out of the question.   Note that this statement does not impose any particular evaluation order on the policy rules, allowing for optimized policy rewrites. Nor does it rule out highly optimized attribute acquisition strategies, such as determining early in the evaluation what subset of attributes it might need and not asking for any others.   Regards, --Paul   From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of remon.sinnema@emc.com Sent: Friday, 24 February, 2012 09:31 To: xacml@lists.oasis-open.org Subject: [xacml] Issue #4: Context Handler - Proposal   All,   Current text 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   Proposal Context handler The system entity that converts decision requests in the native request format to the XACML canonical form , coordinates with Policy Information Points to add attribute values to the request context, and converts authorization decisions in the XACML canonical form to the native response format.     Current text 474 4. The context handler constructs an XACML request context and sends it to the PDP.   Proposal 4. The context handler constructs an XACML request context , optionally adds attributes, and sends it to the PDP.     Current text 3280 7.3.5 Attribute Retrieval 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.   Proposal 7.3.5 Attribute Retrieval The PDP SHALL request the values of attributes in the request context from the context handler. The context handler MAY also add attributes to the request context without the PDP requesting them. The PDP SHALL reference the attributes as if they were in a physical request context document, but the context handler is responsible for obtaining and supplying the requested values by whatever means it deems appropriate , including by retrieving them from one or more Policy Information Points .     Thanks, Ray  


  • 9.  Re: [xacml] RE: Issue #4: Context Handler - Proposal

    Posted 02-28-2012 10:15
    Hi, I think Ray's and Paul's proposals are good. Best regards, Erik On 2012-02-27 22:06, Tyson, Paul H wrote: I agree with these changes.   I would also add under 7.3.5 Attribute Retrieval something like:   “Regardless of any dynamic modifications of the request context during policy evaluation, the PDP SHALL behave as if each bag of attribute values is fully populated in the context before it is first tested, and is thereafter immutable during evaluation. (That is, every subsequent test of that attribute shall use the same bag of values that was initially tested.)”   This seems like an obvious requirement, but I don’t see anything in the spec that requires a conformant PDP to act this way. It’s even hard to imagine such an ill-behaved context handler, but if it were especially lazy and there were many attribute sources (perhaps even different sources could contribute to the same multi-valued attribute), it is not out of the question.   Note that this statement does not impose any particular evaluation order on the policy rules, allowing for optimized policy rewrites. Nor does it rule out highly optimized attribute acquisition strategies, such as determining early in the evaluation what subset of attributes it might need and not asking for any others.   Regards, --Paul   From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of remon.sinnema@emc.com Sent: Friday, 24 February, 2012 09:31 To: xacml@lists.oasis-open.org Subject: [xacml] Issue #4: Context Handler - Proposal   All,   Current text 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   Proposal Context handler The system entity that converts decision requests in the native request format to the XACML canonical form , coordinates with Policy Information Points to add attribute values to the request context, and converts authorization decisions in the XACML canonical form to the native response format.     Current text 474 4. The context handler constructs an XACML request context and sends it to the PDP.   Proposal 4. The context handler constructs an XACML request context , optionally adds attributes, and sends it to the PDP.     Current text 3280 7.3.5 Attribute Retrieval 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.   Proposal 7.3.5 Attribute Retrieval The PDP SHALL request the values of attributes in the request context from the context handler. The context handler MAY also add attributes to the request context without the PDP requesting them. The PDP SHALL reference the attributes as if they were in a physical request context document, but the context handler is responsible for obtaining and supplying the requested values by whatever means it deems appropriate , including by retrieving them from one or more Policy Information Points .     Thanks, Ray