Simplifying OpenId

[S. Alexander Jacobson]

On Mon, 9 Jan 2006, Martin Atkins wrote:
> I don't want to give consumer sites my email address. I don't want them
> to contact me.

Then you must not be able to use a lot of web sites that require an 
email address e.g. craigslist or the nytimes.  Many actually send the 
user a confirmation email and require that the user click on the 
enclosed link in order to approve an account.  Users who don't like 
exposing their real email address use throwaway email account to cover 
this problem.  All I am trying to do is lower the transaction cost of 
these existing workflows.

> You're adding new DNS RR types now? Bang goes any chance of adoption.
> Nameservers won't support it for years, and in the short term most of
> the freebie DNS hosting services can't even manage SRV records, let
> alone some wacky new one you've just made up.

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.

And if the issue is really new DNS RR types then we can just use a TXT 
record for an ad_hoc subdomain of the mail domain e.g.

   openid_.gmail.com  IN TXT  http://authserver.google.com
   openid_.mail.yahoo.com IN TXT http://auth.yahoo.com
   openid_.degeneration.co.uk IN TXT http://martinatkinsserver.com

> So essentially, you've just created a weak LID clone with an extra layer
> of abstraction over it so you can pretend you're using email addresses
> as tokens. In practice, all you've done is created identifiers that look
> a bit like email addresses; my email address is unlikely to be the same
> as my identifier because my free mail hosting provider doesn't support
> authentication and my identity provider doesn't provide email service.

No.  The identifies really are email addresses.  The entity in control 
of the mail server is the entity responsible for authentication.  If 
such an entity isn't offering a web based mode of authentication 
(exposing a valid openid_.* TXT URL), the natural failure mode is the 
one used now, an email with a confirmation link.  The good news is 
that everyone has an email address and everyone understands that 
sometimes they need to click on confirmation links in them.

> Also, if you're going to add new stuff to DNS anyway, why not just make
> the identifier be a domain name rather than pretending it's an email
> address? I can enter frank.livejournal.com just as easily as I can enter
> frank at livejournal.com, and that makes the procedure much simpler.

Because everbody has at least one email address.  Most people don't 
have domains.  And the user of an email address already trusts their 
email provider to authenticate them (to receive their email).  The DNS 
is per mail server domain NOT per email address.

> Of course, DNS responses have a practical upper limit on length, so
> returning entire URLs  which can potentially be quite long in them is
> likely to cause strange failures with differing DNS server and client
> implementations.

Fortunately, this is very controllable so it should not be much of an 
issue.  Remember it is one auth domain per mail domain.  So on average 
we are talking about adding maybe 10 characters to a domain to refer 
to a URL.  This is strikes me as entirely a non-problem.

> Sorry to be so negative, but you've already enumerated every possible
> benefit I can think of, so I figured your proposal could do with a
> healthy dose of drawbacks too.

No problem.  It is important to work through all the details.  The big 
change I made here is from a new RR to the TXT record of a reserved 
word subdomain.  I think I've now addressed all your objections. 
Please tell if there are more or if there are others that I have 
missed....

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








> S. Alexander Jacobson wrote:
>>
>> On reflection, I don't get the use of <link rel...> tags and homepage
>> URLs.  Email addresses already the de-facto Internet standard for user
>> identity.  We should be enhancing use of this namespace rather than
>> creating new ones.  Here is the obvious protocol for authenticating
>> email addresses:
>>
>>   1. User supplies email address to consumer site.
>
>
>>   2. Consumer site looks up UserId DNS record for email address domain name.
>>      (Note: I don't think UserId records need to have priorities like MX
>>       records)
>
> You're adding new DNS RR types now? Bang goes any chance of adoption.
> Nameservers won't support it for years, and in the short term most of
> the freebie DNS hosting services can't even manage SRV records, let
> alone some wacky new one you've just made up.
>
>>   3. If UserId record is absent/broken, send email with a validation URL.
>>      If UserID DNS record is present, consumer site posts to UserID_URL:
>>
>>      POST UserID_URL
>>      content-type: application/x-www-form-urlencoded
>>
>>      email=user at domain&is_email=is_email_url
>>
>>      201 CREATED
>>      Location: redirectURL
>
> So essentially, you've just created a weak LID clone with an extra layer
> of abstraction over it so you can pretend you're using email addresses
> as tokens. In practice, all you've done is created identifiers that look
> a bit like email addresses; my email address is unlikely to be the same
> as my identifier because my free mail hosting provider doesn't support
> authentication and my identity provider doesn't provide email service.
>
> This is a similar situation with Jabber: my Jabber ID is completely
> different from my email address, and though I could make it the same
> with substantial effort on my part, that's just because I have my own
> domain and the technical knowledge to run my own DNS server and my own
> Jabber server.
>
> Also, if you're going to add new stuff to DNS anyway, why not just make
> the identifier be a domain name rather than pretending it's an email
> address? I can enter frank.livejournal.com just as easily as I can enter
> frank at livejournal.com, and that makes the procedure much simpler.
>
> Of course, DNS responses have a practical upper limit on length, so
> returning entire URLs — which can potentially be quite long — in them is
> likely to cause strange failures with differing DNS server and client
> implementations.
>
>
>
> Sorry to be so negative, but you've already enumerated every possible
> benefit I can think of, so I figured your proposal could do with a
> healthy dose of drawbacks too.
>
> All the best,
> -Martin
>
> ** CRM114 Whitelisted by: mart at degeneration.co.uk **
>