[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: The Hal/David model
IMHO, the 'authenticator' and 'sensitivity' are not required to supply the functionality we intend. Therefore, I don't think that we should include them in the specification - they could be easily facilitated by the extension fields. Regards, Darren > -----Original Message----- > From: Hal Lockhart [mailto:hal.lockhart@entegrity.com] > Sent: Wednesday, March 14, 2001 7:34 AM > To: 'Tim Moses'; 'Orchard, David'; > security-services@lists.oasis-open.org > 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 > > ------------------------------------------------------------------ > To unsubscribe from this elist send a message with the single word > "unsubscribe" in the body to: > security-services-request@lists.oasis-open.org >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC