MyOpenID

First, I see that MyOpenID has implemented MicroID. Excellent implementation. They allow you a lot of control over how your information should be shared – and with your confirmed email addresses, they publish MicroID for others to be able to better confirm it’s really you.

Plaxo

Second – Plaxo has rolled out their canonical myplaxo.com URLs for each user. Before, the myplaxo.com space autoforwarded to an ‘add me’ page for each user. This was less than perfect for MicroID since MicroID calculates hashes based on the displayed URL in the browser.

With a tweak to the apache configuration at Plaxo, the URLs are stable and Joseph got it working to spec and now things are humming.

Plaxo publishes a MicroID for each of the verified email addresses in your account.

Good stuff.

Digg

In another strong showing for the spec – this morning, Digg rolled out MicroID on their user pages as well. You can see them on any user page at http://digg.com/users/username. Additionally, Digg has taken the interesting new approach to publishing MicroIDs in their responses to API calls as well. A request for developer Steve Williams’ profile via the API produces:

<?xml version="1.0" encoding="utf-8" ?>
<users timestamp="1201200757" total="1" offset="0" count="1">
 <user name="sbwms" icon="http://digg.com/users/sbwms/l.png" registered="1135702996" profileviews="14706" fullname="Steve Williams" microid="mailto+http:sha1:e945976887f47a4ae2bc20dace1a3e4a3808143c">
  <link href="http://www.baychi.org/" description="BayCHI" date="1190263703" />
  <link href="http://www.nuqu.org/" description="Moffett Blog" date="1190263688" />
  <link href="http://www.sbw.org/" description="Home Page" date="1190263641" />
 </user>
</users>

Excellent work all around – this Data Portability thing is actually going to happen one day.

A wonderful discussion – technical but listenable. Full interview is 50 minutes.

Peter spoke about how we are moving offline aspects of oneself online and moving online aspects of oneself offline as well as how the Internet has given us the ability to share personal states (such as “mood”) outside of our small home circle.

I liked this assessment:

If I had to conclude my impression of the chat, I’d say that we are heading into an era of super connectedness between people, people and machines, and across the offline and online worlds. Evolved presence and lifestreams will be very much the plumbing to build that highly-wooven fabric.

Yes, we’ll be merging and projecting. And there will be lots of consternation about how to deal with all of it. Good thing we’ve got Peter and quite a few of the rest of the Identity Gang to help us all get there a little smoother.

And Happy New Year – we’re in the future, again!

As I wrote over at claimID, we had an incredible few days. There was a new energy in the air this time as interoperability was assumed and a focus on services began to take centerstage. There was a lot of talk about Reputation, OpenID 2.0, and OAuth 1.0. We’ve got the pieces now to begin building compelling applications and services. The business models will be appearing in May at the next conference.

We even had an impromptu OAuth party on Tuesday night in honor of the spec being released. Smarr/Recordon/Wachob/Hammer-Lahav/Messina and myself.

I ran a session on Tuesday morning on OpenLifeBits (thanks to John Panzer for the wiki notes) – and had some excellent feedback as well as discussion around what we should be building to house/manage our personal information. How do we define these bits and who owns this content? Is the information we have housed in the corporate silos our own? If someone else is involved in the creation of a particular piece of data – do we both own it? Do we own it jointly with the company as well? A friend request on Facebook – who’s is that to share? Mine? Hers? Facebook’s? Legally, today, it’s Facebook’s.

I’ll take credit here for two quotes captured on the wiki:

“Stalkers were on MySpace, now Facebook _is_ the stalker.”

A little over the top – but definitely something I feel strongly about. We’re seeing individuals post more and more personal information into corporate repositories willingly and without due consideration for where their information is visible and/or to be used under the terms of service.

I see Beacon as part of a greater slippery slope – we’ll all be living, publicly documented, without recourse.

“It’s a good thing that a bad thing became public” — on FB Beacon.

I feel strongly that Beacon is only the first public-facing version of what these large corporations have been doing for years. It is completely naive to think that companies will give away their services for free to the consumer without trying to leverage what they learn through statistics and demographics to make money. They have to have a bottom line, or they go out of business. Free or not, this stuff costs money to run.

When Facebook shows the public what is possible with their data, at first we squirm and yell, then we realize that we like more targeted information – it becomes less about SPAM and more about information we actually wanted.

The tricky part lies in where that fuzzy line of ‘worth it’ is drawn. Is it worth it for me to give my information to a company so I can get a free burger or $5 off my next box of detergent? For most consumers, the answer is clearly yes – or we wouldn’t continue to see these types of offers.

A quote from Alison Black:

Getting inside people’s decision-making, to inject caution before commitment is likely to be extremely difficult (even with well-understood hazards, such as smoking and alcohol, health educators have difficulty getting their message across). But given that there is a likelihood that many people will continue to act humanly and, therefore, incautiously, there is an opportunity for companies to commit openly to respectful data handling. It may cramp their style for trading data in the future, but as more companies commit themselves to rigorous standards, those that don’t will stand out. Maybe this contrast could pique people’s consciousness just enough for them to ask ‘whatever they’re offering, do I want to hand my data over to them?’

