I’m biased but I think this post is one of Doc Searl’s best about VRM and what’s going to compel it forwards. It’s about the July 31 Wall Street Journal article about behavioral tracking on the net.

He’s been preaching that a paradigm change is coming and he’s dead right (hint: see PDS). That’s why I’m travelling all the way to Boston for the VRM+CRM conference Aug 26/27 in Boston. This despite my standing rule of NO CONFERENCES IN AUGUST. (Damn fool Americans need to learn from the Europeans about how to enjoy life, especially summer, especially in Seattle.)

But I’m making an exception this year (and also for the Privacy Identity Innovation 2010 conference, which is easy because it’s in Seattle) because this paradigm shift is so important.

And because it’s one of the key breakthroughs that user-centric identity has been developed to enable.

Every so often you experience a technical problem you can’t find any information about and which takes you forever to solve. Then, after you finally solve it, you are left scratching your head saying, “I don’t get it­—there must be millions of people with this problem—why is there so little information about it?”

Once before, back in 1991, I ran into such a problem with Windows 3.0. After finally solving it, I shared my solution with my friend Seattle Times tech columnist Paul Andrews. He published it in his column, and it turned out that thousands of people had the same problem but nobody understood quite what was happening. So that’s why there was so little information about it.

Now 20 years later, even though we’ve got the Internet and Google and all, I’ve just been through the same experience. And the irony? The problem is with none other than Google accounts—the very accounts that we need from this search giant to access many of the services it offers.

Over the holidays I finally bore down, worked the problem all the way through, and solved it. And throughout the process I was consistently stunned to find so little information available about it, either from Google or anywhere else.

So this time around I’m being proactive about it and publishing the solution right here so it will be easy for anyone to reference. (And, of course, for Google’s own search engine to find — the Internet brings new heights to irony.)

Warning: read this all the way through. The easy fixes are also the ones you may live to regret.

The Problem

1. A friend shares a Google doc with you.
2. You receive an email containing a link to this Google doc.
3. When you click on the link, you are prompted to log into your Google account, but once you do, you can’t get access to the doc because the email address that the friend used is not the same email address you used to originally create your Google account.

Arrggh! (That’s an exact quote from an email I just received from a friend for whom I’m solving this problem by writing this blog post!)

The Simple Solution That Will Get You In Trouble

There is a simple solution for which I thank George Fletcher of AOL, who first explained it to me and others on the OpenID mailing list who were having this problem a few years ago.

The solution is: register a new Google account under the email address that your friend used to share the Google doc with you.

It’s very easy…BUT…read the warning afterwards as to why it’s a red herring.

1. Go to http://google.com.
2. If you are signed in, sign out (top right corner).
3. On the next screen (the plain jane Google home screen), click the Sign in link in the top right corner.
4. On that screen, underneath the login box on the right, click the link “Don’t have a Google account? Create an account now”.
5. Even though you may already have a Google account, enter the email address you want to register for another Google account (the one your friend sent the Google doc too).
6. Confirm the email address via the standard process.
7. When you are done, log in using to this new Google account (using the email address you just registered, not the one for your other Google account).
8. Go to Google Docs (http://docs.google.com).
9. The Google Doc your friend shared with you will be on the list.

Yes, it’s that simple. BUT…

The New Problem This Creates

The reason NOT to solve the problem this way, to which I can attest by long and painful experience, is that while you will now have access to all the Google docs shared with you…you will also have to log in and log back out of each of your different Google accounts in order to access the different sets of Google docs shared with you under your different email addresses.

This might seem like a small pain at first, but believe me, after the 500^th time you will be wishing there was a better way.

There is.

The Better Solution…That Still Isn’t the Right Answer

The “better way” is a standard feature of almost any identity or directory system: aliases. (Disclaimer: I’m in the Internet identity business, so this is the kind of stuff I deal with all the time.) In an identity or directory context, an “alias” is just an alternate name for the same account. And in fact Google accounts supports aliases. What’s interesting, though, is that: a) they don’t call them “aliases”, and b) aliases for Google accounts are completely different than aliases for Gmail accounts.

Gmail accounts, you ask? What’s the difference between a Google account and a Gmail account?

Therein lies a whole ‘nother can of worms (and possibly the reason there is so little information about the Google account problem).

Let me start by explaining the difference (as best I understand it – this WHOLE BLOG POST is an open invitation for the good folks at Google to correct any of my misunderstandings and provide better explanations).

First, a Google account and a Gmail account are not exactly the same thing. The first rule is: every Gmail account is a Google account, but NOT every Google account is a Gmail account.

In other words, if you have a Google account that is NOT a Gmail address, then you have a Google account that is NOT a Gmail account.

The second rule is: BOTH a Google account AND a Gmail address can have an alias. BUT THEY ARE NOT THE SAME THING, AND NEITHER CALLS THEM ALIASES.

I am not making this up. An alias on a Google account (and remember, every Gmail account IS also a Google account) is another name for the entire Google account. But for Gmail, an alias is ONLY an alternate email address that you can send or receive email from using your Gmail account. A GMAIL ALIAS IS NOT A GOOGLE ACCOUNT ALIAS. A GOOGLE ACCOUNT ALIAS IS NOT A GMAIL ALIAS.

Is that clear as mud?

