Below is a version 0.1 ecosystem map of providers of four things: source code, communities, technical specifications and products that you can use right now. All are about promoting dignity–”the state or quality of being worthy of honor or respect”–of individuals. In place of dignity I could have used other words like autonomy, independence, re-decentralization, personal sovereignty, etc. Anything to do with today’s status quo web of centralized, websites and services is out of scope. My personal bias towards user-managed identity and personal data ownership/control is also noted.

Some terminology:

• Cloud-Free (P2P): Minimal or no dependency on cloud-based services
• Federated Cloud: Multiple independently hosted servers/services interconnected using common protocols
• Hostable: Can be self-hosted or hosted by a 3rd party provider of your choosing
• $: Paid service

Hyperlinked version of the above (even cooler!)

Fascinating to dive into the IndiWeb community, their aspirations and principles. So many echos and similarities from earlier technologies.

Markus Sabadello made a great point that the marriage of the IndieWeb with Johannes’ IndieBox (FreedomBox, etc.) is a powerful combination.

I’m listening to Ben Werdmuller riff about how he thinks standards should be developed using an incremental, agile approach with an open hacker-oriented community.

To get started read indiewebify.me. A new startup currently called idno.co (comprised of Erin Jo Richey erinjorichey.com and Ben Werdmuller) will create this as a one-click tool (based on PHP, MySQL).

I missed this post on Life Management Platforms (LMPs) by KuppingerCole a year ago. Martin writes:

Life Management Platforms will be among the biggest things in IT within the next ten years. They are different from “Personal Data Stores” in the sense of adding what we call “apps” to the data stores and being able to work with different personal data stores. So they allow to securely working with personal data by using such apps which consume but not unveil that data – in contrast to a data store which just could provide or allow access to personal data. They thus are more active and will allow every one of us to deal with his personal data while enforcing privacy and security. Regarding “Personal Clouds”, that might be or become Life Management Platforms. However I struggle with that term given that it is used for so many different things. I thus prefer to avoid it. Both today’s personal data stores and personal clouds have a clear potential to evolve towards Life Management Platforms – let’s wait and see. I’ve recently written a report on Life Management Platforms, describing the basic concepts and looking at several aspects like business cases. This report is available for free.

The key sentence is:

“They are different from “Personal Data Stores” in the sense of adding what we call “apps” to the data stores”

I agree with this need to add apps to PDSes. This is similar to what we worked on back in the heady Information Card days. In 2009 when we saw that getting adoption of pure InfoCards was going to be a long march, we tried to add the concept of “apps” to the data held in the InfoCard (or better yet “pointed to it by an r-card). We called them app-cards–a superset of InfoCards. We decided to integrate Kynetx‘s KRL technology to implement these apps. Which means the apps got executed in the cloud.

Advertising: Did you know that any adult and employed resident of Kent, Washington can easily get up to $1,000 for any needs? Such a cash advance is called a payday loan.

Inside front cover of The New Tom Swift Jr. Adventures series

Back in grade 6 when I should have been doing homework, I daydreamed of someday growing up to be the next Tom Swift Jr. This image was inside the front cover, and really caught my imagination. The back cover of these books reads:

These are the famous books about a young scientist whose amazing inventions promise to be the great achievements of the future

Tom and his father had a secret laboratory on a secluded island where together they invented and built spaceships, flying submarines (!) and go involved in adventures. Hardy Boys for geeks.

Love this one by Mike Troiano:

Love this chart. Copied from Fred Wilson’s blog

I wanted to express my gratitude for Steve. Not for all the things that the worlds knows, but for a couple of things that he did for me personally.

The first was in the early 90′s when Steve was at NeXT. My startup at the time had some ideas about how to help make the NeXT machine’s operating system better even than a Mac for electronic publishing application. We went to visit Steve to ask for some funding. I explained our ideas and situation and what we could do for NeXT. He like what he heard, but said that in his view the best software was written by starving software developers in garages and that providing funding to them would distort their values. Or something to that effect. Starving we were. But then he did something truly generous. He loaned us 14 new NeXT machines (at about $10k each) to help us, and then never asked for them back. I can’t tell you what this meant to us and to me.

The second was after he was back at Apple in the late 90′s. I found that Steve, despite being CEO, always had time to meet with me about new ideas. He even made time for a fellow developer, Michael Hoffman, when I asked Steve if we could come to One Infinite Loop and meet with him so Michael could present some cool new ideas to improve the Mac Finder. I think one of Steve’s greatest strengths was his ability to recognize talent and attract it. I guess making time for new people and ideas was part of his greatness.

