Equals Drummond

Phil Windley, co-founder and CTO of Kynetx (among the many hats he wears), wrote his own rules language, KRL, to “program the Web”. So when Phil writes the following about XDI after he and his team did a two-day deep dive on XDI with XDI4J project founder Markus Sabadello and I, it means a lot.

I haven’t been posting much about XDI because the OASIS XDI Technical Committee (which I co-chair) is still working on the XDI 1.0 technical specs. But since our philosophy has been to code everything in at least one implementation first before committing it to a spec, and since the core XDI graph model and metagraph model are now very solid, by the time the specs come out there will already be multiple operational XDI services.

I hope to finally get time to do many more posts about XDI this fall. In the meantime if you want to learn more, ping me about different ways to get involved.

My primary involvement as a member of the board of the Data Portability Project has been input about XDI as an open standard for portable data. But I’ve always been very enthusiastic about DP’s work on Portability Policies. The DP Project just announced their first Portability Policy deliverable via this blog post on TechCrunch.

On the DP Project board call this morning I shared the view that Portability Policies are an inevitable first step — and a highly welcome one — towards widespread adoption of personal data stores (see my posts earlier this year about PDS here and here). When PDS finally arrive, the irony is that the policy will turn in the other direction, i.e., the individual will have their own data sharing terms and the vendor will be agreeing to those. That’s the essence of VRM.

Iain Henderson of VRM pioneer Mydex is already working on the terms for such an agreement at the Information Sharing Working Group at Kantara.

Bit by bit, the age of personal data stores and personally-controlled data sharing is dawning.

Remember that year-end blog post about how personal data stores (PDS) are closer than they may appear? Now read Phil Windley’s wonderful summary of why it makes so much sense to create a PDX (not really an acronym for “personal data exchange” so much as just a moniker for a global internetwork of PDS).

It’s happening. Look for more news about it by Internet Identity Workshop (May 17-19 in Mountain View, CA). As if you didn’t have enough great reasons to go already.

Joe Andrieu has a wonderful way of cutting the Gordian knot on complex socio-technical topics, with clear prose, compelling arguments, and clever illustrations that explain why you should look at something decidedly differently.

Now he wields that knife on the very knotty “problem” of data ownership.

I passionately agree with Joe (and his Kantara Working Group co-chair Iain Henderson) on this subject; I suspect it’s because my perspective on it was long ago warped by the lens of XDI, which itself is a new way of thinking about data.

Turn the telescope to look at personal data from the standpoint of who controls its  sharing with whom, and many pieces finally come into focus.

Keep that in mind as we move into an XDI-enabled world.

I recommend Doc’s new post that explains the essence of what’s behind VRM. It’s a big vision, his, but Doc has a way of framing the future that makes it look inevitable – all that remains is the question of “how close is it in the mirror”?

I’m betting that this object is closer than it appears.

This entire fall has been intense with work, thus the paucity of posts here. The holidays brings a welcome respite and a chance to catch up with a few key mental threads.

One of them is the growing awareness of the need for what the VRM community calls personal data stores (PDS). The concept is relatively simple: an online store for your own personal data — anything from classic PII (personally identifiable information), such as your identity and contact data, to any other data that you generate or control (files, blog posts, pictures, papers, music, videos, etc.)

Three things have surprised me about PDS:

1. How generally accepted the notion is by almost anyone who spends much time online, even folks well outside the identity community. It’s a relatively intuitive idea as soon as you understand the basic premise that individual people should have their own data source online.
2. How many names have been applied to the same general concept. As I indicated, PDS is only the term applied by the VRM community. The same general concept has been called probably a dozen other names. Here’s an excellent blog post by Mark Dixon that calls it a Personal Identity-Persona Service and a Security Identity Bank Vault.
3. How hard it is to implement. Though there have been several attempts, such as the Mine! Project, nothing has come remotely close to catching on yet.

I have several theses as to why this is so (and yes, the need for a Internet data sharing standard like XDI is high on the list), but I’ll save those for another blog post.

Here, I’ll just conclude with a simple prediction: it’s a threshold problem. Once the first practical solution for PDS starts to take hold, it will catch on and grow just like the first social networks did. The only question is what application will provide that initial traction.

At the Glue Conference this week I’m enjoying a great set of speakers lined up by Eric Norlin on the topic of how everything in the networked universe gets glued together using Web 2.0 tools and beyond. (The talk Mitch Kapor gave this morning was worth the trip all by itself.)

In a few minutes I’ll be on a panel called Implementing the Open Web. In chatting with Lloyd Hilaiel of Yahoo, Kevin Mullins of MIT, and Phil Windley of Kynetx about this topic last night, we hit on one key point that Phil articulated this way: “People tend to conflate ‘open’ with ‘public domain’, i.e.,  that anything that qualifies as open must be freely available to all.”

