Decius wrote:

For example, it seems like you don't really want to authenticate to this system every time. I'd prefer it handed you a cookie, and I embed a web bug from their site in my page. When you hit my site, they'll get their cookie, and the url for the image I'll link will include a hash that uniquely identifies this user/session on my site. I can then make a request to their site with that hash and get back the user details associated with the hash in an easy to parse XML file. When you go to reply to a post is automagically filled out with your details.

I am trying to understand what you are describing. I seem to be failing.

If I understand it, you generate an image request that points to my openid authentication service. In the process of serving that request, I authenticate with my authentication server -- if I have a logged in cookie, this is transparent. You may now query my authentication service about the session tag that you generated and I authenticated to, and it can provide you with details of my account.

Before I argue why that doesn't work, can you confirm that that is what you mean?

My purpose is that you can send emails out, and they come from an address, and I want to make sure that address works. Having that take care of once rather then for every site on the net would reduce the hassle associated with making accounts on sites.

That seems like a worthy project. But I don't see that they need to be tied; or at least, yours seems like a secondary benefit that could be a simple extension. My OpenID server can claim to have an authorative email address, and you can use that whether it is true or not -- if you don't trust that mechanism, either show off the address it is going to with a user modification option, or make them input it despite potentially having it available..

I'm not sure how much of an advantage you could derive from it regarding registration, as I claim that the bulk of that is still for client tracking.

RE: news: OpenID support