OASIS eXtensible Access Control Markup Language (XACML) TC

In his discussion with the TC last week Bill Fisher of NIST/NCCOE said he was looking for activities NCCOE might take to advance the implementation of ABAC in the private sector. He also described several of the past and present projects, including the ABAC Building Blocks publication ( https://nccoe.nist.gov/sites/default/files/documents/NCCoE_ABAC_Building_Block_v2_final.pdf )  and the more recent NIST 1800-3 ABAC Practice Guide (  https://nccoe.nist.gov/library/nist-sp-1800-3-attribute-based-access-control-practice-guide ).  The XACML TC submitted comments on the latter, as you may recall. Although it came up only tangentially in the discussion last week, the NCCOE's program is based on some diagnosis of why ABAC adoption has been disappointingly slow.  I believe Bill mentioned NIST's perception that one obstacle is lack of detailed guidance on how to integrate and configure ABAC components; hence the Practice Guide. He also mentioned being interested in identifying technology or product/tool gaps.  Perhaps it would be useful for us to take a step back from ideas on "what to do" and have a look at "what's the problem." In other words, maybe we should consider developing and documenting a common understanding of ABAC implementation obstacles and their relative importance.  This would then provide a sound basis for NIST/NCCOE (and others, including ABAC product vendors) to focus on activities that address the obstacles.  So, here's a "starter set" of obstacles (or categories of obstacles) for your consideration:  1.  The elephant in the room:  what is the business case for ABAC? Some possible answers below, but in all cases I'd say there's a lack of well-documented (preferably with some before-and-after metrics) "case studies" of how ABAC has delivered one or more business benefits. (A brief nod to Axiomatics who seem to be trying to address this with their recent series of WebEx events.) Possible business benefits:      a.  Ability to put more sensitive information on-line (within the enterprise but especially for sharing with customers and business partners)     b.  Compliance: demonstrated conformance with data-protection regulations like Sarbanes-Oxley, various jurisdictions' privacy regulations, HIPAA, etc.     c.  Privacy and security:  not the same as "compliance", which is process- vs outcome- oriented     d.  Operating cost savings     e.  "Agility" -- ability to implement access-policy changes quickly and consistently across the enterprise or other relevant environment. Also ability to reach a targeted user demographic quickly when a new information service is fielded.  2.  Lack of understanding or engagement among enterprise "policy authorities" (CFOs, Counsels, CPOs, CISOs) on developing "digital-ready" policies in their respective areas of responsibility. "Digital-ready" means policy expressed in natural-language but unambiguous _expression_ (i.e., "if-then" statements.)   3.  Lack of incentives for operators of "authoritative attribute" data sources to make their attribute data available for digital access-control use.   4.  Lack of standards for how resource attributes (data tags, etc) can be identified and accessed (by a "context handler.')  5.  Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a "law-enforcement officer" or a "physician", or "PII" or a "medical record"?)  6.  Unapproachability of raw XACML (which means that implementer technical resources are dependent on vendor-specific tooling for policy/rule writing.) 7.  Lack of a widely recognized or standardized logical architecture (with testable component functions and interfaces) for full ABAC, resulting in "customized" solutions that are therefore very expensive and also non-interoperable across different organizations.   Regards, Martin          -- Martin F Smith, Principal BFC Consulting, LLC McLean, Va 22102 703 506-0159 703 389-3224 mobile

I agree with most of this, Martin. Thanks for putting it all in one place.   ---- The main point I disagree with you on is:   5.  Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a "law-enforcement officer" or a "physician", or "PII" or a "medical record"?)    IMHO this is not going to happen. Any AC scheme that has this as a precondition is not going to be adopted. For the foreseeable future, policies are local with rare exceptions.   ----- To your elephant in the room, I suggest that to answer this question we have to be very specific about what we are comparing XACML or ABAC to. Many people implicitly compare it to permissions or ACLs or even RBAC. However, far and away the most common form of access control is program code written in a Turing-complete language and embedded within the application.   In this context the greatest benefit is simply to be able to identify what the policy is, as distinct from various aspects of the application logic or UI.   Hal   From: Martin Smith [mailto:bfc.mclean@gmail.com] Sent: Sunday, April 03, 2016 12:59 PM To: XACML TC Subject: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)   In his discussion with the TC last week Bill Fisher of NIST/NCCOE said he was looking for activities NCCOE might take to advance the implementation of ABAC in the private sector. He also described several of the past and present projects, including the ABAC Building Blocks publication ( https://nccoe.nist.gov/sites/default/files/documents/NCCoE_ABAC_Building_Block_v2_final.pdf )  and the more recent NIST 1800-3 ABAC Practice Guide (  https://nccoe.nist.gov/library/nist-sp-1800-3-attribute-based-access-control-practice-guide ).  The XACML TC submitted comments on the latter, as you may recall.   Although it came up only tangentially in the discussion last week, the NCCOE's program is based on some diagnosis of why ABAC adoption has been disappointingly slow.  I believe Bill mentioned NIST's perception that one obstacle is lack of detailed guidance on how to integrate and configure ABAC components; hence the Practice Guide. He also mentioned being interested in identifying technology or product/tool gaps.    Perhaps it would be useful for us to take a step back from ideas on "what to do" and have a look at "what's the problem." In other words, maybe we should consider developing and documenting a common understanding of ABAC implementation obstacles and their relative importance.  This would then provide a sound basis for NIST/NCCOE (and others, including ABAC product vendors) to focus on activities that address the obstacles.    So, here's a "starter set" of obstacles (or categories of obstacles) for your consideration:    1.  The elephant in the room:  what is the business case for ABAC? Some possible answers below, but in all cases I'd say there's a lack of well-documented (preferably with some before-and-after metrics) "case studies" of how ABAC has delivered one or more business benefits. (A brief nod to Axiomatics who seem to be trying to address this with their recent series of WebEx events.) Possible business benefits:      a.  Ability to put more sensitive information on-line (within the enterprise but especially for sharing with customers and business partners)     b.  Compliance: demonstrated conformance with data-protection regulations like Sarbanes-Oxley, various jurisdictions' privacy regulations, HIPAA, etc.     c.  Privacy and security:  not the same as "compliance", which is process- vs outcome- oriented     d.  Operating cost savings     e.  "Agility" -- ability to implement access-policy changes quickly and consistently across the enterprise or other relevant environment. Also ability to reach a targeted user demographic quickly when a new information service is fielded.  2.  Lack of understanding or engagement among enterprise "policy authorities" (CFOs, Counsels, CPOs, CISOs) on developing "digital-ready" policies in their respective areas of responsibility. "Digital-ready" means policy expressed in natural-language but unambiguous _expression_ (i.e., "if-then" statements.)   3.  Lack of incentives for operators of "authoritative attribute" data sources to make their attribute data available for digital access-control use.   4.  Lack of standards for how resource attributes (data tags, etc) can be identified and accessed (by a "context handler.')  5.  Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a "law-enforcement officer" or a "physician", or "PII" or a "medical record"?)  6.  Unapproachability of raw XACML (which means that implementer technical resources are dependent on vendor-specific tooling for policy/rule writing.) 7.  Lack of a widely recognized or standardized logical architecture (with testable component functions and interfaces) for full ABAC, resulting in "customized" solutions that are therefore very expensive and also non-interoperable across different organizations.     Regards,   Martin                                -- Martin F Smith, Principal BFC Consulting, LLC McLean, Va 22102 703 506-0159 703 389-3224 mobile

Hal--thanks for the response.  Regarding the semantic standards issue, I think we're going to have to agree to disagree. I will agree you have a lot of company in the view you express, but I'd make three points:  1.  There is considerable movement to develop semantic standards, not for everything but to support specific transactions within a business community of interest. Both OASIS' UBL and the National Information Exchange Model NIEM) have recently come out with revisions. For NIEM the the approach is to delegate coordination of standardization of specific exchanges (so-called IEPDs)  to domain coordinators within broad sectors such as health, law-enforcement, emergency management, defense. etc. 2.  Many--perhaps most--information-access policies are not local. This is the biggest change from the traditional view where a local database admin keeps a list of names on an ACL, according to his own best lights. But many policies are based in law that has wide application, which means that the legal concepts (like the ones I mentioned -- law-enforcement officer, physician) are also widely applicable. In this increasingly compliance-oriented world, having standardized concepts for required info access policies should be of significant value to enterprise officers responsible for documenting compliance.  3.  Most important I think is that a lot of the potential value of ABAC will be left on the table if the model cannot be extended outside a single enterprise. And cross-organizational sharing of sensitive information requires semantic "interoperability" between business partners, which may start as bilateral agreement on terms but has to be broader than that (but not universal) if it is to scale. The XACML TC's IP and Export Control profiles are examples of standardizing attribute semantics for two specific classes of transactions.  Regards, Martin   On Thu, Apr 14, 2016 at 1:50 PM, Hal Lockhart < hal.lockhart@oracle.com > wrote: I agree with most of this, Martin. Thanks for putting it all in one place.   ---- The main point I disagree with you on is:   5.  Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a "law-enforcement officer" or a "physician", or "PII" or a "medical record"?)    IMHO this is not going to happen. Any AC scheme that has this as a precondition is not going to be adopted. For the foreseeable future, policies are local with rare exceptions.   ----- To your elephant in the room, I suggest that to answer this question we have to be very specific about what we are comparing XACML or ABAC to. Many people implicitly compare it to permissions or ACLs or even RBAC. However, far and away the most common form of access control is program code written in a Turing-complete language and embedded within the application.   In this context the greatest benefit is simply to be able to identify what the policy is, as distinct from various aspects of the application logic or UI.   Hal   From: Martin Smith [mailto: bfc.mclean@gmail.com ] Sent: Sunday, April 03, 2016 12:59 PM To: XACML TC Subject: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)   In his discussion with the TC last week Bill Fisher of NIST/NCCOE said he was looking for activities NCCOE might take to advance the implementation of ABAC in the private sector. He also described several of the past and present projects, including the ABAC Building Blocks publication ( https://nccoe.nist.gov/sites/default/files/documents/NCCoE_ABAC_Building_Block_v2_final.pdf )  and the more recent NIST 1800-3 ABAC Practice Guide (  https://nccoe.nist.gov/library/nist-sp-1800-3-attribute-based-access-control-practice-guide ).  The XACML TC submitted comments on the latter, as you may recall.   Although it came up only tangentially in the discussion last week, the NCCOE's program is based on some diagnosis of why ABAC adoption has been disappointingly slow.  I believe Bill mentioned NIST's perception that one obstacle is lack of detailed guidance on how to integrate and configure ABAC components; hence the Practice Guide. He also mentioned being interested in identifying technology or product/tool gaps.    Perhaps it would be useful for us to take a step back from ideas on "what to do" and have a look at "what's the problem." In other words, maybe we should consider developing and documenting a common understanding of ABAC implementation obstacles and their relative importance.  This would then provide a sound basis for NIST/NCCOE (and others, including ABAC product vendors) to focus on activities that address the obstacles.    So, here's a "starter set" of obstacles (or categories of obstacles) for your consideration:    1.  The elephant in the room:  what is the business case for ABAC? Some possible answers below, but in all cases I'd say there's a lack of well-documented (preferably with some before-and-after metrics) "case studies" of how ABAC has delivered one or more business benefits. (A brief nod to Axiomatics who seem to be trying to address this with their recent series of WebEx events.) Possible business benefits:      a.  Ability to put more sensitive information on-line (within the enterprise but especially for sharing with customers and business partners)     b.  Compliance: demonstrated conformance with data-protection regulations like Sarbanes-Oxley, various jurisdictions' privacy regulations, HIPAA, etc.     c.  Privacy and security:  not the same as "compliance", which is process- vs outcome- oriented     d.  Operating cost savings     e.  "Agility" -- ability to implement access-policy changes quickly and consistently across the enterprise or other relevant environment. Also ability to reach a targeted user demographic quickly when a new information service is fielded.  2.  Lack of understanding or engagement among enterprise "policy authorities" (CFOs, Counsels, CPOs, CISOs) on developing "digital-ready" policies in their respective areas of responsibility. "Digital-ready" means policy expressed in natural-language but unambiguous _expression_ (i.e., "if-then" statements.)   3.  Lack of incentives for operators of "authoritative attribute" data sources to make their attribute data available for digital access-control use.   4.  Lack of standards for how resource attributes (data tags, etc) can be identified and accessed (by a "context handler.')  5.  Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a "law-enforcement officer" or a "physician", or "PII" or a "medical record"?)  6.  Unapproachability of raw XACML (which means that implementer technical resources are dependent on vendor-specific tooling for policy/rule writing.) 7.  Lack of a widely recognized or standardized logical architecture (with testable component functions and interfaces) for full ABAC, resulting in "customized" solutions that are therefore very expensive and also non-interoperable across different organizations.     Regards,   Martin                                -- 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

From the Healthcare perspective I agree with Martin.  The vast majority of our work nowadays involves interoperability, standards, standard vocabulary.  The most current healthcare models for ABAC have involved standards for labeling including Implementation Guides, a Classification System, world-wide interoperable vocabulary, standards for Security and Privacy labeling services, Privacy protection services based on labeling etc. We have integrated traditional XACML with OAUTH and UMA for further expansion of business needs.   Biggest gap in XACML?  Inability within the standard to exchange obligations between organizations for the post receipt handling of labeled information.     John “Mike” Davis VHA Security Architect 760-632-0294       From: xacml@lists.oasis-open.org [mailto:xacml@lists.oasis-open.org] On Behalf Of Martin Smith Sent: Thursday, April 14, 2016 12:03 PM To: Hal Lockhart Cc: XACML TC Subject: [EXTERNAL] Re: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)   Hal--thanks for the response.    Regarding the semantic standards issue, I think we're going to have to agree to disagree. I will agree you have a lot of company in the view you express, but I'd make three points:    1.  There is considerable movement to develop semantic standards, not for everything but to support specific transactions within a business community of interest. Both OASIS' UBL and the National Information Exchange Model NIEM) have recently come out with revisions. For NIEM the the approach is to delegate coordination of standardization of specific exchanges (so-called IEPDs)  to domain coordinators within broad sectors such as health, law-enforcement, emergency management, defense. etc.   2.  Many--perhaps most--information-access policies are not local. This is the biggest change from the traditional view where a local database admin keeps a list of names on an ACL, according to his own best lights. But many policies are based in law that has wide application, which means that the legal concepts (like the ones I mentioned -- law-enforcement officer, physician) are also widely applicable. In this increasingly compliance-oriented world, having standardized concepts for required info access policies should be of significant value to enterprise officers responsible for documenting compliance.    3.  Most important I think is that a lot of the potential value of ABAC will be left on the table if the model cannot be extended outside a single enterprise. And cross-organizational sharing of sensitive information requires semantic "interoperability" between business partners, which may start as bilateral agreement on terms but has to be broader than that (but not universal) if it is to scale. The XACML TC's IP and Export Control profiles are examples of standardizing attribute semantics for two specific classes of transactions.    Regards,   Martin           On Thu, Apr 14, 2016 at 1:50 PM, Hal Lockhart < hal.lockhart@oracle.com > wrote: I agree with most of this, Martin. Thanks for putting it all in one place.   ---- The main point I disagree with you on is:   5.  Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a "law-enforcement officer" or a "physician", or "PII" or a "medical record"?)    IMHO this is not going to happen. Any AC scheme that has this as a precondition is not going to be adopted. For the foreseeable future, policies are local with rare exceptions.   ----- To your elephant in the room, I suggest that to answer this question we have to be very specific about what we are comparing XACML or ABAC to. Many people implicitly compare it to permissions or ACLs or even RBAC. However, far and away the most common form of access control is program code written in a Turing-complete language and embedded within the application.   In this context the greatest benefit is simply to be able to identify what the policy is, as distinct from various aspects of the application logic or UI.   Hal   From: Martin Smith [mailto: bfc.mclean@gmail.com ] Sent: Sunday, April 03, 2016 12:59 PM To: XACML TC Subject: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)   In his discussion with the TC last week Bill Fisher of NIST/NCCOE said he was looking for activities NCCOE might take to advance the implementation of ABAC in the private sector. He also described several of the past and present projects, including the ABAC Building Blocks publication ( https://nccoe.nist.gov/sites/default/files/documents/NCCoE_ABAC_Building_Block_v2_final.pdf )  and the more recent NIST 1800-3 ABAC Practice Guide (  https://nccoe.nist.gov/library/nist-sp-1800-3-attribute-based-access-control-practice-guide ).  The XACML TC submitted comments on the latter, as you may recall.   Although it came up only tangentially in the discussion last week, the NCCOE's program is based on some diagnosis of why ABAC adoption has been disappointingly slow.  I believe Bill mentioned NIST's perception that one obstacle is lack of detailed guidance on how to integrate and configure ABAC components; hence the Practice Guide. He also mentioned being interested in identifying technology or product/tool gaps.    Perhaps it would be useful for us to take a step back from ideas on "what to do" and have a look at "what's the problem." In other words, maybe we should consider developing and documenting a common understanding of ABAC implementation obstacles and their relative importance.  This would then provide a sound basis for NIST/NCCOE (and others, including ABAC product vendors) to focus on activities that address the obstacles.    So, here's a "starter set" of obstacles (or categories of obstacles) for your consideration:    1.  The elephant in the room:  what is the business case for ABAC? Some possible answers below, but in all cases I'd say there's a lack of well-documented (preferably with some before-and-after metrics) "case studies" of how ABAC has delivered one or more business benefits. (A brief nod to Axiomatics who seem to be trying to address this with their recent series of WebEx events.) Possible business benefits:      a.  Ability to put more sensitive information on-line (within the enterprise but especially for sharing with customers and business partners)     b.  Compliance: demonstrated conformance with data-protection regulations like Sarbanes-Oxley, various jurisdictions' privacy regulations, HIPAA, etc.     c.  Privacy and security:  not the same as "compliance", which is process- vs outcome- oriented     d.  Operating cost savings     e.  "Agility" -- ability to implement access-policy changes quickly and consistently across the enterprise or other relevant environment. Also ability to reach a targeted user demographic quickly when a new information service is fielded.  2.  Lack of understanding or engagement among enterprise "policy authorities" (CFOs, Counsels, CPOs, CISOs) on developing "digital-ready" policies in their respective areas of responsibility. "Digital-ready" means policy expressed in natural-language but unambiguous _expression_ (i.e., "if-then" statements.)   3.  Lack of incentives for operators of "authoritative attribute" data sources to make their attribute data available for digital access-control use.   4.  Lack of standards for how resource attributes (data tags, etc) can be identified and accessed (by a "context handler.')  5.  Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a "law-enforcement officer" or a "physician", or "PII" or a "medical record"?)  6.  Unapproachability of raw XACML (which means that implementer technical resources are dependent on vendor-specific tooling for policy/rule writing.) 7.  Lack of a widely recognized or standardized logical architecture (with testable component functions and interfaces) for full ABAC, resulting in "customized" solutions that are therefore very expensive and also non-interoperable across different organizations.     Regards,   Martin                                -- 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

Don’t get me wrong. I don’t disagree that semantic agreement would be very desirable. I am just saying that if it is considered a precondition to adoption, then adoption is never going to happen.   Hal   From: Martin Smith [mailto:bfc.mclean@gmail.com] Sent: Thursday, April 14, 2016 3:03 PM To: Hal Lockhart Cc: XACML TC Subject: Re: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)   Hal--thanks for the response.    Regarding the semantic standards issue, I think we're going to have to agree to disagree. I will agree you have a lot of company in the view you express, but I'd make three points:    1.  There is considerable movement to develop semantic standards, not for everything but to support specific transactions within a business community of interest. Both OASIS' UBL and the National Information Exchange Model NIEM) have recently come out with revisions. For NIEM the the approach is to delegate coordination of standardization of specific exchanges (so-called IEPDs)  to domain coordinators within broad sectors such as health, law-enforcement, emergency management, defense. etc.   2.  Many--perhaps most--information-access policies are not local. This is the biggest change from the traditional view where a local database admin keeps a list of names on an ACL, according to his own best lights. But many policies are based in law that has wide application, which means that the legal concepts (like the ones I mentioned -- law-enforcement officer, physician) are also widely applicable. In this increasingly compliance-oriented world, having standardized concepts for required info access policies should be of significant value to enterprise officers responsible for documenting compliance.    3.  Most important I think is that a lot of the potential value of ABAC will be left on the table if the model cannot be extended outside a single enterprise. And cross-organizational sharing of sensitive information requires semantic "interoperability" between business partners, which may start as bilateral agreement on terms but has to be broader than that (but not universal) if it is to scale. The XACML TC's IP and Export Control profiles are examples of standardizing attribute semantics for two specific classes of transactions.    Regards,   Martin           On Thu, Apr 14, 2016 at 1:50 PM, Hal Lockhart < hal.lockhart@oracle.com > wrote: I agree with most of this, Martin. Thanks for putting it all in one place.   ---- The main point I disagree with you on is:   5.  Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a "law-enforcement officer" or a "physician", or "PII" or a "medical record"?)    IMHO this is not going to happen. Any AC scheme that has this as a precondition is not going to be adopted. For the foreseeable future, policies are local with rare exceptions.   ----- To your elephant in the room, I suggest that to answer this question we have to be very specific about what we are comparing XACML or ABAC to. Many people implicitly compare it to permissions or ACLs or even RBAC. However, far and away the most common form of access control is program code written in a Turing-complete language and embedded within the application.   In this context the greatest benefit is simply to be able to identify what the policy is, as distinct from various aspects of the application logic or UI.   Hal   From: Martin Smith [mailto: bfc.mclean@gmail.com ] Sent: Sunday, April 03, 2016 12:59 PM To: XACML TC Subject: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)   In his discussion with the TC last week Bill Fisher of NIST/NCCOE said he was looking for activities NCCOE might take to advance the implementation of ABAC in the private sector. He also described several of the past and present projects, including the ABAC Building Blocks publication ( https://nccoe.nist.gov/sites/default/files/documents/NCCoE_ABAC_Building_Block_v2_final.pdf )  and the more recent NIST 1800-3 ABAC Practice Guide (  https://nccoe.nist.gov/library/nist-sp-1800-3-attribute-based-access-control-practice-guide ).  The XACML TC submitted comments on the latter, as you may recall.   Although it came up only tangentially in the discussion last week, the NCCOE's program is based on some diagnosis of why ABAC adoption has been disappointingly slow.  I believe Bill mentioned NIST's perception that one obstacle is lack of detailed guidance on how to integrate and configure ABAC components; hence the Practice Guide. He also mentioned being interested in identifying technology or product/tool gaps.    Perhaps it would be useful for us to take a step back from ideas on "what to do" and have a look at "what's the problem." In other words, maybe we should consider developing and documenting a common understanding of ABAC implementation obstacles and their relative importance.  This would then provide a sound basis for NIST/NCCOE (and others, including ABAC product vendors) to focus on activities that address the obstacles.    So, here's a "starter set" of obstacles (or categories of obstacles) for your consideration:    1.  The elephant in the room:  what is the business case for ABAC? Some possible answers below, but in all cases I'd say there's a lack of well-documented (preferably with some before-and-after metrics) "case studies" of how ABAC has delivered one or more business benefits. (A brief nod to Axiomatics who seem to be trying to address this with their recent series of WebEx events.) Possible business benefits:      a.  Ability to put more sensitive information on-line (within the enterprise but especially for sharing with customers and business partners)     b.  Compliance: demonstrated conformance with data-protection regulations like Sarbanes-Oxley, various jurisdictions' privacy regulations, HIPAA, etc.     c.  Privacy and security:  not the same as "compliance", which is process- vs outcome- oriented     d.  Operating cost savings     e.  "Agility" -- ability to implement access-policy changes quickly and consistently across the enterprise or other relevant environment. Also ability to reach a targeted user demographic quickly when a new information service is fielded.  2.  Lack of understanding or engagement among enterprise "policy authorities" (CFOs, Counsels, CPOs, CISOs) on developing "digital-ready" policies in their respective areas of responsibility. "Digital-ready" means policy expressed in natural-language but unambiguous _expression_ (i.e., "if-then" statements.)   3.  Lack of incentives for operators of "authoritative attribute" data sources to make their attribute data available for digital access-control use.   4.  Lack of standards for how resource attributes (data tags, etc) can be identified and accessed (by a "context handler.')  5.  Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a "law-enforcement officer" or a "physician", or "PII" or a "medical record"?)  6.  Unapproachability of raw XACML (which means that implementer technical resources are dependent on vendor-specific tooling for policy/rule writing.) 7.  Lack of a widely recognized or standardized logical architecture (with testable component functions and interfaces) for full ABAC, resulting in "customized" solutions that are therefore very expensive and also non-interoperable across different organizations.     Regards,   Martin                                -- 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

I think I pretty much agree w the general points that both Hal and Martin are making, but I think both are addressing somewhat different perspectives. Based on my own experience w OpenAz and other multi-domain endeavors, I have found that syntactic agreement can usually be obtained fairly readily, if all parties are co-operating, but semantic agreement can remain a roadblock for a long time, which from a policy perspective, imo, is a show-stopper because it makes no sense to have a common policy if people interpret the terms differently. Therefore, I think Martin's points 1 and 2 are compelling because they appear to represent real-world use cases, where semantic agreement, is, in fact, a primary requirement. Also, even though semantic agreement may be a theoretical objective, which can never, in fact, be truly reached (as for example, demonstrated every day on the US Supreme Court, where, ultimately what the law means is what 5 or more judges on court say that it means), at least having the notion of semantic agreement can point the way to a process for ultimately resolving disputes, where presumably the holder of the policy could bring it to the Supreme Court to determine if the holder's interpretation is correct. Also, Martin's point 3, about existing profiles of XACML, essentially performing this role, which I will accept at face value, not having thought about these profiles in that perspective before, may point a direction to augmenting ABAC w a procedure for nailing down semantic agreement on specific attributes that the cooperating parties can work with, while leaving other policies not covered by the profile in the current state of possible semantic ambiguity until someone is concerned enough to nail these down as well.   Thanks,   Rich On 4/28/2016 1:25 PM, Hal Lockhart wrote: Don’t get me wrong. I don’t disagree that semantic agreement would be very desirable. I am just saying that if it is considered a precondition to adoption, then adoption is never going to happen.   Hal   From: Martin Smith [ mailto:bfc.mclean@gmail.com ] Sent: Thursday, April 14, 2016 3:03 PM To: Hal Lockhart Cc: XACML TC Subject: Re: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)   Hal--thanks for the response.    Regarding the semantic standards issue, I think we're going to have to agree to disagree. I will agree you have a lot of company in the view you express, but I'd make three points:    1.  There is considerable movement to develop semantic standards, not for everything but to support specific transactions within a business community of interest. Both OASIS' UBL and the National Information Exchange Model NIEM) have recently come out with revisions. For NIEM the the approach is to delegate coordination of standardization of specific exchanges (so-called IEPDs)  to domain coordinators within broad sectors such as health, law-enforcement, emergency management, defense. etc.   2.  Many--perhaps most--information-access policies are not local. This is the biggest change from the traditional view where a local database admin keeps a list of names on an ACL, according to his own best lights. But many policies are based in law that has wide application, which means that the legal concepts (like the ones I mentioned -- law-enforcement officer, physician) are also widely applicable. In this increasingly compliance-oriented world, having standardized concepts for required info access policies should be of significant value to enterprise officers responsible for documenting compliance.    3.  Most important I think is that a lot of the potential value of ABAC will be left on the table if the model cannot be extended outside a single enterprise. And cross-organizational sharing of sensitive information requires semantic interoperability between business partners, which may start as bilateral agreement on terms but has to be broader than that (but not universal) if it is to scale. The XACML TC's IP and Export Control profiles are examples of standardizing attribute semantics for two specific classes of transactions.    Regards,   Martin           On Thu, Apr 14, 2016 at 1:50 PM, Hal Lockhart < hal.lockhart@oracle.com > wrote: I agree with most of this, Martin. Thanks for putting it all in one place.   ---- The main point I disagree with you on is:   5.  Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a law-enforcement officer or a physician , or PII or a medical record ?)    IMHO this is not going to happen. Any AC scheme that has this as a precondition is not going to be adopted. For the foreseeable future, policies are local with rare exceptions.   ----- To your elephant in the room, I suggest that to answer this question we have to be very specific about what we are comparing XACML or ABAC to. Many people implicitly compare it to permissions or ACLs or even RBAC. However, far and away the most common form of access control is program code written in a Turing-complete language and embedded within the application.   In this context the greatest benefit is simply to be able to identify what the policy is, as distinct from various aspects of the application logic or UI.   Hal   From: Martin Smith [mailto: bfc.mclean@gmail.com ] Sent: Sunday, April 03, 2016 12:59 PM To: XACML TC Subject: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption)   In his discussion with the TC last week Bill Fisher of NIST/NCCOE said he was looking for activities NCCOE might take to advance the implementation of ABAC in the private sector. He also described several of the past and present projects, including the ABAC Building Blocks publication ( https://nccoe.nist.gov/sites/default/files/documents/NCCoE_ABAC_Building_Block_v2_final.pdf )  and the more recent NIST 1800-3 ABAC Practice Guide (  https://nccoe.nist.gov/library/nist-sp-1800-3-attribute-based-access-control-practice-guide ).  The XACML TC submitted comments on the latter, as you may recall.   Although it came up only tangentially in the discussion last week, the NCCOE's program is based on some diagnosis of why ABAC adoption has been disappointingly slow.  I believe Bill mentioned NIST's perception that one obstacle is lack of detailed guidance on how to integrate and configure ABAC components; hence the Practice Guide. He also mentioned being interested in identifying technology or product/tool gaps.    Perhaps it would be useful for us to take a step back from ideas on what to do and have a look at what's the problem. In other words, maybe we should consider developing and documenting a common understanding of ABAC implementation obstacles and their relative importance.  This would then provide a sound basis for NIST/NCCOE (and others, including ABAC product vendors) to focus on activities that address the obstacles.    So, here's a starter set of obstacles (or categories of obstacles) for your consideration:    1.  The elephant in the room:  what is the business case for ABAC? Some possible answers below, but in all cases I'd say there's a lack of well-documented (preferably with some before-and-after metrics) case studies of how ABAC has delivered one or more business benefits. (A brief nod to Axiomatics who seem to be trying to address this with their recent series of WebEx events.) Possible business benefits:      a.  Ability to put more sensitive information on-line (within the enterprise but especially for sharing with customers and business partners)     b.  Compliance: demonstrated conformance with data-protection regulations like Sarbanes-Oxley, various jurisdictions' privacy regulations, HIPAA, etc.     c.  Privacy and security:  not the same as compliance , which is process- vs outcome- oriented     d.  Operating cost savings     e.   Agility -- ability to implement access-policy changes quickly and consistently across the enterprise or other relevant environment. Also ability to reach a targeted user demographic quickly when a new information service is fielded.  2.  Lack of understanding or engagement among enterprise policy authorities (CFOs, Counsels, CPOs, CISOs) on developing digital-ready policies in their respective areas of responsibility. Digital-ready means policy expressed in natural-language but unambiguous _expression_ (i.e., if-then statements.)   3.  Lack of incentives for operators of authoritative attribute data sources to make their attribute data available for digital access-control use.   4.  Lack of standards for how resource attributes (data tags, etc) can be identified and accessed (by a context handler.')  5.  Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a law-enforcement officer or a physician , or PII or a medical record ?)  6.  Unapproachability of raw XACML (which means that implementer technical resources are dependent on vendor-specific tooling for policy/rule writing.) 7.  Lack of a widely recognized or standardized logical architecture (with testable component functions and interfaces) for full ABAC, resulting in customized solutions that are therefore very expensive and also non-interoperable across different organizations.     Regards,   Martin                                -- 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

Hi Rich, On 29/04/2016 7:02 AM, rich levinson wrote: I think I pretty much agree w the general points that both Hal and Martin are making, but I think both are addressing somewhat different perspectives. Based on my own experience w OpenAz and other multi-domain endeavors, I have found that syntactic agreement can usually be obtained fairly readily, if all parties are co-operating, but semantic agreement can remain a roadblock for a long time, which from a policy perspective, imo, is a show-stopper because it makes no sense to have a common policy if people interpret the terms differently. I would say that it makes no sense to have a common attribute if people interpret the terms differently. Trying to shoehorn different concepts into the same attribute is a bad idea, but keep them as separate attributes and it is still possible to have a common policy because XACML provides the tools to do it, though it is not an ideal situation. For example, suppose ACME Corp. has a location attribute that uses town names and AJAX Inc. has a location attribute that uses post codes. It would be nice if ACME and AJAX could agree to standardize on one or the other, but failing that a policy writer can write expressions like: (acme-location=Melbourne or ajax-postcode=3000) to refer to a specific locality. This is a simple case, but XACML has many functions for non-trivial manipulation of attribute values. So semantic agreement is good to have, but it isn't an absolute requirement. To have a common policy, harmonization has to occur at some level. Best case is at the attribute sources. Worst case is at the policy writer. There are other levels in between. It occurs to me that the Attribute Authority idea I floated last year could be used to preprocess acme-location and ajax-postcode attributes coming from the PEP or the PIPs to generate a unified location attribute (using just town names, say) so that policy writers and auditors can believe there is semantic agreement though ACME and AJAX can't get their acts together. Regards, Steven Therefore, I think Martin's points 1 and 2 are compelling because they appear to represent real-world use cases, where semantic agreement, is, in fact, a primary requirement. Also, even though semantic agreement may be a theoretical objective, which can never, in fact, be truly reached (as for example, demonstrated every day on the US Supreme Court, where, ultimately what the law means is what 5 or more judges on court say that it means), at least having the notion of semantic agreement can point the way to a process for ultimately resolving disputes, where presumably the holder of the policy could bring it to the Supreme Court to determine if the holder's interpretation is correct. Also, Martin's point 3, about existing profiles of XACML, essentially performing this role, which I will accept at face value, not having thought about these profiles in that perspective before, may point a direction to "augmenting" ABAC w a procedure for nailing down semantic agreement on specific attributes that the cooperating parties can work with, while leaving other policies not covered by the profile in the current state of possible semantic ambiguity until someone is concerned enough to nail these down as well. Thanks, Rich On 4/28/2016 1:25 PM, Hal Lockhart wrote: Don’t get me wrong. I don’t disagree that semantic agreement would be very desirable. I am just saying that if it is considered a precondition to adoption, then adoption is never going to happen. Hal *From:*Martin Smith [ mailto:bfc.mclean@gmail.com ] *Sent:* Thursday, April 14, 2016 3:03 PM *To:* Hal Lockhart *Cc:* XACML TC *Subject:* Re: [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption) Hal--thanks for the response. Regarding the semantic standards issue, I think we're going to have to agree to disagree. I will agree you have a lot of company in the view you express, but I'd make three points: 1. There is considerable movement to develop semantic standards, not for everything but to support specific transactions within a business community of interest. Both OASIS' UBL and the National Information Exchange Model NIEM) have recently come out with revisions. For NIEM the the approach is to delegate coordination of standardization of specific exchanges (so-called IEPDs) to domain coordinators within broad sectors such as health, law-enforcement, emergency management, defense. etc. 2. Many--perhaps most--information-access policies are not local. This is the biggest change from the traditional view where a local database admin keeps a list of names on an ACL, according to his own best lights. But many policies are based in law that has wide application, which means that the legal concepts (like the ones I mentioned -- law-enforcement officer, physician) are also widely applicable. In this increasingly compliance-oriented world, having standardized concepts for required info access policies should be of significant value to enterprise officers responsible for documenting compliance. 3. Most important I think is that a lot of the potential value of ABAC will be left on the table if the model cannot be extended outside a single enterprise. And cross-organizational sharing of sensitive information requires semantic "interoperability" between business partners, which may start as bilateral agreement on terms but has to be broader than that (but not universal) if it is to scale. The XACML TC's IP and Export Control profiles are examples of standardizing attribute semantics for two specific classes of transactions. Regards, Martin On Thu, Apr 14, 2016 at 1:50 PM, Hal Lockhart <hal.lockhart@oracle.com < mailto:hal.lockhart@oracle.com >> wrote: I agree with most of this, Martin. Thanks for putting it all in one place. ---- The main point I disagree with you on is: 5. Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a "law-enforcement officer" or a "physician", or "PII" or a "medical record"?) IMHO this is not going to happen. Any AC scheme that has this as a precondition is not going to be adopted. For the foreseeable future, policies are local with rare exceptions. ----- To your elephant in the room, I suggest that to answer this question we have to be very specific about what we are comparing XACML or ABAC to. Many people implicitly compare it to permissions or ACLs or even RBAC. However, far and away the most common form of access control is program code written in a Turing-complete language and embedded within the application. In this context the greatest benefit is simply to be able to identify what the policy is, as distinct from various aspects of the application logic or UI. Hal *From:*Martin Smith [ mailto:bfc.mclean@gmail.com < mailto:bfc.mclean@gmail.com >] *Sent:* Sunday, April 03, 2016 12:59 PM *To:* XACML TC *Subject:* [xacml] NCCOE discussion and impediments (to XACML and ABAC adoption) In his discussion with the TC last week Bill Fisher of NIST/NCCOE said he was looking for activities NCCOE might take to advance the implementation of ABAC in the private sector. He also described several of the past and present projects, including the ABAC Building Blocks publication ( < https://nccoe.nist.gov/sites/default/files/documents/NCCoE_ABAC_Building_Block_v2_final.pdf > https://nccoe.nist.gov/sites/default/files/documents/NCCoE_ABAC_Building_Block_v2_final.pdf ) and the more recent NIST 1800-3 ABAC Practice Guide ( https://nccoe.nist.gov/library/nist-sp-1800-3-attribute-based-access-control-practice-guide ). The XACML TC submitted comments on the latter, as you may recall. Although it came up only tangentially in the discussion last week, the NCCOE's program is based on some diagnosis of why ABAC adoption has been disappointingly slow. I believe Bill mentioned NIST's perception that one obstacle is lack of detailed guidance on how to integrate and configure ABAC components; hence the Practice Guide. He also mentioned being interested in identifying technology or product/tool gaps. Perhaps it would be useful for us to take a step back from ideas on "what to do" and have a look at "what's the problem." In other words, maybe we should consider developing and documenting a common understanding of ABAC implementation obstacles and their relative importance. This would then provide a sound basis for NIST/NCCOE (and others, including ABAC product vendors) to focus on activities that address the obstacles. So, here's a "starter set" of obstacles (or categories of obstacles) for your consideration: 1. The elephant in the room: what is the business case for ABAC? Some possible answers below, but in all cases I'd say there's a lack of well-documented (preferably with some before-and-after metrics) "case studies" of how ABAC has delivered one or more business benefits. (A brief nod to Axiomatics who seem to be trying to address this with their recent series of WebEx events.) Possible business benefits: a. Ability to put more sensitive information on-line (within the enterprise but especially for sharing with customers and business partners) b. Compliance: demonstrated conformance with data-protection regulations like Sarbanes-Oxley, various jurisdictions' privacy regulations, HIPAA, etc. c. Privacy and security: not the same as "compliance", which is process- vs outcome- oriented d. Operating cost savings e. "Agility" -- ability to implement access-policy changes quickly and consistently across the enterprise or other relevant environment. Also ability to reach a targeted user demographic quickly when a new information service is fielded. 2. Lack of understanding or engagement among enterprise "policy authorities" (CFOs, Counsels, CPOs, CISOs) on developing "digital-ready" policies in their respective areas of responsibility. "Digital-ready" means policy expressed in natural-language but unambiguous expression (i.e., "if-then" statements.) 3. Lack of incentives for operators of "authoritative attribute" data sources to make their attribute data available for digital access-control use. 4. Lack of standards for how resource attributes (data tags, etc) can be identified and accessed (by a "context handler.') 5. Lack of institutions or processes for developing cross-organizations semantic standards (e.g., what's a "law-enforcement officer" or a "physician", or "PII" or a "medical record"?) 6. Unapproachability of raw XACML (which means that implementer technical resources are dependent on vendor-specific tooling for policy/rule writing.) 7. Lack of a widely recognized or standardized logical architecture (with testable component functions and interfaces) for full ABAC, resulting in "customized" solutions that are therefore very expensive and also non-interoperable across different organizations. Regards, Martin -- *Martin F Smith, Principal* *BFC Consulting, LLC* McLean, Va 22102 703 506-0159 <tel:703%20506-0159> 703 389-3224 <tel:703%20389-3224> mobile -- *Martin F Smith, Principal* *BFC Consulting, LLC* McLean, Va 22102 703 506-0159 703 389-3224 mobile