OASIS eXtensible Access Control Markup Language (XACML) TC

Minutes of XACML TC Meeting 28 May 2015 I. Roll Call Attendees Crystal Hayes Richard Hill Steven Legg Rich Levinson Hal Lockhart (Co-Chair) Bill Parducci (Co-Chair) Remon Sinnema Martin Smith John Tolbert Quorum achieved (90% per Kavi) Approval of Minutes Vote on approval of 28 May 2015 TC meeting minutes APPROVED: UNANIMOUS CONSENT II. Administrivia New OASIS Discussion List: IAM Framework TC Hal: [Provided a review of discussion list mechanics.] In this case it centers on exploring consistent Identity Management across implementations. Rich: In reading the email I was not available to get a good feel for the topic, however I was able to find some archived documents that provided a good overview. Martin: There is a list archive active now with comments and attachments that have draft submissions as well as a summary from the original conference call. John: This seems like a great way to encourage the adoption of ABAC based security. Martin: There are a numbers of levels of complexity associated with a variety of business use cases. The goal is to provide a framework by which potential users can map the appropriate solution onto their needs, thereby lowering perceived risk to implementation. Hal: There are ways to handle this now technically, however there are many ideas being introduced constantly so it seems like this effort should carefully consider its boundaries early on to avoid being too ambitious. Richard: What are the planned next steps? Martin: Probably have a second conference call to review the next draft proposal. Timing information will be posted to the discussion list. I will ask Oasis (Chet) if a broader announcement is possible. XACML v3.0 Related and Nested Entities Profile Version 1.0 Hal: Steven has posted an updated version. Per the note these are editorial only. Steven: There is an issue with Attribute functionality that is not addressed in the Core specification regarding how responses are handled when the AttributeCategory has no element matching the request. There are two possible solutions: return NULL or bulle up an Indeterminate. I will send an email to the list to initiate discussion on how to handle this. Hal: Historically we do what the Xpath spec says and XACML proceeds from there. Steven: In this case we reach this before the XPath expression is invoked. Martin: I reviewed this and was wondering where does the data come from? Steven: This would be issued from the PIP. In practical terms, this is likely some sort of database. Martin: Yes, but in real terms the PIP is a virtual construct. Have you considered how to explicitly collect the data? Hal: This is a common issue, not limited to this Profile. Martin: Right. Practically speaking this would come from corporate directory of some sort, etc. Hal: In the OpenAZ project we have discussed the sources of Attribute Retreiver and the list has been quite short. LDAP, ActiveDirectory, etc. however how this is dealt with consistently is still very much in flux. Rich: The scope of Attributes realistically is defined by the Policies. The information source is logically determined a priori to Policy editing being made available. Martin: Agree. I was wondering if there were some common assumptions made in this area. Revised version posted: https://lists.oasis-open.org/archives/xacml/201506/msg00001.html Description of chgs to the new version: https://lists.oasis-open.org/archives/xacml/201506/msg00002.html III. Issues No new issues introduced on list

This isn't a request to update the minutes but rather a followup to Martin's question. On 12/06/2015 8:39 AM, Bill Parducci wrote: Minutes of XACML TC Meeting 28 May 2015 Martin: I reviewed this and was wondering where does the data come from? An unstated assumption of the Entities Profile is that the data model for an application comes first. By "data model" I mean a description of the types of entities that are available and the attributes that they hold. It could be simple prose as in the opening paragraphs of Section 7.2 of the profile or it could be as formal as an entity-relationship diagram. It could be internal documentation for a custom development or written up in a standardized profile. For a custom development, the data model needs to be devised with an understanding of what data are available. A standardization profile can only be supported if the required data are going to be available. Once the data model is established, the PEPs, context handler and/or PIPs can be configured (ideally) or engineered to provide the necessary entities and attributes from the available data sources. Finally, the policy writers write their policies in conformance with the established data model. There is no expectation that policy writers can use whatever data model comes to mind and that somehow the context handler and PIPs will know where to get the necessary data from. Regards, Steven