On both counts, and all the better known ones, I’m indebted to Steve.

This (v3) document describes Information Card related R&D that has been undertaken over the past five years by Microsoft, the Eclipse Higgins open source project (especially contributions from IBM, Novell and Azigo), from Axel Nennker, and from the FC2 consortium. In this revision we start with the lessons learned and then follow with a summary of some relevant experiences and development efforts. The opinions expressed here are my own.

Terminology

• A website that relies on assertions from the user agent is referred to as a service provider (SP).
• A web service that issues cards to the user, authenticates the user agent to the card, and provides a set of signed claims on request by the user agent is referred to as a identity provider (IdP).
• An attribute about the user is sometimes referred to as a claim.
• The software integrated with the browser (either entirely within a browser extension, or invoked by the extension) is referred to as an active client or sometimes as a selector.

Lessons Learned

This section summarizes what worked and what didn’t across all known Infocard projects.

User Experience

• Card metaphor. Expressing a facet of a person’s composite digital identity as a card, seemed to work well. There are two broad classes of cards. A managed card represents a set of claims from an external IdP. A managed card holds no claim values, but rather the endpoint of an IdP web service (often called a Security Token Service (STS)). A personal card represents (and physically holds) a set of self-asserted claims from the active client’s internal IdP.
• Usability. First generation Infocard implementations provided complete transparency, notice and consent to the user related to every disclosure of claims to an SP. While providing the best possible security and privacy, the experience was considered overly intrusive and annoying. The balance needed to be readjusted. To improve usability, and admittedly at the expense of some privacy and security, more recent active clients implemented the following usability improvements:
  • Instead of popping up the card selector window each time, the selector would remember what card had been used on the previous visit to this same SP. Microsoft’s CardSpace 2 beta (never released) selector experimented with an option wherein the SP rendered the image of the previously used card “inline” within their web page. Clicking on this card would cause the login (claims transmission) without popping up the card selector window at all.
  • Instead of showing all of the details of the claims required and/or desired by the SP in the initial card selector window, these details were hidden and accessed by drilling in on a link. Examination of the UI of OAuth-based systems in the wild shows that the OAuth (e.g. Facebook Connect, etc.) community has come to an even more extreme simplification of the UI in this area. The UI is often reduced to a checkbox saying that the user is consenting to the disclosure to the OAuth consumer of “some”, [unspecified and not discoverable list of] attributes and other kinds of disclosures.
