Access Control Draft

I've volunteered and Jim has accepted me as document editor for
the access control issue.  I am currently working on a "Requirements"
draft which will serve as the direction for a later Draft
Specification for access control.

It is possible that access control will grow too big for this WG;
it may grow into either a subgroup of WEBDAV or even a WG of its
own.  This will be determined later.

Right now, I am soliciting initial input on some major questions
we need to answer before we can even begin drafting the Requirements
specification.  I would like to propose some initial questions.
I'll compile responses together, and then that can serve as a basis
for discussing the pros/cons of different things that could show
up in the Requirements draft.  If you have other issues that you
think should be discussed, please send them to me.

1.  Should an access control specification attempt to encompass any
    of the following:

    a) Potential extensions to HTTP;
    b) A server-based API approach;
    c) A file-oriented specification (e.g., an Access Control List
       specification for the Web).
 
    We need to determine if the scope of the Requirements will be
    to include one or more of the above items, and the pros/cons
    of different ways of solving the issue through the different
    overall approaches.

2.  If an API based approach is used, what is the best design
    philosophy to utilize?  An ODBC-like approach consisting of
    modular API design which separates implementation from interface
    has already been discussed in this group.  Are there other ideas?

3.  Should the Specification attempt to include any of the following:

    a) A _required_ set of access control token-naming-conventions
    b) A _suggested_ set of access control token-naming-conventions
 
    If either of the above, what should the scope of tokens include?
    What are the kinds of access we need to think about?

4.  Should the access control specification reflect a particular
    file-system convention, e.g., the UNIX-based filesystem, or
    should the specification include any sort of policy and/or
    protocol that abstracts filesystem from access control data?
    If it uses an "abstracted" filesystem, is it safe to assume
    that URL-based conventions are the best way to specify control
    over a file?  How does existing work in the areas of filesystems
    (e.g., Andrew, etc.) reflect on these concepts?

5.  Should the specification include any notions around "groups"
    or should this be implementation dependent?

6.  How should the access control specification deal with the identity
    of a user, i.e., what authentication standard/proposal will
    the implementation explicitly support, if any?  If an API-based
    specification is pursued, should the API explicitly support an
    interface to a specific authentication interface or should it
    be fairly abstract?

7.  Should there be any embedded/defined support for the object model
    in the access control system, e.g., inheritance of access tokens.

8.  Should the scope of the access control specification include:

    a) Checking to see if a user has a certain permission;
    b) Assigning permissions to a user;
    c) Revoking permissions;
    d) Relating permissions to objects on the Web;
    e) Any other management-related functions?

9.  What are the ideas around non-file-access type permissions?
    (For example, permissions that define what a user is allowed
    to do inside an application).

10. Should the draft specification intend to ultimately include a
    reference implementation?

11. What other questions are there?

Sincerely,

Jon Radoff
NovaLink

Received on Monday, 12 May 1997 20:57:21 UTC