Re: Access Control Draft

Some comments.

It seems premature to be developing preliminary designs without having a
clear statement of the requirements.  While I realize it is helpful to have
some kind of design framework in mind when developing requirements, and the
requirements and design phases have a fuzzy boundary, the requirements
still need to be specified first.

For example, if the only requirement for interoperable access control is to
provide privacy to a draft while an author is working on it, then this
design is incredibly heavyweight.  The only word processor, spreadsheet, or
HTML authoring tool I know of which exposes access control capability in
its user interface is FrameMaker, which allows a user to set Unix file
permissions in its Save As... dialog box.  It is not clear to me that this
functionality is used very often.

Some questions I'd like to see answered before more design work takes place are:
Why do I need access control functionality in WebDAV at all?
When would access control capability show up in the user interface?
When would access control capability be used by an application to implement
other features (during some behind-the-scenes processing)?

>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.)

This needs to be more precise.  A forms-based approach would still use the
HTTP protocol.  I have no idea what the "URL invocation convention" is,
since an http scheme URL is a location, and has no intrinsic executable
state.

The way our charter is written, access control work within WebDAV must
limit itself to working within the HTTP framework.

>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.

I'm not sure where this is headed.  HTTP already defines standard methods
which are associated with resources, "read" is known as "GET", "write" is
known as "PUT", and "delete" is known as "DELETE."  What is the benefit of
giving these known, well-defined methods new names?  Or are you suggesting
something similar to the AOLserver model, where they sometimes create
pseudo methods for assigning access control rights.

>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.

Work on CORBA is outside the scope of activity of this working group, as
specified in our charter.  But, I agree with you, once an interface
standard has been developed, its packaging in various other formats (CORBA,
RPC, etc.) is much easier.

- Jim

Received on Tuesday, 20 May 1997 16:31:13 UTC