OASIS eXtensible Access Control Markup Language (XACML) TC

Paul, About http://wiki.oasis-open.org/xacml/XACMLandRDF "XACML and RDF" "2. Add provisions in the request/response syntax to identify resources, subjects, and actions by URI alone." According to the 3.0 core spec (lines 2418-2419), attributes are identified by all of category, attributeId, data type, and issuer (if present). I'm assuming there were good reasons to include category et al? In practice, I don't think I've seen any attributeId reused across categories. Is anyone actually doing that? "3. Extend the policy language to test ontological conditions such as subclass membership and class relations." What extensions do you think are necessary to support such features? "Attributes/properties of what?" The Document example rule matches any document, but in practice one would often want to grant access to a limited set of documents. I think we need to some semantic definitions on attribute *values* to handle this. That seems to be the case for hierarchical actions as well. Another example where that would be helpful is with hierarchical roles. A policy may grant access to 'employee', but the request may specify 'manager' as the value for the role-id attribute. The ontology should be able to define that 'manager' implies 'employee'. The RBAC profile allows us to specify such a role hierarchy, but not very elegantly IMHO, since the permission PolicySets "must be stored in the policy repository in such a way that they can never be used as the initial policy for an XACML PDP" (lines 160-161). Defining the role hierarchy as an ontology, and specifying some machinery in the context handler to process ontologies could improve the RBAC profile. "RDF for attribute metadata" "We don't want to force the PEP to include type="Document" and type="SpecialDocument". So the first thing the PIP does is to discover all the additional types entailed from the initial request context." According to Figure 1 of the core 3.0 spec (lines 475-478), the PIP is asked for attribute values *after* the PDP decides it needs them. What in the Document/SpecialDocument example would make the PDP request attribute values from the PIP? Or did you mean the context handler? Thanks, Ray

