RE: Access Control Draft

>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).
Although what we do influences what happens at the server and the
client, ultimately (IMHO) this group is concerned with the
"over-the-wire" issues.  APIs are out of our scope.  On (c), if it read,
"A resource-oriented specification...", I would agree this would be part
of the specification.  Many Webs are now being served by database
servers -- ordinary files are no longer involved.

>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?
We will probably need both.  Offhand, I think our model should be that
of OS access control, which (for authoring) usually consists of read,
write, create, and delete.  (Others may be able to add to this list.)

>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?
Since we are *Web* Distributing Authoring and Versioning, the spec
should be at the URL level.  This also fits well with how most current
servers seem to be implemented.

>5.  Should the specification include any notions around "groups"
>    or should this be implementation dependent?
Although the notion of groups is extremely powerful, I think that this
is 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?
I would recommend that standardly, the standard HTTP authentication
methods should be supported (which right now is only Basic
Authentication, although Digest Access Authentication is
standards-track).  Perhaps these could be expanded, such that (for
example) a SecurID-like scheme could be implemented where it passes the
current displayed card# as the user ID and the PIN # as the password.
Basically, my approach is to make the username and password "magic
cookies", letting the server interpret them how it will.

>7.  Should there be any embedded/defined support for the object model
>    in the access control system, e.g., inheritance of access tokens.
Again offhand, I would say only the limited inheritance now given by
Basic Authentication and Digest Access Authentication (implicit
re-authentication within a user-agent session).

>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?
Not sure -- I'll need to think more about these issues.

>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).
At the least, this is way out of scope for WebDAV (although an
interesting idea).

>10. Should the draft specification intend to ultimately include a
>    reference implementation?
Only if someone wants to supply it. (W3C's Jigsaw might be a good
reference server implementation platform.)

>11. What other questions are there?
>
>Sincerely,
>
>Jon Radoff
>NovaLink
>

Received on Thursday, 15 May 1997 13:51:22 UTC