4 ms·

So, to summarize, inertia. Nothing wrong with that but that just says you are a late adopter as far as this technology is concerned. My stackoverflow is not i

by kniwor 17y ago

So, to summarize, inertia. Nothing wrong with that but that just says you are a late adopter as far as this technology is concerned. My stackoverflow is not inextricably linked to anything. My identity is my own home page (which by itself is uber cool). And my workflow has never been simpler. (Oh and you can change your openid url on your stackoverflow profile page.)

RiderOfGiraffes 17y ago
> So, to summarize, inertia. No, not inertia. That seems to me a completely inappropriate "summary" of a well-structured reply. I hate OpenID with a passion because it ties me to one way of working. I too have a well-managed workflow using different IDs and different passwords for nearly every site, ensuring that one leak doesn't destroy all my accounts. I don't need to invest a lot of time and effort learning about something that actually damages my current capabilities. I would explain further, but since you don't seem to bother to read carefully, I won't take the time.
- 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.
mechanical_fish 17y ago
Oh and you can change your openid url on your stackoverflow profile page. Have you tried? Is this a special power unlocked by high karma, or something? My profile page displays my OpenID url, thank god, or (as I already mentioned) I would have no idea what it was. But where, oh where, can I change it? The displayed value is greyed out and unclickable. I am staring at my stackoverflow Edit Profile page right now. It has handy fields for "Display name", "email", "real name", "website", "location", "birthday", and "about me". Oh, and there's "change picture". It is an apparently elegant UI, not too cluttered, and there is no field for my OpenID URL, which is an ugly-ass string of Yahoo-derived GUID. Believe me, if that string was on this Edit form, I would expect to see it. It would stand out like a pit bull in a hamster cage. But maybe I just can't see it. Age has not been kind. So please tell me how to change it; I sincerely want to know that I can.
- kniwor 17y ago
  New login. There is a new login on your profile page. That will allow you to associate an alternate openid. You can swap alternate and primary openid on the profile page and every new login overwrites your primary openid.
  - mechanical_fish 17y ago
    Ah! Somehow I didn't notice those words: - I had conceptualized as my goal as edit my OpenID and was therefore seeking for it on the edit page, not the main profile page. - The words "New Login" seem unrelated to my goal: I have already logged in, so I don't need to log in again. - If I did notice those words, I surely interpreted them as another way to say "Log out, so that someone else can log in with another name". Many other sites have such links, and when you click them they take you to a new login page, which is just what this one does. It looks for all the world like you've logged out and have to log in again. Only if you read the fine print do you find out that the second page is for logging in on top of your previous login. Because in OpenID world you can log in six or seven times to the same site! How intuitive.
    - codinghorror 17y ago

by kniwor 17y ago

RiderOfGiraffes 17y ago

> So, to summarize, inertia. No, not inertia. That seems to me a completely inappropriate "summary" of a well-structured reply. I hate OpenID with a passion because it ties me to one way of working. I too have a well-managed workflow using different IDs and different passwords for nearly every site, ensuring that one leak doesn't destroy all my accounts. I don't need to invest a lot of time and effort learning about something that actually damages my current capabilities. I would explain further, but since you don't seem to bother to read carefully, I won't take the time.

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.

mechanical_fish 17y ago

Oh and you can change your openid url on your stackoverflow profile page. Have you tried? Is this a special power unlocked by high karma, or something? My profile page displays my OpenID url, thank god, or (as I already mentioned) I would have no idea what it was. But where, oh where, can I change it? The displayed value is greyed out and unclickable. I am staring at my stackoverflow Edit Profile page right now. It has handy fields for "Display name", "email", "real name", "website", "location", "birthday", and "about me". Oh, and there's "change picture". It is an apparently elegant UI, not too cluttered, and there is no field for my OpenID URL, which is an ugly-ass string of Yahoo-derived GUID. Believe me, if that string was on this Edit form, I would expect to see it. It would stand out like a pit bull in a hamster cage. But maybe I just can't see it. Age has not been kind. So please tell me how to change it; I sincerely want to know that I can.

kniwor 17y ago
New login. There is a new login on your profile page. That will allow you to associate an alternate openid. You can swap alternate and primary openid on the profile page and every new login overwrites your primary openid.
- mechanical_fish 17y ago
  Ah! Somehow I didn't notice those words: - I had conceptualized as my goal as edit my OpenID and was therefore seeking for it on the edit page, not the main profile page. - The words "New Login" seem unrelated to my goal: I have already logged in, so I don't need to log in again. - If I did notice those words, I surely interpreted them as another way to say "Log out, so that someone else can log in with another name". Many other sites have such links, and when you click them they take you to a new login page, which is just what this one does. It looks for all the world like you've logged out and have to log in again. Only if you read the fine print do you find out that the second page is for logging in on top of your previous login. Because in OpenID world you can log in six or seven times to the same site! How intuitive.
  - codinghorror 17y ago