In Context

September 8, 2014

Dignity 0.1

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!)

October 6, 2010

Personal Data Service vs. Personal Data Store

Filed under: — paul @ 2:02 pm

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:

August 18, 2010

XDI, Semantic Web

Comparing two “standards” stacks and one implementation project (Higgins):

July 19, 2010

Violent agreement breaks out at Internet of Subjects Forum

On the morning of July 5th I had breakfast with Iain Henderson and David Alexander of Mydex. And then, within 5 minutes of walking in to the IoS meeting I met Serge, Sampo and Graham. Between meeting them on the one hand and the breakfast on the other I knew the whole trip was worthwhile. It’s a great pleasure to spend time with people who share the vision of giving individuals more control over their own personal data. We all had a chance to share what we’re all learning about creating Personal Data Stores, VRM (TRM?), user managed identity, data portability, etc.

Check out Internet of Subjects. This is a new effort that deserves our support. I particularly like the fact that it’s not based in the (privacy-challenged) US. The effort is being indirectly supported by EU investments in TAS3, a project that I’m only now learning about.

Here’s a quote from Graham Sadd’s post about the IoS meeting:

Serge Ravet, CEO of EIfEL, prefaced the Eifel Learning Forum with the inaugural Internet of Subjects Forum to an international audience in London yesterday. The plenary presentations were made by Sampo Kellomaki, Chief Architect at Symlabs, Graham Sadd, Founder & CEO of PAOGA (read interview) and Paul Trevithick – Founder of Higgins Project and CEO of Azigo.

May 6, 2010

Internet of Subjects

Well, here’s a new organization, iosf.org, that I should have known about. I hope I can get to their event. It’s on July 5th and I have to be in Paris on the 6th for an Information Card workshop with FC2. Hmmm…should be possible.

March 21, 2010

Apps and Personal Data Stores

This post presents an architecture comprised of apps, a dashboard, and a personal data store (PDS) that can be implemented by multiple developers, hosted by multiple operators over an open, personal data network and whose goal is to give users more control over their own identity (personal data, profiles, preferences, affiliations, and relationships). It is in support of aspirations that have been widely reported by others and called variously VRM, data portability, user-centric identity, the Data Web, Augmented Social Network (2003), and so on.

I’ve annotated the diagram above with little “H” and “A” markers so you can see specifically the areas that Higgins and Azigo are working on respectively. Lots of other folks are also working on other parts of the picture too, of course.

Apps

Apps are of course the most important kind of component since they are what the end user sees and appreciates. Apps gain access to the user’s data by making calls (e.g. getAttribute) to an API exposed by the PDS Client. Architecturally, we’ve seen the need to support both conventional kinds of apps: web, mobile (iPhone, Android, etc.), and desktop, as well as a more unusual kind of app, I’ll call a Javascript app.  In this latter case Javascript is fetched from a web service (e.g. from Kynetx KNS) injected locally into your browser by a browser extension. This same browser extension exposes the same PDS Client API to this Javascript program.

Dashboard

The dashboard is an admin GUI app for your personal data. It is an occasional-use tool that provides: (a) a control panel to manage the permissioning policies that control which of your attributes are shared with whom (including so-called “selector” functionality to approve the release of your info)  (b) a dashboard GUI to see and manage all of your identity data attributes (including profile data, credentials, friends lists, etc.) whether stored in your own PDS or managed by others (c) a place to directly enter self-asserted attributes (d) an embedded app marketplace (e) a canvas area where apps can extend the UI to add their own admin interfaces (f) a place to import & manage your i-cards and OpenID OP relationships.

ASIDE: Dashboard is a new word I’m trying out. The reality is that this piece of software is a bit of a swiss army knife where each blade/tool is called something different. A few examples: Microsoft calls the aspect that pops up to give notice and consent to release a set of attributes an identity selector. Inside Google they call identity-related client add-ons to a browser an active client. The “show me all of my stuff” aspect does sound like a dashboard. On the other hand, the permissioning aspect is something Eve would call a relationship manager (or I think she would). And I think Bob Blakley would too.

