Federated Model for Managing Personal Data

A platform for managing such personal portals could be implemented by organizations who already maintain personal information such as banking transactions, insurance claims or medical histories. This would provide a powerful environment in which personal information may be managed securely to the advantage of all concerned. However, it is appreciated that in order for effective deployment to occur, it is necessary to establish design principles and rules for operation. The design principles will translate into the principles of personal information management; these being a set of principles that apply differently to all customers of the personal portals system.

October 9th 2007

• It is proposed that the information about an individual, that is to say the identity owner, is the property of that individual or customer. Certain information such as profile information about an identity owner that is captured and held by a trusted intermediary or supplier may be considered as being in joint ownership between the identity owner and the trusted intermediary.
• It is proposed that information captured and held by a trusted intermediary can be analysed and used by the trusted intermediary to conduct its own business activities, although the nature of these business activities should be defined and declared in the contract between the trusted intermediary and the customer or identity owner.
• It is proposed that the identity owner specifies preferences for interaction and communication in the core identity information or contact details. A third party must be registered with any portal host that manages an identity owner’s portal to be able to be granted permission to interact with the identity owner via their personal portal. As previously described, the registration process for a customer will include a piece of real world authentication to provide assurance of valid identity.

It is proposed that a set of default permission preferences may be provided that will address the needs of the majority of identity owners. However, the ability to customise the permissions set will be available to all users via a user interface. Furthermore, an identity owner can give a trusted intermediary or another identity owner permission to manage their permissions on their behalf.

Process for creating and registering a new portal host

Each portal host is linked into the network and authenticated. This is normally done by a central governing body, which may be known as the board of portal hosts. Upon successful registration, the host is given a unique portal host ID. The portal host is expected to agree to conditions to ensure compliance with the principles of personal information management.

Physical world authentication

It is likely that authentication would require some form of identity card or device where the user’s identity can be confirmed prior to the setting up of a personal portal. If a biometric scan is performed, the portal host must be sure that this represents the identity owner. The scanning process produces a public biometric key that is held as part of the core information for a personal portal. The private key is the person themselves or rather the part that is subjected to the biometric scan.

Creation of portal host access

The identity owner will access their first personal portal and create a record that will allow other portal hosts access to the first portal to pick up the core information that includes the public biometric key. The identity owner signs in with update access and generates permission for another portal host to join the personal portal network. This sets the new portal host up as a host and generates a public key that the identity owner can pass to the new portal host.

Permissions may be held in the identity owner’s portal network information, in a list of all portal hosts hosting personal portals for that identity owner. These may have various state flags attached to them, for example the role of that portal host with respect to the identity owner. When the identity owner creates access for a portal host a new record may be added to the list of portal hosts. The generated public key is specific to a single portal host and valid only to allow them to set up a personal portal that they will host.

Setting up a personal portal

• When the identity owner’s identity has been validated, a portal host is able to set up a personal portal and link it into other portal hosts who also host portals for that identity owner.
• The identity owner and portal host should create a contract that determines the nature of that relationship. The board of portal hosts will approve a limited set of contracts to simplify this operation.
• When an identity owner creates a portal host access key, the portal host’s record may be added into the portal network information. Details such as the type of contract and expiry date should also be held there. When the identity owner is presented with the contract, they may reply with the portal host’s access key, which acts as their signature.

Updating core information

The authenticated identity owner is able to update core information. The identity owner with update permission signs-in after a biometric scan that presents the private key. The identity owner is then in a position to make changes to the core information, which subsequently propagate around the network as described.

Updating transactional information

As an identity owner performs new transactions with a portal host, these transactions are used to update the transactional information part of the personal portal. In certain cases the update will be in real time and in other cases there may be a delay; this being determined by the portal host’s policy. The aggregation of detailed information is also considered and will be a function of when that information will be used, what it is used for and the frequency of use.

Updating profile information

As core data and transaction data increases in volume, the portal host is able to build a profile of the identity owner, inferred from the data and representing for example potential commercial preferences of the identity owner. The profile may be augmented by data supplied by data providers inside and outside of the system. This is similar to overlaying of identity owner data with demographic behavioural profiles. It is appreciated that this overlaying process is not fully accurate therefore the identity owner should be permitted to see and amend profile information, which is considered to be in everyone’s best interest and adds significantly to the value (relevance) of the profile information.

