[Source](http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/ "Permalink to Habitat Chronicles: The Tripartite Identity Pattern") # Habitat Chronicles: The Tripartite Identity Pattern # [Habitat Chronicles][1] ## Cyberspace. Virtual communities. Online games. Distributed systems. Opinion, history, advice, and silliness from two guys who've been building this stuff for a long, long time. ## Say what? In 1985 we began work on what would become one of the world's first multi-person graphical virtual worlds, and arguably the first of what are now awkwardly called "Massively Multiplayer Online Role Playing Games" (MMORPGs). Thus began a series of adventures in technology, business, and the online world which continue to this day. This site is where we tell our story: the things we learned, the mistakes we made, the people we met, a tale of human brilliance and folly and things you would never have imagined. [About Chip Morningstar][2] [About Randy Farmer][3] [About Habitat][4] ## Collected History [The Lessons of Lucasfilm's Habitat][4] [How to Deconstruct Almost Anything][5] [MDC 2004: Habitat Redux][6] [1994: Cyberspace Protocol Requirements][7] ## Blogs We Like * [A Walk Through Durham Township ][8] * [City Comforts ][9] * [Eric Drexler ][10] * [John Massengale ][11] * [Lawrence Lessig ][12] * [Raph Koster ][13] * [Ron Gilbert — Grumpy Gamer ][14] * [Terra Nova ][15] * [The Classicist ][16] * [The Daily WTF ][17] * [The Volokh Conspiracy ][18] * [Virginia Postrel ][19] ## Worthy Things * [Douglas Crockford's Wrrrld Wide Web ][20] * [Metacrap ][21] * [The E Programming Language ][22] ## Search Habitat Chronicles search ## Categories * [Administrivia][23] * [Avatar][24] * [Business][25] * [Education][26] * [Elsewhere][27] * [Food][28] * [General][29] * [History][30] * [Lessons Learned][31] * [News][32] * [Open][33] * [Politics][34] * [Random Lunacy][35] * [Random Lunacy][36] * [Speaking][37] * [Technology][38] * [Theory][39] * [Uncategorized][40] ## Archives * [January 2018][41] * [November 2017][42] * [May 2017][43] * [February 2017][44] * [October 2016][45] * [October 2014][46] * [April 2014][47] * [March 2014][48] * [February 2014][49] * [December 2013][50] * [October 2013][51] * [August 2013][52] * [July 2012][53] * [April 2011][54] * [March 2011][55] * [January 2011][56] * [November 2010][57] * [October 2010][58] * [July 2010][59] * [March 2010][60] * [February 2010][61] * [December 2009][62] * [October 2009][63] * [September 2009][64] * [August 2009][65] * [July 2009][66] * [March 2009][67] * [February 2009][68] * [December 2008][69] * [November 2008][70] * [October 2008][71] * [September 2008][72] * [August 2008][73] * [June 2008][74] * [February 2008][75] * [January 2008][76] * [September 2007][77] * [July 2007][78] * [June 2007][79] * [May 2007][80] * [March 2007][81] * [January 2007][82] * [December 2006][83] * [November 2006][84] * [October 2006][85] * [September 2006][86] * [August 2006][87] * [June 2006][88] * [May 2006][89] * [March 2006][90] * [February 2006][91] * [January 2006][92] * [December 2005][93] * [November 2005][94] * [October 2005][95] * [September 2005][96] * [August 2005][97] * [May 2005][98] * [April 2005][99] * [March 2005][100] * [November 2004][101] * [October 2004][102] * [September 2004][103] * [July 2004][104] * [May 2004][105] * [April 2004][106] ## Feed * [Subscribe to this blog's feed  ![Feed][107]][108] ## October 17, 2008 ### The Tripartite Identity Pattern One of the most misunderstood patterns in social media design is that of user identity management. Product designers often confuse the many different roles required by various user identifiers. This confusion is compounded by using older online services, such as Yahoo!, eBay and America Online, as canonical references. The services established their identity models based on engineering-centric requirements long before we had a more subtle understanding of user requirements for social media. By conjoining the requirements of engineering (establishing sessions, retrieving database records, etc.) with the users requirements of recognizability and self-expression, many older identity models actually discourage user participation. For example: Yahoo! found that users consistently listed that the fear of _spammers farming their e-mail address_ was the number one reason they gave for abandoning the creation of user created content, such as restaurant reviews and message board postings. This ultimately led to a very expensive and radical re-engineering of the Yahoo identity model which has been underway since 2006. Consistently I’ve found that a tripartite identity model best fits most online services and should be forward compatible with current identity sharing methods and future proposals. The three components of user identity are: the _account identifier_, the_ login identifier_, and the _public identifier_. ![Identity 2.gif][109] ## Account Identifier (DB Key) From an engineering point of view, there is always one database key – one-way to access a user’s record – one-way to refer to them in cookies and potentially in URLs. In a real sense he account identifier is the closest thing the company has to a user. It is required to be unique and permanent. Typically this is represented by a very large random number and is not under the user’s control in any way. In fact, from the user’s point of view this identifier should be invisible or at the very least inert; there should be no inherent public capabilities associated with this identifier. For example it should _not_ be an e-mail address, accepted as a login name, displayed as a public name, or an instant messenger address. ## Login Identifier(s) (Session Authentication) Login identifiers are necessary create valid sessions associated with an account identifier. They are the user’s method of granting access to his privileged information on the service. Historically, these are represented by unique and validated name/password pairs. Note that the service _need not generate_ its own unique namespace for login identifiers but may adopt identifiers from other providers. For example, many services except external e-mail addresses as login identifiers usually after verifying that the user is in control of that address. Increasingly, more sophisticated capability-based identities are accepted from services such as OpenID, oAuth, and Facebook Connect; these provide login credentials without constantly asking a user for their name and password. By separating the login identifier from the account identifier, it is much easier to allow the user to customize their login as the situation changes. Since the account identifier need never change, data migration issues are mitigated. Likewise, separating the login identifier from public identifiers protects the user from those who would crack their accounts. Lastly, a service could provide the opportunity to attach multiple different login identifiers to a single account — thus allowing the service to aggregate information gathered from multiple identity suppliers. ## Public identifier(s) (Social Identity) Unlike the _service-required_ account and login identifiers, the public identifier represents how the user wishes to be perceived by other users on the service. Think of it like clothing or the familar name people know you by. By definition, it does not possess the technical requirement to be 100% unique. There are many John Smiths of the world, thousands of them on Amazon.com, hundreds of them write reviews and everything seems to work out fine. Online a user’s public identifier is usually a compound object: a photo, a nickname, and perhaps age, gender, and location. It provides sufficient information for any viewer to quickly interpret personal context. Public identifiers are usually linked to a detailed user profile, where further identity differentiation is available; ‘Is this the same John Smith from New York that also wrote the review of the great Gatsby that I like so much?’ ‘Is this the Mary Jones I went to college with?’ A sufficiently diverse service, such as Yahoo!, may wish to offer multiple public identifiers when a specific context requires it. For example, when playing wild-west poker a user may wish to present the public identity of a rough-and-tumble outlaw, or a saloon girl without having that imagery associated with their movie reviews. _Update 11/12/2008:_ This model was presented yesterday at the[ Internet Identity Workshop][110] as an answer to many of the confusion surrounding making the distributed identity experience easier for users. The key insight this model provides is that **_no_ publicly shared identifier is required (or even desirable) to be used for session authentication**, in fact requiring the user to enter one on a RP website is an unnecessary security risk. Three main critiques of the model were raised that should be addressed in a wider forum: 1. There was some confusion of the scope of the model – Are the Account IDs global? _I hand modified the diagram to add an encompassing circle to show the context is local – a single context/site/RP. In a few days I’ll modify the image in this post to reflect the change._ 2. The term “Public Identity” is already in use by iCards to mean something incompatible with this model. _I am more than open to an alternative term that captures this concept. Leave comments or contact me at randy dot farmer at pobox dot com._ 3. Publically sharable capability-based identifiers are not included in this model. These include email addresses, easy-to-read-URLs, cel phone numbers etc. _There was much controversy on this point. To me, these capability based identifiers are outside the scope of the model, and generating them and policies sharing them are withing the scope of the context/site/RP. Perhaps an interested party might adopt the tripartite pattern as a sub-pattern of a bigger sea of identifiers. My goal was not to be all encompassing, but to demonstrate that only three identifiers are required for sites that have user generated content, and that no public capability bound ID exchange was required. RPs should only see a the Public ID and some unique key for the session that grants permission bound access to the user’s Account._ [Theory][39] | Posted by Randy at [9:45 AM][111] | You can [comment][112]. Trackbacks are closed. ### 11 Comments Hi Randy, Two observations: 1\. There could be multiple login IDs associated with an account ID, right? This would allow services or users to easily reuse external authentication services (OpenID) but not be locked in to them. This also facilitates mergers of different services into the same user pool (due to acquisition, service redesign, etc.) There could also be multiple public IDs, used in different contexts. 2\. Should the account ID never be shown publicly? If the only publicly shown identifier is the user-controlled public ID, then it’s easy for trolls etc to manipulate what others think their identity is. (Though different communities will have different needs here and different weights for this potential problem.) Posted by: [Reed Hedges][113] | [ October 18, 2008, 4:47 am][114] Reed, Glad you liked the post. It may be short, but folds in almost 5 years of refinement and insight. 1\. I agree, as I said in the post above _“Lastly, a service could provide the opportunity to attach multiple different login identifiers to a single account”_ and also _“A … service… may wish to offer multiple public identifiers when a specific context requires”_ 2\. Actually, the Account ID is a key that can be shared for API use, hashed for URLs, etc. _as long as it has no inherent capabilities._ Spoofing is a minor threat, and the account ID could be used to differentiate without displaying it. For example if two folks with the public ID James (and the same photo, age, location, etc.) post to a forum, the page display logic could differentiate them as James(1) and James(2) consistently. Of course, the community might have something to say about anyone who is trying to spoof another person. Posted by: [F. Randall Farmer][115] | [ October 18, 2008, 9:16 am][116] Reed’s scanning error was common when I first published this model inside of Yahoo! I was in a hurry to post the article in time for an upcoming identity standards related event and used an accurate, but perhaps oversimplified,image. This has been corrected. Now if you only look at the picture instead of reading the text completely, you’ll be able to see that the pattern supports multiple Login IDs and Public IDs. Posted by: [F. Randall Farmer][115] | [ October 18, 2008, 10:27 am][117] Thanks, the changed image makes it much clearer. I wasn’t sure if you meant that there could simultaneously be more than one ID, or whether there were multiple options for what form that ID could take. I would make the internal account ID be either completely private (so you can change it someday if needed), or give it some globally unique property (i.e. based on a URI or a GUID or whatever) (so you wouldn’t have to change it). For public APIs, you can generate a key or id from the account ID, specifically for the user to give to another application that is going to use the API. You can generate a new key like this for each third party service, which would also allow the user to disable them selectively or set different access options for each of them. So this would be a third branch of external identifiers. Posted by: [Reed][113] | [ October 20, 2008, 6:33 am][118] This seems to map quite well to the account element in PortableContacs/OpenSocial/SGNodeMapper where username and userid are used for the two parts you call Login ID and Account ID, and displayName is used for what you call Public ID Posted by: [Kevin Marks][119] | [ November 11, 2008, 5:39 pm][120] Thanks Kevin! I’ll try to corner Joseph when I see him later today. Posted by: [F. Randall Farmer][121] | [ November 12, 2008, 8:01 am][122] So I can trust my identity morph to you or manage it myself, right? Posted by: [Orthomentor][123] | [ March 4, 2010, 1:22 pm][124] It’s wrong to say that spoofing is a small problem. In aggregate it may be, but if you’re user being spoofed, it’s a huge problem. If you look at most of Yahoo!’s blogs, it’s trivial to impersonate the writer of a post because it’s so easy to change one’s Core ID nickname. Coloring a blogger’s posts Green and the spoofer’s post Red does nothing to solve the problem because the a third party will not know the pattern used for each. Only if a site (like Y! Sports) uses a special demarcation reserved for Authors can users really know who is who. And for individual users, all hope is lost if someone starts acting like someone else. This tripartite identity model as implemented at Y! took something real (YID’s) and replaced it with something easily fungible and encouraged users to change it on a whim. It encouraged replacing one handle with another that much worse. This was the absolute wrong approach. It created a world of anonymous users with no ability to prevent spoofing nor encouraged users to invest in their identity. One example was my fantasy leagues. I had gotten to know users by their YID’s, and core id ruined this experience. Who a user was could change at a whim, and even playing among close friends, I often don’t know who is who. A suggestion to remedy this problem was to create property specific nicknames that could not be easily changed and must be unique. This was rejected by the folks implementing this spec. Facebook comes along two years later and encourages users to publicly identify themselves everywhere, adds a identifying information like initial network, and clamps down on users spoofing other users, and they win the war. That was the approach Yahoo! should have taken. It’s not right to blame slow adoption of this model as the reason Yahoo! failed at social. Posted by: [EJ][125] | [ December 13, 2010, 1:33 am][126] EJ, Thanks for your comment. You raise several issues – many of which have important and subtle arguments. “It's wrong to say that spoofing is a small problem.” then you say “In aggregate it may be…” So you understand my context. Then you go on “but if you're user being spoofed, it's a huge problem” – that is also true. Though I don’t agree with “it's trivial to impersonate the writer of a post”, at least I don’t agree by design, if not the actual implementation. In order to explain, I’ll quote from the end of your comment: “Facebook comes along two years later and encourages users to publicly identify themselves everywhere, adds a identifying information like initial network, and clamps down on users spoofing other users, and they win the war. That was the approach Yahoo! should have taken.” – All I can do is strongly agree with this statement – and Yahoo! was on this path until the abandoned all efforts to unify their social graphs (YIM, Yahoo 360, etc.) – which I explained in the Quora post on this matter. Identity IS _context_, not a string, unique or not. When Yahoo! stopped caring about building a rich persona/profile behind the user, they lost the war before it started. Note that Facebook lets you change your name “trivially”, but because of deep contextual connections you can tell all the “John Smith”s apart. Facebook names are _not_ unique. Perhaps you didn’t understand that CoreID was only a part (as described in this post) of the needed steps to build robust identity at Yahoo!, not the entire solution (it was never intended to be.) You should feel free to suggest that an incremental approach to this problem would have never worked (and has some of the problems you detail.) Again, in hindsight, I would agree – but there were no other options, except to give up before we started, I guess. The one thing we will probably always disagree on is that the use of a users email address, instant messenger id, and 1/2 their login credentials (aka the YID) as a public identifier for user generated content is appropriate in most contexts. The users told us this over and over. Of this I have no doubts. Posted by: [Randy Farmer][1] | [ December 13, 2010, 1:38 pm][127] Thanks for the detailed response :) Posted by: [EJ][125] | [ December 14, 2010, 2:02 am][128] This is actually the model used by video game developers when able to make multiple characters. It is my belief that it should (or ‘could’ as extra option) be rejected because it leads to fragmentation in buddy recognition (global minds as we are) with already declining user bases (and there is probably no budget to develop ID-tree-based-buddy-systems). I opt for 1 global public ID as motivator to stick to just one account and save customer s(ervice) alot of account management. Furthermore it can support subscriptions for multi boxing characters or selling character spots. It would save the mess from the perspective of the customer where people make alot of accounts to circumvent account constraints. All in all I would say K.I.S.S. for more good available nicknames (public ID’s) and so less discutable pick(s) thereof due to unavailabilities. Only downside is that gender roleplay could complicate an uniform nickname but this could also make people more tempted to pick their (real) gender(s). But an extra universal buddy identifier could just less well done be an implementation. Although it may have to support multiple accounts which would not be desirable. I am all for going ‘real gender’ because AI already allows us to upload our real body model (for parts thereof like the heads). Posted by: Bram | [ February 13, 2018, 1:25 pm][129] ### Post a comment (If you haven't left a comment here before, your comment may need to be approved by the site owners before it will appear. Thanks for waiting.) [Click here to cancel reply.][130] Name: Email Address: (will not be published) URL: Your comment: (you may use HTML tags for style) << [Context is King: Lessons from Online Communities][131] | [Chip and Randy @ Living Game Worlds IV 12/1-12/2][132] >> ©  2018 Chip Morningstar and F. Randall Farmer, all rights reserved. [1]: http://habitatchronicles.com [2]: http://www.fudco.com/chip/resume.html [3]: http://www.linkedin.com/in/frandallfarmer [4]: http://www.fudco.com/chip/lessons.html [5]: http://www.fudco.com/chip/deconstr.html [6]: http://habitatchronicles.com/Habitat/historical/HabitatRedux.ppt [7]: http://habitatchronicles.com/Habitat/historical/ProtocolReqs-2-27-95.pdf [8]: http://www.durhamtownship.com/ "Chip’s favorite photoblog" [9]: http://citycomfortsblog.typepad.com/ "Wise meditations on city design — surprisingly relevant to virtual worlds" [10]: http://metamodern.com/ "Meditations on the future from one of the smartest people on the planet" [11]: http://blog.massengale.com "An architect on architecture" [12]: http://www.lessig.org/new-blog/ "One of the good guys (most of the time)" [13]: http://www.raphkoster.com/ "Raph knows more about online gaming than you do. Just trust us on this." [14]: http://grumpygamer.com/ "Our pal and former coworker from Lucasfilm, and one of the best game designers anywhere" [15]: http://terranova.blogs.com/terra_nova/ "Where virtual world designers go to die" [16]: http://classicist.blogs.com/ "ICA&CA’s house blog, for those of us concerned about the continued health of western culture" [17]: http://thedailywtf.com/ "IT horrors to make your eyes bleed" [18]: https://www.washingtonpost.com/news/volokh-conspiracy/ "Always interesting, even though they’re all lawyers" [19]: http://vpostrel.com "Contrarian culture blogger non pareil" [20]: http://www.crockford.com/ "Save the earth for valuable prizes!" [21]: http://www.well.com/~doctorow/metacrap.htm "Cory speaks truth to utopian W3C weenies" [22]: http://erights.org/ "Electric Communities’ greatest legacy" [23]: http://habitatchronicles.com/category/administrivia/ [24]: http://habitatchronicles.com/category/avatar/ [25]: http://habitatchronicles.com/category/biz/ [26]: http://habitatchronicles.com/category/education/ [27]: http://habitatchronicles.com/category/elsewhere/ [28]: http://habitatchronicles.com/category/food/ [29]: http://habitatchronicles.com/category/general/ [30]: http://habitatchronicles.com/category/history/ [31]: http://habitatchronicles.com/category/lessons-learned/ [32]: http://habitatchronicles.com/category/news/ [33]: http://habitatchronicles.com/category/open/ [34]: http://habitatchronicles.com/category/politics/ [35]: http://habitatchronicles.com/category/random/ [36]: http://habitatchronicles.com/category/random-lunacy/ [37]: http://habitatchronicles.com/category/speaking/ [38]: http://habitatchronicles.com/category/tech/ [39]: http://habitatchronicles.com/category/theory/ [40]: http://habitatchronicles.com/category/uncategorized/ [41]: http://habitatchronicles.com/2018/01/ [42]: http://habitatchronicles.com/2017/11/ [43]: http://habitatchronicles.com/2017/05/ [44]: http://habitatchronicles.com/2017/02/ [45]: http://habitatchronicles.com/2016/10/ [46]: http://habitatchronicles.com/2014/10/ [47]: http://habitatchronicles.com/2014/04/ [48]: http://habitatchronicles.com/2014/03/ [49]: http://habitatchronicles.com/2014/02/ [50]: http://habitatchronicles.com/2013/12/ [51]: http://habitatchronicles.com/2013/10/ [52]: http://habitatchronicles.com/2013/08/ [53]: http://habitatchronicles.com/2012/07/ [54]: http://habitatchronicles.com/2011/04/ [55]: http://habitatchronicles.com/2011/03/ [56]: http://habitatchronicles.com/2011/01/ [57]: http://habitatchronicles.com/2010/11/ [58]: http://habitatchronicles.com/2010/10/ [59]: http://habitatchronicles.com/2010/07/ [60]: http://habitatchronicles.com/2010/03/ [61]: http://habitatchronicles.com/2010/02/ [62]: http://habitatchronicles.com/2009/12/ [63]: http://habitatchronicles.com/2009/10/ [64]: http://habitatchronicles.com/2009/09/ [65]: http://habitatchronicles.com/2009/08/ [66]: http://habitatchronicles.com/2009/07/ [67]: http://habitatchronicles.com/2009/03/ [68]: http://habitatchronicles.com/2009/02/ [69]: http://habitatchronicles.com/2008/12/ [70]: http://habitatchronicles.com/2008/11/ [71]: http://habitatchronicles.com/2008/10/ [72]: http://habitatchronicles.com/2008/09/ [73]: http://habitatchronicles.com/2008/08/ [74]: http://habitatchronicles.com/2008/06/ [75]: http://habitatchronicles.com/2008/02/ [76]: http://habitatchronicles.com/2008/01/ [77]: http://habitatchronicles.com/2007/09/ [78]: http://habitatchronicles.com/2007/07/ [79]: http://habitatchronicles.com/2007/06/ [80]: http://habitatchronicles.com/2007/05/ [81]: http://habitatchronicles.com/2007/03/ [82]: http://habitatchronicles.com/2007/01/ [83]: http://habitatchronicles.com/2006/12/ [84]: http://habitatchronicles.com/2006/11/ [85]: http://habitatchronicles.com/2006/10/ [86]: http://habitatchronicles.com/2006/09/ [87]: http://habitatchronicles.com/2006/08/ [88]: http://habitatchronicles.com/2006/06/ [89]: http://habitatchronicles.com/2006/05/ [90]: http://habitatchronicles.com/2006/03/ [91]: http://habitatchronicles.com/2006/02/ [92]: http://habitatchronicles.com/2006/01/ [93]: http://habitatchronicles.com/2005/12/ [94]: http://habitatchronicles.com/2005/11/ [95]: http://habitatchronicles.com/2005/10/ [96]: http://habitatchronicles.com/2005/09/ [97]: http://habitatchronicles.com/2005/08/ [98]: http://habitatchronicles.com/2005/05/ [99]: http://habitatchronicles.com/2005/04/ [100]: http://habitatchronicles.com/2005/03/ [101]: http://habitatchronicles.com/2004/11/ [102]: http://habitatchronicles.com/2004/10/ [103]: http://habitatchronicles.com/2004/09/ [104]: http://habitatchronicles.com/2004/07/ [105]: http://habitatchronicles.com/2004/05/ [106]: http://habitatchronicles.com/2004/04/ [107]: http://habitatchronicles.com/blog/wp-content/themes/habchron/images/feed-icon-28x28.png [108]: http://habitatchronicles.com/feed/ "Feed for articles" [109]: http://habitatchronicles.com/blog/wp-content/uploads/2008/10/Identity-2.gif [110]: http://iiw.identitycommons.net [111]: http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/ [112]: http://habitatchronicles.com#respond [113]: http://interreality.org [114]: http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/#comment-190 [115]: http://www.habitatchronicles.com [116]: http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/#comment-191 [117]: http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/#comment-192 [118]: http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/#comment-193 [119]: http://epeus.blogspot.com [120]: http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/#comment-194 [121]: http://www.habitatchronicles.copm [122]: http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/#comment-195 [123]: http://Third.ORG [124]: http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/#comment-266 [125]: http://sports.yahoo.com [126]: http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/#comment-584 [127]: http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/#comment-585 [128]: http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/#comment-586 [129]: http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/#comment-99814 [130]: http://habitatchronicles.com/2008/10/the-tripartite-identity-pattern/#respond [131]: http://habitatchronicles.com/2008/10/context-is-king-lessons-from-online-communities/ [132]: http://habitatchronicles.com/2008/10/chip-and-randy-living-game-worlds-iv-121-122/