[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [xacml] 7.7 Obligations
I think XACML specification should basically focus on the functionality on the PDP but it does not necessarily mean that it MUST NOT say anything about entries other than PDP in the normative sections. For example, Section 7.1 describes desirable behavior in "PEP", for example in line 2636-2664. The following are excerpt: - If the "Permit" value is returned, then the PEP MAY permit access to the resource. - If the "Deny" value is returned, then the PEP SHALL deny access to the resource. - If the "Indeterminate" value is returned, it means that the PDP could not make a decision. The PDP MAY return a decision value of "Indeterminate" with a status code of "... missing-attribute", etc. - If the "NotApplicable" is returned, it means that the PDP's policy is not applicable to the request, implying that the PEP should send its request to another PDP. The following are the text regarding obligations and I want to add in this section: - If the "Permit with obligations(s)" value is returned, then the PEP MAY permit access to the resource and PEP is responsible for fulfilling the obligation(s). If there is an obligation that is not understandable by the PEP, then the PEP SHALL deny access to the resource. - If the "Deny with obligations(s)" value is returned, then the PEP SHALL deny access to the resource and PEP is still responsible for fulfilling the obligation(s). If there is an obligation that is not understandable by the PEP, then the PEP SHALL raise an error. How and which error should be raised is outside the scope of XACML. Michiharu Kudo IBM Tokyo Research Laboratory, Internet Technology Tel. +81 (46) 215-4642 Fax +81 (46) 273-7428 bill parducci <bill.parducci@ov To: "'XACML TC '" <xacml@lists.oasis-open.org> erxeer.com> cc: Subject: Re: [xacml] 7.7 Obligations 2002/10/08 10:26 > Decision or no decision, how does it make sense? huh? this a zen thing? :o) > What is a PEP? We know what a PDP is. It takes a well formed input and > evaluates it against a well formed policy and yields a well formed result > semantically consistent with the input and policy. There is a notion of > conformity and compliance. Furthermore that compliances is based on > mathematic principles. > > A PEP is merely a point in some application somewhere, that may or may not > even call on a PDP, PRP, or a PIP. So, how can you place any coformance > requirements on it? Are you going to call an application PEP compliant? > Who would care? so what you are saying is that SAML is a waste time because remote azn requests will never occur amongst vendors? (remote auth is only half of SAML). > If you want to have compliance points based on obligations, they should be > placed on the component we are defining, the PDP, to give you the correct > decision. the issue is not if the pdp gives the correct decision, it is that the decision may have as a component an obligation (note to daniel: obligations may also occur for DENY). by definition any device receiving an obligation MUST be able to comprehend that obligation in order to permit access to a resource. > If the intended behavior is to deny access for non-understandable > obligcations, perhaps, we should say that the PDP should be configured > with "understandable" obligations, and to answer Deny if a decision of > Permit comes up with any obligations not in the "understandable" set. that would mean policies on the PDP must reflect the capabilities of all potential PEPs. that would break encapsulation and lead to an impossibly difficult system to administer (the specter of tiered 'understanding capabilities'). > Alternatively, we can put "understandable" obligations in the > RequestContext, and the evaluation depends on those "understandable" > obligations in the same manner. same issue. b ---------------------------------------------------------------- To subscribe or unsubscribe from this elist use the subscription manager: <http://lists.oasis-open.org/ob/adm.pl>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC