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 <> 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: 

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