• Automatic card matching worked well and was critical to simplifying the user experience. Card matching refers to the active client only displaying the set of cards whose characteristics (e.g. the set of claims it supports, the card issuer, etc.) satisfy the requirements described in the SP’s policy (e.g. the set of claims desired and/or required, the set of IdPs that are trusted by this SP, etc.)
• Performance. All common user interactions must happen in less than a second. Early selectors took several seconds to load and display the “card picker” window (especially the first time). This sluggishness was annoying.
• Roaming. The active client must roam the person’s digital identity (i.e. their set of cards) across all of that user’s devices and browsers.
• Unmodified browser support. A major drawback to Infocard is the inability for it to work work even in a simplified and/or degraded manner with an unmodified browser. We learned that future solutions should instead follow a “better with” philosophy. That is, they should work in some fashion with an unmodified browser and then work “better” if a browser-integrated active client is available.
• Card bootstrapping. Infocard failed to provide a UI that would guide the user who didn’t have any cards that satisfied the SP’s policy, to find and get a suitable card. In this situation future solutions must guide the user to a list of possible card issuing sites (IdPs) where a suitable card can be obtained.
• Active client bootstrapping. Infocard failed to provide a UI that would guide the user who didn’t have an active client (or cloud selector) into becoming provisioned with one. Future solutions must guide the user from the SP side to a list of possible (and likely competing) cloud selectors. And, following the “better with” philosophy to a list of identity-capable browsers and/or browser extensions.
• Cross-platform. The solution must be available on all of the user’s computing platforms including mobile devices.
• Cross-browser. Users often use multiple browsers, the solution must work across all popular browsers.
• Cross-protocol. Users simply want things to work. They don’t care about underlying protocols. The solution should present a consistent UX for identity-related interactions irrespective of underlying protocol. Infocard introduced a new, incompatible protocol with that had the effect splintering the identity ecosystem further and introducing yet-another competing UX to learn and use.
• Dynamic claims. Infocards failed to support the dynamic claims. In some cases the SP needs to be able to not just indicate the types of claims required (e.g. givenname, employer, etc.) but also to be able to indicate (dynamic) parameters to the claims. In payment use cases (e.g. using a card to pay for an item at checkout) the SP must be be able to pass the price as a parameter along with its other “policy” information back to the active client so that the client can in turn pass this price parameter back to the IdP (e.g. a bank). The Infocard community never achieved consensus on how to implement this. Axel Nennker suggested an approach that both his own research project and the French FC2 consortium implemented in their respective selectors.
• Claims aggregation. In more complex use cases SPs need to aggregate claims from multiple IdPs (e.g. physical address information from your mobile provider and payment information from your bank). With most Infocard solutions this causes the selector “card picker” UI to appear multiple times in succession (once for each IdP). This is annoying for the user. David Chadwick worked on and the FC2 consortium implemented multi-card selection in their research selector however the Infocard community never reached consensus on an SP policy format that would support a single request for claims from multiple IdPs. See also my opinions in my Attributes First post.
• Brokered authentication (and claims providers vs. identity providers). Current Infocard solutions require the user to authenticate to each (managed) card issuer (IdP) in order to use the card. While the number of passwords (and other challenges) was greatly reduced from the usual one-password-per-SP model, it wasn’t reduced to a single master password (or other kind/set of “master” challenges). To achieve this, a distinction should be made between an identity provider and a claim provider. Ideally the user would have a very small number of identity providers (ideally perhaps just one) to which they would authenticate themselves using a specific, consistent method for a given level of assurance (and other specific, consistent methods for progressively higher levels of assurance). Claims providers would then rely on assertions from identity providers. The active client would “broker” the identity assertions from the IdP and pass them along with their requests to claims providers. The FC2 consortium in their research active client implemented the ability to have multiple claims providers leverage the results of a single authentication to an identity provider (e.g.  a government issued smart card).

Capabilities

