| I commend you on the cleanliness of your reference implementation. It looks to be a completely by the book rails application. Anyone could contribute I am sure. This is in sharp contrast to the tent guys who for some reason rolled their own web framework in ruby, leading to a very messy codebase in my opinion. But more on topic, I am having a bit of trouble understanding what this service is going to do. What is the usecase? I think I got this from it: 1. A user wants an identity, so he registers at aka.nu (or other provider) and gets a nice url like tinco.aka.nu. 2. The user uses this url as an openid url to create an account on stackoverflow. 3. Stackoverflow gets information about the user by querying the url for meta information. But.. this is exactly what openid does. I have an openid account at myopenid.com, and pointed me.tinco.nl to redirect to it. Now when you go to me.tinco.nl you see my public openid profile. And I log in to stackoverflow with me.tinco.nl as the identifier. And stackoverflow filled in some of the fields with information it got from myopenid. What is your unique selling point? |
First off I should note that an aka is an OpenID (see http://paul-odin-openid-test.blogspot.com/2012/12/hey.html) so all of the pros and cons of OpenID should in principle apply to akas. Akas just have a few constraints (a domain name served over HTTPS) and extras (the host-meta file metadata).
Here are a few circumstances where I think these additions could prove useful:
(1) Following akas. Given an OpenID like me.tinco.nl I don't think I can enter it into an app and keep track of what you're up to. The extra metadata allows an app to find your other profiles and subscribe to your activity. One of the features I was working on but didn't finish yet (there's some dormant code at https://my.aka.nu/hub) was to have the ability to subscribe to the host-meta file itself and automatically discover new additions and changes to your profile.
(2) Using your aka as a personal namespace. I'm hoping to add the ability to use create subdomains under your aka (for example a blog at blog.paul.aka.nu). Obviously you can do this already if you have your own domain name but it's generally viewed as an 'advanced' feature. Also there's no reason you can't use an aka as a domain for your email address. Incidentally this was the reason I originally bought aka.nu, as a demo domain for a simplified DNS administration tool I was working on.
(3) Authentication for non-browser apps. Let's say you've posted a photo somewhere and authorized access to me, paul.aka.nu. I could log in myself to wherever it's hosted using that as an OpenID, but what if I'm not using a browser to access it? My client can send you an assertion that it's accessing it under the authority of paul.aka.nu but you still need to go back to paul.aka.nu to verify it, which is where the extra metadata comes into play. (App.net has similar functionality: http://developers.app.net/docs/authentication/identity-deleg...)