[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