It struck me how true this is. It reminds me of the Richard Stallman quote describing open source (cited in the Wikipedia Gratis versus Libre article): “Think free as in free speech, not free beer.”

In terms of data on the Open Web, what this means that even though a particular pool of data may be available via an open standard, publicly-accessible interface, it does NOT mean this data must be publicly available to anyone. If that were true, the whole concept of a personal data store — a key premise of VRM (Vendor Relationship Management) — would not be possible.

So what makes any system or node participating in the Web “open” is not that its data is public, but that the metadata and services for accessing it are available via a publicly discoverable, open-standard interface. The public discovery portion of this is the goal of the XRD work now underway at the XRI Technical Committee at OASIS (based on the original XRDS work – see this blog post by Eran Hammer-Lahav of Yahoo to understand the differences). The open standard portion is the output of IETF, W3C, OASIS, and all the other SSOs (standards-setting organizations) for the net. (The potential of the Open Web Foundation, once it finishes its bootstrap stage, is to make this process of creating open standards even more lightweight and distributed.)

This combination – open discovery of open interfaces accessible over open protocols – is the DNA of the Open Web. And it applies equally to both public and private data. In fact it can finally open up what might be called the Permissioned Web - the Web of all all data that any one party has permission from other parties to access.

That would lead us to the need for integrating identity and permissions with the data, which brings us to the motivations for XDI as a semantic data sharing format/protocol – but my panel is about to start so that will have to be another post.

More about the long quiet spell soon. First I must post about a trip I made last week to spend the day with Phil Windley, his partner Stephen Fulling, and the inimitable Craig Burton down in Salt Lake City.

What Phil and company are doing at Kynetx is earthshaking. There’s not much info on the website yet, but last week Phil posted a white paper The Advent of Next Generation Browsing that introduces the whole concept of structured browsing. I won’t even bother to try to explain it here; just get the paper and read it. Then read another one of Joe Andrieu’s exceedingly cogent essays with his impressions, criticisms, and suggestions about the Kynetx vision of structured browsing and how it fits with Joe’s work on search maps. Also read Phil’s reply to Joe.

The rules language Phil wrote (KRL – Kynetx Rules Language) is at the heart of their solution for structured browsing. I am a huge fan of what rules languages can do with structured identifiers and structured information. That’s what I was down in Salt Lake talking with Phil, Stephen, and Craig about. Phil followed it up with a great post, First Class Namespaces in Programming Languages, that sums up how XRI and XDI might fit with KRL.

Did I say earthshaking? Watch out when this quake breaks loose.

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 =

Joe Andrieu nails another super post (where DOES he find the time to write/draw all of these???), this time about what it means for a platform to really be open.

My favorite part is that he doesn’t just do it in words — he does it in pictures, deliciously simple and understandable graphics that make it really clear what he means by “open platform”. In short, it’s the protocol, stupid!

Or as Joe puts it:

Level 4 platforms allow developers to build applications anywhere–on a website, on your desktop, even on your cell phone–and those applications can talk to any number of platform providers without restriction, using standard open protocols. Many of us have heard of the most successful protocols: SMTP, POP, HTTP, HTML, TCP/IP, RSS, but most users know these by the applications they enable: email, the World Wide Web, the Internet, blogs.

It’s the perfect message before the VRM Workshop starting tomorrow, and of course it’s exactly what we’re driving towards with XDI. One day I hope Joe can say the same thing about XDI – most users will never have heard of it or the dataweb model of data sharing, but they’ll know the application – VRM!

Doc Searls has done a very succinct post on the Principles of VRM in preparation for the VRM Workshop next week in Boston. You can’t read it and not see how closely VRM is related to r-cards (relationship cards) and XDI. I’m so excited to actually start bringing this to market this year that sometimes I want to drop everything else (standards calls, conferences, email, expense reports, EVERYTHING) and just work on that ’till its out the door.

Like the Web itself, the Web of Relationships — the whole Web becoming a social network — will change the world in ways we can hardly begin to imagine.

So much for the naive thought that I’ have time at the Burton Catalyst conference last week to finally blog about two subjects near and dear to my heart that I knew would be covered at the conference. It backfired because they were too topical — all available time was consumed by related conversations.

I did manage two posts about the first one — launch of the Information Card Foundation — about which there will be much more to say in the coming months.

But the other one — relationship cards — is long overdue. I first promised to blog more about r-cards after both doing a demo and hearing Bob Blakley’s fantastic talk on The Relationship Layer at Spring IIW in May. Then Joe Andrieu and Eve Maler both posted about them and asked me to add more details. Then I fell into an abyss of work (actually building this stuff) from which I have yet to climb out.

