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] proposed amendment to Polar's resolution of PM-2-05


actually i am not proposing that 'nothing' be returned, but that
"indeterminate with insufficient information" not return those attibutes
that are necessary to complete the request. 

personally, i find the case of a PEP not knowing how the authorization
question should be phrased to the PDP unlikely.

b

Polar Humenn wrote:
> 
> Also, in the side dicussion with Bill, I also formulated, and formalized
> with keyword MAY by Konstantin's amendment, was a PDP that must make a
> trust decision on its client, i.e. a PEP in Bill's case, of whether it
> gives up any information about how to obtain an access decision.
> 
> The basic crux of the argument is that a PDP that hands back
> "indeterminate" with "insufficient infomration", and names needed
> attributes that are already supplied in the request, is a protocol error.
> 
> Whether a PDP hands back lists the names of any needed attributes is a
> trust determination on its client. So, if a rouge can get access to the
> PDP, the PDP should have precautions enough not to turn up sensitive
> information to rouges. Otherwise, it should be operating overly paranoid
> mode and return nothing.
> 
> The requirement doesn't say that the PDP MUST return the names of needed
> attributes, merely states that it MAY, and states what is illegal to
> return if it does. The purpose of that requirement is to provide some
> narrowing that converges to an access decision, otherwise, infinate loops
> can occur.
> 
> There is still somewhat of a problem with convergence. Each time with more
> and more attributes supplied the PDP can still ask for different
> attributes, leading you down an infinite path. However, that is a
> determination by a PDP's client for now long that request/reply scenario
> can go.
> 
> I thought about mandating that the PDP must supply the name of ALL
> attributes needed, and cannot return anything not from that initial set.
> However, that requires state, or at the very least a complete determinate
> computation of all needed attributes. Given our structure of XACML and
> the composibility of policies, this is nearly impossible in the general
> sense.
> 
> Cheers,
> -Polar
>


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


Powered by eList eXpress LLC