dotgnu-auth
[Top][All Lists]
Advanced

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

Re: [Auth]IDsec specification draft


From: Mario D. Santana
Subject: Re: [Auth]IDsec specification draft
Date: Mon, 21 Jan 2002 17:51:59 -0800

Hello, all. I'm only just back from vacation, freshly moved from San 
Francisco to Miami, and finally settled in and wired up. I've read Hans' 
IDSec paper and have a couple of questions.

I think that most people, myself included, browse the web for relatively
short periods at a time. It's not likely that I would surf to more than
two or three sites in one session, to which I would give any profile
information. When I do visit one, I'm more likely to let mozilla enter my
login information than to surf over to the Manager and get my new Session
Certificate. Is there a way to send the Owner to the right Session Login
Service from an IDSec-enabled site fully- or semi-automatically?

A related question involves one-time purchases. Many times I buy
something from a site and never see that site again. If the site is
IDSec-enabled, I would have to detour through the Profile Management
Application before purchasing. The question is, from the point of view of
the Owner, is it easier to modify profile ACLs than to type in a CC#?

On the implementation side, if Bucks & Co. has 750 Websphere servers and
a $2M auth scheme already in place, IDSec is going to need a lot of
momentum indeed if it's not almost trivial to implement. How easy can it
be to IDSec-enable a site? I've heard you have some code around -- would 
you mind outlining what the APIs might look like, and what server hooks 
you see them using? (E.g., I can envision an IDSecFakeBasicAuth 
directive for Apache, etc.)

Finally, compared to what's running on servers today, IDSec requires
changes to the content servers and the client browsers, plus the creation
of a whole new entity in the Manager. The large content providers, being
risk-averse, would probably want a phased approach. How can a content
provider run some IDSec-enabled components alongside non-enabled
components? Would they be able to cross-authenticate and -communicate?
Can a Requester benefit from parts of IDSec without committing to it
fully as their main login mechanism?

OK, so it turned out to be more than a couple of questions. =) I mean for
them to be constructive, and I hope they help. It's a great spec, thanks
for writing it!

Cheers.

mds




reply via email to

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