Now, adding an alias to a Gmail account is quite easy, remarkably powerful (most people have no idea how much flexibility Gmail offers to manage your email for any number of email accounts), and surprisingly poorly documented. I just spent 10 minutes searching Gmail for help on this just to see if there was a Gmail help page I could just link to.

Nope.

So here’s how.

Instructions for Adding an Alias to Your Gmail Account (but NOT for your Google Account Even If It Is a Gmail Account!)

1. Login to your Gmail account.
2. Click the Settings link in the top right.
3. Click the Accounts and Import tab.
4. In the second section, Send mail as, click the button labelled, Send mail from another address.
5. Enter the email address as instructed.
6. Google will send you an email with a link you must click to verify you own the address.
7. Go to that mail account, find the mail, click the link (it all takes about 30 seconds).

You’re done. Go back to your Gmail Settings page, click the Accounts and Import tab, and the new email address will be listed in the Send mail as section. You can now send email from this email address by choosing it in the “From” drop down box in Gmail. (See the help link for more info about the different ways you can send mail from a Gmail alias.)

You can add as many email adddresses as aliases to your Gmail account as you want (at least I couldn’t find documentation about a limit). But keep in mind that all of these will ONLY be Gmail account aliases, not Google account aliases — and having them as Gmail aliases does nothing to solve the Google account problem.

So you have to go through a different process — even with the same set of email addresses — to make them Google account aliases. (For example, I have the same four email addresses as BOTH Gmail aliases and Google account aliases.)

The following instructions apply for adding an alias to ANY Google account (whether or not it is a Gmail account), BUT—and this is a big BUT—if your Google account is NOT a Gmail account, keep reading afterwards about why this can come back to bite you.

Instructions for Adding an Alias to Any Google Account (Even If It Is a Gmail Account)

1. Go to www.google.com/accounts. That is the home page for configuring any Google account. If you’re currently logged into Google, Google figures out which Google account you are using via a cookie in your browser. If you’re not logged in, they’ll prompt you to login, and the Google account you will be configuring is based on the email address you use to login.
2. Once you are logged in, confirm it is the correct Google account by checking the email address in black text at the very top of the page (on the left side of the block of links in the top right corner). If this is the right account, proceed. If this is not the right account, meaning you want to add an alias to a different Google account, then sign out (upper right corner), then sign back in under the email address for that different Google account.
3. Under Personal Settings in the top center of the page, the entry at the bottom of the column will be Email addresses. If you have not yet added any aliases to this Google account, you will see only one email address—the same email address as at the top of the page. It will have the grey words (Primary email) next to it. This is the “primary key” for this Google account. You can’t change it! See the warning below.
4. To add an alias (do you see the word “alias” anywhere near here? Or anywhere on this screen? Does Google give you any clue that this is where you should go to access such a feature??), click the Edit link below this email address.
5. On the next screen (https://www.google.com/accounts/EditUserInfo), you will see two blocks: Edit personal information and Add an alternate email address to your account. You want this second block.
6. At the bottom of this second block is a text box labeled: Add an additional email address. Enter the email address you want to add as an alias (the one to which your friend shared the Google doc you can’t access) and click Save.
7. The next screen will tell you that you’ve been sent an email to verify that address.
8. When you receive the email, click the link in the email.

Congratulations, you have just set up that email address to be an alias for your existing Google account.

The benefits?

1. It no longer matters which of your two email addresses your friends share a Google doc with. Either way, the Google doc they shared will show up in your Google docs dashboard at http://docs.google.com. As far as I know, this is true for all the email addresses you add as an alias (again, I don’t know if there is a limit).
2. You no longer have to log in and out of two different Google accounts. All your Google docs will be there in your one master account. Hooray!

Now for the final gotcha. You can do all the above and still end out with a royal headache one day because of the following rule Google explains when you register an alias as described above:

You can use alternate email addresses to sign in to your Google Account, recover your password, and more. Alternate email addresses can only be associated with one Google Account at a time.

In other words, for good security reasons, you can only add an email address as an alias to one Google account at a time. On the surface that doesn’t appear to be an issue…until you circle back to what I explained above…that every Gmail address is also a Google account. By simple deductive logic, you arrive at this conclusion:

You cannot add a Gmail address as an alias to ANY Google account!

In other words, at Google, all email addresses can all serve as primary keys for Google accounts BUT only only non-Gmail accounts can serve as an alias (a secondary key).

So it boils down to this: if have a Gmail account, or ever plan to get one, then you are forcing yourself into the multiple-Google account problem for life UNLESS…

…you make your Gmail account your primary Google account.

Yup, that’s the secret. As long as you make your primary Google account a Gmail account, you’ll never have the problem of wanting to use Gmail but finding yourself forced into the multiple-Google account problem.

What To Do If You Already Have the Multiple Google Account Problem

Okay, say you’ve already fallen into this trap. You did what I did several years ago: created your own non-Gmail Google account using a non-Gmail email address so you could access Google docs under that email address. Then later you started using Gmail, and so now you have at least two Google accounts (and maybe more). And people are constantly sharing Google docs with you under one or the other of the two (or more) email addresses, and you are driving yourself nuts logging in and out of Google trying to remember which email address was used to share which Google doc.

But you CAN’T take your non-Gmail email address and make it an alias to your Gmail Google account (as I advise) because your non-Gmail address is already a Google account.

How do you fix it?

The answer is: a) completely undocumented (at least I couldn’t find it), and b) scary as hell.

