Re: Access Control Draft

I really like the "policy" based approach.  It could also provide
a fairly transparent layer from which could interface with
implementation specific access permissions.

Here is an outline for some of what might be included in this
type of design:

1) A "security policy" resource, which is identified by a
   token string established by the Web server's administrator.
   This security policy resource is implementation-specific, and
   not defined by WEBDAV.  The purpose of WEBDAV in this part
   is principally to define how you name and interact with
   these policy resources.

2) A standardized protocol -- either an HTTP extension, a forms-based
   approach, an extension to the URL invocation convention, etc.,
   which is capable of a assigning a named security policy to a
   named object.  (An object in this context means a particular
   thing you can access via the Web, for example, an HTML document,
   a JPEG image, a Java applet, etc.)

3) In addition, we could also define "methods" which are associated
   with a given resource.  For example, we could identify the
   "read" method for an object, and then assign a particular policy
   to this method for a particular object.  "Modify" and "delete"
   might be other standard methods.  Under this theory, we
   could also support the object model and inheritance by
   associating policies with classes of objects -- for example,
   all "HTML Objects" have such-and-such policy, all "HTML Objects
   in the Marketing Site" either inherit this policy or have their
   own definition.  If any of these things are favored, we need
   to determine what we specify as standard or recommend insofar
   as (a) standard method naming conventions, (b) whether the
   object model is directly support in the protocol or whether this
   is implementation specific.

The server implementation would be responsible for interpreting
the policies, matching them up with resources, authenticating the
user and matching up this information to associate it with
local policy.  Vendors can decide how they want to work with
policy resources -- some might want this to be administered through
forms, others through special client software, etc.  I don't
think this would be important to what we recommend.

It seems that this approach provides a lot of growth potential.

This also allows for development of standardized APIs outside of
this particular specification.  For example, after the initial
protocols for this are determined someone could identify a
CORBA encapsulationg mechanism for modifying security policy
resources.

Jon

Received on Tuesday, 20 May 1997 11:56:15 UTC