Skip to main content
Jump to: navigation, search

Persona Data Model 2.0

Revision as of 15:50, 14 July 2009 by (Talk | contribs) (Card)


Higgins logo 76Wx100H.jpg

Within the RPPS Package are components that persist data objects on behalf of the user. These include user account data, the users set of cards, and other data. Some components use IdAS to persist their data. Others manage their own local data stores "above" IdAS. An attempt to document all of these different kinds of objects and stores would be a major project. Instead of looking backward, this page describes a new, updated data model that we call Persona Data Model.


During the Higgins 1.1 development project we will be working on defining the Persona Data Model. We will not be able to implement the new model in time for Higgins 1.1, but work will continue thereafter.


The Persona Data Model defines the patterns and kinds of objects that exist in a running instance of the I-Card Service. The Persona Data Model can be expressed in the still more general Context Data Model 1.1 and that is exactly what this document does. It describes one model in terms of the other. It is assumed here that the reader is familiar with CDM 1.1. All objects in the persona model are CDM 1.1 Entities, and in this document we use the terms object, resource and Entity and even sometimes node, interchangeably.


Since this document is about design, not implementation we make a short implementation note here before we move on. We expect that when it comes time to implement the new Persona model that a decision will be made that the I-Card Service, the RPPS Package components, etc. store all data objects in IdAS. IdAS would thus become the "data layer" in the traditional tiered model.


The Persona Data Model is a model of the user's data. These data are accessed over the net via the I-Card Service and/or the CardSync Service. If these two services are co-resident, both share the same set of user data objects. We begin by introducing the classes defined by PDM.

Personas and the Persona Graph

The user's data is represented by a graph of Personas. A Persona is a class of Entity that describes some aspect of the user. Personas can have a large number of attributes, or hardly any. All Persona entities MUST have a persona:personaLabel attribute.

In the Persona model the user's data consists of a DAG of Personas all interconnected by higgins:correlation Attribute links. Note: The Persona nodes in this graph may have links to other non-Persona Entity nodes using some other kind of link (other than higgins:correlation) these links are not considered part of the user's Persona Graph.

The Persona Graph is a physically distributed graph of Persona Entity nodes. As you recall from CDM each Entity is stored in Context and these Contexts may be physically located anywhere on the net.

Here's an example graph:


There are three nodes in the Persona graph. The "p:Persona" class entity is not considered a part of the persona graph because the link to it is not higgins:correlation.

The semantics of the higgins:correlation links (aka complex-valued attributes, or entity-valued attributes) are important to understand. The "higgins:" prefix tells you that this attribute is defined in higgins.owl (aka HOWL) and is thus a concept defined in the Context Data Model 1.1. Nevertheless, we remind the reader here of the basic idea. The overall domain of CDM is identity. In the digital realm, rather than a monolithic object, it is most useful to model identity as a set of linked, multiple partial identities each of which holds a set of attributes. As you can hopefully see, this is exactly what a Persona graph is.

In the diagram above several attributes are held on the "meta" Paul node, and comparatively on the Home and Work personas to which it is linked. The diagram was simplified for illustration purposes. In reality there would be far more attributes on the lower Personas than on the root Persona.

User Profile

From the point of view of these services each user is a separate account, and the user (through the agency of their selector) must authenticate to each of these services in order to access their data. We call these accounts User Profiles. Each user has one User Profile. This User Profile is a Persona node, and is the "root" of the Person Graph.

Each User Profile holds account information that includes things like the username of the user, perhaps an email address for password reset, and the authentication materials necessary to authenticate the user (via their selector agent).

The User Profile Entity is always stored in a Context over which the user is authoritative. This Context is called the root Context and is typically co-resident with the I-Card Service or nearby, but in any case within the same trust domain.

The attributes of the User Profile are in many cases sensitive information. Beyond the scalar attributes, the User Profile points to all of the other partial identities that a person may have, including, perhaps a person's Second Life avatar, or their identities in contexts where they wish to remain pseudonymous (e.g. an eBay seller, etc.).

Reusable vs. Context-specific Personas

In the Persona data model all nodes are of class Persona. In the diagram above you might be led to believe that personas are only used for modeling broad reuseable roles (e.g Alice at Home vs. Alice at Work) that can be use across MULTIPLE contexts. For example Alice might interact with many websites using his Work persona role. The Persona nodes also model Context-specific partial identities. For example, Alice may have a fairly rich set of attributes that describe her pseudonymous identity as an eBay seller. This partial identity is still called a Persona. In some ways the "Home" and "Work" personas above are "reusable" Personas, whereas the eBay seller persona is a context specific persona. The data model, in a sense, doesn't care. All of these are Persona instances.


Before we introduce the Card classes, please remember that in CDM multiple inheritance is allowed: any single entity may be a member of multiple classes simultaneously. In this section we leverage this characteristic.

First we define an abstract class called Card. This captures the common attributes across the four sub-classes defined below. These common attributes include:

  • cardId - a unique identifier for the card
  • image - an image bitmap for the background of the card when it is displayed
  • ... and several others.

These four sub-classes of Card are defined:

  • p-card (as in CardSpace)
  • m-card (as in CardSpace)
  • relationship p-card
  • relationship m-card

Any Persona-class entity may be one of the four classes of cards, perhaps in addition to also being an instance of yet other classes.


The attributes that define a Persona P-Card are taken directly from the OASIS IMI specification. An example p-card is shown here:


To keep the example simple only a few of the complete set of attributes are shown. These attributes are defined by IMI and define the card-as-container:

  • p:cardId - an attribute of an IMI personal card
  • p:hashSalt - another attribute of an IMI personal card
  • p:pinDigest - another IMI attribute of an IMI personal card

By contrast, these attributes would be considered the claim types of the IMI card:

  • icf:age-18-or-over - this attribute type is being used as a claim as defined by the ICF Claim Catalog
  • p:eyeColor - this attribute type is being used as a claim. This attribute type is defined by the Persona Data Model and is thus a "private" claim type from the point of view of the ICF and the Information Card ecosystem.
  • foaf:family_name - an attribute defined by the FOAF vocabulary
  • foaf:gender = male - another FOAF attribute


An IMI managed card while having some attributes in common with p-cards (e.g. cardImage, cardId, etc.) also has some m-card-specific attributes.

See Also

Back to the top