dotgnu-auth
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Auth]delurking with opinions


From: Kurt L. Sussman
Subject: Re: [Auth]delurking with opinions
Date: Sat, 4 Aug 2001 13:25:24 -0700
User-agent: Mutt/1.2.5i

Albert Scherbinsky (address@hidden) typed this ...
> > First, I don't want to be tied to any browser. 
> 
> My choice of Netscape as the first prototype implementation
> was not meant to limit anybody. If you want to do
> implementations on IE, Konqueror or Lynx go ahead, there is
> nothing anyone will do to stop you. :)

I'm still not convinced that the browser has to become smarter for this
to work. I do understand that putting this functionality into the
browser opens it up to everyone, whether they can run their own server
or not (due to firewall, policy, or other restrictions). Open access is
a very good thing.

My concern is that people won't install a plugin. It's too much work for
the average user (e.g. my mom). That's how IE got its market share; by
being the default. Passport is the default; how do we get people to take
one extra step to dotGNU auth?

> > Second, I think the kiosk question has to be considered from the
> > beginning. 
> 
> The current SingleLogin/SIML/PIBXML spec can work with
> Kiosks as follows:
> The clever folks at www.webSLAP.com (web SingleLogin
> Application Service) decide to design an implementation
> architecture that works by entirely hosting the Single Login
> application as a web service. So you, from a kiosk with
> nothing more than HTML/HTTPS support, are able to login to
> <snip>
> We have to start somewhere. A mozilla plugin is a good place
> to start.

OK, a proxy service is fairly painless. How about using a proxy to fill
in those forms? Then there are no pesky commercial software vendors to
convince of the project's value. It's easy to set up for most browsers,
and anyone who has a public server can host a proxy for their community.
My company will host such a server, when it exists.

> > Third (and last, for now), I want to restrict the information based on
> > the site it's going to. 
> 
> All this is possible within the current spec since it wisely
> leaves these details to implementors. Perhaps you want to
> implement some access control code for the PIB? :)

That's not my area of expertise, but I'm happy to help where I can. 

As long as the spec is tight enough that any conforming implementation
will work, I'm happy. I just like to see things like that specified.
After all, privacy is one of the reasons we're not satisfied with
Passport, right? 

> We are not advocating unrestricted access, or promoting one
> implementation architecture over another. We are not
> specifying either of these things as part of the standard.
> We leave these details to implementors to allow for the best
> ideas to rise to the surface. Each user can decide what they
> want from the available implementations.

Once there's a reference implementation for me to plagiarize, I'll try
to build a proxy-based form-filler with access control on a per-element
basis. Maybe it'll rise to the top... #:)

> Thanks for your input,

I'm never short of opinions. #:)

--Kurt
-- 
----------------------------------------------------------------------
    Merlot Research Group, Inc               http://www.merlot.com
    Software Quality and Testability Consulting     address@hidden


reply via email to

[Prev in Thread] Current Thread [Next in Thread]