The issuance of keys

If an identity owner issues a key to another customer, the key will contain elements specific to both parties to ensure fully authenticated access. If the key is issued to a third party who is not a customer, they will be treated as a marketer and will need to be recognised by at least one portal host in the customer’s personal portal network, before being allowed to establish communication with the customer via the personal portal network, according to certain rules, such as the user-preferences set by the customer.

Proposed components of an identity

As previously described, there are three information types that make up an electronic identity, comprising core identity information, transactional information and profile information. Core identity information should include full name, addresses (personal, mailing and business etc), date of birth, telephone contact numbers, fax number, email addresses and payment information such as credit card numbers with associated identification numbers and validation codes.

• Core identity information takes an identified format in any personal portal so as to ensure that the core identity information can be accurately maintained across the individual’s federation of personal portals using the propagation model.
• Transactional information will be the most granular data that an organisation is prepared to keep about an individual. This information may be held in any format that is convenient and effective for the portal host.
• Profile information is information derived from transactional information, core identity information and acquired data. It may also include overrides to derived information as defined by the individual. The overrides will state personal preferences such as how to communicate with the identity owner or what type of products and services the identity owner has expressed an interest in receiving information about. Thus a communication channel controlled by the personal portal network may allow highly focussed marketing information to reach the customer, but would not allow unsolicited and / or unwanted communications such as ‘spam’.

Granting permissions

It is proposed that only the identity owner is able to grant access permissions to information held within their personal portal. Certain permissions will be granted to the portal host implied by their agreement to act as a portal host for that identity owner. The identity owner is only able to directly grant access permissions to aspects of their core information but not to transactional or profile information. To grant permission to create a new personal portal with another portal host, stringent access checks will be required.

It is proposed that an identity owner may browse for new portal hosts on the network, whereafter they may select a host of choice and generate a public key specific to the new portal host. This public key would reside in a new record in the portal network information that represents the new personal portal of the new portal host. When the identity owner presents themselves to the new portal host, the portal host will perform a boimetric scan that will allow them to create a new personal portal with core data from the existing personal portal.

Role based access control

Role based access control is considered to be a set of rules that determine who is able to perform what actions on what pieces of information; providing the gateway for authorisation. Thus, before allowing any party to perform any action upon any piece of information, the rule set is consulted. The identity owner and portal host have final authority to establish the rule set; each of them being able to grant permissions on different aspects of the identity.

Propagation of core identity information

Upon updating core identity information, an update type may be set too, in this instance, Source information, indicating that an update was done at a particular personal portal and an appropriate time stamp may be set. Subsequently, when data is transmitted to other portals, the originating portal will have the update type set to ‘Source’ while the rest will have an update type indicating ‘Propagated’. In this way, it is possible for a target personal portal to perform a time comparison. If the local clock shows a relative time later than the source time stamp, the update will be carried out. However, if not, an error condition has occurred and the propagation will not be completed.

Upon receipt of data, a target portal may send a confirmation of receipt. If the transaction completes successfully, the target may send a notification of successful completion of updates, again with a time stamp.
In the preferred embodiment, time stamp information is all referenced to a single clock, shared by all the portal hosts on a particular personal portal network. This will reduce the opportunity for fraudulent updates to be made and committed.

In an alternative embodiment, a portal host may continually send out messages through other portal hosts while receiving messages from other portal hosts. Updates to the core identity information would be given a high priority and appropriate queues established, operating on a significance scheme, described below. Furthermore, transaction requests on any personal portal may be processed once all the received updates have been processed.

Transactions

In the early adoption stages, there are essentially two types of transaction facilitated by communication via the personal portal network to be defined. The first is a pull model where the identity owner initiates the process and a marketer responds. The second is a push model where the marketer identifies a potential prospect base and attempts to solicit them.

The pull model for transactions

The pull model relies on the identity owner having accurately set preferences on their profile information. Thus, for example, if the identity owner is ready to purchase an automobile, the identity owner will access the personal portal that will facilitate car buying and select car preferences. These may include, for example, make, model, engine size, body style and more generic information. The identity owner will then select and specify their preferences.