• Decentralized architecture. Infocard architecture allows IdPs, active clients, and SPs to be developed independently of one another.
• Extensible schema. For managed cards, the issuer of the card (i.e. the IdP) may independently define the set of claims it chooses support. The browser’s active client dynamically supported any set of claims on a managed card. This loosely coupled, extensible approach worked well. It relied on market forces to “socialize” a set of claim types that one or more IdPs might issue and one or more SPs might rely on. The personal cards as implemented by Microsoft supported a fixed 14 claim-type schema. There was some discussion in open source projects of allowing personal (self-asserted) cards to also support an extensible schema but this was never implemented.
• Claims as URIs. URIs worked well as claim types since they provide a well-understood global namespace management approach. But we could have gone further. The URIs were treated within the Infocard active clients as opaque strings. There have been discussions initially with Dick Hardt and later with Mark Wahl, Drummond Reed, Markus Sabadello, John Bradley, Axel Nennker and others about the benefits of actually having these claim/attribute URIs be dereferenceable to a metadata description of themselves. There were some early proposals on the semantics of this metadata. Each advocate for a given set of semantics preferred a different serialization format: Dick’s was in XML, Mark’s in RDFa, Higgins used RDF, etc. No consensus was ever reached on either the semantics or the serialization. See Identity Schemas WG for some related work on claim URIs.
• Claim catalog. The ecosystem of Infocard proponents created a central, common Claim Catalog to promote interoperability. The thought was that we should have a common repository of well-known claims in order to prevent unnecessary minting of claims with the same semantics as existing claims. The catalog was maintained using a lightweight process based on an email list managed by the Schemas WG of the Information Card Foundation. This process worked well. We noticed that despite the fact that minting claim URIs rooted in one’s own domain offers no advantage over using the standard “https://schemas.informationcard.net/@ics” organizations acting as IdPs often preferred to use their own domains.
• Browser-initiated invocation. Unlike SAML and similar redirect-based approaches wherein the SP initiates the flow, with Infocard the browser actively looks for “trigger” markup in the SP web page and if it is found invokes and displays the selector app. This approach worked well and provided a level of phishing protection. The Microsoft-proposed, (later, OASIS IMI) trigger mechanism was an embedded <object> tag in the HTML. An alternative mechanism was implemented by Axel and Higgins that used a URI link to trigger invocation. This URI used a  scheme (e.g. “icard:”) that was detected as a trigger by browser plugins. This approach has a second key advantage, namely, that it works with mobile smartphones. Smartphone borwsers (e.g. iPhone and Android) while not supporting plugins to associate apps with URI schemes. This allowed an active client (aka selector) app to be associated with the scheme.
• Passive advertisement of SP policy. Markup in the SP passively declares the SP’s policy–things like what identity providers (IdPs) are trusted by the SP (or if self-asserted claims are acceptable, the set of “required” claims, the set of “optional” claims. The Microsoft-proposed, (later, OASIS IMI), approach included the policy as embedded markup within the <object> tag. Axel, Kantara ULX, Higgins and others felt that instead the trigger mechanism (see above) should be separated from the SP policy description. By using a URI scheme for the trigger mechanism, the URI acts as a reference to the policy. Some work was done on defining a JSON format for this policy.
• Minimal disclosure. When the user selects a card to “send” to the SP, the active client provides minimal set of claims necessary, not all of the claims “supported” by the card.
• Non-correlatable identifiers (PPIDs). The active client generated pair-wise unique Private Personal Identifiers (PPIDs) to allow persistent SP-specific pseudonyms. This capability increased privacy while ensuring that the SP can reliably recognize the same visitor over time.
• Audit logs. Active clients implemented audit logs (sometimes called ledgers) that kept track of what claims the user had disclosed to which SP.

Implementation trade-offs

• Performance vs. security. The original Infocard implementation with its secure desktop while more secure was considered unacceptably sluggish.
• Cost of cloud services. Cloud-based selectors have many advantages, however their reliance on centralized processing increases the cost to deploy them.
• Pure browser extension vs. browser extension + app. Whereas a pure browser extension has deployment advantages (easy download/install and in some cases some cross platform support), five years ago the thinking was that such an approach had three disadvantages: (i) the lack of isolation in browsers (at that time) meant that the selector would be too vulnerable to attack (ii) a pure browser extension wouldn’t be useable by local (non-browser-based) apps and would thus not be as “universal” a solution (iii) it would take more development effort since more of the code would be browser-dependent and less of it common, browser-independent code. Note: the latest thinking in Higgins 2.0 is to go back to the original approach. On these three points the thinking is now, respectively: (i) the security characteristics of browsers are now good enough, (ii) non-browser-based apps are less important to worry about, and it may even be possible to have a local app leverage the browser (iii) the benefits of i) and ii) outweigh the cost of a lot of per-browser development.
• Identity in the browser vs. Identity in the platform. CardSpace and most (though not all) other active clients were separate applications that were invoked by browser extensions. In the case of CardSpace the application was bundled with the operating system (e.g. Vista and Windows 7) and was more correctly “identity in the platform.” The benefit of this approach is that the active client can be invoked by applications other than the browser. In this way the user has a consistent “identity” experience across both the Web and local apps. The Higgins project implemented a “selector switch” abstraction layer that decoupled the user’s choice of browser from the user’s choice of active client application. It allowed, for example, IE to invoke CardSpace or a Higgins-based active client. Until an “identity” layer is integrated into either the platform or the browser, users will have to download and install something. Experience has shown that making this installation experience extremely light and fast is very important for user adoption. As a consequence the Higgins 2.0 project has backed off from the “in the platform” goal and has (for now) abandoned the selector switch idea because the simplest and fastest user experience (for conventional PCs) is the installation of a browser extension using the browser’s native installation mechanisms.

Driving Adoption

• Focus on SPs. Infocard proponents were too slow to realize that the hardest part of driving adoption is getting the SPs to adopt the technology (not recruiting IdPs nor even building active client support into browsers). Resources must be invested in creating libraries and services to make it as easy as possible for SPs to adopt a new technology, especially since SPs are so numerous compared to the population of IdPs.
• Create a non-competitive, layered, protocol stack. As mentioned above, users simply want identity-related interactions to work with a consistent experience irrespective of the underlying protocols. Layering a consistent experience over protocols that were never designed to work together appears to be difficult and creates a fragmented, competitive landscape. A more promising approach would be to collaboratively create a layered model of protocols and user experiences. This could unify the ecosystem instead of creating multiple competing solutions with differing strengths and weaknesses.
• Microsoft vs. an ecosystem. Microsoft, having gotten a black eye years before with Passport and Hailstorm, was determined to learn from these mistakes with Infocard. And they did. The changes were profound: the Infocard architecture was decentralized, the network protocols were  contributed to a standards organization (OASIS), the IP was covered by an Open Specification Promise (basically an agreement not to sue developers) and Microsoft was uncharacteristically open and collaborative with open source projects (e.g. Higgins). They genuinely wanted to see the emergence of active clients integrated with other browsers and other (especially non-Windows!) platforms. The reality was quite good. The problem was one of market perception. Despite the collaboration, openness, standardization, IP stances taken etc. the perception in the market was that Infocard was a “Microsoft” technology. Industry analysts by lauding Kim and his team for their seminal contributions and by never quite realizing that solving the Internet identity problem would “take a village” (an ecosystem with multiple tech providers). The unintended consequence of promoting Microsoft’s early role was to limit greatly the appeal of Infocard. Many at Microsoft could never quite understand that the more they promoted Infocard (and thereby made it seem like a Microsoft-controlled technology), the less successful it would be in the marketplace.

