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