Hi Ray, >
Original Message----- > From: remon.sinnema@emc.com [ mailto:remon.sinnema@emc.com ] > Sent: Thursday, 01 December, 2011 03:33 > To: Tyson, Paul H > Cc: xacml@lists.oasis-open.org > Subject: XACML & RDF > > Paul, > > About http://wiki.oasis-open.org/xacml/XACMLandRDF > > > "XACML and RDF" > > "2. Add provisions in the request/response syntax to identify > resources, subjects, and actions by URI alone." > > According to the 3.0 core spec (lines 2418-2419), attributes are > identified by all of category, attributeId, data type, and issuer (if > present). I'm assuming there were good reasons to include category et > al? In practice, I don't think I've seen any attributeId reused across > categories. Is anyone actually doing that? Quadruple-keyed attributes is a different issue than what I was talking about. I was suggesting that we should provide a means to identify subjects and resources by *name* (URI) instead of by attribute values. So I could say "the resource is < http://example.com/docs/Document1 >" instead of "I'm thinking of a resource, and the URI of the resource is ' http://example.com/docs/Document1 '". Referring to things by their URI is a fundamental idiom of the semantic web. We don't say "the document whose URI is ' http://example.com/docs/Document1 ' was created by a person whose name is 'John Doe'. We say (in turtle): '< http://example.com/docs/Document1 > dc:creator "John Doe".'. (Well, actually, it's more complicated than that because of the way Dublin Core terms are defined.) The point is that the document URI is the grammatical subject in this statement. In fact, it's cumbersome to say in RDF, "the document whose URI is ...". You would have to make up a property, like 'hasURI' or something, but then you have converted essence to attribute and lost some of your expressive capability. That is one option for doing it in XACML, but I'm suggesting we adopt a nicer idiom. > > > "3. Extend the policy language to test ontological conditions such as > subclass membership and class relations." > > What extensions do you think are necessary to support such features? I haven't thought it all out. For writing the tests in a Condition or Match element, we can use rdf:type and rdfs:subClassOf as attribute values. However, this presumes some knowledge of an ontology that defines the classes that these predicates refer to. So we need some sort of ontology import mechanism, perhaps by naming the required ontologies (by URI) at the top level of Policy or PolicySet. These ontologies then would be available in the request context. > > > "Attributes/properties of what?" > > The Document example rule matches any document, but in practice one > would often want to grant access to a limited set of documents. I think > we need to some semantic definitions on attribute *values* to handle > this. That seems to be the case for hierarchical actions as well. I'm not quite sure what you mean here. There is a difference between granting access to a class of documents versus granting access to any particular document, and there should be different rules in these cases. XACML makes it easy to confound these cases because policy writers often think in terms of classes of resources and subjects. But requests are for individual resources: a *particular* marketing document, not *all* marketing documents. The rule might say "if the subject is in the marketing department, and the resource is a marketing document, then permit". But the request does not ask "can a person in the marketing department see all marketing documents?", nor could this policy respond to such a request (except by iterating over the population of marketing documents). To respond directly to a request like this, the rule would have to say "if the subject is in the marketing department, and the resource is *the class consisting of all marketing documents*, then permit". But XACML is usually implemented in order to make fine-grained access control decisions that cannot be handled easily by ACL or RBAC. The Target and Condition elements of XACML can be thought of as defining codependent classes of subjects, resources, and actions. If the request represents a set comprising at most one each *individual* subject, resource, and action that are in those classes, the rule is effective. > > Another example where that would be helpful is with hierarchical roles. > A policy may grant access to 'employee', but the request may specify > 'manager' as the value for the role-id attribute. The ontology should > be able to define that 'manager' implies 'employee'. The RBAC profile > allows us to specify such a role hierarchy, but not very elegantly > IMHO, since the permission PolicySets "must be stored in the policy > repository in such a way that they can never be used as the initial > policy for an XACML PDP" (lines 160-161). Defining the role hierarchy > as an ontology, and specifying some machinery in the context handler to > process ontologies could improve the RBAC profile. I haven't analyzed this. I think RBAC is a bit ontologically muddled to start with, so I'm not sure it's profitable to try to build much on top of it. > > > "RDF for attribute metadata" > > "We don't want to force the PEP to include type="Document" and > type="SpecialDocument". So the first thing the PIP does is to discover > all the additional types entailed from the initial request context." > > According to Figure 1 of the core 3.0 spec (lines 475-478), the PIP is > asked for attribute values *after* the PDP decides it needs them. What > in the Document/SpecialDocument example would make the PDP request > attribute values from the PIP? Or did you mean the context handler? Yes, the context handler would have to take on the semantic duties of entailment and reasoning. Regards, --Paul

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? Thanks, Ray

Ray, I don't think that a REP would add any value to the spec. The context handler already has all the capability to do this. Best regards, Erik On 2011-12-05 15:37, remon.sinnema@emc.com wrote: 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? Thanks, Ray --------------------------------------------------------------------- To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org For additional commands, e-mail: xacml-help@lists.oasis-open.org

Erik, >
Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On > Behalf Of Erik Rissanen > Sent: Wednesday, December 14, 2011 9:10 AM > To: xacml@lists.oasis-open.org > Subject: Re: [xacml] RE: Context Handler > > Ray, > > I don't think that a REP would add any value to the spec. The context > handler already has all the capability to do this. The value would be that we identify an extension point in the architecture, like is done with the PIP. For instance, I use this extension point to support hierarchical actions. It would also be the place to add semantic entailment. Secondly, separating the REP out of the context handler would better define what the context handler should and shouldn't do, because that's currently a little vague. Thanks, Ray

Ray, To add hierarchical actions or semantic entailment, you can provide this through a PIP in the architecture. Why would you need to change anything? Best regards, Erik On 2011-12-19 10:40, remon.sinnema@emc.com wrote: Erik,
Original Message----- From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Erik Rissanen Sent: Wednesday, December 14, 2011 9:10 AM To: xacml@lists.oasis-open.org Subject: Re: [xacml] RE: Context Handler Ray, I don't think that a REP would add any value to the spec. The context handler already has all the capability to do this. The value would be that we identify an extension point in the architecture, like is done with the PIP. For instance, I use this extension point to support hierarchical actions. It would also be the place to add semantic entailment. Secondly, separating the REP out of the context handler would better define what the context handler should and shouldn't do, because that's currently a little vague. Thanks, Ray

