On 17 October, Polar Humenn writes: Re: [xacml] bags and targets. Forwarded message from Seth Proctor. > This sentence means exactly what it says. If the the selector or > designator evalutates to an empty bag, then there is no match, i.e. the > match "predicate" is False. > > The match predicate is akin to asking, "Do you have one or more of any > subject ids that match "john.*". If you have none, then False, if you have > at least one, then True. Are you saying that the result will be "False", rather than "Indeterminate", when an not-found attribute is compared to a value? If so, I think this is wrong. If we can't find an attribute value in the Request Context, for whatever reason, then the result should be "Indeterminate", because there MAY be such a value available somewhere and we simply weren't able to get it. If your application needs to know for sure that something is not available (e.g. "Is this person a convicted felon?"), then the application needs to use a positive attribute like "Is not a convicted felon", where a trusted authority makes a positive assertion that such information is missing, rather than depending on a missing "Is a convicted felon" attribute. We really need to pin this down. Daniel, I think, says that only some sort of operational error in talking to the PIP or repository would result in "Indeterminate". But we can't guarantee that an error would be detected or that the PDP wasn't querying the wrong PIP or repository. A classic security breach is to make something silently unavailable (unplug a relay, re-route a message, etc.), and use that to access systems that assume something that is not available is false. If an attribute is not present, then the PDP doesn't know what its value is, and the result should be "Indeterminate" - which means "the PDP is unable to determine the result". 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