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


On Mon, 7 Oct 2002, bill parducci wrote:

> 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).

I didn't say anything about 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.

I am not arguing that. But the question is something that permits access
with an obligation has more power over somebody who permits plain access
without any obligations. This forces you to ask all PDPs for and combine
their obligations.

> > 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').

Not really. The PDP has a clue about what obligations it will emit. If the
PEP states its understandable obligations either by configuration or by
RequestContext input, the PDP makes decision about whether to Permit with
obligations or a Deny. This can be stated in a standard answer when
converting the result of a rule/policy combining algorthim to a PDP
Result.

> > Alternatively, we can put "understandable" obligations in the
> > RequestContext, and the evaluation depends on those "understandable"
> > obligations in the same manner.
>
> same issue.

Exactly.

However, this way everything is specified, and furthermore, the answer
returned from a PDP can go through compiliance tests for that feature,
yielding MORE ASSURANCE to the Process, Methods, and Products.






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


Powered by eList eXpress LLC