OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [xacml] 7.7 Obligations


> 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



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC