Re: [Auth]IDsec specification draft

[Hans Zandbelt]

At 17:51 1/21/2002 -0800, Mario D. Santana wrote:

>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?

This is an implementation issue. As we see it (and as we do in our current
implementation) users don't have to surf explicitly to the Manager: this
functionality is handled by a IDsec client handler (browser plugin) that
reacts on response fields coming from the web-site that a user visits. So
it means an "implicit" login (probably only seen as a popup asking for your 
password).

>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#?

True. You'll have to indicate somehow that this site can be trusted.
Our current implementation solves it in the way you describe. We foresee
an implementation that shows a popup asking if the current site certificate
should be added to specific ACLs. This again is functionality that could
be provided by the client-side IDsec handler (proxy/plugin) in combination
witht the Profile Management Application.

>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.)

We are indeed working on a "real-world" IDsec implementation. This means
coding it in C and make appropriate modules/libraries for client/server
environments. Currently we are making progress on an IDsec Apache module
that a Service Provider can use, which is exactly what you describe.

>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?

I did not look into migration scenario's yet in detail but I think some
glue code can solve al lot of those issues.

>Can a Requester benefit from parts of IDSec without committing to it
>fully as their main login mechanism?

Yes. One could choose to implement a proprietary login mechanism but
still retrieve certain additional IDsec profile settings. I think that
many Service Providers would still maintain a customer database that
contains extended information about users instead of relaying it all
to the IDsec profile.

>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!

Thanks for your comments!

Hans.


------------------------------------------------------------
Hans Zandbelt                         address@hidden 
Telematica Instituut                     http://www.telin.nl 
P.O.Box 589, 7500 AN                   Phone: +31 53 4850445 
Enschede, Netherlands                    Fax: +31 53 4850400