[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