Erik, >
Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On > Behalf Of Erik Rissanen > Sent: Monday, December 19, 2011 11:08 AM > To: Sinnema, Remon > Cc: xacml@lists.oasis-open.org > Subject: Re: [xacml] RE: Context Handler > > To add hierarchical actions or semantic entailment, you can provide this > through a PIP in the architecture. Why would you need to change anything? Semantic entailment can *not* be done through a PIP (see the email thread Paul and I exchanged on this subject), and I'm sure that there are other examples like that. Thanks, Ray

Hi Ray, I did not understand that. As far as I can see, when the PDP needs the "type" attribute, it can ask a PIP to provide it. The PIP has all attributes of the request available as key values. How is this different from a REP? The available information seems to be the same in either case. What did I not get? Best regards, Erik On 2011-12-19 11:43, remon.sinnema@emc.com wrote: Erik,
Original Message----- From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Erik Rissanen Sent: Monday, December 19, 2011 11:08 AM To: Sinnema, Remon Cc: xacml@lists.oasis-open.org Subject: Re: [xacml] RE: Context Handler To add hierarchical actions or semantic entailment, you can provide this through a PIP in the architecture. Why would you need to change anything? Semantic entailment can *not* be done through a PIP (see the email thread Paul and I exchanged on this subject), and I'm sure that there are other examples like that. Thanks, Ray

Erik, >
Original Message----- > From: Erik Rissanen [ mailto:erik@axiomatics.com ] > Sent: Monday, December 19, 2011 2:59 PM > To: Sinnema, Remon > Cc: xacml@lists.oasis-open.org > Subject: Re: [xacml] RE: Context Handler > > Hi Ray, > > I did not understand that. As far as I can see, when the PDP needs the > "type" attribute, it can ask a PIP to provide it. The PIP has all > attributes of the request available as key values. How is this > different > from a REP? The available information seems to be the same in either > case. What did I not get? In Paul's example, the ontology is such that SpecialDocument is a type of Document, so any rule matching on type=Document should also match on type=SpecialDocument. Now assume there is a single rule that matches on type=Document, and that the PEP supplies type=SpecialDocument. The PDP will then see the type attribute with value SpecialDocument, and will conclude it isn't applicable. Since the request contains the type attribute, there is nothing that will make the PDP ask the PIP for more information. A REP, however, operates *before* the request is sent to the PDP and therefore doesn't suffer from the same problem. It can inspect the ontology, add type=Document based on the supplied type=SpecialDocument, and the PDP will happily match the rule. Does that make sense? Thanks, Ray

Hi Ray, Ok, I understand, but I would say that this is a flaw in the implementation in this case. Just because the PEP provides one value for an attribute does not mean that a PIP should not be able to augment it with more values. There are many attributes which may have some values provided by a PEP and others by a PIP. For instance, a user may login with a token which has a user group, but a PIP could provide more groups from an external directory. Best regards, Erik On 2011-12-19 15:24, remon.sinnema@emc.com wrote: Erik,
Original Message----- From: Erik Rissanen [ mailto:erik@axiomatics.com ] Sent: Monday, December 19, 2011 2:59 PM To: Sinnema, Remon Cc: xacml@lists.oasis-open.org Subject: Re: [xacml] RE: Context Handler Hi Ray, I did not understand that. As far as I can see, when the PDP needs the "type" attribute, it can ask a PIP to provide it. The PIP has all attributes of the request available as key values. How is this different from a REP? The available information seems to be the same in either case. What did I not get? In Paul's example, the ontology is such that SpecialDocument is a type of Document, so any rule matching on type=Document should also match on type=SpecialDocument. Now assume there is a single rule that matches on type=Document, and that the PEP supplies type=SpecialDocument. The PDP will then see the type attribute with value SpecialDocument, and will conclude it isn't applicable. Since the request contains the type attribute, there is nothing that will make the PDP ask the PIP for more information. A REP, however, operates *before* the request is sent to the PDP and therefore doesn't suffer from the same problem. It can inspect the ontology, add type=Document based on the supplied type=SpecialDocument, and the PDP will happily match the rule. Does that make sense? Thanks, Ray

