using the identity url to contain a key fingerprint

[Jean-Luc Delatre]

Martin Atkins wrote:

> I would *love* to see a proper public-key based login system as you 
> describe. I've been going around telling everyone what a great idea it 
> is for a long time. However, there is no way to do that without 
> modifying the client, and the client is a big, heavy, immovable 
> object: everyone uses a different client, and many people will never 
> upgrade it. Most importantly, there are millions of clients!

Javascript is the answer.
In spite of numerous still  standing browser incompatibilities many 
"advanced" Javascript tweakings are
currently doable on all four major browser families Firefox/Mozilla, IE  
5.5 and beyond, Opera and Safari.
This does not need any awareness from the user and private keys could be 
themself crypted and stored in a cookie to be unlocked by a pass phrase.

> OpenID provides a working solution which works for websites today. It 
> does not provide a magic bullet for authentication needs in every 
> scenario by any stretch of the imagination, and it can in many 
> respects be described as a "giant hack", but it's a hack that works.
>
Agreed  ;-)

> Most of our discussions here have been about refining the system and 
> attempting to make it more general or more secure without losing the 
> simplicity, which I think is a good goal.
>
> To address your final point:
> > If the deployment is awkward it will not take off, YOU WILL BE
> > SCREWED...
>
> I'd would argue that deployment of a client-only public-key system 
> would be far more awkward than OpenID, which requires only a change to 
> the server. There are far more clients than there are servers. I think 
> OpenID's simplicity is its primary virtue, actually.

Not agreed!
Deployment  of a Javascript based public key system will be fully 
transparent modulo a few cross-domain scripting security hindrances.
But I bet this can be done for a "good cause" when it is  already done 
for malfeasance.

And, targeting "grandmothers", which scenario would look easiest at 
*client side* deployment time:

-  Choose a passphrase to initiate your access and be carefull to note 
it somewhere (but not on a post-it note...)
-  Please go to LiveJournal/Movable Type/TypeKey/... create an account 
if you don't have one and come back
   to this page with the account URL.

After this initial step both modes of operation will look about the same.

Even if this introduce yet more constraints on the protocol, namely the 
ability to forward private keys from clients machines to authentication 
servers, it would be nice to have full interoperability between such a 
system and existing OpenID.
If only to answer Imran's objection:

Imran Ghory wrote:

 >On 5/25/05, Jean-Luc Delatre <jld at club-internet.fr> wrote:
 >
 >>- Everything secret is now on  the client side and under his
 >>*responsibility*.
 >> There is *no* need for any authentication server!
 >> There is *nothing* secret to distribute.
 >
 >
 >Right, now when the user wants to login from another computer
 >(cybercafe/school/work) how do you propose to transfer the private
 >keys ?
 >
 >Imran
 >--
 >MSN: tickletux at hotmail.com
 >AIM: tickletux1
 >

BTW Imran, your message didn't make it thru, you are not on the list!

The whole point is:
Which is the primary source of the ID/private key?
An "initial" client machine or a blog account?

> However, even if for some reason this doesn't take off beyond 
> LiveJournal+clones and Movable Type/TypeKey it's already being used by 
> a very large portion of the "weblog" community, which was what it set 
> out to do in the first place.

Don't be too modest, remember, the new games are "Winner take all"...

All the best,

JLD [Kevembuangga]

P.S. I am CCing Stephen Downes because he is mentioned in the OpenID 
home page and he is obviously interested in much the same topic (and he 
didn't object yet...)