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

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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