When things like Facebook Beacon force us to realize what is happening behind the scenes, we’re more likely to have informed opinions in the future (which is a good thing). That said, I’m not holding my breath for when we’ll see all these companies go with opt-in as their default. In today’s market, it just doesn’t pay nearly as well.

I have been watching and reading about social network portability and data portability and OpenID and facebook beacon and doc searls’ vendor relationship management and Obama’s call for open formats and Google Drive and Jon Udell’s hosted lifebits scenarios (another post just today).

And Chris Messina has been hanging around this space for a while as well and posted two solid write-ups this past week – on data portability and data brokers.

All of these things seem to scream for some integration, for a system that plays by all the rules and ‘just works’ for the simplest of use cases today, and is ready to scale up and handle the use cases of tomorrow.

I’m envisioning a wrapper – a specification that defines how data should be held and managed for an individual. At first, this should be a single human – later, perhaps organizations or groups of people.

It should be the bucket where our digital stuff lives and the vehicle through which we interact with vendors and each other.

I see three parts – at least for now.

1. Data Repository

This is the heart of the matter. A solid datastore on which to build. This can be a collection of approved document formats – ones that are found to be open and/or well understood. Archival quality stuff here. These need to last for a long time and not be rendered incompatible or unreadable in the future. Really, this is nothing more than a well-defined filesystem or collection of files.

I think it’s most useful at this point to consider the different types of data and simply list the types of formats that meet these criteria. If we don’t have such a format at this time, document the gap and hope that the next few years provide standards that match up.

• ICS/iCal – Calendar/Event Data
• MPEG – Video Data
• Ogg – Video and Audio Data
• TXT – Text, preferably UTF-8
• PDF – Portable Document Format
• ODF – Open Document Format (Word Processing, Charts, Spreadsheets, Presentations)
• vCard – People Listings, AddressBooks
• JPEG – Photographs / Images
• SVG – Scalable Vector Graphics / Images
• PNG – Portable Network Graphics / Images
• KML – Keyhole Markup Language – Mapping Data
• FOAF/XFN – Relationships between people
• OPML – Subscriptions
• GEDCOM – Geneology Data (has limitations)
• PHR/EHR – Personal/Electronic Health Record – complicated, lots of standardization attempts
• APML – Attention / Interest Data
• Financial Data – records, transactions, balances, gets complicated quickly, OFX, GnuCash

2. Data Channels

This is the second piece – getting data in and out of the repository. Open protocols are the key here and it seems we have quite a number of them already being pushed around the live web. Let’s name some and find some gaps…

• XMPP – Messaging – does voice, text, images, this is the Jabber protocol
• HTTP – The web protocol – very handy
• RSS/Atom – Syndication
• OAuth – Authentication between applications
• OpenID – Authentication of Users
• Yadis – Service Discovery
• SMTP/IMAP – Mail protocols

3. Data Management

The third part of this specification would be focused on the management of the data that in the repository and keeping things secure and logged. This is the most complicated part and what makes OpenLifeBits the most different from anything we’ve already got today. Encryption should be at the heart of keeping things well secured (having a brokered encryption market (managing access to secret keys) is another task altogether). Additionally, the dataset should have the capability to be split/merged at will. If you don’t want your medical history stored near your financials, so be it.

• Metadata – describe the data in the repository – using open standard METS
• Permissions – access control – does an open standard exist, Unix permissions?
• Encryption – variety of standards, definitely should have good, strong defaults
• Backup – needs to be atomic, automatic, and recoverable (versioned, even)
• Logging – a full record of what has happened to the life of the dataset

Interfaces

A fourth piece that is really beyond the scope of the definition of any spec is the interface(s) into this data and how a person actually interacts with the data and the outside world via the dataset. A comprehensive list will not be possible to create today, but a solid look at what is available today should force a flexibility of thinking to allow future innovators to do what they do best.

• Mac
• Windows
• Linux
• API
• smartphone
• star trek communicator

Brokered Digital Identity Management

The entire infrastructure/dataset should be portable. Most people will not want to worry about the intracacies of managing this kind of data. We already do it for banking – we get a broker. We outsource and allow experts to manage our stuff for us. We let them worry about the details and there is a marketplace to encourage them to behave well. If they do not, we can move our stuff. This should be the case with our lifebits as well.

Big Picture

There is a large amount of momentum (and cash) behind today’s corporate model (companies own data about you). Inverting the system to be beholden to me and my permission model is not something that will happen overnight. Additionally, the legal questions around ownership of data and the contractual obligations of those you share your information with remain unanswered questions. I have a hunch though that a lot of these types of questions have precedent – just not with the specifics of personal data archives.

As we move into a more digital existence, we will need tools that begin to manage this type of stuff on the personal level. Do you think we can start small and simple and grow into the more complicated models later? Is anyone going to see any value in this OpenLifeBits model besides the geeks among us?

Next week’s IIW in Mountain View should have quite a few people willing to talk about an OpenLifeBits. Please come and find me if you want to hash some of this out further.