New Issue#66: XACML-Core 2.0,3.0 Missing attributes may be underspecified

I have added the following issue to the issues list:


    http://wiki.oasis-open.org/xacml/IssuesList


The point of the issue (below) is not to identify trivialities with the
example, but

to use the example as a basis for some general comments more toward

end of the issue description. It seemed to me that using the example

as context would be an effective way to raise the somewhat complex

issues/concerns that are the main point here. (I will be happy to

re-edit the issue if that makes sense after people have had a

chance to look at it).


    Thanks,

    Rich


66. Missing
attributes may be underspecified
I did a somewhat detailed analysis of "Example two" in the core spec
from the point of view of understanding how fine grained authorization
(fga) (applying resource attrs to az decision) was implemented and came
across a number of items that I think need to be addressed especially
in potential interoperability situations. I will put all in one issue
initially, we can decide if it needs to be broken out later. 
1. line 1090-91 describing ResourceContent. In both the core
spec and the sample messages, the ResourceContent contains the
following: 

  <ResourceContent>
    
      <md:record
xmlns:md="urn:med:example:schemas:record"
        
          xsi:schemaLocation="urn:med:example:schemas:record 
http:www.med.example.com/schemas/record.xsd"> 
        
        
          <md:patient>
            
              <md:patientDoB>1992-03-21</md:patientDoB>
<md:patient-number>555555</md:patient-number> 
            
</md:patient> 
        
</md:record> 
    
</ResourceContent>
<Attribute AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
    DataType="xs:string">
    
      <AttributeValue>
        
          //med.example.com/records/bart-simpson.xml#
xmlns(md=
http:www.med.example.com/schemas/record.xsd)
xpointer(/md:record/md:patient/md:patientDoB) 
        
</AttributeValue>
      
    
</Attribute> 

While I recognize that the example itself is not intended to be
perfect, it provides a convenient context for raising the following
questions/issues, especially wrt fga. 

  
    If this is a first request from a PEP, why is the PEP supplying
patient-number on line 1056? This looks like a required attr to
evaluate Rule 1 (line 1141), if the requestor is the patient, but this
example the requestor is the physician. 
    
      
        The physician-id is supplied in the request (line 1044), but
the only rule it appears in is rule 3 (line 1522). This rule only
allows "write" access (line 1507), so I expect this request would
probably fail as it is currently set up. i.e. we would need to add a
"read" action to rule 3 or add a physician-id test to rule 1. 
      
    
  


  
    b. Assuming the above request fails, let's consider what might
be done. There was a "read" request issued (line 1072), so that would
mean that rule 1 (line 1182), rule 2 (line 1347), or rule 4 (line 1668)
could be applied. 
  

Rule 1 requires a Subject attribute patient-number (line 1134) to
match the patient-number in the requested resource record (line 1141).
Presumably a <MissingAttributeDetail>
could be returned, somehow identifying these 2 attributes to the PEP. 
Rule 2 requires a patientDoB resource attr (line 1297), a
parent-guardian-id subject attr (line 1363), and a parentGuardianId
resource attr (line 1371). Similarly a <MissingAttributeDetail>
could be returned requesting these. 

  
    Assuming this to be the case, one question I have is how does
the <MissingAttributesDetail>
tell the PEP whether the attributes that are missing should be
resubmitted as part of the Subject or as part of the Resource? This
info is provided in the Request from the xml structure, however, the
<MissingAttributeDetail>
does not have equivalent structure to make such distinctions. 
  

The above is intended just to give an example of questions that
occur for this particular example, but it is my opinion that it is
symptomatic of a general problem of how PEPs are supposed to know how
to construct the proper RequestContext necessary, in general,
for complex scenarios that require substantive fga attrs. 
In these more complex fga scenarios it is likely that <MissingAttributeDetail>
will be typically needed to collect all the required attributes.
Therefore, I believe some more robust mechanisms, possibly using MissingAttributeDetail
as a good starting point will be needed to adequately define operation
in this area. 
In this context as well, it is likely that xpaths are probably not
the way to go since they are only applicable to certain types of
resources (xml-based) and those resource structures are likely to
change in time, and these changes should not percolate into the
enterprise Policy arena. Therefore, mechanisms such as vocabularies
should be recommended usage here with the PEP being responsible for
mapping the vocabulary item to the particular resource physical access
path such as the xpath. 
CHAMPION: Rich 
Status: OPEN