The dashboard combines aspects of earlier client efforts. In 2006-2007 we saw Information Card Selectors like Windows CardSpace as well as the Higgins selectors provide an interface to view and manage multiple digital identities displayed as visual cards, as well as provide notice and consent to the release of your selected digital identity. In 2009 Azigo augmented the selector concept support for Kynetx apps in Azigo (along with cross-platform and card roaming support). Prototypes shown by Microsoft (e.g. OpenID Active Client) and Higgins at IIW in 2009 added OpenID support thus demonstrating multi-protocol support. Mozilla Lab’s Account Manager is doing some great work in this area. The Higgins project is working on a next-generation client as part of the Higgins 2.0 Active Client expected in 2011.

Personal Data Store

A PDS is a web service that works on your behalf, giving you more control over your own personal data whether it is stored in the PDS or managed elsewhere. PDS stores local attributes in blinded form so that only the user has the decryption key–not the PDS service provider. The PDS is an idea that has been underdevelopment for years. For some background see Joe Andrieu, Joe again, and Iain Henderson. As part of Higgins 2.0 the PDS is being developed. Another interesting PDS development project is Mine!

PDS Client

The PDS Client has no UI, but provides an API for apps that wish to read/write attributes from the PDS. Here are some of its functions:

  • Maintains (and syncs to the PDS and other clients) the user’s ”permissions”–the decisions that the user has make as to who (what app or relying party) has access to what attributes. For example, the first time a new app/RP asks for a certain set of attributes, the PDS Client will trigger the PDS Dashboard to present the policy decision to the user. The next time this same request happens, the PDS Client remembers the grant and usually doesn’t have to bother the user about it this time.
  • Maintains a local copy of some or all of the person’s personal data stored in the remote PDS
  • Maintains an OAuth WRAP access token that it gets by authenticating itself to an external authentication service. It passes this token along in XDI messages to the remote PDS service.
  • Can be configured to encrypt attribute values before they are sent over the wire (e.g. in XDI messages) to the remote PDS
  • Contains a local Security Token Service (STS) that allows it to create and sign SAML (for example) tokens for self-asserted attributes.
  • Contains an STS client to support remote IdP/STSes managed by external parties (e.g. to support managed i-cards).
  • Performs cross-context schema mapping.

The Higgins 2.0 PDS Client is packaged as either a C++ or Java code library or as a separate operating system process (e.g. on Windows it is a Windows Service).

Network Protocol

Drummond Reed with his OASIS XDI and OASIS XRI work was first to my knowledge to define an open data web. A few years later Tim published his Linked Data paper. We’re starting to see implementations of Linked Data so now the Semweb folks also have a data web. Both of these approaches are important.

An open community is starting to form around the XDI that is focused on PDS-related use cases and create might be called a profile of XDI in this area. The community is leveraging XDI’s existing strengths in the areas of identity management integration, security, access control, data sharing and versioning, as well as extending them where needed in order to meet the PDS-related requirements.

This focus probably provides a critical time-to-adoption advantage over the Linked Data effort in this PDS area. Since the objective is interoperability (i.e. an interoperable ecosystem of PDSes and apps over a common protocol) assembling a community focused on this area would seem to be the fasted way to get there. Linked Data (like “vanilla” XDI) has a much broader link-all-the-worlds-data-together mission and lacks direct support for many of the PDS-related requirements. As a consequence RDF developers (including Higgins) define ad-hoc extensions to RDF to make it support the PDS use cases that are only interoperable within their own developer community.

PDS Schema

The Higgins PDS uses its own internal schema called the Persona data model. This is not to say that the PDS architecture imposes a single ontology on its clients. Quite the opposite. Every attribute call (e.g. getAttribute) may request attributes in any vocabulary. As I’ve mentioned in my schema mapping post, we follow the philosophy of mapping into and out from the internal schema.