History

We begin by describing Microsoft CardSpace and then discuss other projects and how they differed and innovated.

2006: Microsoft Windows CardSpace 1.X

In 2006 Kim Cameron and his team at Microsoft released Windows CardSpace.

The following section describes the salient points about CardSpace.

Cards & Selectors

• Uses the card UX metaphor (and introduced a browser-integrated “identity selector” client app to hold and manage them). A card is a metaphor for a digital identity–a set of claims (attributes) by some issuer (the user or an IdP)
• Supports personal cards (that contain attributes (aka claims) & values as asserted by the user)
• Supports managed cards (that contains a pointer to an IdP (the IdP that issued the card to the user))

Sending a Card to a Site User Experience

• User goes to a website and sees a purple icon.
• The icon indicates that the site either wants the user to login or it wants the user to provide a set of claims.
• User clicks on the icon and the selector application’s “card selector” UI window is displayed
• A set of zero, one or more cards that match the SP’s policy (requirements) is shown within this window
• The user clicks on a card to “send” it to the site

Get Card User Experience

• User goes to a card-issuing website
• User logs in and may have to provide other attributes
• User clicks on the icon of a card
• User downloads an info card (a 3kb-ish signed XML file) that is automatically imported into the user’s selector

Architectural Highlights

• Overview: browser plugin that communicates with a desktop selector app. Selector was almost entirely written in managed (C#) code and leveraged .NET.
• Browser-initiated invocation. Unlike SAML and similar redirect-based approaches wherein the SP initiates the flow, with Infocard the browser actively looks for “trigger” markup in the SP web page and if it is found invokes and displays the selector app.
• Passive advertisement of SP policy. Markup in the SP passively declares the SP’s policy–things like what identity providers (IdPs) are trusted by the SP (or if self-asserted claims are acceptable, the set of “required” claims, the set of “optional” claims.
• Selector-to-IdP protocols: based on a suite of SOAP protocols centered on WS-Trust.
• Selector/browser-to-SP protocols: HTTP(S) POST of a security (e.g. SAML 1.1, etc.) token.
• Security: selector supported only a single “getToken()” API.
• Security: the selector runs in its own protected operating system process called a secure desktop.

Implementation

• Commercially released application.
• Compatible with IE.
• Installable on Windows XP; bundled with Vista & Windows 7.

Capabilities

• Federated login. User can login to a SP without an SP-specific password.
• Verified claims. User can convey a signed set of claims from an IdP to the SP.
• Multiple identities. Each card represents a different digital identity of the user. Each card supports a different set of claims. For example, a card might support only the single claim that a person is over the age of 21.
• Card matching. When the card selector window appears only the set of cards whose characteristics (e.g. IdP domain, set of supported claims, etc.) match what the SP has declared in their policy are displayed.
• Minimal disclosure. Only the intersection of (a) the set of claims supported by the card/IdP and (b) the set of claims required by the SP, are disclosed to the SP.
• Non-correlatable identifiers (PPIDs). An identifier (e.g. an email address or userid, etc) is a kind of claim. For privacy reasons where possible cross-SP correlatable identifiers should be avoided and less identifying claims used instead. CardSpace used a pair-wise key generated between the selector and the SP to generate the value of a PPID claim (if the SP policy asked for it). In this way the SP can reliably know that this was the same user as an earlier visit without being able to collude with other SPs to aggregate information about the user.
• Audit logs. The selector automatically maintained a log of what cards & claims had been used at what SPs
• SP authentication. The selector provided visual cues to help the user recognize the identity of the SP

2006-2010: Eclipse Higgins 1.0 and 1.x

Cross-browser and Cross Platform support

The Higgins project initially wanted to see if a selector could be implemented entirely as a pure browser extension. This would have the advantage of making it more easily deployed, and for cross-platform browsers (e.g. Firefox) would provide a cross platform solution. The initial browser targeted was Firefox 2.x as shown below.

Higgins also experimented with another approach to achieving cross platform support, namely by developing a native application written in a cross-platform toolkit. Contributors to Higgins from Novell created a GWT-based selector to run on several flavors of Linux as well as Windows. Theoretically a GWT-based app could also run on OSX, but in practice the UI wasn’t acceptable, so a native Cocoa-based app was also developed by the Novell team.

Roaming

One of the most serious drawbacks of the selectors mentioned above is that they suffer from the “card roaming” issue. Since cards are stored within the selector clients, if the user wishes to use more than one machine, or borrow someone’s computer, or use a kiosk, etc. their cards are not available. Two approaches to address this limitation were pursued at Higgins.

One approach was to develop the heart of the selector as web service. Then, the active client portion that is integrated with the browser is merely a presentation layer with the cardstore being resident in the web service. The Higgins I-Card Service is such a service, and provides web services to a “UI-only” Adobe AIR rich client selector as well as the iPhone selector shown below.

Mobile Browsers

A number of mobile Infocard solutions have been developed. As mentioned in the Lessons Learned section, since mobile browsers don’t support plugins it was necessary to replace the IMI-defined <object> tag trigger with a URI-based trigger in the SP’s web pages.

As an example of a mobile solution, the Higgins iPhone Selector relies on a hosted I-Card web service:

A second approach to providing card roaming was also explored and partially implemented. In this architecture the selectors would be full clients having their own local cardstores but have the ability to optionally take advantage of a cloud-based cardstore and synchronization service.

Browser-Only Support (Cloud Selectors)

One of the most serious drawbacks of the active client approach is quite simply that they require an active client (even if in some cases this active client is merely a browser extension) in order to work. Within Higgins a Cloud Selector was developed that worked with an unmodified browser. The cloud selector relied on OpenID to allow the SP to initiate redirect to the cloud selector. The “back end” of the cloud selector remained unchanged with the required security token being returned in the second redirect back to the SP. Note that without an active client more care must be taken (e.g. a second factor of authentication added) to strengthen the authentication between the user and selector.

I share Drummond’s perspective on this issue. When I describe the concept of a Personal Data Store to techies I’m constantly having to explain that it’s about centralizing control over personal data, but not centralizing its location.

David Siegel calls it a Personal Data Locker, others Personal Data Space or Personal Data Vault. W3C folks are working on Personal Data Wiki. I was just on a VRM call today. At Drummond’s suggestion a bunch of us are going to try to create wikipedia entries, and hopefully a diagram (as Iain Henderson suggested) that define some common terms. It would be helpful at this early “market development” stage to have a common set of terms that developers and techies can understand. Here are my contributions:

Terms:

• Personal Data Service (PDS) – A service that enables the user to participate as a peer within a distributed personal data ecosystem. A PDS provides one or more of the following services: (a) a web portal that provides a dashboard view of the user’s data, the ability update self-asserted data, and a way to manage authorizations (e.g. using something like an UMA Authorization Manager) and set policies under which 3rd parties gain access to portion of the user’s information, (b) supports a Discovery API that allows you to be discoverable by other people, organizations, apps and exchanges whose inquiries that meet criteria you specify, and (c) provides an identity provider (IdP) endpoint (e.g. OpenID OP)
• Attribute Data Service – Service that (A) locally stores your self-asserted data attributes, makes them available via APIs, and supports active clients. Ideally these self-asserted data are stored in encrypted form using a key that the PDS operator does not know. It also (B) maps data from both external data services (e.g. Facebook, etc.) as well as from external Personal Data Services (e.g. your friend’s PDS or a PDS managed by your favorite telco), makes it all available via APIs (e.g. XDI, SPARQL, oStatus, etc.), and supports active clients.
• 3rd Party App – A web app that consumes data from the PDS. These include information refineries –a kind of app that reads datasets from the PDS, refines them, and writes them back to the PDS user. The refinery process includes analytics, inferencing, segmentation, etc. Refineries generally to create higher value, more refined data from the more raw forms of data, while often also making the data sets less personally identifying. These also include information exchanges–a kind of PDS App that is involved in creating personal data exchanges analogous to a stock exchange. An exchange itself is a platform that supports yet another layer of apps above it [this is not shown above].

Couldn’t resist drawing a picture: