OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [xacml] Where does the data come from ?


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

ForgeRock Logo 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]