Steven-- Thanks for the follow-up. I was not intending to question whether or not some data series would be available, but rather just inquiring as to whether, in constructing the profile, had made any background assumptions about how and from where the data would be gathered. You answered that during the call by pointing to the PIP (i.e., that your starting point was there vs. original data sources.) This is entirely reasonable given the scope of the XACML TC; I admit I was thinking about how the relatively complex data models your profile could manipulate might be generated and kept acceptably current by the overall multi-organizational IAM ecosystem. From that same ecosystem perspective, I'd like to comment on your follow-up explication about how data availability should constrain policy-makers. First, I roughly equate "policy-makers" in your follow-up to "analysts generating queries against the data model in the PIP." Of course queries are limited to what's in the data model. In the short run. In the longer run, if the business need of the analyst's employer can't be satisfied by the available data, then either efforts will be made to add to the available data or the analyst's project will be abandoned. This is as applicable to access-control as it is to breakfast-cereal marketing. In access-control, the requirements of law, regulation, contracts and other sources of info-access policy imply a data model. Of course there may be compromises where a proxy or indicator data element may be an acceptable substitute for an "ideal" datum, but there is a tipping point where the lack of acceptable data makes a whole ABAC project not worth the effort. And I would assert that today the lack of the right (in terms of evidence for policy conformance) data significantly limits the value of implementing ABAC, at least for multi-organizational information sharing use cases and use cases in highly regulated sectors like government and health care. Again, I realize these considerations are outside the scope of the XACML TC, but until ecosystem issues like attribute data sources are addressed the demand for ABAC systems and XACML-based products will remain constrained. Regards, Martin .      On Fri, Jun 12, 2015 at 12:31 AM, Steven Legg < steven.legg@viewds.com > wrote: This isn't a request to update the minutes but rather a followup to Martin's question. On 12/06/2015 8:39 AM, Bill Parducci wrote: Minutes of XACML TC Meeting 28 May 2015     Martin:      I reviewed this and was wondering where does the data come from? An unstated assumption of the Entities Profile is that the data model for an application comes first. By "data model" I mean a description of the types of entities that are available and the attributes that they hold. It could be simple prose as in the opening paragraphs of Section 7.2 of the profile or it could be as formal as an entity-relationship diagram. It could be internal documentation for a custom development or written up in a standardized profile. For a custom development, the data model needs to be devised with an understanding of what data are available. A standardization profile can only be supported if the required data are going to be available. Once the data model is established, the PEPs, context handler and/or PIPs can be configured (ideally) or engineered to provide the necessary entities and attributes from the available data sources. Finally, the policy writers write their policies in conformance with the established data model. There is no expectation that policy writers can use whatever data model comes to mind and that somehow the context handler and PIPs will know where to get the necessary data from. Regards, Steven --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Martin F Smith, Principal BFC Consulting, LLC McLean, Va 22102 703 506-0159 703 389-3224 mobile

