Here’s how you can bring the ideas in our data portability policy to hundreds of millions of people. I’ll need your help in May and June to start. In short: build portability principles into boilerplate identity contracts.

What’s a trust framework? . . . → Read More: #portability4trust: How we will bring data portability to trust frameworks this quarter.]]>

Dial or Skype details for this Wednesday’s Conference Call to start before IIW.

Here’s how you can bring the ideas in our data portability policy to hundreds of millions of people. I’ll need your help in May and June to start. In short: build portability principles into boilerplate identity contracts.

What’s a trust framework?

Trust frameworks are the many contracts that say how all the parties who move your personal data should behave.

For example, there are contracts between you and organizations that hold and use your data. These can be a Facebook, a bank, a hospital, a phone company, a government agency, a school or a library. These organizations help you use your identity with them, like your Facebook ID, to prove who you are to third-parties.

Trust frameworks describe the contracts between you and each identity provider, between the identity provider and the relying parties who receive and change your data. Trust frameworks improve clarity and accountability and lower the cost and effort of sharing data well and safely.

These are the legal and policy counterparts to the technical protocols like OAuth used to sign you in among web sites and to move your data. There are a few trust frameworks live and more on the way. The contracts promise things like keeping your data safe or asking for permission before selling your data.

I believe they should include data portability practices among the promises made to users.

Why now?

NSTIC is an international program to encourage everyone to build and use trust frameworks. NSTIC is short for the National Strategy for Trusted Identity in Cyberspace. Here is the full text of the NSTIC strategy document. Last week the White House moved the NSTIC project office to the US Department of Commerce’s NIST, the National Institute of Standards and Technology. Corporate, startup and NGO interest are high.

The World Economic Forum launched a three year “Rethinking Personal Data” project, including data portability. Their first report, Personal Data: The Emergence of a New Asset Class, shows their directions.

The Personal Data Ecosystem Consortium is picking up members, traction, and launching three programs over the next few weeks.

What can we do as the DataPortability Project?

We can give organizations building trust frameworks the raw material they need to define data portability in practice and in enforceable contracts. They are writing standard language for millions of contracts right now.

Data Portability Trust Framework Documents

Teams building trust frameworks with data portability need our Project to draft, validate, refine, and publish these seven documents.

• A portability principles manifesto. Listing the principles of data portability and why they matter.
• A portability policy pledge. A short, direct promise to support the data portability principles.
• A portability policy template. Like the questions found at PortabilityPolicy.org, a structured way to assure all data portability principles are addressed and disclosed, whether they are supported or not.
• A portability policy minimum disclosure. Describe the least amount of disclosure required by a trust framework.
• A portability policy minimum practice. Describe required data portability practices. This is prescriptive.
• A portability policy recommended practice. Describe portability practices above and beyond the required. With time and support of the trust framework’s organization, recommended practices may become required.
• A portability glossary. Defining our terms.  

Some of these documents should and can be in simple, plain language. For example the manifesto should explain data portability persuasively.

Others should be sufficiently specific that a third-party could verify portability claims in practice. So if you say you delete all a user’s data on request, the minimum practice lists how that would be proved.

We’ll version these documents and bring them through stages of maturity, from proposed to draft to final, or a similar approach. This way everyone knows exactly what they sign up for.

The next 30 days.

Now through June. Project volunteers will write and edit the documents.

27 April. I’ll host a Portability for Trust Frameworks conference call Wednesday to get things started.

• 11:00 AM Pacific, 2:00 PM Eastern, 7:00 PM London, 20:00 Berlin, other local times.
• In the USA: +1-201-793-9022, access code 1719146#.
• Toll free via Skype:+9900827041719146.
• Skype IM backchannel: http://tinyurl.com/dpptrust.
• We will have weekly conference calls where they don’t conflict with other events.

3-5 May. The Internet Identity Workshop (IIW12). We will have data portability working sessions to scope, write, edit, and test the documents. See you there.

10-13 May. European Identity Conference. Munich. Not yet scheduled, but we’re hoping for a birds-of-a-feather session to discuss this work and recruit EU contributors. More than five hours of this EIC are on trust frameworks.

11-13 May. Telco 2 and Personal Data 5. London. I hope some of the Personal Data unconference attendees will schedule a working session on day three.

