[DotGNU]Re: [Project-Proposal]<Original>FreeGate

[Khen Ofek]

Hi

I wrote:


> > Description: This project will define and implement a general
> > interface for web services. Authentication will be treated
> > like a web service.

> > Take a look at the initial design at :
> > http://www.cheno.f2s.com/FreeGate2.htm <http://www.cheno.f2s.com/FreeGate2.html>

I want to explain my underline ideas regarding FreeGate.
I have defined FreeGate interface to be an abstract interface. This 
interface should be self contained (i.e. it should define all the 
concepts that we use inside  FreeGate system). If I understood correctly 
this is what Barry calls spec proposal
After we will decide on such an abstract interface we should implement 
it using binding to known (and future) forms of communication systems. 
This can be called a project proposal (i.e. a project will define the 
binding and will implement the abstract interface on specific platforms 
using this binding).

Barry Fitzgerald wrote:

> Hello,
>
> First, at first glance, this seems to overlap with the RLS and Tokens
> documents in some areas.  I'd suggest that you look at those two
> documents and try to fit your spec into that general ideology.  Of
> course, if something doesn't seem to fit quite right in those documents
> to you, please post about the issue in the address@hidden list.  
I want to try to specify the connections between FreeGate and RLS+Tokens 
specs:
As I see it we can define a binding of FreeGate inteface to the RLS 
framework.
For example :
FreeGate's ServiceID will be the string |<DotGNU Service>| in RLS.
GateProtocol for RLS will be defined as the pair : <"RLS",host name>. I 
mean that AccessMethod = "RLS" and AccessData=host name.
FreeGate's UniqueID will be the username in RLS.
Lets look at the exmaple in the FreeGate document:ServiceID="login", 
GateRoles={"PasswordGate","Client"}, Data=Password (a string)
A request for the login service to a service provider that have the 
ability to talk RLS can be:
rls://address@hidden/login?RLS, <host name for 
PasswordGate>,<my Password>
now the service provider will have to contact the PasswordGate to 
"validate" the user:
rls://address@hidden/validateUser?Client,Password
We can also call the service provider using PasswordGate of SELF to 
indicate that the service provider should validate the user internally:
rls://address@hidden/login?SELF,<my Password>
I am sure we can define a formal binding once the FreeGate and the RLS 
specs will be finalize.
The Tokens spec is a way to pass data between clients and servers. 
Because the FreeGate interface is an abstract interface and the Tokens 
method is a general way to pass data it is very simple to define binding 
of the Data in FreeGate to Tokens.

Because RLS+Tokens is a general communication and data framework it 
should not be too difficult to bind the abstract FreeGate interface to 
this framework. But the RLS+Tokens is new framework which is not 
implemented yet. For that reason I think that first we should define 
binding of FreeGate to more established ways of communications and if we 
find them unsatisfactory then we can go to RLS+Tokens.
For exmaple : why not define binding of FreeGate to standard CGI interface?
Note that the RLS interface is very similar to CGI.
The request will be something like that : 
http://ServiceProvider.com/login?DotGNU-CGI,<host name for 
PasswordGate>,Client,<my Password>
And then we need to implement a simple CGI script that the web masters 
can use with current framework (servers, communication protocols etc.)

Khen Ofek