Martin An interesting post,  I have some comments and follow ups on it. I do not believe that your assessment is totally valid: acceptable data makes a whole ABAC project not worth the effort. And I would assert that today the lack of the right (in terms of evidence for policy conformance) data significantly limits the value of implementing ABAC, at least for multi-organizational information sharing use cases and use cases in highly regulated sectors like government and health care. You are looking at this in trying to get back to basic sources of data. If however, you look at any problem space as having defined players in an access control space,  and that these players have specific attributes,  then how those attributes are determined becomes much less important.  Even in highly regulated industries, what really is important is the value of the attribute,  not how it was determined.  In these industries, the problem is actually cleaner, since the actual policies and attributes are defined by the governance. As long as the attribute value can be communicated, with teh appropriate assurance, then a policy decision can be made using it. The Data Model becomes a lower layer service, that ultimately becomes merely an implementation detail.  It should not impact the access control evaluation, which deals with attribute interaction.  I guess this is what Steven was getting to when he says policy makers need to constrain, not to the point of where and how a data item is maintained,  but how it can be communicated and correctly interpreted by the bigger ecosystem Allan Simplify Email: Email Charter Allan Foster - ForgeRock VP APJ CTO Location: Singapore, SG p: +65 9353 8304 email: allan.foster@forgerock.com www: www.forgerock.com www: www.forgerock.org blogs: blogs.forgerock.com/GuruAllan On 6/12/15 9:53 PM, Martin Smith wrote: Steven-- Thanks for the follow-up. I was not intending to question whether or not some data series would be available, but rather just inquiring as to whether, in constructing the profile, had made any background assumptions about how and from where the data would be gathered. You answered that during the call by pointing to the PIP (i.e., that your starting point was there vs. original data sources.) This is entirely reasonable given the scope of the XACML TC; I admit I was thinking about how the relatively complex data models your profile could manipulate might be generated and kept acceptably current by the overall multi-organizational IAM ecosystem. From that same ecosystem perspective, I'd like to comment on your follow-up explication about how data availability should constrain policy-makers. First, I roughly equate policy-makers in your follow-up to analysts generating queries against the data model in the PIP. Of course queries are limited to what's in the data model. In the short run. In the longer run, if the business need of the analyst's employer can't be satisfied by the available data, then either efforts will be made to add to the available data or the analyst's project will be abandoned. This is as applicable to access-control as it is to breakfast-cereal marketing. In access-control, the requirements of law, regulation, contracts and other sources of info-access policy imply a data model. Of course there may be compromises where a proxy or indicator data element may be an acceptable substitute for an ideal datum, but there is a tipping point where the lack of acceptable data makes a whole ABAC project not worth the effort. And I would assert that today the lack of the right (in terms of evidence for policy conformance) data significantly limits the value of implementing ABAC, at least for multi-organizational information sharing use cases and use cases in highly regulated sectors like government and health care. Again, I realize these considerations are outside the scope of the XACML TC, but until ecosystem issues like attribute data sources are addressed the demand for ABAC systems and XACML-based products will remain constrained. Regards, Martin .      On Fri, Jun 12, 2015 at 12:31 AM, Steven Legg < steven.legg@viewds.com > wrote: This isn't a request to update the minutes but rather a followup to Martin's question. On 12/06/2015 8:39 AM, Bill Parducci wrote: Minutes of XACML TC Meeting 28 May 2015     Martin:      I reviewed this and was wondering where does the data come from? An unstated assumption of the Entities Profile is that the data model for an application comes first. By data model I mean a description of the types of entities that are available and the attributes that they hold. It could be simple prose as in the opening paragraphs of Section 7.2 of the profile or it could be as formal as an entity-relationship diagram. It could be internal documentation for a custom development or written up in a standardized profile. For a custom development, the data model needs to be devised with an understanding of what data are available. A standardization profile can only be supported if the required data are going to be available. Once the data model is established, the PEPs, context handler and/or PIPs can be configured (ideally) or engineered to provide the necessary entities and attributes from the available data sources. Finally, the policy writers write their policies in conformance with the established data model. There is no expectation that policy writers can use whatever data model comes to mind and that somehow the context handler and PIPs will know where to get the necessary data from. Regards, Steven --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Martin F Smith, Principal BFC Consulting, LLC McLean, Va 22102 703 506-0159 703 389-3224 mobile

