RE: [xacml] CD-1 issue #10: denied access to internal nodes in hierarchy

["Tyson, Paul H" <PTyson@bellhelicopter.textron.com>]

I agree that no change is required, but for a different reason.  The
issue is, what does an application do with an XML instance after getting
decisions?  That is not in the domain of XACML.  In this case, the
application wants simply to delete denied nodes of a document, which of
course can violate the schema.  There are other solutions to this
problem that have nothing to do with XACML.

It is important for many other applications to have complete
independence of decisions for all nodes of a hierarchy.  XACML should
make no presumption about the meaning of hierarchy for determining
access.

--Paul

> -----Original Message-----
> From: Erik Rissanen [mailto:erik@axiomatics.com] 
> Sent: Friday, September 11, 2009 08:11
> To: XACML TC
> Subject: [xacml] CD-1 issue #10: denied access to internal 
> nodes in hierarchy
> 
> The issue number refers to the XLS-sheet found in this email:
> http://lists.oasis-open.org/archives/xacml/200909/msg00013.html
> 
> The commenter notes that if access is denied to an interior 
> node and access is allowed to descendants of the denied node, 
> then the reassembled allowed nodes do not correspond to the 
> original schema anymore. The commenter proposes that the 
> specification is changed so that denying an internal node 
> also means deny to all descendant nodes.
> 
> The problem is actually wider than that. Denying (and thus 
> removing) any single leaf node could invalidate the schema 
> since the node might be required by the schema. So the 
> proposed change would not fix the identified problem. The 
> problem is inherent in doing access control on XML documents.
> 
> Also, in a more general case, it is useful to have the current model. 
> For instance, in a medical application it could be the case 
> that a researcher is allowed to see selected diagnostics 
> information contained in a patient record, but the rest of 
> the record, such as patient identifying data, is denied to him.
> 
> I propose that we make no change.
> 
> Best regards,
> Erik
> 
> ---------------------------------------------------------------------
> 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_workgr
> oups.php 
> 
>