Skip to main content

Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.

Jump to: navigation, search

Persona Data Model 2.0

Revision as of 09:43, 12 August 2009 by Ptrevithick.gmail.com (Talk | contribs) (Relationship M-Card)

{{#eclipseproject:technology.higgins|eclipse_custom_style.css}}
Higgins logo 76Wx100H.jpg

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. This page, when complete, will document Persona Data Model 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.

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.

Data-models-1.1.101.png

(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 a graph of Entities in containers called Contexts. The root of this graph (and some other nodes) is in the "meta" context. Entities in this meta context are called Personas. Persona entities MUST have a persona:personaLabel attribute. This Persona class is really just a tagging class to distinguish between the Entities directly managed by the user (e.g. using a selector and the I-Card Service) (and living in the meta context) and other Entities in the wild (e.g. those managed by other domains and for which the user is not authoritative) that live in contexts other than the meta context. [We say tagging because the class could have been inferred from the presence of the personalLabel attribute]

In the Persona model the user's data graph consists of a directed, acyclic graph of Entities interconnected by higgins:correlation Attribute links. The nodes in this graph may have links to other Entity nodes using some other kind of link other than higgins:correlation. However, these links are notconsidered 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 persona graph is a distributed graph. 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:

Alice-meta-graph-v3.png

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.

ICard

Before we introduce the ICard 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 two sub-classes of 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:

  • 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.

P-Card

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

Example-p-card.png

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

  • p:cardId - an attribute of an IMI personal card. This is an attribute of all Cards.
  • p:hashSalt - another attribute of an IMI personal card. This is an attribute of all Cards.
  • p:pinDigest - another IMI attribute of an IMI personal card. This is an attribute of P-Cards.

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 - another FOAF attribute

M-Card

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.

Ex-managed-card-v3.png

These two m-card specific attributes (and values) are shown above:

  • p:ic07IssuerInformation
  • p:requireAppliesTo

But you will also notice that this Persona entity also has these attributes that are not part of the IMI card itself:

  • p:eyeColor = green - here a non-ICF-defined (nor well known) claim type is being used. As you can see by the "p:" prefix, this attribute/claim is defined in the Persona data model
  • pcrd:phone - here is an ICF-blessed "well known" claim type.

As is described in axiom #2 (see Card Axioms section), the above two attributes are considered to define the two "supported" claims of this m-card

Relationship P-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:

Example-r-pcard-v2.png

As you can see the resource-udr attribute/claim value points to itself.

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:

Example-r-mcard.png

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

Low 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:



See Also

Back to the top