OASIS eXtensible Access Control Markup Language (XACML) TC

I still think BTG is a subset of a more general use case.

Following along with the obligation, my impression was that this must be followed with an ageement to abide by the obligation constraints, e.g. a "promise". The promise could act to tell the PDP to change the policy set (in this case to BTG). With the "state" change the decision is now correct.

Mike Davis

Hi Mike, Erik, Paul, and David, Here's my two cents on what I've taken from the emails on this thread, David's BTG profile and protocol description. I agree w Erik's statement that the XACML model does not have state built in, and that there is not yet a compelling reason to add it. However, my interpretation of state is wrt the Policy definitions. i.e. the Policy defns themselves are static . However, for Policy evaluation , the state is the RequestContext, namely whatever values are in the Attributes in the RequestContext at Policy evaluation time may be regarded as the state . So, for BTG , what I see as the essential ingredient is the defn of a BTG-State Attribute, that can be supplied by the PEP, or some PIP that supplies it to an attribute finder during policy evaluation. Testing the attribute would be triggered by its presence in a Policy with it MustBePresent xml attribute set to true, and the Policy should be defined, so that the BTG-State Attribute is not tested unless the request is not permitted without it. This is equivalent to what we did in the RSA-2008 Interop, where the BTG-State attribute was hl7:pea-001 , which would allow an external user access, where they would otherwise be denied. i.e. the presence of hl7:pea-001 effectively changed the state of Policy evaluation, which enabled BTG logic to be applied. With respect to David's documents, I basically agree with the approach, except for statements like in the protocol descr step 8, where it says: The PDP sets the relevant BTG-state variable to true ... . I think it is fine to return an Obligation as the Profile describes, and that this be used as the basis of the User obtaining a BTG-State Attribute, which can be submitted in the follow-up request. I think the presence of this attribute is sufficient state for the Policy to evaluate properly.       Thanks,       Rich Davis, John M. wrote: EABFCFD64432124F98EF01B2C3E87F6D098EB79A@VANCRMSGW1.vha.med.va.gov type= cite > I still think BTG is a subset of a more general use case. Following along with the obligation, my impression was that this must be followed with an ageement to abide by the obligation constraints, e.g. a promise . The promise could act to tell the PDP to change the policy set (in this case to BTG). With the state change the decision is now correct. Mike Davis
Original Message ----- From: Erik Rissanen <erik@axiomatics.com> To: xacml@lists.oasis-open.org <xacml@lists.oasis-open.org> Sent: Wed Feb 23 04:42:41 2011 Subject: Re: [xacml] BTG comment [WAS: [xacml] Proposed Agenda 10 February 2011 TC Meeting] Hi Paul and Mike, I agree, but isn't this exactly what David is proposing? That is how I understand it, at least for the PEP state mode. The other alternative with the PDP maintaining state is something I don't think is a good idea. To make David's proposal better, it needs: - Drop the PDP state approach since this goes against the capability of the XACML model which does not have a state built in. - Define identifiers for at least the BTG obligation/advice (advice is better, but for XACML 2.0 an obligation needs to be used), the action-id for breaking glass (as well as giving some kind of direction of what the BTG request should look like in relation to resources being accessed). - It would be nice with a full, worked through example. Best regards, Erik On 2011-02-23 05:06, Davis, John M. wrote: Concur with Paul's analysis. We also see BTG as a state change. Regards, Mike Davis, CISSP Department of Veterans Affairs Office of Health Information Security Architect 760-632-0294

When we say that the PDP is stateless, what is meant is that no state is carried by the server from one decision to the next. Policy decisions are purely a function of policies in force and the content of the request context.   I agree with the general view that this is a valuable property which not should be lightly changed across the board. However, I am keeping an open mind on the desirability of explicitly defining entities within the access control architecture which do maintain state.   For example, the RBAC profile as it currently exists implies some kind of stateful mechanism to keep track which dynamic roles have been enabled. The exact mechanism was deliberately not specified as it was recognized that many designs were possible.   Hal
Original Message----- From: Rich.Levinson Sent: Wednesday, February 23, 2011 11:57 AM To: Davis, John M. Cc: erik@axiomatics.com; xacml@lists.oasis-open.org Subject: Re: [xacml] BTG comment [WAS: [xacml] Proposed Agenda 10 February 2011 TC Meeting] Hi Mike, Erik, Paul, and David, Here's my two cents on what I've taken from the emails on this thread, David's BTG profile and protocol description. I agree w Erik's statement that the XACML model does not have state built in, and that there is not yet a compelling reason to add it. However, my interpretation of state is wrt the Policy definitions. i.e. the Policy defns themselves are static . However, for Policy evaluation , the state is the RequestContext, namely whatever values are in the Attributes in the RequestContext at Policy evaluation time may be regarded as the state . So, for BTG , what I see as the essential ingredient is the defn of a BTG-State Attribute, that can be supplied by the PEP, or some PIP that supplies it to an attribute finder during policy evaluation. Testing the attribute would be triggered by its presence in a Policy with it MustBePresent xml attribute set to true, and the Policy should be defined, so that the BTG-State Attribute is not tested unless the request is not permitted without it. This i