That’s why I’m writing this blog post. There’s no reason Google needs to make this so hard. Why they haven’t written it up in one of their generally decent Help articles I have no clue. I even wrote one of my identity friends at Google to ask him. His answer was essentially, “This is just too hard for most users to understand.”

Well, that may be true, but IMHO it’s not a reason to withhold the documentation. The users who are experiencing the problem are highly motivated to understand it, and in fact the solution is pretty easy once you know what it is.

It’s just scary.

In brief, the way to make a non-Gmail Google account an alias for your Gmail account is to first delete the non-Gmail Google account.

Completely. Kaput. Gone. Which, as you might suspect, would ordinarily mean YOU LOSE EVERYTHING ASSOCIATED WITH THAT ACCOUNT.

How’s that for a scary thought? Honestly, that’s why I held off fixing this for so long. Who wants to bother with working around that?

Luckily, the workaround is not that hard once you know what it is and you are sure it is going to work. That’s the other reason I’m writing this blog post: I could not find anything posted anywhere – or even get it confirmed by those I knew at Google – that this procedure would work and everything would be okay in the end.

But I finally got so tired of the problem that I just did it, and I’m happy to say it works just fine.

So: please read and follow the instructions below carefully. I don’t want anyone coming back and telling me that they lost precious data because of my advice that they delete their Google account.

Part One: Share (or Otherwise Backup) All the Data in the Google Account

1. First, make sure you have at least one other Google account (preferably a Gmail account—see above—however this procedure should work with any other Google account. In these instructions I’ll assume this other account is a Gmail account.)
2. Go to the home page of the Google Account you want to delete at  https://www.google.com/accounts/ManageAccount.
3. Make sure this is the account you want to delete by checking the correct email address in black text at left end of the links at the very top of the page.
4. Under Personal Settings, click on the Dashboard link (second one down) called “View data stored with this account”.
5. This helpful utility (created for personal privacy management) will show you all the data you have at Google associated with this account. Now comes the hard part. You need to go through every Google service on this list, then go through any associated documents or data files for each of those services, and share them with your Gmail account. Even more importantly, if you are the owner any document/file, then transfer ownership to your Gmail account. If you don’t own a document/file (someone else shared it with you), don’t worry, you can’t lose it when you delete this Google account. But, as long as you have Edit privileges on the document/file, share it with your Gmail account just so you don’t have to go back to the original owner and ask them to reshare it later. If whomever shared it with you DIDN’T give you Edit privileges, just contact them and have them share it again with your Gmail account.
6. Did I say do this for EVERY document/file in EVERY Google service you use? Go back to your Personal Dashboard and check it again.
7. IMPORTANT: as a final check, log into your Gmail account and VERIFY that all the docs are shared. If you own the document/file, VERIFY that your Gmail account is the new owner.
8. Check everything one more time. If you are unsure than anything has been shared and will not go “poof” when you delete this Google account, just download a copy to your local hard drive (or email it to your Gmail account). Like I said, never come back to me and say you lost any Google data because of this blog post.

Part Two: Delete the Google Account

1. Go back to the home page for the Google account you want to delete: https://www.google.com/accounts/ManageAccount.
2. MAKE SURE this is the right Google account by confirming the email address in black at left end of the links at the very top of the page.
3. Next to the My products header (the second horizontal section down the page), click the Edit link. This should take you to https://www.google.com/accounts/EditServices.
4. The second option on the page is to Delete Account. Choose that option and follow the instructions to confirm you want to permanently delete this account (and wipe that sweat off your brow). Seriously, if you’ve shared or backed up all the files associated with this account, you’ve nothing to fear. It’s just like reformatting a hard drive <ouch>.

Once you’re done, take a deep breath. Wait 15 minutes. (I don’t know if you actually have to wait this long, but I figured it’s long enough to wait for Google’s servers to go through all their account deletion machinations.)

Part Three: Add The Alias to Your Primary Google Account

1. Log back in to your Gmail account (or whichever Google account you want to make your primary).
2. Follow the instructions earlier in this blog post to add the email address (for the Google account you just deleted) as an alias to this Google account.
3. Once Google confirms it as an alias, you’re done.

Problem solved.

Why It’s Still Not Perfect: A Final Warning

It’s worth pointing out that privacy, not just security, can be an issue with account aliases. Sometimes you don’t want someone to know you are using Gmail address to do all this cool stuff. But if your Gmail account is your primary Google account (as I advise), then take note of the following warning:

Note: In some Google services, if you share your alternate email address with your contacts, they might be able to learn your primary email address.

In short, Google hasn’t fully figured out yet how to provide you with completely separate personas on the Web. In my personal opinion, they would be well-advised to do so. It’s not easy — acheiving this level of privacy can be as hard as acheiving corresponding levels of security. But Google has the talent and, I believe, the motivation to attain this goal. I hope they consider it soon.

According to Facebook founder Mark Zuckerberg, yes. See the video with your own eyes and read the ReadWriteWeb analysis of the interview he did with TechCrunch’s Michael Arrington.

Is the age of privacy really over, or does Mark Zuckerberg just want it to be over?

Myself, I don’t think so. Istead what’s headed for extinction are companies that try to make their money by convincing people they need less privacy.