Authorization Manager (AM)

The AM provides the “back end” authorization manager for access control of attributes managed by data services other than your own PDS. The Higgins project has been tracking the promising UMA Authorization Manager effort that Eve Maler and others have been developing.

Kynetx KNS

KNS is a web service that serves up compiled Javascript apps for injection into browsers. The app developer uses the Kynetx AppBuilder tool to create apps. Each app is packaged as an information card. The developer puts this app on their website for folks to download and install. If you click on it and already have a PDS Dashboard the new app gets installed in about one second. If you click on it an you don’t already have a PDS Dashboard, then you download an installation package that includes a Dashboard (with the app pre-installed inside it).

May 18, 2009

The Diamond Framework

Filed under: — paul @ 2:34 pm

Why?

As we all try to make sense of identity technologies, we go through a process of fitting what we’re learning into our own mental map. It’s a lot of work. In the hope of possibly be of use to others I’m sharing my personal map. It consists of four actors and the six interconnections between them.

Four actors

Across a variety of identity technologies for identification, authentication, data sharing, authorization and so on there exist to varying extents four main kinds of actors. All of them are digital. The human user has been omitted in the interest of simplicity. If it were included it would be shown as interacting only with the user agent (U).

  • U – A local user agent. It may just be a browser. Or it may include an OpenID, WS-*, password or SAML IdP,  selector client. It may include a local personal data store. It works on behalf of the user.
  • R – A relying Website or Web service or a local application. This relying agent performs some service and/or provides access to some resources. In the non-local cases it is usually an agent of some organizational or individual entity other than the user.
  • P – An Internet service (or local application) providing a specific service (e.g. a calendar service), an identity provider, an attribute/claim provider or an authorization provider. In the non-local case it is usually an agent of organizational or individual entity other than the user. Examples include a Plaxo Portable Contacts service, an OpenID OP, WS-* Security Token Service, or a SAML IdP
  • A – A cloud-based agent that works on behalf of the user. It may act as an authorization manager to which you delegate authorization services. It may provide a service discovery service. It may provide storage of self-asserted identity data (sometimes called a personal data store). It may provide linkage of partial identities (attribute sets) across data sources. It may provide schema mapping of identity attributes and social relationships necessary to achieve data portability. It may provide an auditing service. It may provide Cloud Selector functionality (tunneling WS-* functionality through OpenID AX extensions). Finally, it may provide other “sync” services such as information card synchronization services (to synchronized cards across our browsers and devices). Various subsets of these functions are sometimes referred to as a relationship manager. I sometimes refer to the entire bundle as a personal identity agent.

Each developer community has chosen to name these same four actors different things. For example, in Oauth the “R” is called a “consumer”. Or in SAML the “R” is called a “service provider.” Here are some examples:

Actor OpenID SAML WS-* Oauth VRM ProtectServe Higgins ID-WSF
U Browser Browser or local app Browser + Selector Browser Browser + [Selector] Browser + [Selector] Browser + [Selector] Rich Web or local app
R Service Provider Service Provider Relying Party Consumer Vendor Consumer Relying Party Web Services Consumer
P OP IdP IdP STS Service Provider Third Party Service Provider IdP STS Web Services Provider
A n/a n/a [future: CardSync] n/a 4th Party Authorization Manager Cloud Selector, Identity Data Service, CardSync ID-WSF Service Architecture/COT

Six interaction paths

As you can see there are a total six interaction paths between the four actors. Each path is named by the letters of its start and end. For example, path PA is the path between P and A. Similarly, PU, UA, etc.

So that’s the basics of the framework. With it we can more easily compare technologies and protocols like OpenID, Oauth, WS-*, ProtectServe, VRM, etc. I’ll begin to do so in future posts.

Powered by WordPress