Simplifying OpenId

[Dick Hardt]

On 9-Jan-06, at 12:04 PM, S. Alexander Jacobson wrote:

>> if (3), then why not just document <link rel= ...> tags and each  
>> protocol can work on solving all the issues in their own way?
>
> On reflection, I don't get the use of <link rel...> tags and  
> homepage URLs.

It is for protocol discovery, not user identity. I think everyone on  
this list is aligned that URLs are a good way to identify a user that  
does not disclose more info than you would want disclosed.

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

A view I have is that URIs are identities. So mailto:dick at sxip.com is  
an identity.

>
>   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)
>
>   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
>
>   4. Consumer redirects user to redirectURL and grants authentication
>      if it receives a GET is_email_url
>
> Advocacy:
>
> * All internet users have email addresses. Users without email
>   addresses can safely be ignored.

not necessarily true.

Few people have lots of email addresses. 1:1 relying party <-> user  
identity mapping is key to conform with Kim's laws of identity  
(unidirectional) Something that is hard to do with OpenID or LID --  
and really hard to do with email as proposed below

>
> * Email addresses designed to be easy to type (much less
>   punctuation!).  URLs are really verbose for manually entered data.
>   (If you don't require http:// or https:// in URLs then you open up
>    substantial ambiguity!)
>
> * Email addresses imply both identity and authentication.  Homepages
>   imply nothing.  Expecting most users to understand the difference
>   between homepages with appropriate link tags and homepages that
>   don't seems lik a tall order.

The ability to edit a homepage implies ownership and control.

>
> * Most users do NOT currently have homepages.  Users without homepages
>   need to be supported.  Absent URI or email addresses, there is no
>   global namespace.  Per site identity namespace fragmentation limits
>   interoperability.

The Homesite managing a users identity can easily generate a page for  
them.

>
> * DNS is designed for exactly this sort of directory lookup.  Multiple
>   link tags in ill-formed HTML create interesting opportunities for
>   ambiguity.  Moreover, requiring that homepages be HTML is just poor
>   design.  We should not prohibit flash homepages or pages with
>   some other XML content-type styled by XSLT to generate HTML.

I think you are mixing protocol discovery up with identity.

Also, most of us are thinking more of blogs, then homepages ...