Digital Persona

Connected Services Framework
Within the CSF environment, a persona is the view of the user presented to other services within a service broker. The persona is constructed with the following components:

    Identity Credentials for the user across multiple services. Credentials can take a number of different forms and include username and password combinations, X.509 certificates, tokens, and so forth

    Profile Each user has a profile, which contains information about the user, created within the CSF environment. This profile includes:

  • General information about the user - for example, address, age, occupation, and so forth
  • Implicit personalization - personalization profile based on behaviors, patterns, and so forth
  • Explicit personalization - personalization profile specified explicitly by the user
  • Service subscriptions - services the user subscribes to
  • Device mappings - the user's devices and the behavior across these devices

The information for each of these items is probably stored in a number of places. Therefore, the CSF persona is an aggregation of information from a variety of sources. For example, subscription information may be obtained from the OSS/BSS environment. The primary key used to bring all this information together is the CSF master identity of the user. Each user has a master identity - created within the service delivery platform environment - that is the single primary key for the user's persona information.

Persona as a Service (The Persona Participant)

Within the context of the user, user is presented at the same level as all other services. This is a very important architectural concept. Within the abstract notion of a collaboration context, CSF makes no distinctions between users, services and devices. As such, a user is represented within the collaboration context as another service known as a persona service or persona participant. It is a specialized service that represents the user in that collaboration context. The persona service exposes identity and profile information about that user to other services.

Within the Session (that is, the implementation of the collaboration context), the persona is represented as a specialized participant proxy object. Other services and connectors within the Session can access the profile information through this specialized participant.

It is also important to understand that personal profile information involves the concept of distance. This means that profile information is not a single unit of information; it can be divided into multiple sets based on the level of information the user wants to share. Some information is personal (closer to the user) and, as such, is more closely guarded. Other information may not be as important and is readily shared. Examples of closely guarded information include credit card numbers, phone numbers, addresses, and so forth. When profile information about a user is shared between services, it need not be all or nothing. It can be the level of information that the user is comfortable sharing with the system. This notion of distance or "zones of closeness" must be considered for each collaboration context that involves the user with the services.

The persona service uses the concept of distance with regard to profile information as it relates to a user implemented through an authorization mechanism. For trusted service collaboration instances, the user might allow services to access more "private" profile information. For collaborations that are not trusted, the user might allow access only to "less-public" information, such as an e-mail address.

We all create a number of public digital personae today. For example, at Microsoft we are identified by our work profile on corpnet. Wherever we go within corpnet, we are authenticated, identified and profiled, based on our corpnet ID. At home, we may use one or more identities. The profile that we use to access each of our financial institutions is probably different from the one we use to access online services such as Amazon or eBay. In most services today, the user consumes the service and is thus established as a branded entity within a service as opposed to another entity involved in collaboration with the service.

Within CSF, the intent is to enable the user as another service at the same level as today's services. This means that the service may consume the user!

When the service consumes the user, one of the things the service must render a service is access to the user's profile. This allows the user to be in control of the information that he or she shares with the services. The actual profile data may still be contained within each of the services as attributes of the user's association with the service. For example, the e-mail ID is an attribute of the user's association with the e-mail service. When the user chooses to share this information with Amazon, it does not change the fact that the e-mail ID is still a profile attribute of the user, resulting from the association of the user with the service.

Some people will trust Microsoft to hold private information such as credit card information; others may trust only partially or not at all. So the concepts of trust and distance are intertwined.

Within CSF, the user's persona (that is, digital identity and profile) is presented within a service as another entity at the same level. This allows the service to consume the user and the user to consume the service. In Connected Services Framework 2.5, Persona Participant is limited to managing identity.