But Bob’s new talk on The Relationship Layer at Catalyst last week, followed by Eve’s talk on The Care and Feeding of Online Relationships, plus the upcoming VRM (Vendor Relationship Management) Workshop at the Harvard Berkman Project on July 14-15, compels me to finally post about why I believe r-cards may be what finally pushes Internet identity across the chasm.

—-

First: what is a relationship card (”r-card”)? At the most general, the definition I would offer is:  “a digital object instantiating a mutually authorized data sharing relationship between two or more parties on a network”. The abstraction is intentional: the generic concept of an r-card, like the generic concept of a folder, a link, or a network, can take different forms in different implementations.

To take a step more towards the concrete, the concept of an r-card was conceived at the Higgins Project as a new kind of information card (i-card). For their part, i-cards were first conceived by Kim Cameron and team at Microsoft, where they have been promoted as a key element of Microsoft’s vision of an identity metasystem. These memes subsequently took hold at Higgins, among other places, where the concept of an i-card was generalized to the definition that currently appears on Wikipedia:

An i-card is a rectangular icon displayed in the user interface of an identity selector (sometimes also called an identity agent) that represents a digital identity–a set of claims about some entity (typically a person, but it could also be an organization, application, service, digital object, etc.).

The i-card metaphor is based on familiar physical identity credentials like business cards, credit cards, library cards, association cards, driver’s licenses, badges, etc. However, just as computer file folders are similar to but more powerful than real-world file folders, i-cards are similar to but more powerful than real-world identification cards. The i-card metaphor is identical to the information card metaphor used in numerous identity selectors.

So what distinguishes an r-card from a plain-vanilla i-card? The capability to instantiate an ongoing data sharing relationship. In other words, a standard i-card invokes a one-time exchange of a set of digital claims using a security token. An r-card, by contrast, exchanges a set of claims and associated policies that enables both parties to continue to share other information over time, e.g.:

• Updates to the initial values of the claims
• New claims
• Permissions and controls over communications via other channels
• Changes to the r-card itself

A simple analogy would be: a standard i-card is like showing your driver’s license to a bartender to prove you are of age: you use it once and put it away. An r-card is much more like giving a business card to an associate or a customer: it is an invitation for an ongoing relationship via the address(es) and other information shared on the card.

—-

But while instantiating a private data sharing channel by exchanging a digital object is cool — sort of like RSS on steriods — for some reason that aspect alone doesn’t capture the real power of r-cards. Case in point: after a live participatory enactment of how r-cards work with audience members during the first day of IIW in May (all based on business cards, scissors, and string — no computers involved), several audience members came up to me and said, “Why didn’t you show this years ago? Anyone can understand the value of r-cards. They are the most compelling use case we’ve ever heard for all this Internet identity stuff.”

After that experience, even I was trying to grok what it was that made r-cards so intuitive and attractive. I was having trouble putting it into words until I was listening to Bob Blakley’s talk on The Relationship Layer again at Catalyst last Wednesday morning. At the midway point, he put up an “intermission” slide with five bullets summarizing the first half of his talk. Two of them hit me like they were shot out of a gun:

Relationship is the context which protects the security and the privacy of identity information.

Identities are built in the context of relationships.

This Copernican revolution Bob was proposing — that relationship is really the sun around which identities orbit — suddenly made me look at r-cards in a new way. It wasn’t just that r-cards enabled bidirectional data sharing. It was that r-cards create the context for a relationship. And by doing so, they call forth all social dynamics of real world relationships that are often missing on the Web today. Dynamics like:

“I am more inclined to trust you because we both know if you break that trust, I can terminate the relationship.”

“Of course you wouldn’t share our private shared information outside our relationship — friends always respect each other’s privacy.”

“Each of us shares information in proportion to the value it brings to the relationship — both of us are incented to build that value.”

That’s why people find r-cards so intuitive — they are a way of creating and managing the same balanced, mutually-controlled, give-and-take between two parties over a network that we have in the real world relationships we manage every day. And they can apply to any form of relationship — person-to-person, person-to-community, person-to-employer, person-to-vendor, etc.

—-

Okay, okay, at this point I know all the geeks are screaming “enough with the soft stuff — where’’s the technical beef??” I don’t want to duck that question, because as I’ve told Joe Andrieu, chair of the VRM Standards group, I’m knee-deep in it every day. But with the limited time I have left for this post, I can only give the high-level recipe we are currently putting to the oven test at Parity and the Higgins Project:

