Comments on: OpenID 2.0 Status http://kveton.com/blog/2006/10/07/openid-20-status/ Husband, father, geek, pizza maker & bacon lover Sun, 23 Nov 2008 17:00:57 +0000 http://wordpress.org/?v=2.3.2 By: http://kveton.myopenid.com/ http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1625 http://kveton.myopenid.com/ Wed, 11 Oct 2006 15:44:34 +0000 http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1625 James: there is no way to transfer your identity information from one provider to another right now. If you have your own domain, however, you can simply point it at whatever provider you choose. i-names maintains a central database of i-names-to-i-numbers. This allows you to seamlessly move from i-broker to i-broker without having to lose your information. This is a centralized model and one that might not work for everyone; there is a central repository that is managed by the i-brokers. Think root servers on the Internet and registrars. James: there is no way to transfer your identity information from one provider to another right now. If you have your own domain, however, you can simply point it at whatever provider you choose.

i-names maintains a central database of i-names-to-i-numbers. This allows you to seamlessly move from i-broker to i-broker without having to lose your information. This is a centralized model and one that might not work for everyone; there is a central repository that is managed by the i-brokers. Think root servers on the Internet and registrars.

]]> By: James http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1623 James Wed, 11 Oct 2006 10:26:10 +0000 http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1623 Perhaps this is out of scope for OpenID itself, but one feature request I saw was the ability for a user to swap one identity provider for another - eg say I don't want to use typekey any more and instead set up my own OpenID provider. How can I tell all the sites that+use my typekey to authenticate against my own provider, but keep the associated data? Or is the openid URI supposed to be the only identifier ... *reads up on i-name* maybe i-name is what I want. *recovers comment from cookie, fails to post using openid* Perhaps this is out of scope for OpenID itself, but one feature request I saw was the ability for a user to swap one identity provider for another - eg say I don’t want to use typekey any more and instead set up my own OpenID provider. How can I tell all the sites that+use my typekey to authenticate against my own provider, but keep the associated data? Or is the openid URI supposed to be the only identifier … *reads up on i-name* maybe i-name is what I want.

*recovers comment from cookie, fails to post using openid*

]]> By: kveton http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1595 kveton Tue, 10 Oct 2006 13:52:56 +0000 http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1595 Robin: what is some of the complexity that you're concerned about? It should be just as easy with v2.0 to implement as v1.1 with the libraries that will be released a few days after the specification is finalized. Robin: what is some of the complexity that you’re concerned about? It should be just as easy with v2.0 to implement as v1.1 with the libraries that will be released a few days after the specification is finalized.

]]> By: http://robin.myopenid.com/ http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1594 http://robin.myopenid.com/ Tue, 10 Oct 2006 13:50:03 +0000 http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1594 I think 2.0 is too bulky. I\'d like to see, at least, a 2.0mini which will remove some of the complexity that 2.0 draft 9 is plagued with. Robin I think 2.0 is too bulky. I\’d like to see, at least, a 2.0mini which will remove some of the complexity that 2.0 draft 9 is plagued with.

Robin

]]> By: Forsooth http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1555 Forsooth Mon, 09 Oct 2006 20:45:20 +0000 http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1555 Hey no problemo... I do think there's lots of goodness in i-names when used for attributes. But I would go so far to say that it's broken in implementation complexity when used as a top-level namespace. This will become readily apparent to implementors fairly soon, so I'm actually not too worried that it will ever find its way in. Hey no problemo…

I do think there’s lots of goodness in i-names when used for attributes. But I would go so far to say that it’s broken in implementation complexity when used as a top-level namespace. This will become readily apparent to implementors fairly soon, so I’m actually not too worried that it will ever find its way in.

]]> By: kveton http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1547 kveton Mon, 09 Oct 2006 17:50:03 +0000 http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1547 i-name support has been critical because of its place in the identity world. Lots of people really are liking the i-name concept, the people behind it and the possibilities it may enable. And yes, if you put it in terms of HTTP then yes, OpenID is a data exchange ... but c'mon!! That sounds o' so not sexy! :-) Thanks for the comments and kudos Forsooth ... I appreciate folks keepin' me/us honest ... :-) i-name support has been critical because of its place in the identity world. Lots of people really are liking the i-name concept, the people behind it and the possibilities it may enable.

And yes, if you put it in terms of HTTP then yes, OpenID is a data exchange … but c’mon!! That sounds o’ so not sexy! :-)

Thanks for the comments and kudos Forsooth … I appreciate folks keepin’ me/us honest … :-)

]]> By: Forsooth http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1545 Forsooth Mon, 09 Oct 2006 17:00:45 +0000 http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1545 I-name support is not even in OpenID yet, how has it been critical to early adoption? I disagree about OpenID not being about data exchange. Really HTTP is obviously all you need for data exchange, the only disadvantage is that it's not peer-to-peer. (asymmetry between requester and responder) Whereas OpenID + HTTP allows either parter to initiate a request because of shared secrets allowing the requester to be authenticated as well as the responder. Anyway don't mean to sound hypercritical or anything, I think you guys are doing a great job, and keep up the good work! I-name support is not even in OpenID yet, how has it been critical to early adoption?

I disagree about OpenID not being about data exchange. Really HTTP is obviously all you need for data exchange, the only disadvantage is that it’s not peer-to-peer. (asymmetry between requester and responder) Whereas OpenID + HTTP allows either parter to initiate a request because of shared secrets allowing the requester to be authenticated as well as the responder.

Anyway don’t mean to sound hypercritical or anything, I think you guys are doing a great job, and keep up the good work!

]]> By: kveton http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1522 kveton Mon, 09 Oct 2006 15:39:05 +0000 http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1522 Kai Hendry: I actually really love that idea and have thought in a general sense it would quickly get us to attribute exchange without re-inventing the wheel. You could couple this with the data transfer protocol if you want to do it securely (in the case where you want to make sure that the user is who they say they are). I've heard Brad over at <a href="http://www.livejournal.com" rel="nofollow">LiveJournal</a> mention that he would support microformats if <a href="http://www.technorati.com" rel="nofollow">Technorati</a> would support OpenID. I think that would be fantastic and we'd have a great feedback loop on two really simple technologies that would just feed off of each other. Kai: you want to go ahead and propose that to the OpenID general list? :-) Kai Hendry: I actually really love that idea and have thought in a general sense it would quickly get us to attribute exchange without re-inventing the wheel. You could couple this with the data transfer protocol if you want to do it securely (in the case where you want to make sure that the user is who they say they are).

I’ve heard Brad over at LiveJournal mention that he would support microformats if Technorati would support OpenID. I think that would be fantastic and we’d have a great feedback loop on two really simple technologies that would just feed off of each other.

Kai: you want to go ahead and propose that to the OpenID general list? :-)

]]> By: kveton http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1521 kveton Mon, 09 Oct 2006 15:36:16 +0000 http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1521 Forsooth: I think i-names support has been critical to the early adoption of OpenID. I am also a little concerned about confusion for end-users but I still believe its important today. OpenID is just authentication with a dash of discovery and attribute exchange on the horizon. It is not data exchange today. I should also point out that the draft for the data transfer protocol that I listed in this post is quite out of date. Forsooth: I think i-names support has been critical to the early adoption of OpenID. I am also a little concerned about confusion for end-users but I still believe its important today.

OpenID is just authentication with a dash of discovery and attribute exchange on the horizon. It is not data exchange today. I should also point out that the draft for the data transfer protocol that I listed in this post is quite out of date.

]]> By: Kai Hendry http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1402 Kai Hendry Sun, 08 Oct 2006 23:19:02 +0000 http://kveton.com/blog/2006/10/07/openid-20-status/#comment-1402 Couldn't OpenID parse microformat's hCard to gleam user's information? Perhaps it could be at least an optional feature of a server to help fill in the blanks... http://microformats.org/wiki/hcard Couldn’t OpenID parse microformat’s hCard to gleam user’s information?

Perhaps it could be at least an optional feature of a server to help fill in the blanks…

http://microformats.org/wiki/hcard

]]>