Erik, >
Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On > Behalf Of Erik Rissanen > Sent: Monday, December 19, 2011 4:02 PM > To: Sinnema, Remon > Cc: xacml@lists.oasis-open.org > Subject: Re: [xacml] RE: Context Handler > > Hi Ray, > > Ok, I understand, but I would say that this is a flaw in the > implementation in this case. I don't think the spec is clear enough in this area. It doesn't define what exactly a PIP can and cannot do. If we make the description of the PIP clearer so that it explicitly can do more than retrieve values for attributes that are missing from the request, then I agree we don't need a REP. However, I do wonder based on what information the PDP will decide to ask the PIP for more attribute values. Or do you propose the PDP always reaches out to all PIPs? Thanks, Ray

On 2011-12-19 16:11, remon.sinnema@emc.com wrote: Erik,
Original Message----- From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Erik Rissanen Sent: Monday, December 19, 2011 4:02 PM To: Sinnema, Remon Cc: xacml@lists.oasis-open.org Subject: Re: [xacml] RE: Context Handler Hi Ray, Ok, I understand, but I would say that this is a flaw in the implementation in this case. I don't think the spec is clear enough in this area. It doesn't define what exactly a PIP can and cannot do. If we make the description of the PIP clearer so that it explicitly can do more than retrieve values for attributes that are missing from the request, then I agree we don't need a REP. However, I do wonder based on what information the PDP will decide to ask the PIP for more attribute values. Or do you propose the PDP always reaches out to all PIPs? Thanks, Ray Ray, This is easy to control through the context handler setup/config. A context handler which is configured to always invoke a particular PIP is equivalent to deploying a "REP". The XACML architecture is intended to be an abstract view of the big picture and applicable to many diverse environments, so it intentionally leaves out many details. Making it more detailed would clutter the architecture or make it less generally applicable. There are so many things it could cover, like caching, pre-fetching, communication protocols, when to invoke which PIP, etc. I prefer to keep it simple in the spec. Best regards, Erik

Erik, >
Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On > Behalf Of Erik Rissanen > Sent: Monday, December 19, 2011 4:48 PM > To: Sinnema, Remon > Cc: xacml@lists.oasis-open.org > Subject: Re: [xacml] RE: Context Handler > > Ray, > > This is easy to control through the context handler setup/config. A > context handler which is configured to always invoke a particular PIP > is > equivalent to deploying a "REP". > > The XACML architecture is intended to be an abstract view of the big > picture and applicable to many diverse environments, so it > intentionally > leaves out many details. Making it more detailed would clutter the > architecture or make it less generally applicable. There are so many > things it could cover, like caching, pre-fetching, communication > protocols, when to invoke which PIP, etc. I prefer to keep it simple in > the spec. I agree 100% that the spec should not prescribe (or even mention) any implementation details like caching. However, I don't think that whether a PIP can only retrieve values for missing attributes or can also do other things is an implementation detail. If I'm relying on the PDP to call my PIP, but it doesn't, then my solution doesn't work. Thus this issue is a matter of importance for interoperability and as such I feel that the spec should address it. Thanks, Ray

Hi Ray, What would be the concrete change you would like to make in this case? Could you make a proposal? Also, could you handle it by the PIPs, rather than introducing an entirely new component like the REP? Best regards, Erik On 2011-12-19 17:41, remon.sinnema@emc.com wrote: Erik,
Original Message----- From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On Behalf Of Erik Rissanen Sent: Monday, December 19, 2011 4:48 PM To: Sinnema, Remon Cc: xacml@lists.oasis-open.org Subject: Re: [xacml] RE: Context Handler Ray, This is easy to control through the context handler setup/config. A context handler which is configured to always invoke a particular PIP is equivalent to deploying a "REP". The XACML architecture is intended to be an abstract view of the big picture and applicable to many diverse environments, so it intentionally leaves out many details. Making it more detailed would clutter the architecture or make it less generally applicable. There are so many things it could cover, like caching, pre-fetching, communication protocols, when to invoke which PIP, etc. I prefer to keep it simple in the spec. I agree 100% that the spec should not prescribe (or even mention) any implementation details like caching. However, I don't think that whether a PIP can only retrieve values for missing attributes or can also do other things is an implementation detail. If I'm relying on the PDP to call my PIP, but it doesn't, then my solution doesn't work. Thus this issue is a matter of importance for interoperability and as such I feel that the spec should address it. Thanks, Ray

