OASIS eXtensible Access Control Markup Language (XACML) TC

RE: [xacml] bags and targets. Forwarded message from Seth Proctor .

  • 1.  RE: [xacml] bags and targets. Forwarded message from Seth Proctor .

    Posted 10-18-2002 18:12
    On 18 October, Daniel Engovatov writes: > What you are suggesting is that PDP should have some sort of an internal > knowledge of what information must be available in the context and signal > any discrepancy via Indeterminate result. I do not think it is a workable > operational requirement, especially given that we do not specify much about > the internals of our virtual context (and I do not think we should). Such > intrusion detection is probably the job of the PIP service, and yes - it can > pass Indeterminate value to the PDP if, for example, some SHA signature is > off etc. But that is not the job of the PDP, and an empty bag is a > critically useful abstraction to use. I believe it is your interpretation that suggests that the PDP has some sort of internal knowledge about what information must be available in the context. I am being very clear in saying that the PDP does NOT have that knowledge, and if it is unable to find an attribute that is referenced by an AttributeDesignator, for whatever reason, it will ALWAYS return "Indeterminate" as the result. > If you want to write your policy in the way, that prohibits access if > something is missing - you can. Polar suggested several different > approaches to this - using present, *-one-and-only will achieve the same > effect. a) I can't use those in the Target b) If I try to use an attribute whose retrieval could fail in a Target, then the Target will evaluate to NotApplicable. This will happen even if a temporary network glitch was the cause for the attribute retrieval failure, and even if the policy has a "Deny" effect and would have caused me to deny access had the attribute been available. > I do not remember whether we agreed or even discussed my proposal to treat > designator supplied as an argument to a function requiring a single value > attribute as an implicitly wrapped in *-one-and-only type transformation > (but at least several examples used around do treat it that way). > Explicitly stating such an assumption will probably answer your concern - it > does produce Indeterminate on missing attribute, when applied to a function > requiring a singleton.. That would answer only one concern. I agree, however, that if we accept your interpretation, we must spell this out. Anne -- Anne H. Anderson Email: Anne.Anderson@Sun.COM Sun Microsystems Laboratories 1 Network Drive,UBUR02-311 Tel: 781/442-0928 Burlington, MA 01803-0902 USA Fax: 781/442-1692