Simplifying OpenId

[S. Alexander Jacobson]

On Tue, 10 Jan 2006, Martin Atkins wrote:
>> Users understand email as identity.  Support from a few just a mail
>> server operators (Google, AOL, MSFT, and Yahoo) would result in support
>> for ~100m users basically instaneously.  It is hard to see how any
>> protocol that requires user adoption of new homepages/domains is even
>> close to as adoptible.
>>
>
> This isn't how "adoption" works. Things are first tried out by early
> adopters. Early adopters are just random geeks and other interested
> users. These early adopters must be able to do this thing for themselves
> in the short term.

Agreed.  I initially figured early adopters are capable of doing 
adding a new DNS RR record.  As a result of your comment I modified it 
so early adopters now only need to add a TXT record in a special 
subdomain.   I think it is now easy enough for most every 
reasonable early adopter.

> No big providers — especially those you listed — will
> support this until it's already in common use and it seems to provide a
> benefit.

The problem I had with the OpenId spec as it now stands is that once 
the early adopters have tried it, the path from there to wide scale 
adoption is MUCH harder.  Explaining the concept of authorizing domain 
names/homepages to millions AOL users just strikes me as infeasable.

In contrast, these people already understand the email confirmation 
process well enough and if they have already provided an email address 
a redirect to the auhtorization page of their existing email provider 
would be entirely unshocking to them.  As such, I can see how once we 
have test-driven the concept, the biggies may adopt it.  I just don't 
see how the biggies can adopt the homepage/domain model on any 
near-term basis.

> On the other hand, web sites are one thing that "the public" has
> mastered. I'm not going to claim that any old guy off the street and
> write a web page, but certainly more people can do that than can
> administer a DNS domain and run their own email service. The barrier of
> entry for an early adopter in a web-based approach is much lower than in
> your approach.

No.  Email, email address confirmation, and *using* web sites are the 
only things that "the public" has mastered.  Even the old guy off the 
street knows how to go to a web site, enter an email address, and do 
an email address confirmation.  If his email provider automatically 
handled address confirmation via a web based interface he would be 
entirely unsurprised.

The barrier to entry for implementation are basically identical.  In 
the email case, you update a DNS record to point to an auth server. 
In the html case, you update a web page to point to an auth server. 
The difference is that in the former, implementation immediately 
supports all users in that domain.  In the later, it only supports one 
user.

In other words, the email version gets much more early adopter bang 
for the buck, both in terms of immediate service and lessons for the 
biggies.

> ** Your proposal doesn't actually function as an email validation
> replacement at all, really. There's nothing to stop me setting up a
> domain which does not provide email service but which answers "Sure, why
> not?" to all identity inquiries anyway. This means I get to sign up with
> an invalid email address, which means that your proposal will never be
> adopted by those sites that for some reason feel they MUST have a valid
> contact email address for every user.

Nothing currently stops users from setting up throwaway hotmail 
accounts for this purpose either.  Nothing to stop me setting up a 
procmail script that automatically hits all the enclosed URLs.  And, 
in the openId case, nothing stops me from pointing my homepage to a 
server that says "Sure, why not?" to all queries either. I'm not sure 
I see a difference here.

-Alex-

______________________________________________________________
S. Alexander Jacobson tel:917-770-6565 http://alexjacobson.com