StingRay Logo

Social Networks
FacebookInstagramLinkedInRSSTwitterYouTube
FacebookInstagramLinkedInRSSTwitterYouTube
Human Silhouette

Decentralized Identification with OpenId

The given article is the continuation of the talking on implementing user registration on a website, particularly using the external mechanism of trusted network identification called OpenId.

OpenId

As I mentioned in the previous article, the notable OpenId standard did not have ready-to-use ASP libraries for my website, so I had to examine all its specifications on my own. My general understanding of the OpenId identification process was correct:

  1. A user of my website enters his/her OpenId identifier.
  2. My website redirects the user to the website of the appropriate OpenId provider.
  3. On the website of the “native” OpenId provider the user passes the usual for him/her authentication and confirms that he/she trusts my website (allows his/her OpenId provider to give the profile information to my website).
  4. The OpenId provider redirects the user back to my website with an indication of the successful user identification and the data of his/her profile (excluding the user password, of course).
  5. My website recognizes the user as identified both by the OpenId provider and for itself (this is the trusted network identification, and my website trusts the OpenId provider) and gives him/her the appropriate benefits.

However, the technical overview looked not so simple. Particularly, it raised the following questions:

  • Should my website also have some own table (database) of users? If yes then what exactly should it store? There was a supposition that one of the main benefits of the trusted network identification in general and of the OpenId in particular is the minimal architecture complexity and implementation efforts; particularly I thought there was no need to store any user information at my side. The only thing that seemed must be stored was an indication of the identified user but a session variable should be enough for that.
  • Should my website give users the option to change their (nick)names specifically in the local context, or should it always use the values from their OpenId profiles? Initially I thought the local profile changes must be impossible, otherwise I had to answer “yes” to the previous question (to have a local user table on my website for storing the changed (nick)names). I even explained this to my users in the most ridiculous ever possible: “this minimizes (nick)name conflicts and even safer”. However, later my opinion changed…
  • If a user (nick)name changes, either in the external profile or locally on my website, should the user’s earlier messages and comments be updated and displayed with new nickname? If the messages and comments should be updated there may be the following problem: the user took part in some discussion as “John”, and he was addressed in the discussion by this name; but once he became “Peter”, all the addressed to him became strange? And if the messages and comments should not be updated then a single user may become the author of messages and comments under different names…

All this delayed the implementation process or rather made me justifying myself in the subconscious postponement of the implementation… Until I met Loginza.

Add your comment, or log in to (un)subscribe.
OpenId
Preview
Smile Wink Tongue Grin Laugh Sad Very Sad Shocked Crazy Indifferent Silent Cool Evil Mad Confused Sorry In Love Angel Devil Thinking FacePalm See No Evil Bold Italic Underline Strike Font Size Hyperlink Quote
Loading…