Log in

No account? Create an account
A proposal: email to URL mapping - brad's life [entries|archive|friends|userinfo]
Brad Fitzpatrick

[ website | bradfitz.com ]
[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

A proposal: email to URL mapping [Feb. 3rd, 2008|01:43 pm]
Brad Fitzpatrick
[Tags|, ]

People have different identifiers, of different security, that they give out depending on how much they trust you. Examples might include:
  • Homepage URL (very public)
  • Email address (little bit more secret)
  • Mobile phone number (perhaps pretty secretive)
As has been shown with OpenID, XFN, etc... URLs are people too. You can do a lot of things with a URL: give out information, point to other identifiers, do Yadis service discovery on it (to find, say, an OpenID server, calendar server, friend/contact server, etc...)

It's also possible to do a <a href="mailto:me@example.com" rel="me"> to an email address, making a one-way claim that you own an email address. But how do you make a rel="me" back from the email address to a URL, completing the cycle?

Another problem people have been bringing up regularly is how to use an email address as an OpenID identifier. For this to work, you need to do service discovery on it to find out the O.

If you could map from email address to URL (going from a private identifier to a more public identifier), both problems are solved... the mapping from email to URL is the rel="me" link, and the pointed-to-URL can then be used for any URL-like purpose:
  • Being an OpenID identifier
  • hosting an hCard
  • Pointing to another Yadis service type (OAuth-protected friends/contact server)


How to map from an email to a URL?
I propose:

Given, say, bradfitz@my-email-service.com, you do Yadis capabilty discovery on my-email-service.com, looking in the resultant XRDS service document for a capability of type, say, "http://schemas.net/2008/email-to-url/", and the resultant endpoint which speaks that capability protocol. Here's an example document (retrieved via Yadis, which means sending HTTP Accept: header of right mime type and getting it immediately, or looking at link from <head>):

<?xml version="1.0" encoding="UTF-8"?>
<!-- Sample YADIS XRDS file -->

    <Service priority="0">


The 2008/email-to-url capability endpoint (email2url_mapper.cgi, in this example), then speaks this "protocol":
GET /email2url_mapper.cgi?email=bradfitz@my-email-service.com HTTP/1.1
Host: apis.my-email-service.com

HTTP/1.1 302 Found
Location: http://bradfitz.com/
That's about it.


Why the Yadis indirection?
That's what Yadis is for. Discovery capabilities of an endpoint. This is exactly how OpenID works. There are libraries for it. Yadis discovery is cached. In practice, this step won't cost.

Privacy! Stealing my email addresses!
No, you start with the email address. You already have it. It's up to the user to determine if they want a public URL (presumably more public than their email address) attached to their email address.

Why not use $X?
What's X? I'm not aware of anything else. (Except for something I saw recently which was tied to OpenID and was pattern-based)

Why not pattern-based?
I want to tell, say, hotmail.com that my URL is http://bradfitz.com/, not MSN Spaces, or whatever hotmail.com might choose for a static username-to-URL mapping. It needs to be a dynamic lookup, not a published pattern.

Why not tie this to OpenID?
Layering violation.

The 302 could include an expires header.

But only the dorks would support this.
Maybe, but that's how it always starts. Maybe we could get some big email providers to do this too. Imagine a tab in your favorite Big3/Big4's email options which says:
Your public URL: [___________________________]
(This is the web URL that will be given out to anybody with your email address.)

The end

From: ext_4309
2008-02-04 06:55 am (UTC)

What about the other way round

You propose to map all users' e-mail addresses to the same Yadis file, and then you "personalize", to each user, the result by going through the CGI indirection.

What about the other way around: you allow a potentially different Yadis file for every user. That way, each user could express user-specific information in that file, instead of having to be put into the same straightjacket as all other million users. Also, it would allow to return multiple values, which in turn could be annotated with things like priority or whatever annotations make sense.(E.g. multiple "me" relationships with a qualifier what kind of "me" it is)

foo@example.com -> Yadis discovery on http://example.com/~foo -> contains the actual endpoint, not the CGI script. Of course, sites could still decide to map all accounts to the same Yadis file, but architecturally it wouldn't be a requirement.
(Reply) (Thread)
[User Picture]From: brad
2008-02-04 07:06 am (UTC)

Re: What about the other way round

You can do Yadis discovery (or hCard parsing, etc) on the resultant URL.

So Yadis on gmail.com returns bradfitz.com. Yadis on that returns my primary and secondary openid servers, optionally using delegation.
(Reply) (Parent) (Thread)