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


Help: OASIS Mailing Lists Help | MarkMail Help

xacml message

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

Subject: RE: [xacml] Explanation - Capability model

Title: Explanation - Capability model
Hal - It sounds like we are in agreement.
I believe the thing that is defining of a "capability" policy is not that it is conveyed in a bearer token (otherwise, a digital certificate would certainly not qualify), but that it is identified with the subject (rather than the resource) and describes the things that the subject is "capable" of doing.  I have no interest in pursuing this model.  And if all in the group feel the same way (as you appear to), then I suggest that we not address the capability model in our work.
All the best.  Tim.

Tim Moses
Tel: 613.270.3183

-----Original Message-----
From: Hal Lockhart [mailto:hal.lockhart@entegrity.com]
Sent: Tuesday, October 16, 2001 3:28 PM
To: 'Tim Moses'; 'XACML'
Subject: RE: [xacml] Explanation - Capability model

-----Original Message-----
From: Tim Moses [mailto:tim.moses@entrust.com]
Sent: Tuesday, October 16, 2001 10:59 AM
Subject: [xacml] Explanation - Capability model

Colleagues - A decision request contains (as a minimum) the subject, the resource and the action.  Job one for the PDP is to locate, retrieve and verify the policy appropriate to the decision request.  By "policy" I mean the complete set of rules that must be considered when formulating the decision. 

From an XACML perspective, I think we need to first determine the inputs and the model structure and then determine what items must be present. Everyone is tired of hearing me say subject is not required, certainly it could be argued that action is not required, for example, consider a application protocol with only one operation. (http is almost that way since any given page is usually only accessed with a particular operation (e.g. GET) and all operations can perform reads and writes.)
Not withstanding that, I agree with your use of the term policy.
Certainly the PDP must IDENTIFY the policies that apply to any given decision. It seems to me that whether it must locate, retrieve and verify them seems to me to be implementation specific and not necessarily the concern of XACML.

We need a way of identifying policies, for two reasons.  Firstly, most mechanisms for locating and retrieving policy will be based on the policy's "name".  I am thinking of LDAP, "The Web", ODBC, etc..  In addition, for security reasons, the PDP must verify that it has retrieved the correct policy for the decision request.  So, it must be verifiable, by examining the policy and the decision request, that it is the right policy for the request.  One way (perhaps the best way) is to name the policies according to the situations to which they apply.  The PDP has to assure itself that the policy was issued by an authority (or authorities) that is (are) competent to set policy for the situation and that it has not been altered, and (furthermore) that the policy's name identifies it with some aspect of the decision request. 

I don't understand why you introduce the concept of "naming" policies. My view is that XACML should say, these inputs are used to determine which policies apply. If you want to (for example) concatenate the values, hash the result and use that to create an LDAP query, fine. If you have all the policies hard coded in your PDP, that is fine too.
The means by which a PDP decides to trust a PRP also seems outside of XACML. Certainly we could provide the optional ability to sign policies using XMLdsig, but in many cases other means will be used. For example, the PRP and PDP may share an address space.

When policies are identified with the subject, the model is called a "capability" model.  

Capabilities specifically mean the use of a bearer token that specifies the right to do something. See for example: http://www.garlic.com/~lynn/secure.htm which cites both RFC2828 and the National Security Decision Directive:
"(I) A token, usually an unforgeable data value (sometimes called a 'ticket') that gives the bearer or holder the right to access a system resource. Possession of the token is accepted by a system as proof that the holder has been authorized to access the resource named or indicated by the token. (C) This concept can be implemented as a digital certificate. [RFC2828 ] A protected identifier that both identifies the object and specifies the access rights to be allowed to the accessor who possesses the capability. In a capability-based system, access to protected objects such as files is granted if the would-be accessor possesses a capability for the object. [AJP][NCSC/TG004"
I consider capabilities infeasable in medium and large scale environments because they create to close a coupling between the user repositories and the resources protected by the PEPs. Either the capabilities must be so coarse grained that they are not useful (whole web site) or the administrative coodination required is impractical (if I add a single page to my web application, I have to inform the capability issuing point).
When a policy layer is interposed between the "capabilities" and the actual policy decision, essentially you end up with user attributes, as in the SAML/XACML domain model. If you want to call a SAML Attribute Assertion a capability, then I guess we don't have any fundamental disagreement, but that is different from how the term has been used in the literature.

When policies are identified with resource and action, the model is called an "access control" model.

At least in theory, policies could be identified with ancillary parameters (e.g. time of day).  But, this doesn't seem to be an especially helpful option.

In the capability model, policies are located and retrieved based on the subject's name, and in the access control model, policies are located and retrieved based on the name of the resource and action.

We'll have to decide whether to support both capability and access control models.  Personally, I would be quite happy to ignore the capability model.  Perhaps, the group could consider taking this position, and seeing if anyone complains.  If someone were to complain, then we would have to define a general model that accommodates both capability and access control approaches. 

 Perhaps this is only an issue of definition. I believe strongly that the domain model, with potentially multiple authorities is the right kind of approach. As long as your notion of capabilties fits in that framework, I have no problems with it.

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

Powered by eList eXpress LLC