• Take a conventional i-card as currently defined by the Microsoft ISIP documents (which can’t get into an SDO fast enough).
• Add an OpenID — or to be precise, an identifier on which you can do XRDS discovery to locate a data sharing endpoint. In Higgins we call this form of identifier a UDI (Universal Data Identifier).
• When the r-card recipient receives the r-card, use the UDI to perform XRDS discovery of an Internet data sharing protocol supported by both parties.
• Intiatite data sharing via the selected protocol, using the UDI and other supporting claims on the r-card as necessary.

Of course readers of this blog know what data sharing protocol I have in mind: XDI — specifically the XDI RDF model. It’s particularly well-suited to r-cards because XDI link contracts provide a portable, machine-readable description of the mutually-agreed data sharing controls. But it’s important to clarify that any data sharing protocol supported by both parties will work. As an example, Asa Hardcastle showed a wonderful demo of OpenID-enabled Liberty ID-WSF at Spring IIW, and we are deep in conversations about how UDI discovery for ID-WSF endpoints can work. OpenID Attribute Exchange is another option because any OpenID identifier can already support XRDS service discovery.

—-

I know that’s only the tip of the iceburg, but this is a huge topic that I’ll be posting about for months. For example, in Bob’s talk he showed a relationship schema that he, Lori Rowland, and their colleagues at Burton group have already started to develop. I eagerly anticipate working with them to map that to XDI link contracts to make sure we have all the bases covered.

And I’d like to find time to start posting some example r-card XDI messages using super-simple X3 format to illustrate common use cases like the VRM personal address manager.

But right now I’m going to work on maintaining a particularly important relationship — with my wife — by getting to bed!

Ryan Janssen pinged me via my contact page last week to ask if I had time to share the story of how I came to be working on XRI, XDI, OpenID, i-cards, Higgins, and Identity Commons. He reached me this afternoon and we talked for almost two hours. Boy, did it bring back memories. I’m so focused on building out working identity infrastructure and applications based on all these standards and projects that I rarely have a moment to reflect on how many twists and turns (and dollars) its taken to get here. So this was a full-out stroll in the park.

He’s posted an overview and will be writing more as he talks to others who have been pounding away forging this Internet identity layer. Ryan’s really done his homework too — he even included a link at the end to the original XDI white paper that co-chair Geoffrey Strongin and I contributed at the start of the OASIS XDI Technical Committee in early 2004. Wow, did that trip off the old synapses. Most fascinating is seeing the original proposed XDI schema which had just four elements. Four years later, after numerous twists and turns (and by my count 23 intermediate proposals), the XDI RDF model has…four elements (plus the XDI wrapper element). It’s not the same schema (now it’s based on the RDF graph model) — and in fact the preferred serialization is no longer even XML (it’s X3). But it’s uncannily close.

Deju vu all over again…

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.

I’ve never been part of a self-organizing community as large or as effective as the Internet Identity Workshop. If you care about the emerging user-centric identity layer for the Internet – or even if you only only care about the applications that are possible on top of that layer (which frankly are a whole lot sexier than the infrastructure), then don’t miss this next one, Dec. 3-5 at the Computer History Museum. I know of more groups pre-planning sessions for this IIW than ever before, including sessions on Higgins 1.0 (due out at the end of the year), new Identity Commons Working Groups, the new XRI Resolution 2.0 specification (note that the final-final link will be available before IIW), and XDI-RDF.

Paul Trevithick just posted about a significant new step for the Higgins Project – the first contributions adding support for SAML 2.0. At first blush that may not seem surprising – SAML is the granddaddy of modern Internet identity protocols – but it speaks volumes precisely because Higgins established its early reputation as an alternative implementation of CardSpace and WS-Trust.

What this reinforces is that Higgins is really protocol-independent. As Paul puts it:

Higgins is about a consistent card-based experience over whatever protocols have traction in the marketplace.

I’m spending a lot of time with Paul and the Higgins team now working on integration of XRI and XDI for the same reason. Both are open protocols being developed at OASIS for digital addressing and data sharing. Both “plug in” to the Higgins framework and its abstract data model. By serving as a “interchange hub” for data and tokens from different protocols, Higgins has the potential to do for identity interactions what TCP/IP routers did for the net itself – finally get us all speaking to each other.

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.

Joe Andrieu, one of the leaders of the VRM (Vendor Relationship Management) community, has posted a good initial assessment of Microsoft’s first foray (post-Passport) of storing personal data for consumers via their Health Care Record initiative. It’s well worth reading his assessment of how this really legitimizes the market for “personal data stores”.

Since that’s one of the primary use cases for which XDI is being developed as a protocol and Higgins is being developed as an open source projects, there will be much more to say about this in the coming months.

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.