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: The Hal/David model



Tim Moses wrote: 
>The model should include "authenticator".  The authenticator is contained
in the 
>authentication assertion and relied upon by the PDP.  For instance, if the
Principal has a 
>public key, then it is an authenticator and is contained in the
authentication assertion 
>and the PDP verifies that the Principal knows the corresponding private
key.

I believe that all assertions must have two properties. There must be away
to confirm identity of the Asserting Party. The must also be a way to
confirm its association with a request. In an interactive environment, this
may be done indirectly by associating a request with a session and
asssociating the session with a user. In a queued message environment, it
could be done directly by binding the assertion to the request document, or
by binding the assertion to the user who signed the document.

Your authenticator seems like a possible way to do this in some
environments, but hardly fundamental to the domain model. It also smacks of
design in the requirements and therefore you run the risk of incurring
Philip's wrath. ;-) 

>The model should show "environmental data" available to the PDP.  Examples
include "account 
>balance", "time of day", etc..  Out of scope, no doubt.  But, I think the
picture is 
>supposed to show things that are out of scope in order that we can be
explicit about what 
>is and is not in scope.

This is what the "other" arrows in my diagram were intended to convey. I
realize the picture tends to suggest network messages, however this is
probably true for "account balance" although not for "time of day".

>The model should contain an attribute of the resource that is its
"sensitivity".  
>Sensitivity reflects the harm that may result if the resource's methods can
be executed by 
>a Principal that does not have the appropriate privilege.

I disagree. I don't think this concept is a scalar and even if it is I doubt
we could agree on how to measure it. But most importantly, I don't see what
actions would be taken based on the value. If the sensitivity is "low" does
that mean we use weak keys? ignore signatures? use Beta software? treat
response failures as a positive response?

>The model should contain a "session authority" that issues "session
assertions" expressing 
>the state of a user's session in the Primary domain.

This is a good idea I will add it. I propose we call it a Session Manager,
on the analogy with a distributed Transaction Manager, which performes
similiar actions to orchestrate a two phase commit.

>On the subject of "Primary domain".  The "Protocols" section contains
definitions for 
>"Primary domain", "Secondary domain", "Principal", "PEP", "PDP" and some
others.
>I believe the definition of "Authorization assertion" that you have here is
too limited.  
>This definition is resource- or ACL-orientated.  In S2ML and in your model,
the 
>authorization is more Principal-orientated.

I am confused as to which version of the definitions you are refering to.
The output of an Attribute Authority is Attribute Assertions which refer to
the user initiating a request. 

An Authorization Policy specifies the conditions under which a request for a
type of access to a resource should be granted. The conditions can involve:

The attributes of the original requestor
Environmental data (e.g. date/time)
Application data (e.g. transaction amount)
Authentication method (e.g. two factor)
Identities of Intermediaries in request
other

The case of the policy being based entirely on the requestor's attributes is
common and familiar. However, it is equally sensible to have policies thet
use only other factors. (Anyone can do this between 10PM and 4AM.) 

Regards,

Hal


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


Powered by eList eXpress LLC