- From: Fisher Mark <FisherM@exch1.indy.tce.com>
- Date: 1997年5月15日 12:50:02 -0500
- To: "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>, "'Jon Radoff'" <jradoff@novalink.com>
- Message-ID: <c=US%a=_%p=THOMSON%l=TCEIS5-970515175002Z-101680@tceis5.indy.tce.com>
>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