I have no objection (from a TC standpoint) to anyone using any XACML attribute to do anything they want. There is no need of an OASIS standard for those cases. I do, however, want the specifications and profiles produced by the TC to encourage good architecture and consistent behavior of XACML systems. The BTG proposal in front of the TC describes distinguished obligation IDs, action-id values, and attributes whose intended use includes specific behavior of a XACML system that heretofore has not been sanctioned by the specifications. (Nor, as far as I can tell, has it been proscribed.) I am not trying to over-complicate things, beyond the complexity that was introduced by the proposed BTG profile. Regards, --Paul Agree with Doron: in fact, BTG does not “break the rules” – because the rule set includes the rule that “if BTG_condition = true then permit . .” One notion I have not seen explicitly in the discussion is that in the case of the BTG scenario, the “authoritative attribute source” is the requestor (who is asserting that an emergency condition exists.) Can that attribute be asserted falsely? Sure. But assuming we have audit, then there is probably adequate control of that risk. This is how we plan to handle a whole class of situations where (1) the appropriate “attributes” are difficult or impossible to obtain as facts from sources other than the requestor (e.g., “probable cause” or action “for the purpose of”) and (2) where audit of the action is considered adequate to control the risk of requestor self-assertion. Martin Martin F. Smith
Director, National Security Systems
US Department of Homeland Security
NAC 19-204-47
(202) 447-3743 desk
(202) 441-9731 mobile I agree. The PEP provides an attribute Emergency="true" (set by user action). Glass is broken. Period. Why make things complicated?
Doron Grinstein Hi Erik,
I do not disagree with your assumed example that has the PDP and StateDB conspire
to reduce the bank account balance before the transaction has been executed. If you
are suggesting that I am making a suggestion along those lines, then you are mistaken.
In the RSA 2008 Interop, when a doctor from an external facility made a request to
see a patient record, the doctor was denied access. However, the doctor then
"declared an emergency", and was able to obtain an emergency-override attribute,
which was then submitted with a follow-up request and access was allowed.
Although not specified, the act of the doctor "declaring the emergency" means that
the doctor as an authorized user of StateDB was able to change the state of the
situation and thus an attribute became available that was not previously enabled.
In theory, now the PDP could look for the emergency access attribute and the PIP
could obtain it from StateDB, which could not have been done before the doctor
declared the emergency.
I have not fully reviewed Paul's email that refers to David's proposal. However,
I was under the impression that in David's proposal, the first request resulted
in the generation of an obligation, which from my perspective would inform
the PEP that a situation now existed that is being denied, but that there is
an option to override, if some external action is taken to enable the override.
Whether or how any state changes take place in the external StateDB at this
point is beyond the scope of the XACML specs, and any presumptions as
to what anyone would propose to do at this point is purely in the realm of
conjecture and the creation of strawmen, such as an academic question of
what would one's opinion be of a PEP that reduced the bank balance before
the transaction was attempted.
From my perspective the discussion has solved the problem by informing
the world outside of XACML that a situation exists that is being denied,
but could be permitted if someone in authority were to grant a particular
privilege.
Thanks,
Rich
<LONG TAIL CUT OFF – pht>
|