Marketers are then invited by the portal host to solicit the identity owners with their propositions based on the identity owner’s preferences. They may use the preference information to filter the propositions that they present to the identity owner. For example, a car dealership may have been invited to pitch their proposal to an identity owner. The car dealer ship may have a number of car options available but will only propose the car that the identity owner has specified an interest in.

If the car dealership presents a proposal outside the parameters specified by the identity owner, it may then be the identity owner’s prerogative to revoke the channel of communication with the dealership. Thus, the identity owner’s preferences, the profile information and the marketer’s proposition data need to be held in a computable format. All parties should adopt a set of information standards that other parties who wish to participate are able to adopt.

When the marketer receives an invitation to solicit the customer, this comes in the form of a permission key that grants access to that marketer to access the portion of profile information about the identity owner that is pertinent to the proposition being offered by the marketer. The marketer is able to read in the profile data that the portal host creates and the preference parameters that have been set by the identity owner. The offer is sent out by the marketer to the portal host with an instruction to deliver this communication to the identity owner and the communication will come complete with the public key for the marketer and the identity owner. The marketer should specify how the reply from the identity owner should be prepared and be able to deal with the return communication. All communications should carry the public key that is specific to the marketer and the identity owner.

The push model for transactions

The marketer may use the profile information to predict the needs of customers. Therefore if a customer is able to exactly specify their needs, the marketer will not need to guess.

Then portal host may use the transaction data to generate the profile data in exactly the same way as in the model described above; the transaction data is summarised to classify the identity owner into one of a number of segments, therefore normally bringing a set of typical characteristics and behaviours associated with those segments.

The marketer will be granted a key to view and analyse aggregated data and anonymous profile information. They may be able to specify selection criteria and how the result is reported back and then run a query. The results should be numerous in terms of identifying owners having certain characteristics or exhibiting certain behaviours. Consequently, the marketers will be able to gain a result on the number of (as yet unidentified) potential customers that fit a certain profile based on the information held by a specific portal host. Extending this approach, profile data can be aggregated across multiple portal hosts thereby further enriching the information.

If the marketer wishes to contact the target market, the query may be stored by the portal host and given a unique identification number. The marketer would then approach the portal host and ask to be able to contact the relevant customers. The portal host will rerun the query (without the customers being anonymous) thereby resulting in a list of identity owners. Identity owners who have expressed the desire not to be contacted will be stripped out and those who have specifically excluded a particular marketer will also be removed. This will leave a list of identity owners who do not mind being contacted by parties within the network. Thus, the marketer can then pass an offer to those identity owners by sending the proposition to the portal host, then having the portal host communicate with the identity owners. All such communications will carry the public key that is specific to the marketer and the identity owner.

Closed loop rejection

In the course of a dialog between a marketer and an identity owner via the personal portal network, if at any point the identity owner desires to terminate communication, the identity owner will be able to instruct the personal portal through which the marketer is communicating with them to cease forwarding messages from that marketer.

An experienced marketer, always expecting a certain proportion of identity owners to reject the proposition at certain points of the sales cycle will build a mechanism for rejection into their process. This will not only give the customer an easy way of terminating communications, but will simultaneously solicit their feedback as to why they desire to terminate the dialog.

Managing contention

As the relevance of the personal portal network grows, there will be an increased amount of traffic on the network. Contention will become an issue where various customers of the system will demand a response service level on a request, especially if real time transactions are dependent upon the answer to a request.

An example prioritization system for handling contention upon a Personal Portal receiving a request is defined:
a. Internal transactions (from within the Portal Host’s system)
b. Propagation transactions (where the timestamp determines the priority)
c. Identity Owner transactions
d. Portal Host requests (within this set, the requests are prioritized using the scheme described that gives priority to the most significant requestor – see below)
e. Marketer requests

For Portal Host requests, the most significant requestor is a function of number of transactional records added in the past 12 months, the significance of the transactional data and the number of requests for information received in the past 12 months. This is expressed in a function:

Significance = (1 / log10T) x R2 x √T,

where T = the number of transactions and R = the number of requests. The lower the Significance value , the greater the commercial significance and therefore the higher priority the request.

Patent Filed in 2007 but abandoned due being preceded by too many similar claims in a patent filed by Sun (presumably for the Liberty Alliance project)