W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > April to June 1997

Re: Access Control Draft

From: Sukanta Ganguly <SGANGULY@novell.com>
Date: Fri, 16 May 1997 10:46:11 -0600
Message-Id: <s37c3b2d.045@novell.com>
To: jradoff@novalink.com, gjw@wnetc.com
Cc: w3c-dist-auth@w3.org
Hi,
   I am of the proponent of a CORBA based approach for the call
specifications. I would like to see the drawbacks that Jon is talking about
the CORBA approach. I feel that the system is quite developed and generic so
that people could make use of IIOP for communication among the objects on
the WEB. 
  Even then, I would assume the group has to formalize some standard
interfaces that are to be followed by the developers of tools based on these
specifications. So I still would like to stick some standard interfaces that
are bare neccesary for tools to be compliant with the specifications. I do
recognize that the access control mechanisms would have specifics about the
host OS on which it is implemented, the platform, internal netwrok etc. So
it would not be a very good approcah to  make developers work with our rigid
api's, but some common interfaces could be published that the tool
developers should comply with.

What do you poeple think about this ?


>>> Jon Radoff <jradoff@novalink.com> 05/15/97 05:11PM >>>
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 12:47:21 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 2 June 2009 18:43:42 GMT