19-21 May. Privacy, Identity, Innovation 2011 conference (PII), with PrivacyCamp on Saturday. We’ll have working sessions during PrivacyCamp. Silicon Valley.

What you should do now.

1. Put time on your calendar for our events and conference calls. (5 minutes)
2. Join our low volume Google group (2 minutes).
   

   Subscribe to "Data Portability Trust Framework"

   Email:

   Visit this group

3. Re-read the 10 Questions on PortabilityPolicy.org so you are familiar with the baseline documents. (10 minutes)
4. Invite fellow authors to work on this.
5. #Portability4Trust is our hashtag. Spread the word that we need help, please.
6. Cash. Some of this work will involve travel and professional services. The DataPortability Project is a 501(c)3 California charitable corporation. Underwrite our work with donations and in-kind legal services.

As always, I’m available to talk in private. +1-510-316-9773, skype:evanwolf, @evanwolf. – Phil Wolff.

A draft of slides for IIW below…

Why am I posting AS updates to the DataPortability blog?

Activity Streams reflects our data portability values, helping users have their . . . → Read More: Notes from the ActivityStreams lunch]]> The ActivityStreams group’s technical efforts to finalize a spec in time for the next OpenSocial event in May are coming along nicely. What about the other elements that make for healthy protocol adoption?

Why am I posting AS updates to the DataPortability blog?

Activity Streams reflects our data portability values, helping users have their data wherever they go online. I’m participating in the AS effort on behalf of the #DPP.

— Phil Wolff, editor

We talked about what it takes to launch the ActivityStrea.ms site. This was about a half hour of our April 1st, 2011, four-hour lunch at Chevy’s in San Francisco during the Web 2.0 Expo.

We started with design questions.

Who is our site’s customer? We tried to categorize by organization size (BigCos, startups, individuals) but this didn’t work. Roles worked better. So far we’re clustering geeks (engineers, technologists) and non-geeks (suits, product managers, designers).

Goals? What might these users want when they visit?

• Fix my stream. Technical help.
• Learn. How to, specs, why.
• Get. SDKs, code samples, books, t-shirts.
• Discuss. Specs evolution, issues, implementation.
• Promote my stream. Testimonials, leaderboard.
• Build tools. Extensions, validators.

Unique Selling Proposition? Why would an organization adopt activity streams? We listed five business drivers:

1. With AS you have fewer protocols to support. You’ll use the Facebook APIs and then ActivityStreams APIs for everything else social. Benefits: Increased simplicity, lower up-front cost, lower maintenance cost.
2. AS brings many data sources to your site. This increases your service’s relevance to your customers. It also lowers the time and effort to implement and to minimize the cost of keeping up to date with hundreds of partner APIs.
3. AS is extensible. You can publish and consume data specific to your problems and markets. This means increased reach for your content, relevance for your users, and fit-to-market for your services.
4. AS offers better uptake than your custom API. Your updates will be consumable by the entire ecosystem.
5. AS is proven. A long list of large Internet companies use AS. This lowers engineering and adoption risks for your project.

KPIs. We brainstormed "Measures of Success" for the AS project launch. We might measure:

• Adoption
  • Registered AS publishers/consumers
  • Developers using the SDK, documentation
  • Validator activity
  • Millions of activities shared
  • github activity
• Health
  • Problem backlog
• Community
  • Conversation

Our conversation continues on the Activity Streams mailing list.

Well, sort of. To date, the DataPortability project has often referred to its vision as “Open Standards based Data Portability”.

The problem, though, is that people don’t get why Open Standards are so important. Some even think that we’re advocating open standards for the sake of open standards. In . . . → Read More: Forget Open Standards]]> Forget Open Standards…

Well, sort of. To date, the DataPortability project has often referred to its vision as “Open Standards based Data Portability”.

The problem, though, is that people don’t get why Open Standards are so important. Some even think that we’re advocating open standards for the sake of open standards. In truth, Open Standards are just a means to an end. It’s time the community started to focus on the end, rather than the means.

The end is not “Open Standards based Data Portability”. Rather it’s what I’m starting to call ‘Peered Data Portability’.

Peered Data Portability differs dramatically from what we have today from Facebook Connect. Here are some diagrams to explain:

FB Connect Version of data portability - Hub n Spoke

The Future of Data Portability - Peered Nodes

Does the peered model look familiar? It should

The Internet is already a Peered environment

