Google-Facebook: Identity Management in a Brave New Internet

So there's been a lot of press in the last few days about Facebook shutting off access from the recently announced Google Connect social platform. For those of you that pay attention to identity management, but haven't paid attention to this particular situation, note the following couple of quotes: Robert Scoble comments:


Facebook is being consistent here. Dave Morin told me a few months ago all about Facebook's concerns. Such as, what happens if you change your email address, will it change everywhere that your email address got copied to?
Michael Arrington of TechCrunch responds:


So when Robert Scoble wrote this evening that Google is in the wrong, I disagree. I think Facebook's intentions aren't to let users get data out of the network until Facebook is absolutely forced to do so, and then only on Facebook's terms (see Facebook Connect). The fact is, this isn't Facebook's data. It's my data. And if I give Google permission to do stuff with it, I'm damned well within my rights to do so. By blocking Google, Facebook has blocked ME. And that, frankly, kind of frustrates me.

Michael is clearly in the user centric identity camp with his comments.

Robert's comments (or rather his agreement with Dave Morin's comments) are very similar to the type of concern your typical IT manager has about moving data between applications...only on a much larger scale.

In an ideal world, your identity is your own and you have granular control over who gets what and where it moves.

In reality, if the average user was presented this question as often as identity was requested, it would be a bit like these "desktop firewalls" that continuously ask you to "accept outbound connection to IP 10.10.10.20". Meaning that you'll grow numb to the requests at some point and simply grow accustomed to clicking "Accept" for every request for that data, knowing that clicking "Deny" means that the program (or service) won't work.

This is actually one of the issues that must be overcome by the user-centric identity crowd. It's one thing to provide a layer of security and control, but another thing to make that meaningful in real life.

On the other hand, assuming a data owner (in this case Facebook) wants to actually share their information with a partner (in this case, Google), Robert's mentioned concern about keeping synchronized copies of the data is valid. What's the solution to this part of the problem (assuming that the real problem here isn't Facebook being concerned about Google cannibalizing their business by building a better widget with their users)?

Seems like a case for some combination of virtualization and federation. What do you think?

UPDATE: Note a slight update on Scoble's blog that clarifies a few key details. Removes some of the synchronization/staleness issue, but interesting never-the-less.


UPDATE2: Google employee Kevin Marks says I'm wrong in comments here. Here's his correction to this post: "Robert, you're wrong about Friend Connect data getting stale. It's fetched directly from your linked Friend Data sources, including other Social Networks, with short-term caching on Friend Connect servers. There is a live two-way connection - Friend Connect posts back events to the Social Networks' activity streams when the user choses to do so."

Technorati Tags: , , ,


Comments:

Post a Comment:
Comments are closed for this entry.
About

This is Clayton Donley's official blog. Views expressed are not necessarily those of Oracle.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today