Difference between revisions of "Persona Data Model 2.0"

Revision as of 10:04, 19 October 2009

The data model based on Context Data Model 1.1 that is used by Higgins 1.1 web services (e.g. I-Card Service 1.1).

Version

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

Background

Within the RPPS Package are components that persist data objects on behalf of the user. These include I-Card Registry, and others (not counting temporary caches). These include user account data, the users set of cards, and other data. Some components use IdAS 1.1 Package to persist their data. Others manage their own local data stores "above" IdAS. The overall data model has never been documented in one place and it didn't have a name. As of now we are calling it the Persona Data Model 1.0 (PDM 1.0).

PDM 1.0 has evolved over the past few years as we've piled on more and more requirements. At this point, we need to evolve it still further, but before we do so, we'd like to document the new model, Persona Data Model 1.1, so that it can be peer reviewed, combed through and made as self-consistent, simple and powerful as possible. The new model will have more generality and be easier to implement than what we have today.

Relationship to CDM

The Persona Data Model 1.1 (PDM 1.1) defines the patterns and kinds of objects that exist in a running instance of the I-Card Service. PDM 1.1 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.

The IdAS 1.1 Package implements the very general purpose Context Data Model 1.1. This generality means that CDM and IdAS can be used for many different applications. You can think of the Higgins I-Card Service and CardSync Service as "applications" that use the Persona Data Model 1.1.

(Diagram Key)

Implementation

Since this document is about design rather than implementation, we will only 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.

Introduction

The Persona Data Model 1.1 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. [Note: If these two services are co-resident, both share the same set of user data objects.] 

A graph of Entities

In PDM 1.1 the user's data is represented by an acyclic graph of Entities interconnected by higgins:correlation Attribute links. The root of this graph (and some other nodes) is in the "meta" context. By convention Entities in this meta context are of class Persona and all have a persona:personaLabel attribute.

The nodes in this graph may also have links to other Entities using some other kind of link other than higgins:correlation. However, these links are not considered part of the user's Persona Graph.

Since the entities in the user's data graph may live in disparate contexts and these contexts may be managed in different locations, the data graph is logically distributed. since each Entity is stored in Contexts that may be physically located anywhere on the net.

Here's an example graph:

There are seven nodes in the Persona graph connected by h:correlation links. We follow a convention that the name of the containing context follows the "ex:" and precedes the "-". Thus "ex:Meta-Alice_at_Home" is Persona node in the "Meta" context. For clarity the attributes of the nodes have been omitted.

The semantics of the higgins:correlation links (aka complex-valued attributes, or entity-valued attributes) are important to understand. The "h:" prefix tells you that this attribute is defined in higgins.owl  and is thus a concept defined in the Context Data Model 1.1 (CDM). Nevertheless, we remind the reader here of the basic idea. The overall knowledge domain of CDM is digital 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.

User Profile

From the point of view of the Higgins I-Card Service or CardSync Service 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, a Persona node that is the root of the graph.

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

Each User Profile holds account information attributes such as the username of the user, an email address for password reset, and the authentication materials necessary to authenticate the user (via their selector agent).

As you can see, the attributes of the User Profile contain sensitive information. Beyond the scalar attributes just mentioned, the User Profile also points to all of the other partial identities that a person may have. These may well include the person's Second Life avatar, eBay seller information, or other identities in other contexts where they wish to remain pseudonymous. Access to the meta context is restricted only to the user. Further, the h:correlation links are directed "away" from the root entity. For privacy and security reasons, Contexts do not contain backward links back "up" the graph.

Personas and correlations

The persona nodes in the meta context are used to represent cross contextual relationships. The h:correlation links emanating from a given persona node express the concept that these target entities are contextualized, partial manifestations. To represent what Alice says about herself in the context of shopping at amazon.com we use an entity with attributes in the amazon context. To represent what Alice says about herself in the context of buying a ticket on orbitz.com we use another entity. And to represent that these two entities are both about what to Alice is the same person, we use a persona node pointing with correlation links to each of these two respective entities.

