| A proposal: email to URL mapping |
[Feb. 3rd, 2008|01:43 pm] |
Background
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)
etc.
So....
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 -->
<xrds:XRDS
xmlns:xrds="xri://$xrds"
xmlns="xri://$xrd*($v*2.0)">
<XRD>
<Service priority="0">
<Type>http://schemas.net/2008/email-to-url/</Type>
<URI>http://apis.my-email-service.com/email2url_mapper.cgi</URI>
</Service>
</XRD>
</xrds:XRDS>
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.
FAQ:
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.
Caching?
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
Discuss? |
|
|
| Sun & OpenID |
[May. 15th, 2007|09:34 am] |
This is good for OpenID...
Sun just pre-announced their OpenID IP Non-Assertion Covenant, saying very clearly and strongly that they won't assert any patent claims against anybody implementing OpenID, as long as said person/company doesn't assert any patents against any other OpenID implementation (not just against Sun). And also said they don't necessarily have any relevant patent claims. etc, etc.
The official legalese (going up on their website soon) is actually very readable. Thanks, Sun!
Basically big company making public statement that OpenID is safe and preventing anybody from suing anybody.
Patent cold war == good thing (considering current patent situation).
( Picture stolen from David... ) |
|
|
| AOL supporting OpenID |
[Feb. 16th, 2007|05:25 pm] |
Yes, friends, AOL is now supporting OpenID.
I figured I'd better say something so everybody stops spamming me about it. :-)
Microsoft, AOL, Verisign, Symantec, .... anybody else I'm forgetting? Good times. |
|
|
| Microsoft & OpenID |
[Feb. 6th, 2007|09:54 am] |
So Bill Gates just announced earlier this morning (while I was sleeping in / recovering) that Microsoft is supporting OpenID.
When I made OpenID, I intentionally left the method of authentication undefined. (feature, not a bug!)
Now people ask me what I think about Microsoft supporting it, using their InfoCards as the method of authentication.... I think it's great! So far I've seen Kerberos integration for OpenID, voiceprint biometric auth (call a number and read some words), Jabber JID-Ping auth, etc.... all have different trade-offs between convenience and security. But as more people have CardSpace on their machines, users should get both convenience and security. (sorry, I'm not totally up on all the details... just seen demos....)
Anyway, I and others at Six Apart are thrilled to see Microsoft supporting OpenID. Kudos!
Other news from the blagosphere:
http://www.identityblog.com/?p=668
https://blogs.verisign.com/infrablog/2007/02/verisign_microsoft_partners_to_1.php
http://kveton.com/blog/?p=221
http://www.sxip.com/newsitem-microsoft_openid_community_sxip_janrain_verisign
http://netmesh.info/jernst/Digital_Identity/cardspace-openid.html
http://yro.slashdot.org/yro/07/02/06/2152214.shtml |
|
|
| OpenID in Firefox 3?! |
[Jan. 11th, 2007|10:36 am] |
What's this I hear about OpenID planned for Firefox 3?
Anybody know more?
I'm excited that OpenID adoption is picking up!
(I've even got Ben to add RP/Consumer support to Vox... he just needs to hide a bunch of things in the UI when you're logged in as an OpenID user that you can't do as a "half user"...) |
|
|
| OpenID vs. Roboform |
[Sep. 1st, 2006|11:32 pm] |
Heh.... CNET Article on OpenID vs the comments on that post:
"You should use Roboform!"
"Upgrade to a Mac and use Keychain!"
"I love Roboform!"
Heh.
Not quite getting it, y'all. |
|
|
| OpenID and SixApart |
[May. 30th, 2006|10:58 am] |
I've been getting an increasing number of inquiries lately into the state of SixApart's committment/involvement with OpenID now that David Recordon has left SixApart and moved to Verisign.
Hopefully this post will clarify the state of things.
I originally did OpenID as an independent side project, not officially sanctioned by work. I worked on integrating it into TypeKey and LiveJournal and tried to get others at work excited about it. David was one of the most excited, helping me do more LiveJournal integration work, etc. Mark Pascal and Brad Choate also got interested, working on the MovableType side.
(The evidence that OpenID isn't a company-wide thing shows in that TypePad still doesn't have OpenID consumer support.)
As OpenID got more popular and we started to talk to others in the identity space, I started to get overwhelmed and David jumped to my rescue, helping out in the diplomacy world. While I try my best to be patient, David wins hands down. He acted as my buffer and news filter to/from the community.
My goal with OpenID has always been one of pragmatism. I wanted to enable the most with the smallest spec. I wanted something so people could taste roamable identity with minimal effort. Yes, OpenID doesn't solve all problems, but that's a feature!
If solving 90% of use cases takes a 10 page spec, solving 95% often takes a 100 page spec, and 97.5% takes a 1000 page spec. I didn't want a huge spec. 90% is good enough.
My hope is that everything else can be layered atop OpenID as extensions.
This is why I haven't been incredibly thrilled about Sxip, etc. I think profile exchange should be an extension, as should third-party proofs, etc.
JanRain's OpenID extensions for simple registration (profile exchange) show this is possible, and can be done right. I totally applaud such efforts.
So what does David's departure mean for OpenID?
It means OpenID is better than ever! David can work on OpenID a lot more at Verisign. David and I still see other regularly, too, and we're continuing to work on OpenID. The current plan is to address all of the community's concerns:
1) turn the existing spec into a new document that looks more like what people in the identity community want to see. Also updating terminology in places that the identity community has agreed on terms. This is largely a reformatting problem. No OpenID spec changes will come out of this.
2) document the proper way to do OpenID extensions, documenting/referencing the JanRain SimpleReg spec for profile exchange. probaly also adding SimpleReg support to LJ.
3) update the then-reformatted spec to address community requests/confusion/concerns. More on this later. David and I have started to discuss it, but I don't want to misrepresent any of that here, so we'll let it happen on the mailing list.
I'll wrap this post by reiterating that:
1) OpenID is supposed to be small/simple/modular, and that's why the core shouldn't be moving/changing much anymore. It largely Just Works, modulo some confusion which better docs will help. The interesting work is on the edges/extensions/integration.
2) David's departure from SixApart is a good thing for OpenID. He left largely so he could work on identity more. See, for example, the Verisign Personal Identity Provider (PIP) that David and his group have been working on. |
|
|
| OpenID and Subversion |
[Mar. 21st, 2006|12:44 am] |
Artur, David and I discussed how to make Subversion commits using OpenID authentication work today, without changing the subversion client.
Nutshell: client-side tiny HTTP proxy that does the OpenID protocol. Then transmitted user/pass is URL/signature. (well, signature with unixtime that's close to the server's unixtime, so server can implement, say, 24 hour anti-replay cache)
Result: we can grant people commit just by their URL, without giving them a username/password. And don't have to deal with "But I want to change my password!" crap.
Anybody want to hack it? |
|
|
| OpenID in TypeKey |
[Sep. 21st, 2005|12:23 pm] |
The TypeKey that speaks OpenID is live!
Just go rebuild your TypeKey profile page (tinker with your profile or something) and then you can use your profile URL as your OpenID on LiveJournal.com/etc. |
|
|