- From: Dylan Barrell <dbarrell@opentext.ch>
- Date: Fri, 16 May 1997 10:18:43 +-200
- To: "w3c-dist-auth@w3.org" <w3c-dist-auth@w3.org>
For me the real reason why we don't want to specify an API for this is that API's are the client/server way of doing things and protocols are the Web way of doing things - i.e. let's keep it consistent. We should however specify and API whereby the access control can be provided by a third party application (server extension) on the server side thereby relieving the server providers from the necessity of providing the functionality (they only have to support the API). Cheers Dylan ---------- From: Jon Radoff[SMTP:jradoff@novalink.com] Sent: Freitag, 16. Mai 1997 01:15 To: Gregory J. Woodhouse Cc: w3c-dist-auth@w3.org Subject: Re: Access Control Draft The reason an API based approached was initially suggested was to provide a mechanism through which server-based applications which act as "receivers" for requests from the client could have a standardized mechanism for asking the environment whether the user has a particular permission. There are some precedents within the IETF/RFC community for APIs, namely GSS-API (A security API, not related specifically to permissions). The CGI standard effectively implements an API by defining environment variables as a mechanism for passing information between the server and forked processes. In addition, it might be possible to develop an API that is language neutral by using a technology such as CORBA. The principal drawback there is the lack of extensive CORBA deployment and the additional overhead associated with using it. Permissions are essentially a "server" technology. It is unclear to me what information regarding permissions would ever be transacted between the client and the Web server, other than perhaps a denial-of-access response (which is already handled in the HTTP 1.0 spec). In addition, the predominant leaning so far from everyone has been that a spec that governs the creation and management of permissions is out of scope. That leaves us with the issue of resolving what a particular user can or can't do. Any comments on the above?
Received on Friday, 16 May 1997 04:20:10 UTC