OpenID - getting mass take up, anti-spam?

[Johannes Ernst]

On Jan 6, 2006, at 9:31, Martin Atkins wrote:

> Johannes Ernst wrote:
>>
>> The biggest issue in all of this is integration with e-mail  
>> clients. The
>> receiving end is relatively straightforward, but the sending one  
>> isn't. (Maybe
>> you have some better ideas that I do on this, if so, let's hear  
>> them!)
>
> It seems pretty easy from webmail, but not easy at all for a desktop
> client.

An unmodified desktop client, yes. We've been playing around with the  
idea of doing something like this:
     http://netmesh.info/ 
jernst at some.smtp.to.lid.forwarding.server.example.com
as a workaround, but I'm not sure that on balance, this really works.

However, I don't think we need to get general-purpose e-mail  
integration going to have something valuable. Just, say, the "leave  
me a message" use case on somebody's public web page is already quite  
compelling (it certainly is for me ... lots of people have used my  
web form to get in touch with me since I put it up -- amazingly even  
including several who do know my e-mail address!).

> OpenID (and presumably LID too?) doesn't really work outside of
> a web browser.

I can't point to an implementation on the public network, but no, it  
does ;-)

As an example, consider a "speed-dial list" on a phone. You could  
implement this as a list of URLs that happen to support the LID VCard  
profile. When I want to dial your name, the phone does an HTTP GET on
     http://your.name.example.com/?xpath=/VCARD/TEL&lid- 
format=mime:text/plain
and obtains the then most current phone number of yours, and dials it.

If you do not want to "publish" your phone number to the general  
public, but you'd be okay if I got it, the phone would have to sign  
that URL first with my public key, so the request would look like
     http://your.name.example.com/?xpath=/VCARD/TEL&lid- 
format=mime:text/plain&lid-credtype=gpg..&lid-credential=somebigstrong

It's a little bit more complicated for using OpenID authentication,  
but the same principle applies and I think this is a quite  
interesting use case.

> I did, back in the early days of OpenID, write a non-web OpenID  
> consumer
> that worked by making a request to the server supplying a dummy URL  
> and
> parsing the response arguments right out of the redirect URL rather  
> than
> following the redirect. This is obviously a big hack,

I'm not so sure it is a big hack. It's only a hack because the OpenID  
spec does not say that this is something that is expected. But it  
could say that, and what would be wrong with that?

> and still requires
> that there be a browser available to do the optional "Do you want to
> allow this site?" step that some servers do. It has the ugly feature
> that LiveJournal asks:
>
> Do you want to allow:
>     http://www.suspicious-looking-dummy-url.com/
> ...do know you are you?
>    [Yes] [No]
>
> Also, this was based on the original OpenID protocol. I don't remember
> how it worked in enough detail to be able to quickly guess whether it
> would work on the released OpenID protocol or on LID.

I agree that the interface for managing white lists -- whether that  
is senders of messages, or sites that you want to sign in  
automatically, or people who get to have your phone number or  
whatever -- will probably always be web based.

There is one bit missing -- in both OpenID and LID -- so far, and  
that is a protocol by which a 3rd party can request to be put on a  
certain white list, and that request is queued until the user comes  
by to decide on it. And then, the 3rd party is being notified about  
the resolution of the request.  Not exceedingly hard to design, but  
simply nobody has done it so far as far as I know.


Johannes Ernst
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lid.gif
Type: image/gif
Size: 973 bytes
Desc: not available
Url : http://lists.danga.com/pipermail/yadis/attachments/20060106/c6f90e45/lid.gif
-------------- next part --------------
  http://netmesh.info/jernst