Watch this space – more coming on this topic coming soon.

I don’t know why — maybe it’s just the fall weather — but the privacy temperature is changing. We’re in a period of global warming towards privacy as a key component of Internet identity infrastructure. Part of it is my work at the Information Card Foundation on the Open Trust Framework (read this white paper if you haven’t seen it yet). I’ll be blogging more about that soon.

But another sign is this superb post by Bob Blakley on what’s at the heart of privacy and privacy protection. As one of the technologists that’s spent a decade working on technological solutions to privacy, I can’t endorse Bob’s conclusions strongly enough. It’s a social problem, one that technology can only help create the social cues and custodianship to help with.

But read Bob’s post to see how well he frames the problem and what technologists can and can’t do to help.

I’m going to start referring to her as the Venn Queen. Eve Maler has done another Venn diagram, this time to show the relationship of whole areas of the “user-centric” sphere of activities. Going into Digital ID World next week, I’ll use this to help orient conversations around why there needs to be a simple, consistent way for users to control and manage identity and data sharing relationships no matter what site, application, or type of relationship is involved. We just need to build it! (hint: OpenID + relationship cards + XDI =

And congratulations Kim. The news just become official that Microsoft has acquired Stefan Brand’s Credentica and all its intellectual property. This pairs up Stefan with Kim Cameron and Microsoft’s Identity and Access team to bring Credentica’s groundbreaking U-Prove zero-knowledge-proof technology to market.

This is a very exciting development, particularly because it means that between Microsoft’s work on CardSpace and Higgins work on new forms of i-cards, some real breakthrough functionality is coming to the i-card paradigm. It won’t happen overnight, just as it’s taken Stefan 15 years of work to bring U-Prove this far. But once you’ve pushed a boulder that big up a hill that long, a landslide can start much more easily.

(Not that those of us working on XRI and XDI would know anything about that picture. )

Identity Woman (Kaliya Hamlin) posts about why current “friend formats” like FOAF and XFN don’t satisfy the need for privacy and personal control of data that she – and many other women – want before they are comfortable sharing personal information online.

She mentions that XRI and XDI provide this capability. Chris Messina comments that:

As it is now, there are few applications that actually support what
you’re talking about in terms of giving you fine grained control over
your relationship lists… It’s something that I hope is coming down
the pipe but is not something that has to do with the format; instead
it’s all about consistent citizen-centric access controls over their
data.

Let me explain why I believe it does indeed have “something to do with the format”, and thus why XRI and XDI are so relevant to this problem.

The core idea is that to provide the control Kaliya wants — over who has access to what parts of her profile — you can’t tie the access control format down to a specific blog, domain, application, or i-broker that you are using. You need the access control format to be as portable as the data it is controlling, or else we’ll never get to real portable data – data (and relationships) you can “take with you” across different communities and applications as your life and work evolves.

XRI and XDI provide a open standard way to do this. They break the problem of portable access control into two parts. The first part is a portable addressing format — a way to address the data being controlled that is domain- and application- independent. That’s the job of XRI (Extensible Resource Identifier). It enables a layer of abstract addressing on top of any network-addressable resource that enables portability of data across domains and applications.

The second part is a portable format for expressing the controls an individual (or other data authority) wants to assert over access and sharing of their information. That’s the job of XDI (XRI Data Interchange), a very simple XML format in wich every node of a data graph is XRI-addressable. Within this graph, certain nodes are used to store the access control metadata. In XDI these are called link contracts.

Link contracts are are the portable access control format Kaliya is asking for. As she mentions in her blog, XDI link contracts have already been implemented by Andy Dale, Steve Churchill, Barry Beechinor, and the team at ooTao in a large scale data sharing project for La Leche League International. ooTao used the original XDI data graph model, called the Authority/Type/Instance (ATI) model, For more about this implementation, see Andy’s blog, The Tao of XDI.

An even simpler XDI data graph model, XDI RDF, has since been developed based on the RDF graph model. To see examples of what link contracts look like in the XDI RDF model, see the current XDI RDF Model writeup.

With the XRI Resolution 2.0 spec going final (public review will begin next week – I’ll blog more about this shortly), I look forward very much to diving much deeper into XDI RDF and link contracts at the Internet Identity Workshop, coming up December 3-5 at the Computer History Museum in Mountain View.

Denise Caruso published a wonderful article in Sunday’s New York Times on a subject very close to my heart: how to best go about protecting personal identity, profile, and preference data as new technologies like OpenID, Higgins, and XDI make it possible for individuals to aggregate and share this information much more easily. Call it the “new power of personality” – digital personality.

One of the most intriguing ideas Denise covers in the article is one from Mike Neuenschwander, Lori Rowland, Bob Blakely, Jamie Lewis, and their colleagues at the Burton Group. They propose the idea of a new legal entity explicitly for protection of personal identity data: the Limited Liability Persona (LLP, a nice play on the Limited Liability Partnership). Given the amount of time I’ve spent at the intersection of law and technology and personal data, I’m increasingly believing that the Burton Group is right – digital personas will be granted their own status as a legal construct, just as corporations, patnerships, and sole proprietorships have been in many jurisdictions. I blogged about the LLP when I first heard Jamie Lewis speak about it at Digital ID World 2006, and I think it’s time may be coming. I’m adding it as a category on this blog, and I’ll make it a point to keep reporting on it as it develops.

Last week I mentioned the Social Web User’s Bill of Rights that was drafted for the Data Sharing Summit last Friday and Saturday. When it was first posted, it included the phrase, “ownership”, as in “user’s should own their personal data”.

Mary Hodder, the entrepreneur behind Dabble.com, Paul Trevithick, and I were initially wary of using this term for two reasons:

• “Ownership” is very tricky legal territory, not just in the U.S. but all over the world. Personally I believe the term “identity rights” and “identity rights agreements” is actually more appropriate (see more below).
• Mary made the point that it’s really “co-ownership”, i.e., when users share data with sites, it’s for the benefit of both, and sites need to know they can use the data to provide the services they are giving the user.

However in a blog post today, Mary said that after conversations at the Data Sharing Summit, and then with others in the industry and Dabble advisors, she became convinced that the spirit of “ownership” is correct, and so she’s endorsing the Bill of Rights and adjusting the Dabble TOS (Terms of Service) to reflect this concept of user ownership of their data.

Good for her. I fully agree that the spirit is right, and so, with the caveats I expressed above, I’m on board too. So is Doc Searls in a post he just made.

Interestingly, the very last session at the Data Sharing Summit (in fact, after the closing circle – that’s how dedicated the attendees were) was on Identity Rights Agreements (IRAs), a Working Group formed at Identity Commons in the spring of 2006. The whole idea of IRAs is that users actually license their data to sites, and that if the IRA Working Group could come up with a small set of easily understood user data licensing provisions, similar (but not identical to) the Creative Commons license suite for digital works, it could usher in a whole new era of increased trust between users and sites.

Victor Grey called the IRAs session because he’s doing XRI-based data sharing projects where he needs IRAs today, and he wants the IRAs Working Group to start publishing even very simple ones just to get the learning started (Creative Commons licenses all went through several revisions too).

The outcome of the session was to jumpstart the work of the IRAs Working Group. Victor has already set up the mailing list. Please do join us if you support this work and want to help.

I believe IRAs have the potential to remove the last social hurdle to standardized user-controlled personal data sharing (XDI removes the last technical hurdles). I intend to be very active on the IRAs Working Group (as badly time-sliced as I am these days) so that we can make user ownership of personal data not just laudable but actionable.

Certain events scream out for live blogging. The Data Sharing Summit is one of them. So these are my notes from first half of Day 1. (Then why are they being posted at midnight, you ask? Because there was too damn much to talk about during the second half of the day. More on that tomorrow.)

First, this is the list of problems that attendees want to see addressed:

• The distributed schema mapping problem – how do you map across zillions of different local schemas?
• The “Social Web Bill of Rights” or “identity rights agreement” problem – how can you have “Creative Commons licenses for data sharing”?
• The protocol problem – how do you move social graph data around?
• The “too many IDs” problem – how can we not require more IDs (even with OpenID there is starting to be a proliferation of IDs)?
• The directory or “friend discovery” problem – how do you find other people in the social graph (a “People’s Guidestar”)?
• The addressing problem – how can data be addressed in a consistent manner across distributed locations?
• The user privacy and control problem (also called the “fear” or “surprise” problem) – how can users not be spooked by the idea of their social graph data “getting loose”; how can they maintain control over portable social graph data?
• The granular access control problem – how can control be easily brought down to the individual attribute level, e.g., date of birth?
• The regulation problem – how can social graph portability be accomplished within the bounds of data sharing regulations that currently do not permit certain types of personal data to be shared across certain jurisdictions?
• The safety problem – how can portable social graphs not be subject to the same spam, phishing, and phraud problems as email and the Web?
• The political problem – how can we make it “politically necessary” for sites and applications to offer social network graph export?
• The “friend description problem” – how can we have a interoperable means of providing richer description of “friend” relationships?
• The calendar sharing problem – of all the different types of social graph data, how specifically can we reach alignment over sharing of calendar data?
• The adoption problem – what are the compelling uses of social graph portability that will drive large-scale adoption?
• The internationalization problem – how can attribute sharing work across all world languages?
• The user experience problem – how can social graph sharing operations be made simple and understandable to everyday Web users?
• The operational problem – how will large-scale data sharing affect network loads, caching, firewalls, security perimeters, etc.?
• The “invitation fatigue” problem – how can we stop being overwhelmed by yet another source of messages and “click-to-accept” links?

Second, this is the list of solutions being offered at the DSS:

• An OpenID interoperability testing service (Marc Canter)
• A new open source project & community for social data portability using Higgins and Higgins context providers.
• A community dictionary service for schema mapping (Markus Sabadello, Drummond Reed, Paul Trevithick)
• Different companies offering the potential to have open APIs for sharing their social graph data (AOL/AIM, Yahoo, Google, Cyworld).
• OpenID-based attribute exchange (Dick Hardt & Sxip)
• An open API format for social network portability and sync’ing (Brad Fitzpatrick and David Recordon)
• A social network export service (Upscoop from Rapleaf)

Third, here are the demos that were shown before lunch:

• Cloudtripper: Paul Trevithick and Markus Sabadello showed how Higgins in conjunction with Higgins context providers (code chunks that know how to talk to specific data sources) can be used to pull a user’s social graph data together directly to their own desktop client.
• Community Dictionary Service (CDS): Markus Sabadello and I demo’d a new service contributed to the Identity Schemas Working Group at Identity Commons. Intended to help solve the schema mapping problem for highly distributed data sharing, the CDS is a “Wikipedia for machines” – a way for applications to discover and map elements from different data schemas. (I’ll blog a bunch more about this after the Summit is over, but please do see it for yourself.)
• FOAF crawler: David Recordon (now back at Six Apart) showed a service that crawls public FOAF, XFN, or other relationship metadata to produce aggregated social graphs.
• Pownce: Leah Culver demo’d a social network aggregation service that lets users aggregate their own social graph.
• XRI-based data sharing: Mike Mell showed an implementation of a data sharing solution based on XRI structured identifiers for La Leche League International.

In my book Eve Maler’s about as cool as it gets. XMLGrrl was not only one of the inventors of XML, but deeply understands many of its richest applications from DocBook to SAML. And she’s been a pioneer in applying all of this to the challenge of Internet-scale digital identity.
Her latest blog entry on Pushing String (”The future’s so bright I gotta wear shades“) explores a number of recent developments by Jeff Hodges, Scott Cantor, and Peter Davis for lightening up SAML to make it easier for developers who are jazzed about OpenID. In it she asks about the new “directed identity” feature:

I tried figuring out if the OpenID V2.0 work includes this approach [directed identity] as a possibility for URL-based identifiers, and it appears to go part of the way, though the underlying purpose seems to be different. Revision 10’s Appendix C.1 says “Supports IdP-driven identifier selection. This new variation of the protocol flow is initiated by entering an Identifier for an IdP instead of an Identifier for an End User, and allows the IdP to assist the End User in selecting an Identifier.” But I’m having trouble finding where in the normative spec this is defined.

Although I’m not one of the editors, I have worked quite a bit on this feature in the 2.0 spec and I apologize if it’s not clear in Draft 10. However Eve is exactly right: starting with OpenID Authentication 2.0, a user will have two options for logging into an OpenID-enabled site: with their personal identifier, or with the identifier of their OpenID provider (IdP). If the user chooses the latter option, the IdP will let the user choose the identifier they want to share with the site — anything from a specific persona to a one-time URL/XRI generated by the IdP just for this relationship.

This will significantly increase the privacy options available under OpenID. Add this to the prospect of new ways to converge OpenID with SAML, and it’s no wonder Eve is singing this merry tune!

In Jamie Lewis’s talk at Digital ID World this morning, one idea stood out as a real mind-bender: the Limited Liability Persona (LLP). Jamie was careful to give credit to several folks from the Burton Group who came up with this idea: Mike Neuenschwander & Lori Rowland. I captured the high-level bullets from Jamie’s slide on this concept:

• Individuals can have multiple LLPs, each for different modes, roles
• Compromised LLPs can be shed under certain circumstances
• Could even be sold, like an online game idenity
• But LLPs don’t absolve us of civic responsibility, criminal liability
• Reputation damage, other consequences much like the physical world
• Legal symmetry between all parties

This is a fascinating new idea that gibes very closely with the emerging new industry of i-brokers. I’m going to give this one a deep think.

UPDATE 2008-01-04: Jaco Aizenmann, XDI.org trustee from Costa Rica and founder of VirtualRights.org, has in fact been advancing the concept of a legal “virtual personality” (the best English translation of the Spanish term for “digital identity”) for years now. He has been a passionate advocate since I first met him in 2003 that virtual personality should be a full-fledged legal entity at the same level as a corporation, LLC, sole proprietorship, etc. He helped pioneer the concept in Costa Rica and organized the Virtual Personality forum held at the Costa Rican Congress, 10 May 2005. To my knowledge Costa Rica is the first country considering a constitutional amendment to recognize virtual personality/digital identity as a first class legal entity. You can read more about the legal concept on the virtual personality page at Identity Commons. I look forward to more updates on this from Jaco.

This is the title of Bob’s talk at Digital ID World today. Now that he’s at the Burton Group, Bob can really run with his paradigm-inverting views about information systems as they really work in society.

Bob answers the question, “What is privacy?”, this way:

“The ability to lie about yourself and get away with it.”

Bob notes that this does NOT mean the right to lie about yourself and get away with it, just the ability. He places this startling definition of privacy in the context of what he calls the “Identity Oracle”, which is his name for an identity provider (”i-broker” in i-names parlance). What Bob contends is that if an individual designates an i-broker as authoritative, the i-broker should be able to protect the user’s privacy by actively giving out falsified data in response to questions that a third party (typically called the relying party) should not ask. In Bob’s model for an Identity Oracle, anyone can ask it about any identity for which the Identity Oracle may have information. The ability for the Oracle to respond with a lie is simply a very clever defense against parties asking for information who have no legitimate right to ask for it. Bob uses a great quote from Sir Winston to explain this rationale.

“In wartime, trust is so precious that she should be attended by a bodyguard of lies.”

-Winston Spencer Churchill

Talk about a head-banger. As always, I’m going to be thinking about this one for weeks.

The term “identity rights agreements” was coined by Phil Windley, Doc Searls, and friends in a discussion about identity after OSCON last summer. The full story is in a blog post with that title by Phil.

At the Internet Identity Workshop last October, we held an open space session by that name because a number of Identity Gang folks have been talking about the general concept for several years now. In particular, from an XRI/XDI perspective, identity rights agreements fit perfectly with the concept of data sharing controls embodied in link contracts.

Now the idea is moving from concept to reality. Identity rights agreements are becoming one of the galvanizing forces for a revitalized Identity Commons. One of the reasons is the oft-used analogy that “Identity Commons should be to identity rights what Creative Commons is to copyright”.

I want to take a moment to explain why I believe this analogy may be so profound — and thus why identity rights agreements may become one of the hottest topics in digital identity.

The trigger for these thoughts was Bob Blakely’s post On the Absurdity of Owning One’s Identity, in which he makes an argument why Kim Cameron’s First Law of Identity is, to use another legal term, “unenforceable”. While I think Bob makes a number of strong points in his post (and illustrates them with fascinating, richly researched examples — who says the art of the essay is dead?), I ultimately disagree with his conclusion only because I think he misinterprets the importance of the first word of the First Law:

Technical identity systems must only reveal information identifying a user with the user’s consent.

In other words, although much of what Bob says is true, only it applies to the people and businesses that operate identity systems and collect/disseminate identity data, not to the technical systems themselves, which is what I believe Kim meant the First Law to apply to.

But that’s a different subject. What really struck me about Bob’s essay was the knock-down-brilliant points he makes about the fundamental privacy concept of “consent”. To quote his introduction to this topic:

Consent

Negotiating the terms on which you will disclose self-image information is what Consent is all about.
In many cases there are laws and regulations constraining what an organization can do with information it collects about you in situations like this, but you don’t control the content of those laws and regulations – so you’re not making the rules (and in fact the interests of society and the interests of corporations influence the content of laws and regulations at least as strongly as the interests of individuals).

If you want to control your identity based on consent, you have to decide between two approaches:

1. Build one set of terms which covers all uses of your information, and let an automated system take care of negotiating your terms and enforcing your rules. In this case, you need to figure out in advance what all the possible scenarios for use of your identity are, and write a policy which covers each scenario.
2. Negotiate terms manually each time someone asks for your information. In this case, you need to get notified each time someone tries to use your identity, and make a decision about whether or not to grant consent.

Case 1 clearly isn’t going to work all the time; you can’t know in advance what benefits are going to be offered in exchange for identity information, and you can’t know in advance what risks are going to be created by giving that information out – so no matter what your policy is, there will always be cases it doesn’t handle correctly. This means there will be lots of exceptions to your policy, and when these exceptions arise you’ll have to fall back on case 2.

Case 2 doesn’t really work either. We know because we’ve tried it. Look here, or here, or here, or here for examples of what you’re already being asked to consent to. How well do you understand these terms? How likely are you to take the time to clear up the things you’re not sure about? How likely are you to say “no”?

Bob then goes on to explain that there are three forces behind his assessment of the problems with consent:

The forces at work here are obscurity, coercion, and burdens.

I encourage anyone who’s interested in this topic to read Bob’s arguments in great detail. But the one I want to highlight here is:

Because Identity Allocates Risk, society makes rules to make sure Identity is used fairly. Two typical rules are (1) someone who wants to use your information has to tell you what it will be used for (”notice”), and (2) someone who wants to use your information in a way that might create risks for you has to get your permission (”consent”). You have to pay close attention here: the rules don’t say that businesses and other parties can’t create risks for you – all the rules say is that other parties have to tell you when they create risks for you, and they have to get you to agree to the creation of the risks.

These rules create obscurity, because in business, the language of risk is law. The bank makes lots of loans, and therefore it is exposed to lots of risk. Because it’s exposed to lots of risk, the bank is willing to spend some money to protect itself against that risk. It spends that money on people who speak the language of risk – lawyers – and those lawyers write consent agreements that let the business do what it needs to do profitably (in this case, it needs to create risks for you by using your identity information) without breaking the rules.

You probably aren’t a lawyer, so the language in which consent agreements are written is foreign, and confusing, to you. On the other hand, you don’t value your privacy enough to hire your own lawyer each time you encounter a consent disclosure – so you end up doing something (reading a complicated legal agreement which allocates risks between you and the corporation) which you’re not really qualified to do, and it’s confusing and frustrating (Don Davis calls this kind of situation a “compliance defect“).

Bingo! Now, if you haven’t done so already, go here right now and read Phil’s very simple and intuitive description of the purpose of an identity rights agreement.

The two fit together like hand and glove. What identity rights agreements could solve — possibly in a very short period of time — is the problem Bob has labelled obscurity. By establishing a small number of very well-known identity rights agreements — and giving them very simple and highly recognizable visual icons that don’t require a user to read A SINGLE WORD — the use of “obscurity” as a tool to all-but-eliminate the value of consent disappears.

Why could identity rights agreements catch on so quickly? For the simple reason that sites who want to give users the real power of consent will start to advertise that fact by posting identity rights agreement icons right on the Web form where they collect personal data. Just as millions of Internet users were first exposed to Creative Commons licenses by seeing the icon for a CC license posted on a blog or Web page they were reading, they will be exposed to Identity Commons identity rights agreements icons on Web forms. One click through to see what they mean and I predict the reaction will be, “Wonderful! I hated those indecipherable legal agreements anyway. I’m going to support sites that use these icons to let me know they are being straight with me about the use of my personal data.”

And suddenly sites become motivated to choose this simpler and more user-friendly form of consent — possibly leading to one of those rare but real “virtuous cycles” (to use a term I first learned from Bill Washburn) that can infect an entire ecosystem.

That’s why — despite my current 150%-of-my-time focus on establishing fully operational XRI infrastructure — I plan to invest time in supporting the creation of the first operational set of identity rights agreements at the revitalized Identity Commons. I’m challenging the rest of the current and new Identity Commons supporters to do the same — I want us to present the first draft set at the next Internet Identity Workshop in May.

Radovan Semančík recently wrote about the privacy concerns with global unique identifiers in his blog post called Global Troubles. He points out that the same issues arises whether those global unique identifiers are URLs (OpenID, LID, and now SXIP) or XRIs (i-names, i-numbers).

Since my work on XRI has been grounded deeply in privacy since the mid-1990’s, I wanted to point out two things:

1. Radovan is absolutely right — it is very important that techologies that use globally unique identifiers pay supreme attention to the privacy implications.
2. When the privacy architecture is done right, the use of abstract globally unique identifiers can increase privacy, not decrease it.

For example, a major selling point for i-names when they go into general release in early 2006 will be that they offer a higher level of privacy and personal control than any other global addressing system. The reason is that an i-name does not by itself need to reveal any information about its owner. It is not an email address or an IM address or a phone number. It is nothing more than a human-friendly global unique identifier which may be deferenced (resolved) into a set of services for interacting with its owner, all of which are controlled by its owner.

Radovan’s point, however, is that no matter what the nature of a globally-unique-identifier, even just a plain old URL, it can be used for triangulation or correlation by third parties that do not want to respect your privacy. As he says:

The global identifiers…are on-line equivalents of SSN, with most of the SSN drawbacks. The attribute protection mechanisms implemented by “identity” systems does not help here, as the data are already out at service provider’s systems and are not in control of “identity” system anymore. Yes, you may create several “personalities” by using several global identifiers, but the management of these different accounts may soon become very difficult. And even that does not help much. Imagine, that you make a mistake and login to the “adult” site with your “civil” account. That alone leaks some information, that you might not want to be leaked. And if you logout and login with the other account, it may be easy to correlate these two accounts (cookies, IP addresses). And great part your privacy is lost …

He goes on to say:

The use of randomly generated identifiers that are shared only between Authentiation/Identity Provider and one Service Provider (as it is in Liberty case) may help a bit. It limits collusion an such way, that the Identity Provider must be one of colluding parties. That may be more acceptable is some cases (but not everywhere).

But neither of these approaches is ideal. There must be something else to look at, some better solution. Or maybe we are chasing ghosts and people does not really want privacy, after all …

He then adds one final disclaimer:

Disclaimer:
Don’t get me wrong about XRI. I don’t see anyting bad about XRI (as I don’t see anything bad about URI either). I must admit that the more I know about XRI the more I like it. But I don’t like i-names. That use of XRI somehow does not feel right …

Radovan is not unique in this respect. I find the more Internet architects and developers understand about XRI, the more they like it because, as an open standard for structured identifiers (”XML for identifiers”), it can solve a number of problems around intelligent, persistent, privacy-protected identification of resources. And it’s also true that i-names and i-numbers (as the new form of fully-abstract globally-unique resolvable identifiers that XRI architecture makes possible) are only one small fraction of overall XRI architecture.

I find that the discomfort about i-names (whether global or delegated) as identifiers for individuals generally revolves around precisely Radovan’s concern that they may somehow be used to compromise privacy, because even though they can be used to shield personal data (as explaine above), once that data is shared, the i-name provides a global correlation handle.

I have two answers to this, one social/legal, and the other technical.

The social/legal answer is that techologies like i-names, when coupled with the right technical underpinnings like XDI link contracts, provide strong, machine-auditable mechanisms for enforcing privacy restrictions. My personal belief is that the legal and social penalities for not maintaining privacy of customer/partner data will only increase, and the more technology is available to support this, the stronger these protections will become.

However there will always be companies/governments/groups that operate “outside the law” and for this technical solutions are necessary. Again, I believe carefully designed privacy architecture can accomplish the goal. With XRI architecture, for instance, we can address a specific concern of Radovan’s…

Yes, you may create several “personalities” by using several global identifiers, but the management of these different accounts may soon become very difficult. And even that does not help much. Imagine, that you make a mistake and login to the “adult” site with your “civil” account. That alone leaks some information, that you might not want to be leaked. And if you logout and login with the other account, it may be easy to correlate these two accounts (cookies, IP addresses). And great part your privacy is lost …

I-SSO (the i-name-based single sign-on protocol under development at XDI.org), can be designed to offer an anonymous login option, where the user does not login with their i-name, but the i-name of their i-broker or of another third-party service provider that provides anonymous SSO service. That party then generates a unique XRI for the relationship just like the Liberty scenarios that Radovan refers to.

Is it perfect? No — users could still make the mistakes Radovan mentions. Or the i-broker or third-party anonymous SSO service provider could slip over to the dark side. Just like your bank could go out of business and steal all your money tomorrow.

My point is, properly employed, these services and the globally unique resolvable identifiers they use can and will build steadily stronger and more reliable user privacy, not the opposite.