In the Hub and Spoke model, a single node controls the transaction and facilitates data sync between participating 3rd parties. This is efficient and always the quickest and most commercially viable way to get the job done (at least for the central node).

The problem, however, is that it has a central point of control, failure and commercialization. A monopoly, or market confusion, is inevitable. At the very least this model leads to reduced innovation along the connections.

Can you imagine if there was only one Web server? One FTP server? One Email server? Companies like Google would have certainly never been allowed to exist. They might have been sued by the Acme Web Server company early in their life much like Power.com is being sued by Facebook today.

The peered approach, is much more analogues to the web itself. It lets a thousand flowers bloom as equal participants in an open ecosystem. It allows and incentivises innovation at all the nodes. It also means that the solution is not a commercial product, but rather part of the fabric of the web itself, much like HTTP is.

Sure, Open Standards may facilitate interoperable peering, but that’s just a technicality along a much bigger journey. So while Open Standards are important, they are certainly not the point. Standards come and go (and some stick). The peered, web-like nature of the Internet will outlive us all.

It’s time to move the conversation up the intellectual stack.

I look forward to the continued emergence of Peered Data Portability.

Note: This is a follow up to my ‘Forget Facebook’ post last year. I don’t mean to pick on Facebook, but their first mover status provides a clear counter-point.

In case you’ve never heard of it, Twitter is a micro-blogging service that is doing to communications . . . → Read More: Time To Criminalize The Password Anti-pattern]]> Update: Twitter made another commitment today to adopting OAuth which is great! However they acknowledge that it won’t solve all problems (like we argue) – nevertheless these are positive steps to us eradicating the password anti-pattern

In case you’ve never heard of it, Twitter is a micro-blogging service that is doing to communications what search did to information. It has exploded in popularity, and whether they find a revenue model or not – their impact is permanent and is leading the way for a new era of communications. I am one of their biggest fans and want to help them succeed. But I feel with their growth, propelled by loyal users like myself, we ought to let them know there are things that concern us.

The biggest issue is that whilst they enable data portability, they are doing it in an insecure way. As Chris Messina said, lets make 2009 the year we see the end to the password anti-pattern. In this post, I will explain what that anti-pattern is and a way we can fix it. The biggest reason why Twitter is continuiing with this anti-pattern (from my eyes), is because it’s a usability issue. But as you will see me prove below through screenshots, it isn’t. Just think of having a PIN code on your bank card: that’s a usability issue as well, but y’know, one of those good usability issues.

Twitter and Security: all we’ve heard in 2009 so far
Twitter is used to constant free PR, but this year two separate events occurred that could have been non-events (if they do what we ask).

The first was a third-party that provided a feature people wanted. As Twitter has an Application Programming Interface (API), third-party’s can create mashups and therefore provide this functionality to Twitter users. However because Twitter does not support delegated authentication, you need to enter your username and password. There are hundreds of third-party applications like this, and most are safe (we hope), but this particular site within 24 hours had put itself up for sale! And people couldn’t turn off the service – they had to change their password to do so.

The second incident to occur this last week, was an attempted phishing. Apparently, some users were being sent private messages telling them to visit a certain site which compromised their security. It’s ironic that Twitter tells you to not “share your private info” but for you to get value out of their API for mash-ups and third-party tools, that’s exactly what you need to do – and it makes situations like this slightly more risky.

Fortunately, there are things that can be done to minimize the risk of your accounts getting hacked, and for you to never have to give up information about you that will compromise your security.

Delegated authorization
There is a solution to this situation. It’s free to support it, simple to use, and in fact – Twitter’s team inspired its creation the other year. It’s through the use of an Open Standard called OAuth. There is plenty of material you can read on the web about this and a good start is Eran Hammer-Lahav’s explanation of oAuth followed by his three-part series for beginners if you want to dig a little deeper.

The basic concept is that it allows you to delegate authorization for use of an API. Huh?

I’ll illustrate this with an example. Let’s say you come across a Cool Product that allows you to do something unique with your Twitter account (say, being able to stream your Tweets through your e-mail client rather you having to visit the Twitter website). As this Cool Product has no formal links to Twitter, for you to use it, it needs to pretend to be you. Therefore, it asks for your user name and password. It knocks on Twitter’s API door, pretending to be you, and the Cool Product then gets access to your account to do the stuff you want to do with this third-party application. The problem with this approach, however, is that they can knock on Twitter’s door anytime pretending to be you – even when you don’t want them to.

With OAuth, it would be very different. Instead of you needing to provide your username and password, this Cool Product will say “Hey dude, I need to get some permissions – click this link to give it to me”. Then a request will be sent to Twitter’s API and Twitter will send you to a screen saying “hey dude, these third party dudes want access to your account – you cool with that?”. Then, with a simple click of the button, you can approve or deny access. Once approved, the Cool Product can then function – and you didn’t have to give up any private information like your password.

Here are some screen shots between another innovative start-up called FriendFeed and Google (who supports OAuth).

In this scenario, I want to add some more friends on my FriendFeed account. So I click on the option to invite them

When I click on “import from Gmail”, instead of having to type in my username and password to access my contacts, I simply get redirected to a screen. And because I’m permanently logged into my Gmail account, I don’t need to do anything else other than read and click “grant access” (otherwise, I would need to enter my Google credentials).

.

Easy! Compare this to Facebook, another company that needs to think more proactively about its users security. If I want to add friends to my Facebook account, instead of redirecting me to the Google servers where I can grant access, it asks for my password.

Next steps
As people on the web using web services, we’ve been forced to give up confidential information to get the value out of a service. We’ve forced ourselves to be okay with it with the sites we trust, but there are plenty of brands out there we don’t know to trust. But the thing is, this isn’t something we need to trust anyone with. With our health records and financial records accessible online, this isn’t just a matter of reputation risk but one of genuine identity risk.

There is a solution to this problem, and now that you recognize it, demand web services to give you data portability in a secure way. Let’s make 2009 the year that we kill the password anti-pattern. While easier said than done, it’s a fix that will curb some of the security issues: we hope Twitter hurries up in changing their API to require OAuth.

Twitter – we know you’ve been meaning to do it, but hopefully you really mean it this time. Because quite frankly, we as users are fueling your growth and the promotion of your API without some sort of safe-guards like this, is irresponsible (especially as these attacks prove you are going all the more mainstream. I don’t want to tell you how to run your business – it doesn’t have to be OAuth – but for crying out loud, give us some security for our digital identity.

One final Big But
Twitter has strong arguments to not jump onto OAuth, some of which they’ve said publicly and some that I think might be issues. They certainly have a competent team, and whilst they know the benefits, they also understand the fact that jumping onto OAuth or any type of delegated authorization will not fix all problems. However it’s a start. Here are some issues:

1. OAuth is only good for services over web browsers. It is a real pain (or virtually impossible without some hacks) to use it for the client side (ie, on the desktop) and mobile sites – both of which Twitter has a lot of users that use it this way. The response to that is that some security is better than none – it’s not a big deal that users will have to authorize applications via the browser (and Twitter can just point a hairy finger at the standards community so they can fix it). At least give users the option to determine how secure they want to be.
2. Twitter will need to support multiple authentication systems due to the limitations of oAuth. This is a real issue, but not an impossible one to manage, and the community is certainly willing to help out. My main point is that this is actually a security issue that matters, and because the cost is borne by the users and not the company, it’s not given equal recognition.
3. The user experience will suffer for users. Well the reason users will “suffer” is because now, instead of just entering their password, they will now have to click a few buttons on different screens. As the screenshots show above, the user experience is not affected that much and I think while a valid point, it’s more a “different” user experience
4. The user experience will suffer for developers. Yes it will, because instead of the lazy option to just ask users to hand over their password, they actually have to write some code to get the appropriate permissions happening. But this is a core reason why the DataPortability Project supports widely-supported Open Standards, as it minimizes the costs to business: once a developer learns it once, they know it for all future application development.  And like I said above: a bank not puting a code on your bank card, is more painful for your bank, but better that pain than the option without which poses risks for users.
5. It will not prevent phishing.  Lachlan Hardy gives a useful explanation on why (notice all Australians give the best explanations ), as theoretically, people will be more prone to phishing attacks because of the ease. This is a valid point, as people potentially will just blindly click away to their doom, but let’s also remember there will also be a lot more control. A site can monitor suspect services to alert users, there is a full digital paper trail, and a user can revoke their authorization at any time. Certainly a bit of control is better than none, and by reducing the weak spots in the chain, more targeted efforts can be made to ensure users’ security is no compromised.