Alan-- I am not sure I understood all your points, but I agree that the PDP executing XACML should not generally be concerned with the provenance of the data elements it's using. Assessment of the validity and quality, etc.  of a data element (attribute) and the decision by a relying party to accept it from a given source are "design time" (vs. "run time" or "transaction time") issues. These decisions are also presumably implemented in most cases at the PIP, and not in XACML code, and so are really not in scope for the XACML TC.  Regarding your statement that "   In these [highly regulated] industries, the problem is actually cleaner, since the actual policies and attributes are defined by the governance", my experience (in US Federal government mostly) is different. In principle, the problem is "cleaner" in that you at least have something written down to start with. Also, laws and regs tend to apply across many organizations (vs contracts, for example, or one corporation's policies.) This provides a basis for attribute re-use and federation of attributes, and consequently makes it worthwhile in principle to spend resources to maintain and make available applicable attribute data.  However, laws and regs are usually written at the "concept" level, and not at the level of a data element in a specified database. This gap between legal concept and actual data can be very big in some important cases: consider the concepts of "probable cause" or "authorized purpose" or "need to know." Furthermore,even when there is a clear mapping of legal concept to real-world data, it can be surprisingly difficult to get the cooperation of the custodian of that data--I have had multiple personal experiences with this. Again, all this is outside the scope of the XACML TC, but the issues are important for the overall ecosystem, and thus for realization of the potential value of the TC's work.   I'd be happy to pursue this discussion but don't want to clutter this TC's e-mail archive with non-germane traffic. Feel free to contact me directly. Thanks for your thoughts, and best regards, Martin   On Fri, Jun 12, 2015 at 9:40 PM, Allan Foster < allan.foster@forgerock.com > wrote: Martin An interesting post,  I have some comments and follow ups on it. I do not believe that your assessment is totally valid: acceptable data makes a whole ABAC project not worth the effort. And I would assert that today the lack of the right (in terms of evidence for policy conformance) data significantly limits the value of implementing ABAC, at least for multi-organizational information sharing use cases and use cases in highly regulated sectors like government and health care. You are looking at this in trying to get back to basic sources of data. If however, you look at any problem space as having defined players in an access control space,  and that these players have specific attributes,  then how those attributes are determined becomes much less important.  Even in highly regulated industries, what really is important is the value of the attribute,  not how it was determined.  In these industries, the problem is actually cleaner, since the actual policies and attributes are defined by the governance. As long as the attribute value can be communicated, with teh appropriate assurance, then a policy decision can be made using it. The Data Model becomes a lower layer service, that ultimately becomes merely an implementation detail.  It should not impact the access control evaluation, which deals with attribute interaction.  I guess this is what Steven was getting to when he says policy makers need to constrain, not to the point of where and how a data item is maintained,  but how it can be communicated and correctly interpreted by the bigger ecosystem Allan Simplify Email: Email Charter Allan Foster - ForgeRock VP APJ CTO Location: Singapore, SG p: +65 9353 8304 email: allan.foster@forgerock.com www: www.forgerock.com www: www.forgerock.org blogs: blogs.forgerock.com/GuruAllan On 6/12/15 9:53 PM, Martin Smith wrote: Steven-- Thanks for the follow-up. I was not intending to question whether or not some data series would be available, but rather just inquiring as to whether, in constructing the profile, had made any background assumptions about how and from where the data would be gathered. You answered that during the call by pointing to the PIP (i.e., that your starting point was there vs. original data sources.) This is entirely reasonable given the scope of the XACML TC; I admit I was thinking about how the relatively complex data models your profile could manipulate might be generated and kept acceptably current by the overall multi-organizational IAM ecosystem. From that same ecosystem perspective, I'd like to comment on your follow-up explication about how data availability should constrain policy-makers. First, I roughly equate "policy-makers" in your follow-up to "analysts generating queries against the data model in the PIP." Of course queries are limited to what's in the data model. In the short run. In the longer run, if the business need of the analyst's employer can't be satisfied by the available data, then either efforts will be made to add to the available data or the analyst's project will be abandoned. This is as applicable to access-control as it is to breakfast-cereal marketing. In access-control, the requirements of law, regulation, contracts and other sources of info-access policy imply a data model. Of course there may be compromises where a proxy or indicator data element may be an acceptable substitute for an "ideal" datum, but there is a tipping point where the lack of acceptable data makes a whole ABAC project not worth the effort. And I would assert that today the lack of the right (in terms of evidence for policy conformance) data significantly limits the value of implementing ABAC, at least for multi-organizational information sharing use cases and use cases in highly regulated sectors like government and health care. Again, I realize these considerations are outside the scope of the XACML TC, but until ecosystem issues like attribute data sources are addressed the demand for ABAC systems and XACML-based products will remain constrained. Regards, Martin .      On Fri, Jun 12, 2015 at 12:31 AM, Steven Legg < steven.legg@viewds.com > wrote: This isn't a request to update the minutes but rather a followup to Martin's question. On 12/06/2015 8:39 AM, Bill Parducci wrote: Minutes of XACML TC Meeting 28 May 2015     Martin:      I reviewed this and was wondering where does the data come from? An unstated assumption of the Entities Profile is that the data model for an application comes first. By "data model" I mean a description of the types of entities that are available and the attributes that they hold. It could be simple prose as in the opening paragraphs of Section 7.2 of the profile or it could be as formal as an entity-relationship diagram. It could be internal documentation for a custom development or written up in a standardized profile. For a custom development, the data model needs to be devised with an understanding of what data are available. A standardization profile can only be supported if the required data are going to be available. Once the data model is established, the PEPs, context handler and/or PIPs can be configured (ideally) or engineered to provide the necessary entities and attributes from the available data sources. Finally, the policy writers write their policies in conformance with the established data model. There is no expectation that policy writers can use whatever data model comes to mind and that somehow the context handler and PIPs will know where to get the necessary data from. Regards, Steven --------------------------------------------------------------------- To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at: https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php -- Martin F Smith, Principal BFC Consulting, LLC McLean, Va 22102 703 506-0159 703 389-3224 mobile -- Martin F Smith, Principal BFC Consulting, LLC McLean, Va 22102 703 506-0159 703 389-3224 mobile