The semantics of a correlation link is closer to association than aggregation. It is about equivalence as it would be seen by a human observer. Alice, for example, would understand that the two entities are described above are about her. Yet the semantics of correlation isn't necessarily strictly logical. The ontologies in the two contexts may be such that each of the two representations cannot be logically merged and be logically consistent. For this reason higgins does not use owl:sameAs which does imply this ability to directly merge representations.

The persona nodes can be used to represent broad, reuseable roles (e.g Alice at Home or Alice at Work); i.e. roles that can be used fairly consistently across multiple contexts. For example Alice might interact with many websites using her Work persona role. In this way the "Home" and "Work" personas above can be thought of as reusable, or cross-contextual. This is in contrast to regular entities that live in narrower contexts. For example a regular (non-Persona) entity can represent Alice as an eBay seller. The cross-contextual (or meta-contextual) Persona nodes live in the meta Context.

In the example above Alice has three personas below the root. One is about the "work" Alice, one is about the "home" Alice and the third doesn't fall neatly within either of those two classifications. The vCard schema has attributes that describe both work and home roles, so Alice's vCard isn't "under" the home or work personas.

I-Cards

Before we introduce the I-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 I-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 two sub-classes of I-Card are defined:

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

And finally by adding a special attribute either of the above can become an R-Card. The following classes are inferred by the presence of the resource-udr attribute on their respective "base" classes:

• personal r-card
• managed r-card

Although, it is redundant the the inference just mentioned, we also provide an explicit R-Card class. A personal r-card would be a subclass of both the R-Card class and the P-Card class. A managed r-card would be a subclass of both the R-Card class and the M-Card class. All R-Cards MUST be a subclass of R-Card (and either P-Card or M-Card).

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

P-Card

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

M-Card

Here is an example of an IMI managed card:

Personal R-Card

From a structural point of view, the presence of the resource-udr claim on a P-Card or an M-Card makes it be considered an R-Card. Here is an example of a personal R-Card:

As you can see the resource-udr attribute/claim value MAY point to itself or MAY point to some other entity.

Managed R-Card

The final type of card is the managed r-card. The presence of the resource-udr claim makes an ordinary M-Card into an R-Card. Here is an example of a managed R-Card:

More about R-Cards

For more details about R-Cards see R-Card.

Card Axioms

1. For any M-Card: The value of any of the above "supported" claims attributes is considered to be a cache of the most recent value of these claims as fetched from the m-card's STS

Personas and Cards

Now that we've introduced Personas, the special "root" UserProfile, and ICards, let's put them all together. Here is a diagram that shows Alice, her two personas "work" and "home" and a i-card for each:

<TODO:to be completed>

Attribute Class Entities

Now that we've described some examples of entities that represent concrete data instances, we will now discuss Entity Classes and Attribute Classes. These abstract entities provide descriptions of these concrete data instances.

Contexts

Required Context Attributes

In Context Data Model 1.1 all Context attributes are optional. However in Persona Data Model 1.1 we have these requirements:

• All Contexts that are made available by a third party (e.g. the government, a bank, etc.) have a "p:authority" attribute whose value is the domain name of that third party. If the context is self-asserted (even if it is made available by a so-called "fourth party") then this attribute MUST not be present. Nil means that the context contains self-asserted information (information directly asserted by the user). A domain name indicates the "authority" that manages the entities in this context. In reality the situation is much more complex. An authority (e.g. gmail.com) manages entities that are a person's contact list, yet the person is the one who typed in the values. R-Cards allow attribute-level access control to a single entity, and the user may well be allowed to edit and update some attributes of an entity. Nevertheless, it is useful to have a single context-level "authority" string that can differentiate between a person's entry in gmail vs. their profile in facebook.com or some enterprise directory.
• Context's holding the entities to R-Cards point (as opposed to Context's holding the R-Cards themselves) have a required (minimum) schema to support "action" capabilities (scriptability). See R-Card for details.

See Also

• R-Card - details of the Persona Data Model 1.1 relating to r-cards.
• Parallel CardSync and XDI Channels
• Context Data Model 1.1