Erik, >
Original Message----- > From: Erik Rissanen [ mailto:erik@axiomatics.com ] > Sent: Tuesday, December 20, 2011 9:53 AM > To: Sinnema, Remon > Cc: xacml@lists.oasis-open.org > Subject: Re: [xacml] RE: Context Handler > > Hi Ray, > > What would be the concrete change you would like to make in this case? > Could you make a proposal? Also, could you handle it by the PIPs, > rather > than introducing an entirely new component like the REP? Section 3.1 "The data-flow model" should be changed to make it possible for the Context Handler to invoke the PIP before sending the request to the PDP. Section 7.3.5 "Attribute Retrieval" states that the PDP requests attributes from the Context Handler. This should be changed to make it clear that the Context Handler can also give the PDP attributes it didn't request. Thanks, Ray

of possible interest to the TC http://blog.aniltj.org/2011/12/privacy-preserving-attribute.html#disqus_thread

I agree partially with both Erik and Ray. I don't think a new architectural component is required. "Context handler" is sufficiently underspecified to allow any desired level of semantic entailment. I don't think semantic entailment should be "just another PIP", although it could probably be implemented that way. The important point is that there must be some way for the policy author to specify the ontology that governs the world for which he is writing policies. And, developers of PEPs and PIPs must know about this ontology. Currently, policy authors and component developers only need to agree on a common attribute vocabulary. For semantic XACML, they need furthermore to agree on an ontology that defines classes and relationships among them. This agreement could happen "out of band" (as currently happens with the attribute vocabulary), or it could be specified in a XACML syntax instance (perhaps by naming an ontology in a Policy or PolicySet). Regards, --Paul >
Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On > Behalf Of Erik Rissanen > Sent: Monday, 19 December, 2011 07:59 > To: remon.sinnema@emc.com > Cc: xacml@lists.oasis-open.org > Subject: Re: [xacml] RE: Context Handler > > Hi Ray, > > I did not understand that. As far as I can see, when the PDP needs the > "type" attribute, it can ask a PIP to provide it. The PIP has all > attributes of the request available as key values. How is this > different > from a REP? The available information seems to be the same in either > case. What did I not get? > > Best regards, > Erik > > On 2011-12-19 11:43, remon.sinnema@emc.com wrote: > > Erik, > > > > > >>
Original Message----- > >> From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] > On > >> Behalf Of Erik Rissanen > >> Sent: Monday, December 19, 2011 11:08 AM > >> To: Sinnema, Remon > >> Cc: xacml@lists.oasis-open.org > >> Subject: Re: [xacml] RE: Context Handler > >> > >> To add hierarchical actions or semantic entailment, you can provide > this > >> through a PIP in the architecture. Why would you need to change > anything? > > Semantic entailment can *not* be done through a PIP (see the email > thread Paul and I exchanged on this subject), and I'm sure that there > are other examples like that. > > > > Thanks, > > Ray > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: xacml-unsubscribe@lists.oasis-open.org > For additional commands, e-mail: xacml-help@lists.oasis-open.org

Paul, Erik, >
Original Message----- > From: xacml@lists.oasis-open.org [ mailto:xacml@lists.oasis-open.org ] On > Behalf Of Tyson, Paul H > Sent: Monday, December 19, 2011 3:25 PM > To: Erik Rissanen; Sinnema, Remon > Cc: xacml@lists.oasis-open.org > Subject: RE: [xacml] RE: Context Handler > > "Context handler" is sufficiently underspecified to allow any desired level of > semantic entailment. Exactly. My proposal is to extract the REP out of the context handler to get rid of this under-specification. This will also make it clearer that it is an extension point, just like the PIP. Thanks, Ray