[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: Actions from the Focus Group meeting
Tim Moses wrote: [...] >Issue 3 >In the present text, there is no "decision assertion". Instead, the PEP asks the PDP to > return an attribute assertion that affirms its question. For example, if the PEP wants > to know if Joe should be permitted to Get URL http://www.x.com//y, then it asks for an > attribute assertion that states that (according to the PDP) Joe should be permitted to Get > URL http://www.x.com//y. If the PDP decides that Joe should be permitted access, then it > returns the requested assertion along with a status code indicating that the request was > successfully fulfilled. I can't tell if you are supporting this idea or taking issue with it or just making an observation, but I strongly disagree with this notion as a matter of terminology. An attribute assertion contains facts about an individual. Typically they will be aggregate in the sense that others will have the same property. Typically they will be meaningful in a general business context apart from any specific application. Typically they will be available from some sort of non-volatle storage. I expect the only policy considerations involved in the generation of an attribute assertion will be: Who is asking? and Who is the individual?" Attributes MAY be used as ONE of the inputs to an Authorization Decision. In contrast, an access decision may ignore user properties. It may be based on a complex set of policies which include the date and time, the IP address of the requestor, the type of Authenticaiton used, the identity of any intermediaries, the current value of the DJIA or any other factor. A decision assertion is about an action not about a person. Access decisions are closely coupled to a specific application and likely have no meaning outside that application. I realize in practice this gets blurry. If I say "Joe can do X", you may say "Joe has the property to do X". You may also decide that "Anybody who can do X will be allowed to do Y." There is nothing I can do to prevent this. It is possible to use a screwdriver in place of a drill, but that does not mean it is wise. If my PDP lets anybody access Z, it does not seem reasonable to me to say "Joe has the property of access to Z." [Reminds me of (P v ~P) => Q ] There is also a distinction in lifetime. Although user attributes can be modified at any time, usually if someone is a Supervisor at 4:00 they will still be Supervisor at 6:00. However the fact that they can access something at 4:00 provides little assurance that it will be allowed at 6:00. I do agree with your observation that the exchange of information looks like: Q: Can X do Y under condition Z? A: Yes, X can do Y under condition Z. I just don't agree that the second line should be called an Attribute Assertion. Hal
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC