3 ms·

> I would explain further, but since you don't seem to bother to read carefully, I won't take the time. That's not fair. I discarded 2 long drafts of the repl

by kniwor 17y ago

> I would explain further, but since you don't seem to bother to read carefully, I won't take the time. That's not fair. I discarded 2 long drafts of the reply above and went with the most succinct one I could find. This is exactly what inertia is. "I will not move to $new because I truly believe it destroys all the benefits I get from $old and now I have to invest time and effort to learn $new and rework my workflow to account for it." I sincerely believe that the original parent is describing inertia. Also, the one leak destroying all my accounts is a misunderstanding of openid. You can use separate openid providers and openids for various services. (I do.) Login without openid is a n to n problem, after openid it becomes a m to n problem and you can choose m as and how you want to. If you want you can still go with n to n. And again, can you elaborate on what current capabilities does openid destroy? I can't see any.

RiderOfGiraffes 17y ago
OK, I regard this as an opportunity to learn. So far I have invested about 3 hours in trying to understand how I can use OpenID to do what I do now, and I feel none the wiser, and resent the loss of time. You appear to be that rarest of things - a knowledgable enthusiast who will try to communicate clearly. So, here I am, approaching a new site that requires authentication. Under my current workflow I select a userid, which may, but need not, replicate an existing userid. I select a password which is unique, and an email address which is unique. I use these credentials to signup, then reply to the confirmation email. Now I have an account on the new service using a userid with a unique password. If that password is compromised, none of my other accounts are compromised. Further, if the email address I use gets leaked, I know who leaked it. This is how I have confirmed that eMusic are email address leaking bastards. This last capability is important to me, just as is the ability to use unique passwords wherever I go to avoid one leak compromising multiple accounts. Can you now point me at a document that will show how to obtain the above facilities? I'd appreciate it. Thanks. EDIT: In positioning myself to understand what you write or point me at, I have further found this: http://www.links.org/?p=187 http://www.links.org/?p=187 I'd appreciate your comments on that as well. Thanks.
- deleted 17y ago
  [deleted]
- kniwor 17y ago
  I hope this helps. I think the problem with writing simple introductions to openid is that it just offers too many options and it is difficult to decide how to approach. Here is an equivalent but by no means equal workflow[a]. Pre0. Choose your openids before you have the sites needing them! This is username/password registration/recovery/emails as it always was[b]. You come across a new site (web-app) and it supports openid login. Registration workflow: Reg0. We choose some openid from Pre0. Login into that openid at the openid provider's website in a new tab[c]. Reg1. We tell web-app our openid. What happens then is similar to a net banking/credit card transaction. Web-app takes us to openid provider's website. We say yes, we would like to register/authenticate/allow this and we are now registered and logged in. Reg2. We can now safely log out of our openid provider in the other tab if we want. We will still remain logged in at the web-app. Rule of thumb: Openid provider doesn't know what is going on at the webapp and vice a versa and they cannot affect each other in any way at this stage. (Separate cookies, no shared sessions.) You visit the website again. Login Workflow: Log1. We go to our openid provider first and login.[d] Log2. Then we go to our web-app and put our openid in. Webapp does some talking behind the scenes with the openid server and logs us in. Log3. After this point, web-app and openid provider do not talk or know whats going on at the other place. We logout of either server separately. End of workflow. [a] Initially, I replicated your workflow feature for feature but that felt like replicating a svn workflow in git. Just like git, openid is a new paradigm. One can replicate old workflow features in many many ways but methods of doing so are hardly instructive or interesting. If you want me to do so or bring back some/all feature(s) back into this workflow I will gladly do so, if only just to show that it can be easily done. openid is very much the git of the authentication world. It is a surprisingly elegant federated and distributed replacement for old small centralized island situations with a similar price in inertia and the learning curve. [b] May I recommend not mixing your existing ids (yahoo/gmail/etc) with these openids. The single tool for a single job philosophy is nice. wordpress.com is my favourite openid provider, simple interface, minimal and trustworthy enough. myopenid.com is a more fully featured option. [c] At the risk of sounding verbose and simultaneously committing the sin of not using example.com, here is an actual example. I am looking at the openid login box at stackoverflow.com (SO) and I own user.wordpress.com as an openid. I login to wordpress.com as "user" in a tab and then tell SO that I am user.wordpress.com. SO talks to WP and redirects me to WP. WP asks me what it should tell SO on my behalf. I am then taken back to SO. After this SO and WP do not talk amongst each other and I am logged in separately to both even though my username and password are stored and known only on WP. Neat. [d] That takes care of any possibility of phising. (There is a chance of phising if you are not already logged in to your openid provider and web-app redirects you to a false page. To mitigate this, any respectable openid provider doesn't show a login form ever on a page that you could reach after redirection from a web-app.) -- Here is the part about the home page thing I mentioned. You can make any page whose head portion you can edit an alias for an openid. So to carry forward our example in [c]. I put <link rel="openid.server" href="http://user.wordpress.com/?openidserver=1" > <link rel="openid.delegate" href="http://user.wordpress.com/" > in the head of kniwor-home-page.com which I own. Now kniwor-home-page.com is an openid. If tomorrow I lose faith in wordpress I just edit kniwor-home-page.com and let someone more trustworthy handle my username password login process. (I could potentially host a openid server myself on my own machine if I am paranoid enough.) This as I said is uber cool. I thus truly own my id! And I think you one already see all the wonderful things this brings to the table once one is past the initial learning curve. Nothing of value from the old system is really lost and all of the old can be replicated easily. You could just sign up with a new open id provider every time you need a new registration if you want to replicate the old days but it is much more neat to distribute control and trust by importance and other personal metrics. Points of failures are just shifted from places that were not created to handle them (email providers) to places that are now designed with that explicit purpose in mind and a lot of emails double up as openids if you insist that that is where you want your points of failure.

by kniwor 17y ago

RiderOfGiraffes 17y ago

OK, I regard this as an opportunity to learn. So far I have invested about 3 hours in trying to understand how I can use OpenID to do what I do now, and I feel none the wiser, and resent the loss of time. You appear to be that rarest of things - a knowledgable enthusiast who will try to communicate clearly. So, here I am, approaching a new site that requires authentication. Under my current workflow I select a userid, which may, but need not, replicate an existing userid. I select a password which is unique, and an email address which is unique. I use these credentials to signup, then reply to the confirmation email. Now I have an account on the new service using a userid with a unique password. If that password is compromised, none of my other accounts are compromised. Further, if the email address I use gets leaked, I know who leaked it. This is how I have confirmed that eMusic are email address leaking bastards. This last capability is important to me, just as is the ability to use unique passwords wherever I go to avoid one leak compromising multiple accounts. Can you now point me at a document that will show how to obtain the above facilities? I'd appreciate it. Thanks. EDIT: In positioning myself to understand what you write or point me at, I have further found this: http://www.links.org/?p=187 http://www.links.org/?p=187 I'd appreciate your comments on that as well. Thanks.

deleted 17y ago
[deleted]
kniwor 17y ago
I hope this helps. I think the problem with writing simple introductions to openid is that it just offers too many options and it is difficult to decide how to approach. Here is an equivalent but by no means equal workflow[a]. Pre0. Choose your openids before you have the sites needing them! This is username/password registration/recovery/emails as it always was[b]. You come across a new site (web-app) and it supports openid login. Registration workflow: Reg0. We choose some openid from Pre0. Login into that openid at the openid provider's website in a new tab[c]. Reg1. We tell web-app our openid. What happens then is similar to a net banking/credit card transaction. Web-app takes us to openid provider's website. We say yes, we would like to register/authenticate/allow this and we are now registered and logged in. Reg2. We can now safely log out of our openid provider in the other tab if we want. We will still remain logged in at the web-app. Rule of thumb: Openid provider doesn't know what is going on at the webapp and vice a versa and they cannot affect each other in any way at this stage. (Separate cookies, no shared sessions.) You visit the website again. Login Workflow: Log1. We go to our openid provider first and login.[d] Log2. Then we go to our web-app and put our openid in. Webapp does some talking behind the scenes with the openid server and logs us in. Log3. After this point, web-app and openid provider do not talk or know whats going on at the other place. We logout of either server separately. End of workflow. [a] Initially, I replicated your workflow feature for feature but that felt like replicating a svn workflow in git. Just like git, openid is a new paradigm. One can replicate old workflow features in many many ways but methods of doing so are hardly instructive or interesting. If you want me to do so or bring back some/all feature(s) back into this workflow I will gladly do so, if only just to show that it can be easily done. openid is very much the git of the authentication world. It is a surprisingly elegant federated and distributed replacement for old small centralized island situations with a similar price in inertia and the learning curve. [b] May I recommend not mixing your existing ids (yahoo/gmail/etc) with these openids. The single tool for a single job philosophy is nice. wordpress.com is my favourite openid provider, simple interface, minimal and trustworthy enough. myopenid.com is a more fully featured option. [c] At the risk of sounding verbose and simultaneously committing the sin of not using example.com, here is an actual example. I am looking at the openid login box at stackoverflow.com (SO) and I own user.wordpress.com as an openid. I login to wordpress.com as "user" in a tab and then tell SO that I am user.wordpress.com. SO talks to WP and redirects me to WP. WP asks me what it should tell SO on my behalf. I am then taken back to SO. After this SO and WP do not talk amongst each other and I am logged in separately to both even though my username and password are stored and known only on WP. Neat. [d] That takes care of any possibility of phising. (There is a chance of phising if you are not already logged in to your openid provider and web-app redirects you to a false page. To mitigate this, any respectable openid provider doesn't show a login form ever on a page that you could reach after redirection from a web-app.) -- Here is the part about the home page thing I mentioned. You can make any page whose head portion you can edit an alias for an openid. So to carry forward our example in [c]. I put <link rel="openid.server" href="http://user.wordpress.com/?openidserver=1" > <link rel="openid.delegate" href="http://user.wordpress.com/" > in the head of kniwor-home-page.com which I own. Now kniwor-home-page.com is an openid. If tomorrow I lose faith in wordpress I just edit kniwor-home-page.com and let someone more trustworthy handle my username password login process. (I could potentially host a openid server myself on my own machine if I am paranoid enough.) This as I said is uber cool. I thus truly own my id! And I think you one already see all the wonderful things this brings to the table once one is past the initial learning curve. Nothing of value from the old system is really lost and all of the old can be replicated easily. You could just sign up with a new open id provider every time you need a new registration if you want to replicate the old days but it is much more neat to distribute control and trust by importance and other personal metrics. Points of failures are just shifted from places that were not created to handle them (email providers) to places that are now designed with that explicit purpose in mind and a lot of emails double up as openids if you insist that that is where you want your points of failure.