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

{{#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 the 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, 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.

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.] 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. 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 other Entities in the wild (e.g. those managed by other domains and for which the user is not authoritative). 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 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:

Alice-persona-graph.png

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.

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

The following diagram shows the instance/class relationships:

Example-p-card-class.png

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 relationship P-Card (aka r-p-card):

Example-r-pcard-v2.png

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

Relationship M-Card

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

Example-r-mcard.png

Card Axioms

  1. For any Card subclass: Any attribute that is not a Card attribute, nor an M-Card attribute, nor an M-Card attribute, nor a higgins:correlation, nor a Persona attribute (i.e. personaDisplayLabel) is considered to be a member of the set of "supported" m-card claims.
  2. 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


Complex Attributes

So far we've seen examples of simple attributes of a Persona. But let's add a postal address to Alice's home Persona. Here's what it might look like:

Alice-address.png

See Also

Back to the top