Comments on: The Tripartite Identity Pattern

By: EJ

EJ — Tue, 14 Dec 2010 10:02:16 +0000

Thanks for the detailed response :)

By: Randy Farmer

Randy Farmer — Mon, 13 Dec 2010 21:38:16 +0000

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.

By: EJ

EJ — Mon, 13 Dec 2010 09:33:20 +0000

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.

By: Orthomentor

Orthomentor — Thu, 04 Mar 2010 21:22:21 +0000

So I can trust my identity morph to you or manage it myself, right?

By: F. Randall Farmer

F. Randall Farmer — Wed, 12 Nov 2008 15:01:54 +0000

Thanks Kevin! I’ll try to corner Joseph when I see him later today.

By: Kevin Marks

Kevin Marks — Wed, 12 Nov 2008 00:39:10 +0000

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 http://portablecontacts.net/draft-spec.html#account_element

By: Reed

Reed — Mon, 20 Oct 2008 13:33:45 +0000

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.

By: F. Randall Farmer

F. Randall Farmer — Sat, 18 Oct 2008 17:27:56 +0000

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.

By: F. Randall Farmer

F. Randall Farmer — Sat, 18 Oct 2008 16:16:46 +0000

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.

By: Reed Hedges

Reed Hedges — Sat, 18 Oct 2008 11:47:05 +0000

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.)