WO2016193156A1

WO2016193156A1 - Computer-implemented tracking mechanism and data management

Info

Publication number: WO2016193156A1
Application number: PCT/EP2016/062034
Authority: WO
Inventors: Eleanor Simone Frederika LOUGHLIN-MCHUGH; Roman Edward Szczesniak; Duncan Francis
Original assignee: Yoti Ltd
Priority date: 2015-05-29
Filing date: 2016-05-27
Publication date: 2016-12-08
Also published as: CN108140152A; EP3295388A1

Abstract

A computer system for tracking assets comprises an asset tracking system, a digital identity system and a computer interface. The asset tracking system comprises electronic storage and a profile manager. The electronic storage of the asset tracking system holds an initial profile of an asset in association with an asset identifier of the asset. The digital identity system comprises a profile manager and electronic storage configured to hold profiles of entities. The computer interface is configured to receive asset transfer notifications. Each asset transfer notification identifies the asset and a respective entity participating in a transfer of the asset. The profile manager of the asset tracking system is configured to, each time an asset transfer notification is received, create in the electronic storage a new profile of the asset comprising an identifier of the respective participating entity. The new profile of the asset is stored in association with the asset identifier.

Description

COMPUTER-IMPLEMENTED TRACKING MECHANISM AND DATA

MANAGEMENT

The present disclosure relates to a computer-implemented tracking mechanism and computer-implemented data management.

Some aspects of the present invention relate to asset tracking.

Existing asset tracking techniques tend to be based on inventory control software, whereby an inventory control database that is specific to, say, a particular building, is configured to track inventory levels at thereat. Assets may be transferred between, say, such buildings a number of times during their lifetime, so that the movement of assets is at best recorded across multiple, disparate and independently managed databases. Such databases may not even provide a mechanism to distinguish between individual assets of the same type. Moreover, they are ill suited to handling changes in ownership of an asset, or more generally transfers of an asset between different entities. Somewhat more sophisticated asset tracking software is available, but this is still focused on managing one entity's assets, and is equally ill suited to tracking asset transfers, particularly multiple asset transfers that might occur over time.

A first aspect of the present invention is directed to a computer system for tracking assets comprising an asset tracking system, a digital identity system and a computer interface. The asset tracking system comprises electronic storage and a profile manager. The electronic storage of the asset tracking system holds an initial profile of an asset in association with an asset identifier of the asset. The digital identity system comprises a profile manager and electronic storage configured to hold profiles of entities. The computer interface is configured to receive asset transfer notifications. Each asset transfer notification identifies the asset and a respective entity participating in a transfer of the asset. The profile manager of the asset tracking system is configured to, each time an asset transfer notification is received, create in the electronic storage a new profile of the asset comprising an identifier of the respective participating entity. The new profile of the asset is stored in

association with the asset identifier. Entities own assets are tracked within the digital identity system, whilst the full history of the asset transfers is made available in the asset tracking system. An entity's own asset may for example be an asset they own, or which they otherwise hold, have some responsibility for, or relationship to. Thus two perspectives on the asset are provided: not only does an asset transfer change the identity of the participant within the digital identity system, it also changes the identity of the asset within the asset tracking system. The two systems are linked, in that they are responsive to the same asset transfers. Linking them in this manner ensures the two perspectives they provide are consistent. A participant in an asset transfer may for example be a new owner of the asset (more generally an entity newly responsible for, newly associated with the asset etc.), or a seller of the asset or broker of a sale or other transfer of the asset. In preferred embodiments, the asset tracking system also comprises an association module configured to, each time a new profile of the asset is created, associate the new profile with the next most recent profile of the asset, thereby creating a temporal sequence of profiles representing a chain of transfers of (e.g. chain of ownership of) the asset. The temporal sequence is stored in association with the asset identifier.

Existing methodologies are ill suited to tracking individual assets reliably in multiple different contexts. For example, a system well suited to dealing with asset locations may be poorly equipped to manage multiple ownership changes or other multiple transfers. By contrast, the temporal sequence of the present invention held against the asset itself provides an accurate record of the chain of transfers for the asset, and constitutes a micro-database that is specific to the asset in question. A separate micro-database of this kind can be maintained for every individual asset tracked by the system. Existing tracking methodologies also lack robustness to accidental or nefarious record alteration. In preferred embodiments of the present inventions, one or more labels are assigned to respective profiles of the temporal sequence based on cryptographic hashing in a manner that provides robust integrity protection of individual profiles and/or the structure of the sequence as a whole. Among other things, the labels provide a mechanism by which any alteration of the profiles or sequence is detectable.

The system may comprise a label generation module configured to generate a label for each new profile in the sequence, that is then associated with that new profile, by applying a hash function to input data comprising:

(i) data of that new profile, and/or

(ii) data of another profile (e.g. an earlier profile, such as the next most recent profile) in the sequence.

(i) provides integrity protection of the content of that new profile, whereas (ii) provides integrity protection of the sequence as a whole. That is, when the labels are generated from (i) it will be evident if the content of a profile has been altered (e.g. tampered with or accidentally compromised) as it will no longer match its own label; when generated from (ii), it will be evident if the structure of the sequence has been altered as at least one of the labels will no longer match the structure of the modified sequence: for example, consider a sequence of profiles (ρθ,ρΐ ,...,p(n),...). If a label L(n) of a later profile p(n) is generated by hashing data of the next most recent profile p(n-1 ), if the sequence is tampered with to remove or move the earlier profile p(n-1 ), whichever profile ends up at position n-1 in the modified sequence will no longer match the label L(n) of the later profile p(n). More generally (though this is less preferred) this can be achieved by hashing data p (n±m) to generate L(n). If every link in the sequence is covered (which can be achieved by setting m to one of many appropriate values), then the entire structure of the sequence will be protected. Preferably the label L(n) is generated by hashing both data of p(n) and data of p(n±m) (preferably n±m=n-1 ), as in this case the label L(n) provides both types of integrity protection simultaneously. In the described embodiments, the data of p(n±m) that is hashed is its own label L(n±m). It can be detected whether the data to which any label relates has been altered for example by rehashing the data in the same way and checking whether or not the result matches the original label. Preferably each label is also generated based on a secret key. For example, the key may also be included in the input data that is hashed to generate that label. This helps to prevent label forgery. As an example, the labels may be HMACs. Alternatively or in addition, data of the earlier profile may be used as a seed input to the hash function, and the data of that new profile is used as a content input to the hash function. For example, the label generation module may be configured to generate a label for the initial profile by applying a hash function to at least data of the initial profile.

In this respect, a second aspect of the present invention is directed to a computer system for tracking assets comprising: electronic storage holding an initial profile of the asset in association with an asset identifier of the asset; a computer interface configured to receive asset transfer notifications, each asset transfer notification identifying the asset and a respective participant in a transfer of the asset; a profile manager configured to, each time an asset transfer notification is received, create in the electronic storage a new profile of the asset comprising an identifier of the respective participant; an association module configured to, each time a new profile of the asset is created, associate the new profile with the next most recent profile of the asset, thereby creating a temporal sequence of profiles representing a chain of transfers of the asset; and a label generation module configured to generate a label for at least one profile in the sequence by hashing input data which comprises data of the at least one profile and data of at least one other profile at a known position in the sequence (e.g. n-1 where n represents the location of the at least one profile, or more generally ±m), and store the label in association with the at least one profile.

In embodiments of the first or second aspects, the profile manager of the digital identity system may be configured to disassociate the asset identifier from a profile of the previous participating entity in the digital identify system when it creates the association in the digital identity system.

The computer system may be configured to store an association between the asset identifier and a first proxy asset identifier; and the association between the asset identifier and the profile of the respective participating entity in the digital identity system may be created by storing the proxy asset identifier in the electronic storage of the digital identity system in association with the profile of the respective participating entity. Alternatively or in addition the computer system may be configured to store an association between the asset identifier and a second proxy asset identifier, each asset transfer notification comprising the second proxy identifier and thereby identifying the asset. The asset tracking system may comprise an access module configured to, in response to receiving an asset owner identity request identifying the asset: generate an electronic response message identifying a current owner of the asset based on the most recent profile in the sequence and/or based on the profile of the current owner in the digital identify system, and transmit the response message to an instigator of the request.

For example, the response message may render available to the instigator a visual image of the current owner. The initial profile may comprise an identifier of an initial owner of the asset.

At least one (e.g. some or all) of the profiles of the asset may comprise an identifier of a participating entity which comprises:

a visual image of the participating entity, and/or

a link to stored identity data of the participating entity, and/or

a hash of at least part of a payment account number issued to the

participating entity.

For example the link in the at least one profile of the asset may be a link to a version of the participating entity's profile in the digital identity system. E.g. the digital identity system may comprise a publication module configured to publish the participating entity's profile by storing a copy of it to an addressable memory location, the link in the at least one profile of the asset being a link to the

addressable memory location. Multiple temporal sequences of profiles may be stored in the electronic storage, each representing a chain of transfers (e.g. ownership) of a different asset. The computer system may comprise an analyser configured to perform an analysis of the multiple sequences e.g. the assets may be tickets to one or more events, and the analysis may be performed to detect whether a touting condition is satisfied by at least one identifier of an owner that appears in at least some of the analyzed sequences.

A third aspect of the present invention is directed to a computer-implemented method of tracking assets comprising:

creating an initial profile of an asset in association with an asset identifier of the asset in electronic storage of an asset tracking system; and

receiving asset transfer notifications, each asset transfer notification identifying the asset and a respective entity participating in a transfer of the asset, wherein each time an asset transfer notification is received, the method comprises: at a digital identity system: creating in electronic storage of the digital identity system an association between the asset identifier and a profile of the respective participating entity,

at the asset tracking system: creating in the electronic storage of the asset tracking system a new profile of the asset comprising an identifier of the respective new owner, the new profile of the asset stored in association with the asset identifier. A fourth aspect of the present invention is directed to computer-implemented method of tracking assets comprising:

storing an initial profile of the asset in association with an asset identifier of the asset in electronic storage; and

receiving asset transfer notifications, each asset transfer notification identifying the asset and a respective participant in a transfer of the asset, wherein each time an asset transfer notification is received, the method comprises:

creating in the electronic storage a new profile of the asset comprising an identifier of the respective participant, and associating the new profile with the next most recent profile of the asset, thereby creating a temporal sequence of profiles representing a chain of transfers of the asset;

wherein the method also comprises:

generating a label for at least one profile in the sequence by hashing input data which comprises data of the at least one profile and data of at least one other profile at a known position in the sequence; and

storing the label in association with the at least one profile. The methods may comprise steps to implement any of the system features described herein.

Another aspect of the present invention is a bridge system for an asset tracking system and a digital identity system, the bridge system comprising: an input configured to receive an asset transfer notification; a first output configured to connect to a digital identity system; a second output configured to connect to an asset tracking system; and electronic storage configured to store an association between an asset identifier and an associated proxy identifier; wherein the bridge system is configured, in response to the asset transfer notification, to provide the asset identifier to the asset tracking system and the associated proxy identifier to the digital identity system.

In embodiments the asset tracking system may include an asset identifier generator configured to generate the asset identifier in response to an asset identifier request.

Other aspects of the present invention relate to automated ticketing.

Historically, tickets to events would be issued in person, for example at the venue of an event either beforehand or "on the door" at the time of the event itself. However, nowadays, ticket management is moving more and more into the digital domain, whereby tickets are requested and issued via the Internet. Whilst this is generally beneficial for users in terms of convenience, it nevertheless comes with its own set of problems. Where tickets are made freely available without restriction, soon touts will follow. Ticket touting (or "scalping" as it is also known) is the practice of an entity (tout) acquiring a potentially large number of tickets to, say, an event which they have no intention of using personally, i.e. where they have no intention of attending the event themselves, particularly for the purpose of selling them on at a premium. Whilst popular, oversubscribed events in particular have always been somewhat vulnerable to touting, historically the inter-personal nature of ticket purchases kept touting in check to some extent. However the problem of touting is being exacerbated as ticket management moves more and more towards Internet based systems. Not only is this removing the interpersonal aspect of ticket acquisition, but a specific problem that has arisen as ticket management becomes digitized is the ever-increasing presence of "bots". A bot is a software-implemented artificial intelligence deployed on a computer network such as the Internet, in this case acting as a tout i.e. programmed with a function of acquiring a potentially large number of tickets en masse as soon as they become available on the Internet, often in a very short space of time so as to deprive legitimate (i.e. non- touting) users. A problem also exists regarding ticket allocation and identification. Sometimes a ticket seller or broker will mandate that a ticket purchaser has to show up at the venue with some form of identification (e.g. payment card) to prove that the person showing up is the original purchaser of the tickets, or a legitimate re-purchaser who has re-purchased the ticket(s) via the broker's own system. However, in practice the time and effort this involves, and the delays it would result in, means that this is not enforced in practice. In other words, existing mechanisms for linking identity to tickets are unworkable in practice. This is particularly, though not exclusively true of physical tickets. A problem solved by the present invention is one of constructing an automated ticketing system that is robust to touting but does not place undue restrictions on legitimate (i.e. non-touting) users and requires minimal manual oversight. A fifth aspect of the present invention is directed to an automated ticketing computer system that implements a robust, automated anti-touting mechanism. The

mechanism detects touting behaviour by entities, such as humans or possibly artificial intelligence entities, within the system, based on historical ticket usage, and can where necessary automatically inhibit future ticket acquisitions for detected touting entities, without human intervention being necessary to achieve this. The inhibition mechanisms are targeted on detected touts, so as not to restrict legitimate movement of tickets within the system unnecessarily. The touting detection is made possible by linking digital identity to tickets, so that each ticket has a clearly assigned owner within the system.

In accordance with the fifth aspect of the present invention a computer system comprises:

a data store holding: a plurality of profiles, each of a respective entity and stored in association with past ticket usage data indicating a probability that the respective entity would personally use a ticket issued to them based on a history of past ticket usage;

a computer interface configured to receive a ticket request from a requesting device via a computer network, the ticket request identifying a profile of a requesting entity;

one or more processors configured to execute code for managing tickets, the code configured when executed to implement:

a ticket controller configured to: in response to the ticket request, determine whether a ticket should be issued to the requesting entity based on the past ticket usage data associated with the requesting entity's profile, and if so issue a ticket to the requesting entity in electronic form via the network,

a receiving module configured to receive a ticket use notification from a validating device via the network, the ticket use notification indicating: identity data of the requesting entity and identity data of a presenting entity that has presented the issued ticket to the validating device, and

a profile manager configured to: update the past ticket usage data associated with the requesting entity's profile based on the ticket use notification, whereby the updated past ticket usage data conveys whether the requesting entity presented the ticket themselves. Both the issuing and the use of the ticket are tied to the requesting entity's profile. The requesting entity may for example be a purchaser of the ticket, purchasing it via the network (e.g. Internet). "Ticket use" in this context means presenting the ticket to the validating device, which is e.g. available to an event organizer, to gain admission to a ticketed event.

By tying ticket issuing and use to the requesting entity's profile in this manner, it is possible to detect when the requesting entity is obtaining ticket(s) to an event, but not using any of those ticket(s) themselves. This is indicative of touting behaviour and where a profile is used to buy tickets for many events but never (or hardly ever) used to gain admission to those events, it can be concluded that that profile is of a touting entity with a high level of statistical certainty. Conversely, it is possible to detect when the same entity is both acquiring a ticket (or a set of multiple tickets) and also using that ticket (or one of that set of tickets) to gain admission to that event. This is indicative of legitimate (i.e. non-touting) behaviour, and where a profile is used to both to buy tickets for and gain admission to multiple events, it can be concluded that that profile is of a legitimate (i.e. non-touting) entity. Tying the tickets to profiles also makes it harder for bots to even gain access to tickets in the first place, particularly if the profiles are tied to an official identity document such as a passport.

In certain embodiments, no limits are placed on the number of tickets that can be issued to a legitimate entity at all, nor (in some cases) are any limits places on the transfer of tickets between legitimate entities, so that only the activities of identified touting entities are curtailed. In other embodiments, some restrictions may still be placed on legitimate users, e.g. on the number of tickets a legitimate user can purchase to ensure a fair distribution of tickets across all legitimate users, though generally these will be less stringent than those placed on identified touting entities.

The past ticket usage data in a profile of an entity may for example be in the form of a value pair (Nu, Na) or a ratio Nu/Na or other metric function m(Na,Nu) of NA and Nu. Here Na represents the number times that profile has been used to acquire tickets (for example by acquiring them directly from a ticket issuer or indirectly from another entity(s) e.g. through a re-sale), and Nu represents the number times that that profile has been used both to acquire tickets and to gain admission to the corresponding events i.e. the number of times the entity has actually shown up at events they have bought tickets to. For legitimate users, Nu will equal or be close to Na i.e. a ratio close to 1 ; for touting entities, such as human touts or touting bots, Nu will be equal or close to zero i.e. a ratio close to 0. In some cases, the ratio may be biased initially to give entities the benefit of the doubt e.g. Na and Nu may be initialized as, say, Na=Nu=50 to lessen the effect of the entity's first actions on the ratio. Alternatively, Na may represent the number of times the entity has bought tickets but not shown up, so that for legitimate users Nu is equal or close to zero, and for touts it is equal or close to Na. Alternatively the past ticket usage data may, for example, convey the probability indirectly - e.g. it may comprise, for each event for which that profile was used to buy tickets, a respective flag indicating whether or not that profile was also used to gain admission to that event.

When the profile manager detects that the identity data of the presenting entity does match that of the requesting entity (indicating the presenting entity and the requesting entity are the same person i.e. the requesting entity is a person who has shown up at the event), the past ticket usage data may be updated so that the probability indicated thereby increases. Conversely, where the profile manager detects that the identity data of the presenting entity does not match that of the requesting entity (indicating that the requesting entity has not shown up at the event), the past ticket usage data may be updated so that the probability indicated thereby is decreased.

A key aspect is that identify is being validated at the same time as the ticket, in a non-intrusive and practicable way. The identity of the person presenting the ticket is validated by the system as well as validating the ticket itself, and checked against the identity of the original ticket purchaser. This is in contrast to, say, scanning a barcode on a conventional electronic or paper ticket, as this only validates the ticket itself and not the person presenting it. Note, where an entity acquires a set of multiple tickets for a single event, the probability that the entity would personally use a ticket issued to them means the probability of the user using any one of the tickets in the set (giving the remainder e.g. to friends or family).

In embodiments, the updated past ticket usage data may indicate the identity data of the requesting and presenting entities, and the processor(s) may be configured to use the updated past ticket usage data to compare the identity data of the presenting entity with the identity data of the requesting entity to detect whether they match. The ticket controller may be configured to determine whether to reject a future ticket request from the requesting entity based on said comparison. For example said comparison may be performed in response to receiving the future ticket request.

The identity data of the requesting entity and the identity data of the presenting entity may be stored in the computer system and associated with a ticket identifier of the ticket, and the ticket use notification may comprise the ticket identifier and thereby indicates the identity data of the requesting entity and the identity data of the presenting entity. For example the identity data of the requesting entity may form part of the requesting entity's profile. E.g. the ticket request may comprise a credential bound to the requesting entity's profile, and the processor(s) may be configured to implement a validation service for validating credentials, and the ticket may be issued only if the credential is valid.

The identity data of the requesting entity and the identity data of the presenting entity may comprise a hash of at least part of a payment account number issued to the requesting entity and a hash of at least part of a payment account number issued to the presenting entity respectively.

Alternatively or additionally the identity data of the requesting entity and the identity data of the presenting entity may each comprise a string unique to that entity. For example, the unique string of the presenting entity may be received from the validating device in the ticket use notification, having been presented to the validating device with the ticket by the presenting entity.

The computer system may be configured to associate a profile identifying a true owner of the ticket with the ticket identifier. An identifier of the true owner may be transmitted to and outputted by the validating device in response to the ticket being presented to the validating device, and the updating of the past ticket usage data may be conditional on a user of the validating device indicating via the validating device that the presenting entity is the true owner. For example, the profile of the true owner may be associated with the ticket identifier in response to receiving a change of ownership notification identifying the ticket and the true owner.

Alternatively, the profile of the true owner may be the profile of the requesting entity.

The computer system may comprise an asset tracking system, and the identity data of at least one of the entities may form part of a profile of the ticket in the asset tracking system of, the ticket use notification identifying the profile of the ticket.

The computer system may comprise an asset tracking system, and a profile of the ticket in the asset tracking system may comprise a link to the identity data of at least one of the entities, the ticket use notification identifying the profile of the ticket and the link being used to retrieve the identity data of the at least one entity.

The processor(s) may be configured to implement an association module configured, in response to the ticket request, to create an association in the data store between the requesting entity's profile and a ticket identifier of the issued ticket. The ticket use notification may comprise the ticket identifier and thereby indicate the identity data of the requesting entity. The profile manager may be configured to use the ticket identifier received in the ticket use notification to retrieve the identity data of the requesting entity for said comparison based on the association created by the association module.

The ticket use notification may indicate the identity data of the presenting entity by identifying a profile of the presenting entity that comprises that identity data. Alternatively or in addition, the ticket use notification may comprise the identity data of the presenting entity and thereby indicates it.

The ticket use notification may comprise the identity data of the requesting entity and thereby indicates it.

A sixth aspect of the present invention is directed to a method implemented by a computer system comprising a data store holding a plurality of profiles, each of a respective entity and stored in association with past ticket usage data indicating a probability that the respective entity would personally use a ticket issued to them based on a history of past ticket usage, the method comprising:

receiving a ticket request from a requesting device via a computer network, the ticket request identifying a profile of a requesting entity;

in response to the ticket request, determining whether a ticket should be issued to the requesting entity based on the past ticket usage data associated with the requesting entity's profile, and if so issue a ticket to the requesting entity in electronic form via the network;

receiving a ticket use notification from a validating device via the network, the ticket use notification indicating: identity data of the requesting entity and identity data of a presenting entity that has presented the issued ticket to the validating device; and

updating the past ticket usage data associated with the requesting entity's profile based on the ticket use notification, whereby the updated past ticket usage data conveys whether the requesting entity presented the ticket themselves.

A seventh aspect of the present invention is directed to a computer system for detecting ticket touting comprising:

a ticket issuer configured to selectively issue tickets to ticket requesting entities;

electronic storage holding, for each of multiple issued tickets, an initial profile of that ticket in association with a ticket identifier of that ticket; a computer interface configured to receive ticket transfer notifications, each ticket transfer notification identifying a respective one of the issued tickets and a respective entity participating in a transfer of the respective ticket;

a profile manager configured to, each time a ticket transfer notification is received, create in the electronic storage a new ticket profile of the respective ticket comprising an identifier of the respective participating entity;

an association module configured to, each time a new ticket profile is created, associate the new ticket profile with the next most recent profile of the same ticket, thereby creating multiple temporal sequences in the electronic storage, each representing a chain of transfer of one of the tickets; and

an analyser configured to analyse the temporal sequences to detect when an entity identified in at least some of the temporal sequences satisfies a touting condition, wherein the ticket issuer is configured to determine whether to reject a ticket request received from that entity based on said detection.

An eight aspect of the present invention is directed to a method of detecting ticket touting comprising:

creating in electronic storage, for each of multiple issued tickets, an initial profile of that ticket in association with a ticket identifier of that ticket;

receiving ticket transfer notifications, each ticket transfer notification identifying a respective one of the issued tickets and a respective entity participating in a transfer of the respective ticket;

each time a ticket transfer notification is received, creating in the electronic storage a new ticket profile of the respective ticket comprising an identifier of the respective participating entity;

each time a new ticket profile is created, associating the new ticket profile with the next most recent profile of the same ticket, thereby creating multiple temporal sequences in the electronic storage, each representing a chain of transfer of one of the tickets; and

analyzing the temporal sequences to detect when an entity identified in at least some of the temporal sequences satisfies a touting condition, and determining whether to reject a ticket request received from that entity based on said detection.

In a ninth aspect of the present invention, a computer system comprises: a data store holding a plurality of profiles, each of a respective entity and comprising past ticket usage data indicating a probability that the respective entity would personally use a ticket issued to them based on a history of past ticket usage; a computer interface configured to receive a ticket request from a requesting device via a computer network, the ticket request identifying a profile of a requesting entity;

a ticket controller configured to: in response to the ticket request, determine whether a ticket should be issued to the requesting entity based on the past ticket usage data of the requesting entity's profile, and if so issue a ticket to the requesting entity in electronic form via the network,

a profile manager configured to: compare the identity data of the presenting entity with the identity data of the requesting entity to detect whether they match, and update the past ticket usage data in the requesting entity's profile based on said detection.

A tenth aspect of the present invention is directed to a computer program product comprising code stored on a computer readable storage medium and configured when executed to implement any method or system functionality disclosed herein.

For a better understanding of the present invention and to show how the same may be carried into effect, reference is made by way of example only to the following figures in which: Figure 1 shows a block diagram of a computer system for tracking an asset;

Figure 2 shows functional modules of an asset tracking system interacting to create a set of initial profiles of an asset; Figure 3 shows functional modules of an asset tracking system interacting to create a new profile of an asset in response to a change of ownership;

Figure 4 illustrates a use case of a temporal sequence of profiles of a ticket;

Figure 4A shows an asset tracking system and digital identity system responding to the same asset transfer;

Figure 4B shows a relationship between profiles of an asset and profiles in a digital identity system;

Figure 5A shows a ticket purchase transaction;

Figure 5B shows a ticket being used by someone who originally purchased it;

Figure 5C shows a ticket being transferred to another user;

Figure 5D shows a ticket being used by someone who did not originally purchase it; Figure 6 shows an alternative and preferred mechanism by which a legitimate ticket owner can use their ticket.

The remaining figures are described later, under the heading "The uPass System". Preferred embodiments will now be described by way of example.

Figure 1 shows a computer system 1 for tracking an asset. In the following example the asset is a ticket. Tickets are not normally handles as assets in conventional asset tracking systems. To date they have not been considered an asset to be tracked. One important benefit of the present invention is to provide a system which has universal application to multiple types of entities that can change their status with time. The computer system 1 comprises at least one processor 2 executing asset tracking code 4, electronic storage 6 accessible to the processor 4, and at least one network interface 8 via which the processor 2 is connected to a network 10 such as the Internet. For example the computer system 1 may be formed of a set of one or more interconnected server devices, each configured to run at least a respective part of the code 4.

Also shown connected to the network 10 are first and second user devices 14i, 14ii of, i.e. accessible to and operated by, first and second users 12i, 12ii respectively, referred to as Bob 12i and Alice 12ii respectively. The user devices 14i, 14ii are computer devices, for example smart devices (e.g. smartphones, tablet computers etc.), laptop or desktop computers, wearable computer devices etc. Each of the user devices 14i, 14ii can communicate with the computer system 1 via the network 10. Figures 2, 3 and 4 between them show the following functional modules, each representing functionality implemented by executing a respective portion of the asset tracking code 4 on the processor 2: a profile manager 22, an association module 23 a label generation module (labeller) 24, a ticket generation module 28, and an analyser 29. As explained in further detail below, the profile manager 22,

association module 23 and labeller 24 interact with one another to create and manage a set P of profiles of an asset in the electronic storage 6. The profiles of the set P are all profiles of the same asset, and represent ownership of the asset at various stages of the asset's lifetime. The functional modules 22-26 and set of profiles P constitute an asset tracking system 20 implemented by the computer system 1 .

By way of example, an asset in the form of a ticket to an event - such as a concert, gig, music or other festival - is considered in the following. Figure 2 illustrates steps of an initial asset purchase transaction, in which the ticket is initially purchased by the first user 12i from a seller of the ticket such as an event organizer. The transaction is mediated by a broker computer system 19 operated by a broker. The seller may for example be a company or an individual; the same is true of the broker. The first user 12i has a payment card number, sometimes referred to as a payment account number (PAN), that has been issued to them by a bank or other card issuer. The first user's payment card number is denoted PANi. The payment card number PANi is unique, and can be used by the user to effect a transfer of funds to or from a monetary account against which the payment card has been issued, such as a debit account or credit account.

The first user's card number PANi together with their face form the basis of an identity of the first user 12i within the system. As explained below, a user's face can be incorporated by way of an image captured with a camera etc.

For example, the Applicant's co-pending US Patent Applications 14/622527,

14/622709, 14/622549, 14/622737, 14/622740 - incorporated herein by reference - describe a digital identity system, in which a user can, for example, create a profile of their digital identity (referred to therein as a "uPass") based on an identity document, such as a passport, and a self-captured image of their face ("selfie"). Various user profiles are referred to hereinbelow, which may in embodiments be uPass profiles. The uPass system of 14/622527, 14/622709, 14/622549, 14/622737, 14/622740 is described below, under the heading "The uPass system".

At step S2 the first user 12i uses their device 14i to instigate an electronic ticket request message to the broker system 19 via the network 10. The request 30 indicates the following to the broker system 19: an event identifier elD of the event for which they are attempting to secure a least one ticket, an authentication code ACi of the first user 12i, and a visual image of the first user's face Si ("selfie"), e.g. as captured with a camera of their device 14i. For example, the request 30 may comprise one or more of these elements and/or it may comprise a link(s) to one or more of these elements i.e. data identifying a memory location at which one or more of these elements are held and from which they may be retrieved by the broker system 19. E.g. the link may be a URI.

As an particular example, the request 30 may comprise a link to a profile of the first user 12i (e.g. a link to a published version of a uPass profile) that constitutes a digital identity of the first user 12i, and this profile may include a selfie Si previously captured by the first user 12i e.g. when they created or updated the profile. For example, the profile could be a Google, Facebook or other such profile. This saves the first user 12i the inconvenience of having to capture the selfie when sending the ticket request. In some cases, the request 30 may comprise a credential(s), such as a one-time pad, bound to the profile, and the relevant information may only be retrievable from the profile if the credential(s) is valid.

The authentication code ACi of the first user 12i is a keyed-hash message authentication code (HMAC). A HMAC is computed based on both a cryptographic hash function and a cryptographic key, and when applied properly can be used both to integrity protect data, i.e. to enable an check as to whether the data has been altered, and to authenticate the data, e.g. to demonstrate that an originator of the data is who he, she or it claims to be, the originator being the first user 12i in this example. A HMAC is defined in RFC 2140 "HMAC: Keyed-Hashing for Message Authentication" as:

HMAC( d) = H{[K XOR opad] || H([K XOR ipad] || d)) (1) in which K is a cryptographic key; d is the data to which the HMAC is being applied; H is a cryptographic hash function; XOR means the logical operation of bitwise exclusive-OR; and 51 || 52 means a concatenation of strings 51 and 52. In equation (1 ), opad and ipad are outer and inner padding bits, defined in RFC 2014 as B repetitions of the bytes 0x5c and 0x36 respectively where H is configured to operate on data blocks of length B bytes, e.g. B=64 (though in general other set(s) of zero of more padding bits can be used).

The authentication code ACi of the first user 12i is generated as ACi =

HMAC^l, PANi) i.e. by applying the HMAC function to the user's back card number PANi (or at least to a value derived therefrom) with key K1 . This operation is irreversible in the sense that it is, in practical terms, impossible to ascertain the user's card number PANi from the authentication code ACi alone. The key K1 can be provided by the user 12i, or generated by the system on their behalf and provided to them. Either way, it is a shared shared between the user 12i and the asset tracking system 20. A different key K1 may be uniquely generated each time it is needed. To provide additional security, a seed may be added e.g. so that ACi =

HMAC(K1, PANi || seed) .

The authentication code ACi of the first user 12i constitutes an identifier of the first user, as does their face image data as captured in the selfie Si.

The authentication code ACi of the first user 12i is used within the system to identify the first user 12i. This does not carry any security risk as, although the

authentication code ACi is derived from the first user's back card number PANi, the latter cannot be derived from the former. Moreover, because every payment card number is unique, when authentication codes are generated in the same way for other user's they are guaranteed to be unique.

Note that, to this extent, the first user's card number PANi is not being used to access the monetary account against which it has been issued - rather, to this extent, its uniqueness is simply exploited to generate a unique identifier that is tied to the first user 12i. The card number PANi can be used in this way even if the ticket which the first user 12i is attempting to secure is free.

Conversely, the authentication code ACi cannot be used to access the first user's monetary account against which the card number PANi is issued. Thus in the case that payment is required for the ticket, the necessary payment card details 30b must also be included in the request 30 in a form suitable for whatever purchase mechanism is being used to transfer the appropriate funds to the broker in the conventional manner.

It is not essential for the authentication code ACi to be generated at the first user device 12i, though it is preferable from a security perspective. At step S4, in response to the request 30, the broker system 19 instigates a ticket query to the asset tracking system 20, to query whether the first user's request 12i can be accommodated. For example, where the first user 12i has requested a number of tickets (one or more), the broker system 19 may query whether that number of tickets is available. Step S4 may be conditional on one or more criteria assessed by the broker system 19; for example, the broker system 19 may refuse the request if more than a maximum permitted number of tickets is requested. In response to the query, the asset tracking system 20 instigates (S6) a ticket identifier (ID) request to the ticket generation module 28. The ticket ID request identifies the event, for example by comprising the event identifier elD, and requests one or more tickets to the event as appropriate.

Assuming the request can be accommodated, e.g. as may be the case if the event has not yet reached capacity, the ticket generation module responds (S8) to the ticket ID request from the asset tracking system 20 with a unique ticket identifier tID for each requested ticket. A respective profile sequence is created in the tracking system 20 for each ticket identifier. In the following example, it is assumed that only one ticket is requested; where multiple tickets are requested, the relevant steps can performed for each requested ticket as will be apparent.

The ticket ID may for example be generated as a combination (e.g. concatenation or convolution) of a vendor identifier and a randomized sequence, for example a random number in a fixed field. The ticket number is unique and may be large, e.g. it may be a GUID, CSPRNG etc. It may be a prime number (or the randomized sequence may be prime). Alternatively, it may be entirely randomized.

Note where a ticket identifier is used as a device ID (see below), it is the randomised part that is used alone and not the vendor ID part. The ticket identifier tID is supplied to the profile manager 22, and in response the profile manager 22 instigates the creation of the set of profiles P in the electronic storage. When first created, the set P is made up of three initial profiles of the asset: an initial sale profile p(0,0), an initial asset brokering profile p(1 ,0), an initial purchase profile p(2,0). Each initial profile is associated with the ticket identifier tID in the storage 6. The initial sale profile p(0,0) records the initial sale of the asset by the seller. It comprises an identifier of the seller (e.g. event organizer) and metadata, such as a location of the seller, time of the transfer, device metadata (e.g. device ID) of a device used by the seller to conduct the sale. For example, the profile p(0,0) may comprise a link to a profile of the seller themselves, that includes details of the seller, e.g. company details or details of an individual seller as applicable.

The broker profile p(1 ,0) records the fact that the initial sale has been brokered by a third party (the broker). It comprises an identifier of the broker and metadata, such as a location of the broker, time of the transfer, device metadata (e.g. device ID) of the device of the broker system 19 that brokers the sale. For example, the profile p(1 ,0) may comprise a link to a profile of the broker, akin to that of the seller.

The initial purchase profile p(2,0) comprises an identifier IDi of the first user 12i, and thereby identifies the first user 12i as the first purchaser of the ticket. The profile p(2,0) also comprises metadata, such as a location of the purchaser, time of the transfer, metadata (e.g. device ID) if the purchaser's device 14i .

The identifier IDi of the first user 12i comprises at least one of:

• the authentication code ACi of the first user 12i;

· the first user's selfie Si, or a link to the selfie Si;

• a link to identity data of the first user 12i stored elsewhere, such as a link to a profile of the first user 12i (e.g. a link to a published version of a uPass profile of the first user 12i, published as part of a uPass transaction in which the ticket is purchased).

Preferably it comprises both the authentication code ACi of the first user 12i, and the selfie Si or a link to the selfie Si. The labeller 24 also generates a respective label L(0,0), L(1 ,0), L(2,0) for each of the profiles ρ(0,0), ρ(1 ,0), p(2,0). The labels L(0,0), L(1 ,0), L(2,0) are also HMACs, and may for example be generated by applying the HMAC function of equation (1 ) to data of the profiles p(0,0), p(1 ,0) and p(2,0) respectively. Once generated, each label L(0,0), L(1 ,0), L(2,0) is attached to (i.e. associated with in the storage 6) its respective profile p(0,0), p(1 ,0), p(2,0).

At step S1 1 , an answer message 32 is returned to the broker system 19 from the asset tracking system 20. The answer message 32 comprises the ticket identifier tID and the authentication code ACi of the first user 12i, thereby indicating that a ticket identified by the ticket identifier tID has been issued to that user.

At step S12, a ticket 31 is transmitted to their device 14i via the network 10 in electronic form. The ticket 31 may comprise the ticket identifier tID. Alternatively, the first user may not be granted direct access to the ticket identifier tID - in this case, a separate identifier may be used as a proxy for the ticket identifier tID instead proxy ID). For example, the first user's authentication code ACi may be used as a proxy for the ticket identifier. Where a proxy ID is used, a mapping 19a between the proxy ID (e.g. ACi) and the ticket identifier tID is stored at the broker system 19. All access to the ticketing system 20 may be mediated by the broker in this case.

Figure 3 illustrates steps of recording a transfer of the ticket from the first user 12i to the second user 12ii.

At step S22 a ticket transfer notification 34 is received by the profile manager 22. The ticket transfer notification 34 comprises or otherwise indicates: the ticket identifier tID, and an identifier IDii of the second user 12ii.

The identifier IDii of the second user comprises at least one of:

• an authentication code ACii of the second user 12ii, generated from a card number PANii of the second user 12ii in the same manner as the

authentication code ACi of the first user 12i, but using their own key K1 '; • a selfie Sii of the second user 12ii, or link to the selfie Sii;

• a link to identity data e.g. a profile of the second user 12ii.

Preferably it comprises both the authentication code ACii and the selfie Sii or a link to the selfie Sii.

The ticket transfer notification 34 also comprises identifiers of the seller, in this case Bob 12i, and a broker of the sale (which may be the same broker or a different broker, e.g. Bob himself or even Alice). The ticket transfer notification 34 may for example be instigated by the first user 12i from their device 14i, or from the second user 12ii from their device 14ii with the permission of the first user 12i, for example as part of a uPass transaction. In either case, the transfer may be mediated by the broker system 19 as indicated in figure 3. When used, the mapping 19a stored at the broker system 19 may be updated to change the proxy ID e.g. to the authentication code ACii of the second user 12ii instead. Alternatively, as shown in figure 3, the mapping 19a may not be updated and the first authentication code ACi may continue to be used as the proxy ID. This provides an additional way of linking the initial purchase of the ticket from the original seller back to the first user 12i.

In response to the notification 34, the profile manager 22 creates three new profiles p(0,1 ), p(1 ,1 ), p(2,1 ) of the ticket. The profile p(0,1 ) is a new seller profile and comprises the identifier of the seller IDi (Bob in this example). The profile p(1 ,1 ) is a new broker profile and comprises the identifier of the broker. The new profile p(2,1 ) is anew seller profile and comprises the identifier IDii of the second user 12ii, and thereby identifies the second user 12ii as a new owner of the ticket.

The association module 23 associates each of the new profiles p(t,1 ) - 1=0,1 ,2 - representing the three types of profile - of the ticket with the corresponding initial purchase profile p(l ,0) of the ticket, so that three ordered sequences (in the mathematical sense) of profiles (p(t,0),p(t,1 )) are created with p(t,1 ) as the most recent purchaser profile in the relevant sequence at this point in time. Each profile p(t,1 ) comprises the same type of metadata as the corresponding initial profile p(t,0), e.g. location/time of the transfer to which it relates, device metadata of device used in the transfer etc. To do this, the association module 23 generates association data in the storage 6. For example, the label L(t,1 ) or other identifier of profile p(t,1 ) may be mapped to, i.e. associated with in the storage 6, the label L(t,0) or other identifier of profile p(t,0). As will be appreciated, this is just an example any suitable data structure can be used to associate the profiles p(t,1 ), p(t,0) so that they constitute an ordered sequence.

The labeller generates a labels L(t,1 ) for each of the new profiles p(t,1 ), which is attached to that new profile p(t,1 ).

More generally, each time such a ticket transfer notification, identifying the ticket and a new owner thereof, thee new profiles p(t,n) are created. The new profile p(t,n) is associated with the next most recent profile p(t,n-1 ) of the same type i.e. the new seller (t=2) profile with the next most recent seller profile etc.

A label L(t,n) for the new profile p(t,n) is created. Preferably the label L(t,n) is a HMAC of data of both the new profile p(t,n) and the profile p(t,n-1 ) with which it is associated. For example:

L(t, n) := HMAC(tf2, p(t, n) \\ L(t, n - 1)) (2) whereby the label L(t,n-1 ) of the profile p(t,n-1 ) is used to seed content of the profile p(t,n) before hashing. Equation to applies to all n>1 . Once generated, the label L(t,n) is then attached to the profile p(t,n).

The labels L(t,0) are L(t, 0) == HMAC(tf2, p(t, 0)).

To provide additional security, a different key K2(l,n) may be used for each new profile p(l,n). The sequence S is constitutes a micro-database specific to one particular ticket. A separate micro-database in maintained in this manner for every ticket that is issued (and more generally every asset that is tracked by the system 20). An access module (not shown) implemented by the code 4 provides access to the sequence S. At least where a proxy ID is used, the access is mediated by the broker system 19.

In particular, the access module can, upon request, identify the current owner of the ticket to an entity requesting this information. The current owner is the one identified in the most recent profile in the sequence S.

Software executing on a user device may be configured to render the ticket identifier (or a proxy identifier) as a barcode, for example a matrix barcode e.g. QR code, on display of the device. A user of the user device can then present the barcode at the event itself to gain admission to the event, for example to a member of door staff. The ticket identifier is sent to the access module from a device operated by the door staff. The access module returns an identifier of the current owner - preferably a selfie from the most recent profile in the sequence S - to that device, so the door staff can check whether the user presenting the ticket is indeed the current legitimate owner of the ticket. The fact that the owner has actually shown up may be recorded in attendance data of the most recent profile of the sequence so that thereafter the last profile in the sequence not only identifies the last owner of the ticket but also records the fact that they did turn up to the event themselves. For example, this may be in response to the event owner sending an electronic message to the system 20 (e.g. via the broker system 19) from their device that the person who has turned up does indeed match the returned selfie and has thus been permitted to enter.

The last profile in each sequence is denoted p(t,N) below and in figure 4, the final sequence being (p(t,0),...,p(t,N)).

As indicated, in some embodiments, at least some of the profiles p(t,n) in each sequence may include a transfer time, indicating a time at which the asset was transferred as part of the profile metadata (see above). For example, a time at which the profile p(t,n), or the preceding/following profile p(t,n-1 )/p(t,n+1 ), was created or a transfer time extracted from the relevant transfer notification 34.

Figure 4 illustrates how an analysis may be performed based on one or more temporal sequences of ticket profiles P by the analyzer 29 of the asset tracking system 20. For the purpose of analysis, the analyzer 29 has access to at least one temporal sequence of profiles of a ticket 31 , though preferably it has access to multiple temporal profile sequences of different tickets, and most preferably it has access to all three profile sequences (seller, broker, purchaser) for multiple tickets. The analyser 29 is configured to analyze the sequence(s) to which it has access.

The various hashing mechanisms described above provide a level of integrity protection for each chain of ownership that afford it a high level of confidence, thereby significantly strengthening any analysis of which they form a basis.

Tracking the full ownership history of each tickets in this manner across its entire lifetime also enables undesirable activity to be detected within the system. For example, to detect ticket touting. Ticket touting is the practice of acquiring a potentially large number of tickets that the tout has no intention of using personally, but is selling on usually at a premium. Increasingly, a tout may not be a user at all but may be a "bot". A bot is a software-implemented artificial intelligence deployed on a computer network such as the Internet, in this case acting as a tout i.e.

programmed with a function of acquiring a potentially large number of tickets en masse as soon as they become available on the Internet, often in a very short space of time so as to deprive legitimate (i.e. non-touting) users.

To this end, an analysis of multiple profile chains may be performed by the analyzer 29 to detect an identifier of an owner that appears in multiple ones of the analyzed chains in a manner that satisfies a touting condition, indicating that the identified owner is likely to be a tout.

In this respect, the following observations have been made by the inventors:

1 . Touts at best use a small number of tickets they buy, and are far more likely to transfer them on; Touts rarely use tickets themselves

Legitimate (non-touting) users may also transfer tickets on, e.g. give or sell them to friends - but they will generally only do so to a small group of people closely related to them, whereas touts will generally sell to much larger groups of people to whom they have no personal links;

Touts may prefer to use anonymous brokers

Touts will but larger numbers of tickets than legitimate users on average

A touting detection algorithm can be configured to factor in one or more of these. For example:

1 . can be factored in by looking for entities that appear in multiple

seller/purchaser sequences, but always transfer tickets on

2. can be factored in by looking at actual attendance data (see below)

3. can be factored in by including a network analysis, i.e. spotting touts based on the size of the network of users in which their tickets are spread

4. can be factored in by looking at the broker chains

5. can be factored in by counting how many times the same entity appears

across different profile sequences A particular advantage of maintaining three full profile chains (seller, broker, purchaser) is that it provides a sufficient depth of information for a suitably

configured touting analysis algorithm to reliably spot touting behaviour, as it indicates who is selling to whom, and in what manner (the latter indicated by the broker chain). Figure 4 also shows a digital identity system 40. Profiles 42i, 42ii of the first and second users 12i, 12ii in the digital identity system 40 are shown, each profile 42i, 42ii comprising that user's respective selfie Si, Sii, or a link to that user's selfie Si, Sii. As indicated, an individual profile of a ticket may identify an owner of the ticket by a link to the relevant profile 42i, 42ii in the digital identity system 40. A profile 42i, 42ii may be specific to an event (or group of events e.g. related events), so that there is one profile per user per event (or event group); accords multiple events, the profiles for these events may be grouped together into an event profile group.

Alternatively, a user may have a ticket buying profile 42i, 42ii, which the use to purchase and record ownership of all of their tickets. Alternatively the user could even have one profile 42i, 42ii per ticket, though this is less preferred. Alternatively, though this is also less preferred, the user could have one general purpose profile 42i, 42ii that is not specific to events or tickets. The profiles 42i, 42ii may be uPass anonymous profiles, i.e. so that the only user identity data they contain is the selfie Si, Sii (no name, address, date of birth etc.).

The digital identity system comprises its own profile manager 43 for managing user profiles 42i, 42ii.

When the ticket identifier is first generated:

• within the digital identity system 40 the profile manager 43 associates it with the profile 42i of the initial processor;

• within the asset tracking system, the three initial profiles p(0,0), p(0,1 ), p(02,) are created.

When a transfer of the ticket takes place:

• within the digital identity system, the profile manager 43 "moves" the ticket identifier from the current owner's profile 42i to the new owner profile 42ii, by disassociating it from the former and associating it with the latter;

• within the asset tracking system 20, three new profiles p(0,n+1 ), p(1 ,n+1 ) and p(2,n+1 ) are generated and associated within p(0,n), p(1 ,n) and p(2,n) respectively to create the seller, broker and purchaser chains respectively. As shown in figure 4B, each of the asset profiles p(0,n), p(1 ,n), p(2,n) relate to the same asset transfer, and may comprise a link to a published versions 41 v, 44v, 42v of a seller profile, broker rpofile and purchaser profile in the digital identify system 40 - see figure 4B. These published versions may be immutable, to as to provide a snapshot of the identities expressed by the seller, broker and purchaser within the digital identity system 40 at the time the asset transfer took place. Thus as multiple asset transfers take place, within the asset tracking system the transfer chains get longer whereas the asset moves about between profiles within the digital identity system. Interactions between the asset tracking system 20 and the digital identity system 40 are via a bridge system 75, which is not shown in figure 4 but is shown in figure 4A. Figure 4A shows an alternative view of some of the interactions of figure 4. The bridge system 75 may be an event system, operated by on or behalf of the event organizer or multiple event organizers, which includes the ticket generator 19. The electronic storage accessible to the asset tracking system 20 is denoted 6a and the electronic storage accessible to the digital identify system is labelled 6b.

Note: within the digital identity system 40, the ticket identifier tID may not be used directly - a proxy ID may be used instead (similar to the proxy ID used by users 12i, 12ii - see above). In this case, the bridge system 75 stores, in electronic storage of the bridge system 75, an association "tlD<->proxylD" between the proxy ID used in the digital identity system 40 and the ticket identifier tID used in the asset tracking system 20. For example, this may be particularly suitable is the ticket identifier is not globally unique, as it can be mapped to a globally unique proxy ID used in the digital identity system 40. This is particularly appropriate where the proxy ID is treated as a device identifier in the digital identity system 40 (see below). For example, the bridge system 75 may comprise at least one processor executing bridging code so as to implement this functionality.

It will be understood that all description material pertaining to the ticket identifier tID in the context of the digital identity system 40 applies equally to a proxy identifier when that is used instead.

Alternatively the same ticket identifier tID may be used in both systems 20, 40. User profiles 42i, 42ii in the digital identity system 40 may be modified based on the analysis performed by the analyzer 29. For example, a profile in the digital identity system 40 may be associated with what is referred to herein as an anti-touting metric, indicating a probability that the user is a tout, which may be updated based on the results of a tout detection analysis by the analyzer 29. This anti-touting metric may, for example, be used at step S4 and/or step S6 as described above, and the relevant method steps may be conditional on the outcome. For example, when the first user 12i requests a ticket at step S2, the broker system 19 may have a link to the first user's profile 42i provided by the user in the request 30. The broker system 19 can request the anti-touting metric - "ATM" in the figures 5A-5D - associated with the user's profile metric via an API, in response to which a metric generator 76 of the digital identify system generates it based on past ticket usage data "UD" e.g. accessed from the profile sequences P in the asset tracking system 20. The broker system 19 may refuse the request if the anti-touting metric indicates a high probability of the first user 12i being a tout - for example, if it is above a threshold. The broker is free to set the threshold wherever they (or the ticket seller) choose. For example the broker may decide to impose stringent conditions (i.e. a low probability threshold) for very popular events, rejecting requests if there is even a small probability that the request has originated with a tout. For unpopular events, the broker may be more relaxed about or even completely tolerant of touting - that is entirely their choice; the present mechanism allows them to make an informed choice.

Alternatively, or in addition, an equivalent check of the first user's anti-touting metric associated with their linked-to profile 42i may be made by the ticket generator 28. In this case, the issuance of the ticket identifier on an equivalent criteria set by the ticket generator 28. The ticket generator 28 may be operated by the seller rather than the broker, so that the seller is free to set their own anti-touting criteria independently of the broker.

The anti-touting metric may for example comprise a ratio Nu/Na - or more generally a suitable function - of the total number of tickets a user has bought Na (indicated by the initial purchaser profile p(2,0) of the relevant sequences) to the total number of events that have actually shown up at Nu (as indicated by attendance data in the final profiles p(2,N) of the relevant sequences. Alternatively or additionally, the metric may comprise ratio of the number initial purchaser profiles p(2,0) that identify the user to the number of final profiles p(2,N) that identify the user across multiple sequences, if actual attendance is less of a concern. The ratio of function may be biased in the user's favour to begin with, so that they cannot be labelled as a tout immediately. As a simple example, Nu and Na may have non-zero values initially, e.g. they may be both set to 50 so that over time the ratio becomes 51/51 (shows up) or 50/51 (doesn't show up) etc. More generally, the system 1 is configured as a learning system, which assumes that entities are not touts to being with and learns from any touting behaviour they exhibit over time.

Alternatively or additionally, the metric may be based on, say, an average or other indicative amount of time for which the user retains tickets, based on the asset transfer times in the profiles of the analyzed sequence(s).

Note: in this context the actions user 12i could equally performed by a bot, and they system may even permit this to a controlled extent. The analyzer 29 may be configured to detect whether or not this is the case, i.e. whether an asset requesting entity is a human or a bot. The bot may also have an identity, for example a profile(s), within the digital identity system 40. The analyser may insert information into this profile which flags the profile as being of an entity that is a bot, rather than a human. Use of the asset tracking system 20 by an entity, such as the first user 12i, 12ii, may be conditional on that entity setting up a digital identity system 40. That is, use of the digital identity system 40 may be mandated if a transfer is to be recorded using the asset tracking system 20, such that a link to a profile in the digital identity system 40 is required to do so.

Within the asset tracking system 20, the ticket 31 has an identity in the sense that it has profiles of its own. In one sense, the asset tracking system 20 can be regarded as a separate digital identity system but for assets. Within the digital identity system 40, the ticket may by contrast be treated as a virtual device, with the ticket identifier tID or another ticket identifier of the ticket 31 being treated as a device identifier within the digital identity system 40. The digital identity system 40 may, for example, be implemented as a uPass system (see co-pending applications, above). Indeed, in some cases, the asset tracking system 20 and the digital identity system 40 may be implemented as separate and largely independent uPass systems or identity spaces. In this case, within the asset tracking identity space 20, the uPass "entities" are assets. Within the uPass identity space 40, the uPass entities are humans, e.g. users 12i, 12ii, bots etc., and assets are treated at least to some extent as devices.

For a uPass system, links to profiles are in the form of links to published versions of profiles. The terminology "a link to a profile" encompasses a link to a published version of a uPass profile, and does not have to be a direct link to the underlying master profile from which it has been published.

Advantageously, the architecture of the uPass system 40 can be readily adapted to provide a robust anti-touting mechanism that requires little or no manual oversight, and does not curtail legitimate activity by non-touting users unnecessarily.

This is in contrast to existing anti-touting methodologies that are somewhat crude, and often end up curtailing what most would perceive as reasonable activity by legitimate users, such as purchases on behalf of, and a certain amount of re-selling to, genuine friends and family. Moreover existing methodologies tend to involve a significant level of manual oversight.

For example, one existing methodology involves restricting the number of tickets that can be bought on any given credit or debit card, and/or that can be dispatched to any given address (e.g. email or postal). This tends to be enforced by a ticket provider simply revoking tickets, after they have already been issued, should those tickets later turn out to have been issued in violation of these limits. This generally requires at least a degree of manual oversight in ultimately deciding whether or not an already-issued tickets should or should not be revoked. Moreover, it can be unduly restrictive: for example, occasionally a user may wish to buy tickets for a large group of genuine friends with whom they wish to attend the event, which in some cases an event owner may wish to permit. Additionally, for less popular events, such restrictions may be unwanted: for example, an event may be over-targeted by touts i.e. by touts buying up tickets for which there is in fact limited demand so that they are never in fact able to sell them on. This can lead to an event not only selling out, depriving those who genuinely do wish to attend the event - but are (justifiably) unwilling to buy a ticket from a tout - of the opportunity to attend, but also being poorly attended due to the touts' unsold tickets being essentially wasted. From the perspective of a tout, this may amount to an acceptable loss in the context of their wider activities, whereas for an event organizer the effect can be detrimental both to the event itself in the short term and their reputation in the long term. Problems also arise if less than the expected number of attendees turn up:

significant revenues are generated from attendance, car parking, bad drops, food, drinks, merchandise etc. Moreover, ticket increase does not reach the owner or venue either. Another example of an existing methodology is deterring touts by restricting or even forbidding the transfer of issued tickets between entities. This has been enforced by, for example, requiring ticket holder to present the card they used to purchase their ticket(s) to gain admission to a ticketed event. Notionally, this mandates at least the purchaser of a ticket or group of tickets to attend the event in person. However this again relies on manual oversight by those managing the event, and at a busy event such checks will often end up being neglected. Thus, in practice a warning that a purchasing card is required for admittance may amount to little more than a hollow and ineffective threat. Moreover, there can be legitimate reasons why an entity may occasionally wish to transfer a ticket they have purchased, for example where they purchased it with the intention of attending but are prevented from doing so by unforeseen circumstances, or where they have purchased it on behalf of a genuine friend who for whatever reason was unable to purchase it themselves. Thus such tout deterrents may be not only ineffective but also impose an unnecessary burden on legitimate users. Moreover, even where ID is mandated, this is rarely enforced in practice as discussed. Major events e.g. the world cup state they require photo ID, passports etc. to be brought to the venues but in reality they are not checked due to the impact on processing speed. In contrast, the digital profiles of the present invention provide a much more viable identity check mentalism. Embodiments provide a solution to the problem of tout detection by tying both ticket purchase and ticket use to an entity's digital identity within the uPass system 40 across multiple events. In so doing, it becomes possible to track the ticket-related activity of entities within the system, and in particular to detect those entities who are frequently purchasing tickets within the system but never or rarely showing up to the events themselves.

Actions within a uPass system 40 can be effected by uPass transactions, in which a validation service 14b validates the appropriate uPass credentials.

In some implementations, the mechanism by which the ticket 31 is purchased by the first user 12i (referred to as "Bob" below) is a uPass transition. This will now be described with reference to figure 5A. Figure 5A shows Bob buying a ticket from the seller via the broker system 19. To do this, Bob presents (S3a) a credential 52i, that is bound to his uPass profile 42i, to the broker system 19. For example the credential 52i may be part of the ticket request 30. The broker system 19 receives the credential 52i. At this point the broker does not know whether or not it is willing to sell a ticket to Bob as it has not seen Bob's profile. Therefore the broker system 19 sends (S3b) Bob's credential 52i, together with its own credential 54 to the validation service 14b. The broker's credential may also be bound to a uPass profile of the broker 44 in the uPass system 40. Assuming the credentials 52i, 54 are valid, the validation service 14b causes a first receipt 64 to be sent to the broker system 19 (S3c). The first receipt 64 contains a link to a published version of Bob's profile 42i.v1 . In this scenario, the ticket is issued only if the uPass credentials are valid. Bob's profile 34B is associated with past ticket usage data UD, indicating the extent to which he has used (rather than e.g. sold on) in the past. This past ticket usage data comes from the ticket profile sequences in the asset tracking system 20, which in turn link to published versions of his profile 42i for transactions he has participated in. A comparison module (functional module) in the form of a metric generator 76 is shown, which generates an anti-touting metric ATM based on the past usage data UD. This is generated upon request by the broker system 19 via an API of the system 40, and the requested anti-touting metric ATM is supplied to the broker system 19 via the API.

The metric generator 76 may be implemented in either of the systems 20, 40, and may for example represent part of the functionality of the analyzer 29 of figure 29.

Details of the anti-touting metric ATM will be described in due course. Suffice it to say, in this example, the anti-touting metric UD indicates a probability that Bob is not a tout i.e. a probability that, if the broker were to issue a ticket or tickets to Bob, Bob will actually use one of these tickets himself rather than, say, selling them all on. In this example the probability that Bob is not a tout is 80%, which is high enough for the broker to accept Bob's request and issue him with the requested ticket(s). Each ticket comprises a ticket identifier or proxy identifier of the kind discussed above, labelled tID in the various figures. In the following examples, the ticket identifier tID is issued to Bob directly. As will be apparent, the same steps apply when a proxy identifier is used instead, and in this case all interactions with the asset tracking system are via the broker system 19 which translates the proxy identifier to the ticket identifier tID used within the asset tracking system 20.

A less preferred alternative is that Bob's profile 42i contains the anti-touting metric UD.

Within the uPass system 40, the ticket identifier is then associated (enrolled) with Bob's profile 42i in a manner that will be described later. Once this association has been created, Bob (or more accurately Bob's profile 42i) is effectively registered within the uPass system 40 as the owner of the ticket. Note this is a separate mechanism from that used to record ownership changes within the asset tracking system 20. In this example, the instigation of the ticket query at step S4 from the broker system 19 to the asset tracking system 20 is conditional on Bob's anti-touting metric ATM being determined by the broker system 19 to meet anti-touting criteria set by the broker.

Bob also gets a receipt 62i, and Bob and the seller each get a fresh credential. Note: the outcome of figure 5A could also be achieved by the Broker system 19 presenting its credential 54 to Bob (e.g. as a QR code which Bob scans with his device 14i), and Bob's device sending the two credentials 52i, 54 to the validation service 14b.

Figure 5B shows a situation where Bob actually turns up at the ticketed event himself. To gain admission to the event, Bob presents the ticket identifier tID to a validating device 46 being operated e.g. by a member of event staff such as a door supervisor (S26). In turn, the validating device transmits a ticket use notification 72 to the asset tracking system 20. The notification 72 comprises the ticket identifier tID. In response, the door supervisor is granted access to the most recent profile in the sequence of profiles P of the ticket in the asset tracking space 20- the original purchaser profile p(2,0) in this example - and can thus see who the current ticket owner is. In this example, the current ticket owner is indeed Bob so the door supervisor should allow him into the event.

Attendance data AD in the most recent profile p(2,0) is updated to indicate that the ticket owner identified in the profile p(2,0) has attended the event. In some cases, this may be conditional on the door supervisor notifying the asset tracking system 20 from their device 46 that is the true current owner of the ticket that has actually shown up (S30). E.g. an automated feedback mechanism may present them with a simple "yes/no" selectable option on their device 46, so that the effort involved in providing feedback is minimal.

An alternative to adding the attendance data to the profile p(2,N) is adding attendance data to the sequence, in the form of a terminating P(t,N+1 ) profile that is added to each of the t=0,1 ,2 chains to indicate that ticket has been used. These profiles P(t,N+1 ) may transfer the ticket back to the original owner (i.e. the event organizer). Both types of attendance data are examples of past ticket usage data.

The metric generator 76 of the uPass system 40 detects whether an original purchaser of a ticket to whom the ticket is initially issued is the same person as a presenter of the issued ticket i.e. a human entity who is presenting a ticket to an event manager (e.g. a volunteer or member of event staff who is "on the door" at the event venue) in an attempt to gain admission to the event to which it relates. The presenter and the buyer may be the same person, or the presenter may be a different person to whom the ticket has been legitimately transferred.

The metric generator 76 uses the sequence of profiles P of the ticket in the asset tracking system 20 to compare identity data of the original ticket purchaser 12i (i.e. Bob) with corresponding identity data of the ticket presenter (i.e. the person who has actually shown up at the ticketed event, which may or may not be Bob). The identity data may for example comprise HMACs of a card number or part of a card number issued to the relevant entity. For example, the metric generator 76 may detect whether identity data of the initial purchaser as indicated by profile p(2,0) of the ticket in the sequence P matches corresponding identity data of the user indicated by attendance data AD in a profile of the sequence P to have actually shown up at the event. Note "corresponding" means the sets of identity data of the same type i.e. comparing like-for-like.

Alternatively or additionally, the identity data may comprise a unique string (e.g. numerical string, alphanumerical string, bit string etc.) provided by or allocated to Bob, that constitutes a shared secret. The unique string may be communicated to the validating device 76 wirelessly, e.g. via an NFC link or as a displayed barcode (e.g. QR) code, and transmitted from the validating device to the system 20 and stored so that it is accessible to the metric generator 76 when needed.

A profile p of the ticket in the asset tracking space may indicate identity data of an entity because it comprises that identity data, or because it comprises a link to a uPass profile of that entity from which that identity data can be retrieved (for example). In the example of figure 5B, in response to Bob showing up himself, the past ticket usage data in the ticket relevant ticket profile(s) stored in the asset tracking system 20 is updated in a manner that, thereafter, the metric generator generates a more favourable metric ATM for Bob's .

By contrast, figure 5C shows an example situation in which Bob sells or otherwise transfers his ticket to the second user 12ii (referred to as "Alice" below). This can be also be achieved by a uPass transaction.

Bob presents a credential 52i' to Alice's device 14ii (S21 ), and Alice transmits Bob's credential 52i' along with her own credential 52iia and the ticket identifier tID to the uPass system 40. Alternatively the signalling flow may be reversed i.e. Alice presents her credential 52iia to Bob's device 14i, which transmits it with Bob's credential and the ticket identifier tID to the uPass system 40. Within the uPass system 40, the ticket identifier tID becomes enrolled with Alice's profile 42ii in response. This is entirely legitimate - the system allows for transfer of tickets, and Alice is now recorded as the rightful owner of the ticket within the uPass system 40. Alice and Bob each get a receipt linking to the other's profile and a fresh credential.

Again, this is separate from the ownership tracking mechanism of the asset tracking system 20.

To enable tracking within the asset tracking system 20, the asset transfer notification 34 is sent from Alice to Bob's device (possibly via the broker system 19) to the asset tracking system 20, where a new profile p(2,1 ) is added to the sequence of profiles P of the ticket identifying Alice as the new owner in the manner discussed.

Figure 5D shows Alice using the ticket, which she now rightfully owns, to gain admission to the event. From the perspective of Alice and the door supervisor, the process proceeds in exactly the same way as figure 5B, by Alice presenting the ticket identifier to the door manager's device 52M (S28). Alice is identified to the door supervisor based on p(2,1 ). Attendance data is included in the most recent profile p(2,1 ) to indicate that the owner identified by p(2,1 ) - in this case Alice - has actually attended the event. The attended data in p(2,1 ) is associated with Bob's profile 42i by virtue of the fact that p(2,0) in the same sequence of profiles (and thus associated with the same ticket identifier) links to a published version of Bob's profile 42i.

In this instance, thereafter, this causes the metric generator 76 to detect 'behind the scenes' that the person who has shown up to the event (Alice) is not the entity who purchased the ticket. Thus in future it will generate a metric ATM that is less favourable to Bob on the basis that he is more likely to be a tout because he has transferred his ticket to Alice and Alice has used it.

Each time this happens, the past ticket usage data UD used to generate Bob's anti- touting metric ATM will be updated accordingly. If Bob frequently buys tickets but never uses them, there may come a point where his anti-touting metric UD is so unfavourable that sellers may choose not to sell to him in the future, or may place restrictions on what tickets he can buy. Again that is their choice - but the digital identity system provides a means by which they can make informed choices.

The past ticket usage data UD thus indicates a probability that the buyer would personally use a ticket issued to them based on a history of past ticket usage.

The metric ATM may comprise e.g. a ratio of the number of times the buyer has bought tickets to events to the number of times the buyer has actually shown up at any of those events, shown as a percentage in the figures by way of example. This is just an example and the past ticket usage data US can take a number of different forms, such as other functions of these numerical measures.

A uPass profiles 42i, 42ii is published by storing a version of it to addressable memory location. The link to that version of the profile identifies that location. The broker's receipt 64 comprises a link to the published version of the buyer's (i.e. Bob's) profile. In turn, the published version of Bob's profile comprises a current version of the anti-touting metric UD, which the broker system 19 can access by following the link. The broker system 19 can then decide whether to issue ticket to the buyer based on the metric UD, for example based on a threshold. This may be entirely automatic.

For instance, where the probability of the buyer being a tout (as indicated by the metric UD) is below a threshold, the ticket request may be approved by the broker system 19 whereas if that probability is above the threshold it may be refused.

Alternatively, where the probability is above the threshold and a plural number of tickets have been requested, the ticket issuer may only permit a number of tickets that is less than the number requested to be issued (e.g. only one ticket).

The behaviour of the broker system 19 can be agreed with the organizer of an event, who is the ticket seller in this context. Subject to any agreement with the seller, the broker is free to program their system 19 as they see fit. For example, they are free to set and vary the threshold, or to change how the controller responds when the probability is above or below the threshold. This gives the event organizer the freedom to, say, implement strict anti-touting criteria (low threshold and/or strict refusal of tickets to any entity identified as a tout) for a popular event, but less stringent or even no ant-touting criteria for an unpopular event. If a ticket request is approved, the broker system 19 issues a ticket (or however many tickets have been approved) to the buyer's device 14i in electronic form e.g. via the internet. The ticket comprises the ticket identifier (labelled tID in the figures).

The ticket identifier is, in turn, associated with the buyer's uPass profile 42i in the uPass system 40. This can be achieved using the same enrolment mechanism used to enrol a new device within the uPass system 40. The buyer's device 14i submits the ticket identifier to an account service 45 of the uPass system, in the same way it would a device identifier of a new device that the buyer 12i wishes to enrol based on the existing enrolment of their current device 12B. The account service 45 is implemented by the uPass profile manager 43, though this is not shown explicitly. Within the uPass system 40, the ticket is realized as a virtual device hosted on the buyer's device 14i, with the ticket identifier constituting a device identifier of the ticket virtual device. Subject to successful enrolment, a credential is issued to the ticket virtual device and sent to the buyer's (physical) device 14i hosting the ticket virtual device. Within the digital identity system, this credential is bound to both the buyer's profile 42i and to the ticket virtual device in the manner discussed, and thus this enrolment process acts to associate the buyer's profile 42i with the ticket identifier. This is similar to creating virtual devices on servers (see above). Where a proxy identifier is used, it may be enrolled in place of the ticket identifier.

When a change of ticket ownership takes place, that is recorded in the uPass system 40 (separately from the asset tracking system 20) by disassociating the ticket identifier from the previous owners profile 42i, and reenrol ling it as a device bound to the new purchaser's profile 42ii. In this manner, the new owner is recorded as the now true owner of the ticket in the uPass system 40.

All description material pertaining to "device identifiers" herein applies equally to ticket identifiers when enrolled in this manner as virtual devices. For example, where a credential is bound to (i.e. associated with, in the digital identity system) a profile and a ticket identifier, and that credential is presented in a uPass transaction, that transaction may only be permitted to complete if the credential is both valid and presented with a matching ticket identifier (just as is the case for credentials bound to physical devices with physical device identifiers).

In this context, the account service 49 constitutes an association module for associating ticket identifiers with uPass profiles.

The ticket identifier may for example be associated, in a database of the digital identity system, with a network address of the buyer's physical device 14i hosting the ticket virtual device. The uPass system 40, separately from the asset tracking system 20, may record transfers of the ticket virtual device to a different physical device by changing the network address associated with it in the database, for example to a network address of Alice's device 12ii when the ticket is transferred from Bob to her .

The credential bound to the buyer's profile and the ticket identifier may also be associated with the ticket identifier and the buyer's profile in a database of the digital identity system, for example by storing the credential or preferably the ingredients for generating this credential in association with these two elements in the database.

The buyer's receipt 62i comprises a link to the published version of the broker's profile 44, so that the buyer can also verify that the broker is legitimate. For example, the broker's profile 44 may include an identifier (e.g. logo, trademark etc.) of the ticket seller and/or broker and be allocated a high confidence value, indicating that within the digital identity system there is a high confidence that the seller is who they say they are. Final purchase of the ticket may, in some cases, only proceed once the user has been given the opportunity to review the seller's profile and decide whether or not they do indeed wish to proceed based thereon.

Once a ticket has been issued, the buyer is free at least to some extent to pass it on to other entities registered with the digital identity system, for example as a gift or re- sale. Some restrictions may be placed on this, for example restricting the re-sale price, though this is not in fact necessary - rather, the focus of the present anti- touting mechanism is not on preventing movement of issued tickets, but rather on monitoring this movement over time and making a future decision about whether to issue another ticket to the buyer in the future based on this monitoring. This monitoring is recorded by updating the anti-touting metric in the buyer's profile 42i.

When a legitimate ticket transfer takes place from the buyer to a different entity, within the uPass system 40 this is recorded by a uPass transaction, which in this case causes the ticket identifier to be associated with a profile of the new entity instead. For example, the ticket identifier may be re-enrolled as a virtual device, this time as a device of the different entity using the same enrolment mechanism.

Figure 6 shows a preferred mechanism by which a ticket owner 12 (e.g. Alice or Bob) and use a ticket that is rightfully theirs. In figure 6 the identity of the ticket owner is conveyed to the validating device 46 from the uPass system 40, rather than the asset tracking system 20. The user sends the ticket identifier tID from their device 14 along with their uPass credential to the validating device 46. The validating device, in turn, sends the ticket identifier tID, the user's credential 52 and their own credential in the ticket notification 72, which is sent to the uPass system 40 in this example. The validation service 14b validates the credentials 52, 54 and provided they are both valid and provided the user's credential 52 is bound to the same profile 42 as the ticket identifier tID has been enrolled with, it causes a version of the user's profile 42v2 to be published. A receipt is sent to the validating device 46, which comprises a link to this version 42v2 so that the door supervisor can see the identity data (e.g. selfie) of the ticket owner, and compare it against the person 12 standing in front of them. If, on the other hand, the user's credential 56 were bound to a uPass profile which does not match a uPass profile with which the ticket identifier is enrolled (meaning that the user is not the true ticket owner), the system 40 can detect that the user is attempting to use the ticket illegitimately. Moreover, if the door owner were to indicate to the system 40 via their device 46 that the person 12 in front of them does not match the selfie of the true owner supplied by the system 40, they can inform the system 40 via their device that an illegitimate ticket use has been attempted. In either case, the system 40 may be configured so that the ticket does not expire as a result of an illegitimate attempted use.

The uPass system 40 communicates with the asset tracking system 20 via the bridge system 75 to add the attendance data to the records in the asset tracking system 20.

The asset tracking system will also record the user 12 as the true owner of the ticket in the profile p(2,N) for the ticket. This profile also links back to the uPass system 40, as it comprises a link to an earlier published version of the user's profile 42v1 , published in the uPass transaction conducted to transfer the ticket to the user 12.

To provide additional robustness, the identity of the ticket owner could be verified using both the uPass profile and the ticket profiles in the asset tracking system 20, or the asset profiles could be used as a fall back. Currently, tickets for different events tend to be managed in a disjointed and disparate manner using different bespoke, non-interoperable ticket management mechanisms, in a manner that would make it difficult to detect touting behaviour across these different systems. In contrast, in embodiments of the present invention, ticket management for many events can implemented using a common uPass system 40 and/or a common asset tracking system 20. Harmonizing ticket management in this manner provides a central source of ticket usage data, and thus ensures that a wider base of data is readily available which can be used to detect touting.

In some embodiments, identity data of the buyer's uPass profile 42i in the uPass system 40 is located in the system using the ticket identifier received in the ticket use notification, as that identifier has been previously associated by that profile 42i by enrolling the ticket identifier as a virtual device of the buyer when they purchased it.

If the compared sets of identify data do indeed match i.e. if it is determined that the presenter and the original buyer are the same person, then the anti-touting metric ATM of the buyer changes to reflect this, in this example by increasing the

percentage (because this constitutes one more event the buyer has shown up to). This increases the chance of the buyer being able to buy tickets to events in the future within the digital identity system.

Conversely, if the compared sets of identity data do not match, i.e. if it is determined that the presenter is different from the purchaser, then in some (though not in all) cases the anti-touting metric ATM changes to reflect this, in this example by reducing the percentage. A scenario in which the metric ATM may not be changed is where the purchaser has purchased two or more tickets to the same event, kept one for him or herself and legitimately given or sold the other(s) to a friend, as mentioned earlier. Preferably a mechanism for distinguishing between touts and legitimate owners is provided, so that those who sell to genuine friends (for example) are not labelled as touts. This mechanism may be provided by the analyzer 29, and be based on a network analysis, in particular based on the size of a network of entities in which tickets are spread as mentioned previously.

For a uPass implementation, the determination as to whether an entity purchasing multiple tickets on behalf of others is a tout or a legitimate purchaser may use a social graph ("web of confidence" - see below) describing the links between the purchasing entity and those other entities, to ascertain whether or not those other entities are friends of the purchasing entity in the social sense.

In some embodiments, touting behaviour may also be detecting in those who do may obtain tickets directly from the broker 19, but rather indirectly from other entities e.g. through gifts or re-sales that are recorded in the sequence of profiles P.

This allows for the detection of entities who are linked to touts, for example where a tout buys 6 tickets (if initially permitted to do so) and associates 5 of those tickets with "friends" but none of those friends attend the event. Instead the tout or the

"friend" always sells on / transfers on the ticket to a fan - either via a reseller site, or via a real-world (e.g. pub or outside event) handover. In some cases, the system may also target those who buy from proven touts, and make it harder for them to obtain tickets in the future, so as to further discourage the practice of touting.

If unique individuals seem to exhibit low use / temporary Ownership' behaviour despite not originally purchasing the ticket, some event owners will want to ban such non fans (fans usually go to the events if they get a ticket, even if they didn't buy the ticket). That is, the system may favour those who actually turn up at events regardless of how they obtained a ticket, and penalise those who don't.

The anti-touting metric UD in already published versions of the buyer's uPass profile 42i in the uPass system 40 may not modified - in some cases only the underlying master profile 34B is modified, which can of course effect future publications of that uPass profile 42ii.

All of the various functional modules described above and shown in the figures are implemented as code 4 executed on the processor(s) 2. A uPass implementation of the digital identity system 40 is just one example. In other embodiments, the digital identity could for example be implemented as a single sign-on system. As an example, the digital identity system 40 could be Google+. Examples of other suitable profile-based digital identity system technologies that could be used include: Jumio; CallSign; MiiCard; VerifyMe; Facebanx; ldentity.com; ThislsMe and RealMe. In this respect, products in this field include IDScan,

Paycasso TrustID, Aul Otix, ldology,and IdChecker

Note a ticket is just one example of an asset that can be tracked using the system 20 of the present disclosure, and all of the disclosure pertaining to tickets applies more generally to any other type of asset. Examples of assets include:

• hospital beds, which can be tracked from (say) ward-to-ward, room-to-room, hospital-to-hospital etc.;

• computers, photocopiers or other equipment, tracked from office-to-office, building-to-building, floor-to-floor, person-to-person, company-to-company etc.

• patient records. For example separate profile chains may be maintained for diagnosticians, patients, attending physicians etc. e.g. to identify the entity that identifies a condition, the entity that has the condition, and the entity that treats the condition. In this case an asset transfer is a transfer of patient between responsible entities;

• shares e.g. share certificates;

• contracts;

• RF (radio frequency) or other electronic tags, such as an NFC (near field

communication) tag, in which an identifier is embedded and accessible via RF. For example, a tag that can be affixed to a phone, tablet, keys or other object. This could, for example, be a "lost and found" tag, where a person finding a lost object with the tag can scan the tag to make that known to the asset tracking system. Alternatively, a non-electronic lost-and-found tag could include a QR code encoding the identifier.

Note: hereinabove, a number of hash functions are applied to concatenations 51 || S2 of bit strings e.g. H(51 || S2). More generally, a hash function can be applied to any suitable function of the strings ^" (51, 52) that retains sufficient information unique to each string, e.g. H( ^"(51, 52)) .

In the following, the term "initial profile" can be any profile in the chain with which at least one new profile is subsequently associated, and in general is not limited to, say, the first profile in a chain or the very first owner (though neither is excluded). A) The uPass System:

Summary of the uPass System:

According to a first aspect a digital identity system for creating a computer stored digital identity comprises: a network interface configured to send and receive electronic messages; persistent electronic storage; a profile management module configured to receive from an entity an electronic message comprising a data item, extract the data item from the electronic message and store the data item in a digital profile in the persistent electronic storage; a credential creation module configured to generate a credential for the profile and associate the credential with the digital profile; a publication module configured to publish the profile by storing a version of it to an addressable memory location; and a receipt generation module configured to automatically generate two non-matching receipts, each receipt comprising a transaction identifier, a first of the receipts comprising a link identifying the memory location to which the profile is published, a second of the receipts comprising the credential, wherein the first receipt is stored at the digital identity system and the second receipt is transmitted to an address associated with the entity. A

corresponding method is also provided.

The profile creation mechanism of the uPass system provides both a receipt for internal auditing by the digital identity system, and a credential for later use by the user.

Once created, the profile can be used by the entity to assert their identity to another entity (validator) in place of a real-word identity document. The other entity is able to access the published profile to ascertain the entity's relevant details from the data item and any other data items in the profile.

Preferably, presentation of the credential to the digital identity system by a

presenting entity makes the published profile available to a presenting entity (in embodiments this may in fact trigger the publication). Thus the entity can provide their credential to the presenting entity as a way to assert their identity, as embodied in the profile, to the presenting entity. That is, the digital credential can be used as a substitute for a real-world identity document. The data item may for instance be a visual image of the entity. For a human entity, this may be a photo of their face which captured from, or which is known to match, an identification photograph from a real-world identification document such as a passport or driving licence. This may be captured using a camera and/or wireless (NFC, Bluetooth etc.) technology if a suitable electronic chip is embedded in the document. The other entity can verify that the user is who they say they are by visually comparing the user's actual face with that in the published profile. Other data items such the user's name, data of birth, nationality etc. from the identity document may also be received and stored in the profile. Multiple profiles may be created for a user, which may be unique but nonetheless share some data items. For example, a basic profile may have only one data item (e.g. photo), and additional profile(s) may have the photo plus varying degrees of addition user data (name, name and date of birth, name and date of birth and nationality etc.).

By publishing version of the profiles rather than permitting direct access to the profiles, security of the profiles is preserved as the underlying profiles themselves are never visible outside of the digital identity system.

A receipt may be generated every time a transaction involving the profile takes place. Such receipts provide an audit trail, whereby historic activity by the entity is visible within the system. For example, the receipts can be used to isolate historic fraudulent activity by a human entity (user). Where the data item is a visual image of the user's face, this makes it easy to unequivocally link such activity back to an actual human. Preferably the profile is republished at every transaction to provide a "snapshot" of the profile as it was at that time, which is unaffected by future modifications. This ensures an accurate audit trail, whereby activity at any previous point in time can be accurately isolated. Preferably, the profile is published upon presentation of the credential to the digital identity system e.g. by the validator so that the profile only becomes accessible to the validator when they present the credential. For the purposes of auditing, a master receipt comprising data of each receipt may in embodiments be generated and stored in a master receipt book at the digital identity system. That is, both the first and the master receipt may be stored separately at the digital identity system. The master receipt may comprise only part of the first receipt, for instance the link, but not the credential.

In certain embodiments, however, it may comprise a hash (e.g. HMAC) of the credential. That is, a value generated by applying a cryptographic hash (e.g. HMAC) function to the credential. The hash function is irreversible, in that it is impossible to recover the credential itself from the hash of the credential. However, if the original credential is made available to the system later by the user, the hash can be recomputed from the available credential, and the resulting value can be used to locate the master receipt. This can allow, for example, lawful interception of receipts without comprising their security. At least part of the master receipt (at least the link) and/or the published version of profile may be encrypted with the transaction identifier, in which case the master does not include the transaction identifier. That is, the transaction identifier may be used as a cryptographic key to encrypt the link and/or the published profile itself. This means that the published profile can only be accessed by the holder of the receipt comprising the transaction identifier, and cannot be accessed using the master receipt alone.

Preferably the credential is a randomised one-time only use credential, which can only be used to effect a single transaction and becomes invalid thereafter. This links the credential to the creation of the profile specifically. Similar one-time use credentials will then be needed any time the entity subsequently accesses and/or modifies the profile, and or creates a new profile, so that every credentials are linked to one specific transaction. Preferably, metadata available to a computer device sending the electronic message is included in the message. The metadata may be metadata of the device itself, e.g. a device identifier (ID) such as a serial number or MAC address of the device, or it may be related metadata such as (geo)location (e.g. GPS) data identifying a

(geo)location of the device when the message was sent. The metadata can be used to generate the credential, for example as a hash of the metadata and a random sequence (seed). This may result in a credential having a large bit size, thus a significant memory saving results from storing the "ingredients" used to create the credential at the digital identity system rather than the credential itself. A copy of the credential can then be created as and when it is needed, for instance to determine whether a credential presented to the system matches the original (access to the published profile may only be granted if this is the case). The seed and metadata may be hashed a random number of times, and the stored ingredients then include this random number as well.

Where the metadata comprises a device ID to the profile may only be granted if the credential is presented along with a matching device ID. Thus, use of the credential is restricted to that device for added security (if the user wishes to use multiple devices to assert their identify, they can request a separate credential for each device, each credential bound to the profile).

The profile may also have a confidence value allocated to it, which is indicative of the confidence the system has that the entity does indeed have the identity which they are asserting. The confidence value is preferably made available with the published profile, for instance it may be included in and published with the profile itself to the same memory location. Thus, the validator is not simply told that the entity is who or what they say they are, but is told how confident the digital identity system that that is the case. The confidence value may be an easily interpretable metric such as a value between 0 and 1 (or 0% and 100%), 0(%) representing complete uncertainty and 1 (00%) representing total certainty, though the latter is unlikely in practice. The confidence value may change over time. For instance as the user uploads more data items e.g. photos of their face ("selfies") which may in some embodiments be required to log in to the digital identity system and stored at the digital identity system each time this may assert a positive influence on the confidence value causing it to (at least in the absence of other influences) increase, provided the photos do indeed match (whereas photos for which the match is questionable may have the opposite effect). Similarly, as the entity completes additional transaction this may exert a similarly positive influence. Conversely, where the data item(s) in the digital profile are captures from, say, a real-world identify document, as the document ages this may assert a negative influence on the confidence value causing it to (at least in the absence of other influences) decrease. Many such influences may be aggregated, whereby the confidence value reflects an overall confidence. For capturing the relevant data, a second aspect provides a method of registering a digital identity comprising: capturing at a computer device a data item associated with an entity; creating an electronic message comprising the data item; transmitting the electronic message to a registration service; receiving a receipt from the registration service; extracting a credential from the receipt to render the credential available for accessing the data item for authenticating the entity; and storing the receipt in a local receipt book at a location accessible to the computer device.

In the case that the relevant data is captured from an identity document, a third aspect provides a method implemented by executing digital identity software on a processor of a user device (for example a smart device such as a smartphone or tablet) to: capture with a camera of the user device an image of the face of a user of the device; capture data from a real-world identity document (such as a driving licence or passport), the data including an identification photograph, wherein the data is captured with the camera, from an electronic transmitter embedded in the anchoring document, or a combination of both; transmit the image of the user and the captured data to a digital identify system; and receive from the digital identify system a credential for the user, wherein presentation of the credential to the digital identity system renders at least part of the captured data available to a presenting entity.

The captured data also comprises an attribute of the document, for example enough data to be able to ascertain with reasonable certainty a type of the document (e.g. driving licence, passport etc.) and possibly to be able to determine whether or not the document seems authentic. At the system side, a fourth aspect provides a computer implemented method implemented by a digital identity system, the method comprising: receiving in an electronic message from a user device: an image of the face of a user of the user device which has been captured at the user device; and data which has been captured from a real-world identity document and which comprises an identification photograph; storing at least part of the captured data at the digital identity system in persistent electronic storage; comparing the image of the face with the identity photograph using a facial verification algorithm; only if the image of the face matches the identification photograph, generating a credential for the user and transmitting the credential to the user, wherein presentation of the credential to the digital identity system renders at least part of the stored data available to a presenting entity. Using facial verification in this manner ensures users can only use their own identity documents as a basis for a digital identity within the system. The image of their face and/or the photograph captured from the identity document is presented to the presenting entity, which is particularly applicable when one human is identifying themselves to another human in the real-world.

Where an attribute of the document is also received, generation and transmission of the credential may only take place if the attribute matches some predetermined criteria. For example, for a passport, the attribute may be characters captured from a machine readable zone (MRZ) and the condition may be that these have a valid format.

According to various aspects of the uPass system, an identity is instead asserted using a digital profile. A profile may for instance be created from data captured from a real-world identity document such as a passport or driving licence, which preferably comprises an identification photograph form the document. Once created, the profile can be used by the entity to assert their identity to another entity

(validator). In another aspect, a method of authenticating a digital credential of a bearer by a validating device comprises: capturing the bearer credential by the validating device; transmitting to a validation service the bearer credential with a validator credential bound to the validating device; at the validation service, validating the bearer credential and the validation credential, and if the validator credential is valid, using the bearer credential to access a data item of a digital profile and creating an electronic message for transmission to the validating device, the electronic message indicating the data item and comprising a fresh validator credential generated by the validation service; issuing a fresh bearer credential and creating an electronic message to transmit the fresh bearer credential to an address associated with the bearer.

Preferably the method also comprises the step of using the validator credential to access a data item of a digital profile associated with the validating device and creating an electronic message for transmission to the bearer, the electronic message indicating a data item for verification by the bearer. In this manner, a single transaction provides two-way authentication - not only is the validator able to authenticate the bearer using the data item from the bearer's profile, but the bearer is able to likewise validate the validator. Thus a single transaction tells both entities whether or not they should believe that the other is who or what they assert they are. This arises from the novel combination of the validator presenting both their own and the bearer's credential together, and each entity getting back a respective data item for the other entity. The data item relating to the validator is sent to the bearer by out of band signalling, for instance to a device having an address associated with the bearer credential in the digital identity system.

In another aspect a method of providing access to digital profiles held in persistent electronic storage of a digital identity system comprises: receiving from a requesting entity an electronic request message identifying a target entity; in response to the request, publishing: (i) a digital profile of the target entity by storing a version of that profile in an addressable memory location, and (ii) a digital profile of the requesting entity by storing a version of that profile in another addressable memory location; generating two non-matching receipts, each comprising a transaction identifier, a first of which comprises a link identifying the memory location to which the target entity's profile is published, the second of which comprises a link identifying the other memory location to which the requesting entity's profile is published; transmitting the first receipt to an address associated with the requesting entity; and transmitting the second receipt to an address associated with the target entity.

Each entity can validate the other based on the relevant published profile in a single transaction.

By publishing a version of the profile rather than permitting direct access to the profile, security of the profile is preserved as the underlying profile itself is never visible outside of the digital identity system.

A link, such as a Uniform Resource Indicator (URI), identifying the addressable memory location may be transmitted to the presenting device.

The link may be generated from a random sequence and/or the addressable memory location may be selected based on a random sequence. Random generation of links/selection of memory addresses ensures efficient use of the memory address/link space.

The data item may for instance be a visual image of the entity. For a human entity, this may be a photo of their face which captured from, or which is known to match, an identification photograph from a real-world identification document such as a passport or driving licence. This may be captured using a camera and/or wireless (NFC, Bluetooth etc.) technology if a suitable electronic chip is embedded in the document. The other entity can verify that the user is who they say they are by visually comparing the user's actual face with that in the published profile. Other data items such the user's name, data of birth, nationality etc. from the identity document may also be received and stored in the profile. Multiple profiles may be created for a user, which may be unique but nonetheless share some data items. For example, a basic profile may have only one data item (e.g. photo), and additional profile(s) may have the photo plus varying degrees of addition user data (name, name and date of birth, name and date of birth and nationality etc.). Preferably, metadata available to a computer device sending the electronic message is included in the message. The metadata may be metadata of the device itself, e.g. a device identifier (ID) such as a serial number or MAC address of the device, or it may be related metadata such as (geo)location (e.g. GPS) data identifying a

Where the metadata comprises a device ID to the profile may only be granted if the credential is presented along with a matching device ID. Thus, use of the credential is restricted to that device for added security (if the user wishes to use multiple devices to assert their identity, they can request a separate credential for each device, each credential bound to the profile).

A receipt may be generated every time a transaction involving the profile takes place. Such receipts provide an audit trail, whereby historic activity by the entity is visible within the system. For example, the receipts can be used to isolate historic fraudulent activity by a human entity (user). Where the data item is a visual image of the user's face, this makes it easy to unequivocally link such activity back to an actual human. Preferably the profile is republished at every transaction to provide a "snapshot" of the profile as it was at that time, which is unaffected by future modifications. This ensures an accurate audit trail, whereby activity at any previous point in time can be accurately isolated.

Preferably, the profile is published upon presentation of the credential to the digital identity system e.g. by the validator so that the profile only becomes accessible to the validator when they present the credential. For the purposes of auditing, a master receipt comprising data of each receipt may in embodiments be generated and stored in a master receipt book at the digital identity system. That is, both the first and the master receipt may be stored separately at the digital identity system. The master receipt may comprise only part of the first receipt, for instance the link and the transaction identifier, but not the credential.

Preferably each credential is a randomised one-time only use credential, which can only be used to effect a single transaction and becomes invalid thereafter. This links the credential to the creation of a profile specifically. Similar one-time use

credentials will then be needed any time the entity subsequently accesses and/or modifies the profile, and or creates a new profile, so that every credentials are linked to one specific transaction. The profile may also have a confidence value allocated to it, which is indicative of the confidence the system has that the entity does indeed have the identity which they are asserting. The confidence value is preferably made available with the published profile, for instance it may be included in and published with the profile itself to the same memory location. Thus, the validator is not simply told that the entity is who or what they say they are, but is told how confident the digital identity system that that is the case. The confidence value may be an easily interpretable metric such as a value between 0 and 1 (or 0% and 100%), 0(%) representing complete uncertainty and 1 (00%) representing total certainty, though the latter is unlikely in practice. The confidence value may change over time. For instance as the user uploads more data items e.g. photos of their face ("selfies") which may in some embodiments be required to log in to the digital identity system and stored at the digital identity system each time this may assert a positive influence on the confidence value causing it to (at least in the absence of other influences) increase, provided the photos do indeed match (whereas photos for which the match is questionable may have the opposite effect). Similarly, as the entity completes additional transaction this may exert a similarly positive influence. Conversely, where the data item(s) in the digital profile are captures from, say, a real-world identify document, as the document ages this may assert a negative influence on the confidence value causing it to (at least in the absence of other influences) decrease. Many such influences may be aggregated, whereby the confidence value reflects an overall confidence.

In another aspect a digital identity system comprises: an enrolment module configured to receive a data item from an enrolling device and to create in persistent electronic storage a digital profile comprising the data item; a credential creation module configured to generate a credential from a random sequence, to associate the credential with the digital profile in a database, and to transmit the credential to the enrolling device; a publication module configured, in response to later

presentation of the credential to the digital identity system, to publish the digital profile by storing a version of the digital profile in a memory location accessible to a device presenting the credential.

An entity (which may be a user of the enrolling device or the enrolling device itself) can provide their credential a presenting entity (e.g. the presenting device or user thereof) as a way to assert their identity, as embodied in the profile, to the presenting entity. That is, the digital credential and profile can be used as a substitute for a real- world identity document. By publishing a version of the profile rather than permitting direct access to the profile, security of the profile is preserved as the underlying profile itself is never visible outside of the digital identity system.

The link is generated from a random sequence and/or the addressable memory location is selected based on a random sequence. Random generation of links/selection of memory addresses ensures efficient use of the memory

address/link space.

The data item may for instance be a visual image of the entity. For a human entity, this may be a photo of their face which captured from, or which is known to match, an identification photograph from a real-world identification document such as a passport or driving licence. This may be captured using a camera and/or wireless (NFC, Bluetooth etc.) technology if a suitable electronic chip is embedded in the document. The other entity can verify that the user is who they say they are by visually comparing the user's actual face with that in the published profile. Other data items such the user's name, data of birth, nationality etc. from the identity document may also be received and stored in the profile. Multiple profiles may be created for a user, which may be unique but nonetheless share some data items. For example, a basic profile may have only one data item (e.g. photo), and additional profile(s) may have the photo plus varying degrees of addition user data (name, name and date of birth, name and date of birth and nationality etc.).

Preferably, metadata available to a computer device sending the electronic message is included in the message. The metadata may be metadata of the device itself, e.g. a device identifier (ID) such as a serial number or MAC address of the device, or it may be related metadata such as (geo)location (e.g. GPS) data identifying a

Preferably, the profile is published upon presentation of the credential to the digital identity system e.g. by the validator so that the profile only becomes accessible to the validator when they present the credential.

For the purposes of auditing, a master receipt comprising data of each receipt may in embodiments be generated and stored in a master receipt book at the digital identity system. That is, both the first and the master receipt may be stored separately at the digital identity system. The master receipt may comprise only part of the first receipt, for instance the link and the transaction identifier, but not the credential.

Preferably the credential is a randomised one-time only use credential, which can only be used to effect a single transaction and becomes invalid thereafter. This links the credential to the creation of the profile specifically. Similar one-time use credentials will then be needed any time the entity subsequently accesses and/or modifies the profile, and or creates a new profile, so that every credentials are linked to one specific transaction.

In another aspect, a method of providing access to a digital profile comprises receiving a one-time only use credential associated with a digital profile in persistent electronic storage; validating the credential and, only if the credential is valid, publishing the profile to an addressable memory location by storing a version of it at the memory location, thereby invalidating the credential; generating a fresh one-time only use credential for the digital profile; associating the fresh credential with the digital profile; and transmitting the fresh credential to an address associated with an entity, whereby the entity can use the fresh credential once thereafter to cause the profile to be republished to a different addressable memory location. In accordance with this other aspect, every time a current credential is presented, a new version of the profile is published and a fresh credential created. The profile may also have a confidence value allocated to it, which is indicative of the confidence the system has that the entity does indeed have the identity which they are asserting. The confidence value is preferably made available with the published profile, for instance it may be included in and published with the profile itself to the same memory location. Thus, the validator is not simply told that the entity is who or what they say they are, but is told how confident the digital identity system that that is the case. The confidence value may be an easily interpretable metric such as a value between 0 and 1 (or 0% and 100%), 0(%) representing complete uncertainty and 1 (00%) representing total certainty, though the latter is unlikely in practice. The confidence value may change over time. For instance as the user uploads more data items e.g. photos of their face ("selfies") which may in some embodiments be required to log in to the digital identity system and stored at the digital identity system each time this may assert a positive influence on the confidence value causing it to (at least in the absence of other influences) increase, provided the photos do indeed match (whereas photos for which the match is questionable may have the opposite effect). Similarly, as the entity completes additional transaction this may exert a similarly positive influence. Conversely, where the data item(s) in the digital profile are captures from, say, a real-world identify document, as the document ages this may assert a negative influence on the confidence value causing it to (at least in the absence of other influences) decrease. Many such influences may be aggregated, whereby the confidence value reflects an overall confidence.

According to various aspects of the uPass system, an identity is instead asserted using a digital profile. A profile may for instance be created from data captured from a real-world identity document such as a passport or driving licence, which preferably comprises an identification photograph from the document. Once created, the profile can be used by the entity to assert their identity to a presenting entity (validator). The entity can provide the credential to the presenting entity who presents it to a digital identity computer system. Not only is the profile made available to the validator, but a confidence value associated with the profile is presented alongside.

According to another aspect a computer system comprises: electronic storage; a network interface configured to receive electronic messages; and a processor configured to execute identity management code which operates to:

receive an electronic message from the network interface, the message including at least one data item to be included in a digital profile for an entity, the data item associated with the entity an uniquely identifying the entity; extract the data item from the electronic message;

create a digital profile using the data item in the electronic storage, wherein the profile comprises the data item;

allocate a confidence value to the profile, wherein the confidence value is allocated based on at least one of a source of the electronic message and a type of the data item; and

create and transmit a credential to the entity, wherein presentation of the credential to the computer system renders a version of the digital profile and the confidence value available to a presenting entity. The confidence value is indicative of the confidence the system has that the entity, e.g. a human or a device, does indeed have the identity which they are asserting. Thus, the validator is not simply told that the entity is who or what they say they are, but is told how confident the digital identity system that that is the case. The confidence value may be an easily interpretable metric such as a value between 0 and 1 (or 0% and 100%), 0(%) representing complete uncertainty and 1 (00%) representing total certainty, though the latter is unlikely in practice.

The data item may be a visual image of the entity, which may be a user. For example, two visual images of the user may be included in the message: the first an identification photo captured from a real-world identity document; the second a photo of the user's face which they have taken with a camera ("selfie"). Facial recognition may be used to determine how close a match the two data items are, and the confidence value allocated based on the comparison to reflect this. The presenting entity is thus told the extent to which the user's faces matches whatever form of identity document hey have used to create the profile.

The confidence value may change over time. For instance as the user uploads more data items e.g. selfies, which may in some embodiments be required to log in to the digital identity system and stored at the digital identity system each time, this may assert a positive influence on the confidence value causing it to (at least in the absence of other influences) increase, provided the photos do indeed match

(whereas photos for which the match is questionable may have the opposite effect). Similarly, as the entity completes additional transaction this may exert a similarly positive influence. Conversely, where the data item(s) in the digital profile are captured from, say, a real-world identify document, as the document ages this may assert a negative influence on the confidence value causing it to (at least in the absence of other influences) decrease. Many such influences may be aggregated, whereby the confidence value reflects an overall confidence.

Corresponding methods are provided, which are computer-implemented. A computer program product comprising code stored on a computer readable storage medium configured to implement any method or system disclosed herein is also provided.

A version of the profile may be published to render it available. By publishing a version of the profile rather than permitting direct access to the profile, security of the profile is preserved as the underlying profile itself is never visible outside of the digital identity system.

A link, such as a Uniform Resource Indicator (URI), identifying the addressable memory location may be transmitted to the presenting device. The link is generated from a random sequence and/or the addressable memory location is selected based on a random sequence. Random generation of links/selection of memory addresses ensures efficient use of the memory

address/link space. The data item may for instance be a visual image of the entity. For a human entity, this may be a photo of their face which captured from, or which is known to match, an identification photograph from a real-world identification document such as a passport or driving licence. This may be captured using a camera and/or wireless (NFC, Bluetooth etc.) technology if a suitable electronic chip is embedded in the document. The other entity can verify that the user is who they say they are by visually comparing the user's actual face with that in the published profile. Other data items such the user's name, data of birth, nationality etc. from the identity document may also be received and stored in the profile. Multiple profiles may be created for a user, which may be unique but nonetheless share some data items. For example, a basic profile may have only one data item (e.g. photo), and additional profile(s) may have the photo plus varying degrees of addition user data (name, name and date of birth, name and date of birth and nationality etc.). Preferably, metadata available to a computer device sending the electronic message is included in the message. The metadata may be metadata of the device itself, e.g. a device identifier (ID) such as a serial number or MAC address of the device, or it may be related metadata such as (geo)location (e.g. GPS) data identifying a

(geo)location of the device when the message was sent. The metadata can be used to generate the credential, for example as a hash of the metadata and a random sequence (seed). This may result in a credential having a large bit size, thus a significant memory saving results from storing the "ingredients" used to create the credential at the digital identity system rather than the credential itself. A copy of the credential can then be created as and when it is needed, for instance to determine whether a credential presented to the system matches the original (access to the published profile may only be granted if this is the case). The seed and metadata may be hashed a random number of times, and the stored ingredients then include this random number as well. Where the metadata comprises a device ID to the profile may only be granted if the credential is presented along with a matching device ID. Thus, use of the credential is restricted to that device for added security (if the user wishes to use multiple devices to assert their identity, they can request a separate credential for each device, each credential bound to the profile). A receipt may be generated every time a transaction involving the profile takes place. Such receipts provide an audit trail, whereby historic activity by the entity is visible within the system. For example, the receipts can be used to isolate historic fraudulent activity by a human entity (user). Where the data item is a visual image of the user's face, this makes it easy to unequivocally link such activity back to an actual human. Preferably the profile is republished at every transaction to provide a "snapshot" of the profile as it was at that time, which is unaffected by future modifications. This ensures an accurate audit trail, whereby activity at any previous point in time can be accurately isolated.

A computer program product comprising code stored on a computer readable storage medium configured to implement any method or system disclosed herein is also provided. For a better understanding of the uPass system and to show how the same may be carried into effect, reference will now be made by way of example to the accompanying drawings in which:

Figure A1 is a schematic diagram of the core elements of a digital identity system; Figure A1 a is schematic block diagram of the principal components of a digital identity system;

Figure A2 is an expanded schematic diagram of functional components of a digital identity system;

Figure A3a is a schematic block diagram of data items stored as part of a digital identity system;

Figure A3b is a block diagram of a database structure for a digital identity system; Figure A3c shows a master receipt book of a digital identity system;

Figure A4a is a schematic flow diagram illustrating the creation of credentials in a digital identity system;

Figure A4b is a flow diagram showing the flow conducted at a smartphone and registration service of the creation of credentials in a digital identity system;

Figure A5 illustrates standardised passport information;

Figure A6 is a schematic flow diagram showing an authentication process;

Figure A6a is a flow diagram for an authentication process;

Figure A6b shows details of receipts generated during an authentication process;

Figure A6c shows details of a master receipt generated during an authentication process;

Figure A6d schematically illustrates certain relationships between various receipts and master receipts that arise due to their content;

Figure A7 is a schematic flow diagram showing an authentication process for a web service;

Figures A8a (flow chart) and A8b (signalling diagram) describe a situation where a person registered with a digital identity system wishes to have a profile assigned to them by a third party;

Figures A9a (flow chart) and A9b (signalling diagram) show a case where a person not registered with a digital identity system wishes to have a profile assigned to them by a third party;

Figure A10 shows a block diagram of a user device;

Figure A1 1 A exemplifies how a digital identity may be created; Figures A1 1 B to A1 1 H exemplify use cases of a digital profile.

Description of the uPass System The following description discloses an identity registration and authentication system referred to as an uPass system.

As a basic premise, a user of the uPass system is able to upload and register copies of their identity documents and in return they receive an anchored digital ID which can be used to verify their identity to third parties without needing to present these identity documents. They are also able to specify the nature and quantity of personal information which will be made available when doing this.

Use cases for when an identity is to be registered or verified are assumed to be strongly associated with the use of mobile devices such as smartphones and tablets although the uPass system is not restricted to these devices. Further, registration is described which is based on identity documents which are designed to be scanned electronically, either with OCR-friendly text or with NFC-compatible embedded chips, by way of non-limiting example. It will be evident from the following that any kind of data items pertaining to identity may be utilised, and entered into the system in any appropriate manner.

Figure A1 a is a schematic block diagram of the principle components of a digital identity system.

A central service (uPass) A14 stores credentials securely and manages validations. The central service can be implemented in any suitable way and requires at least one processor A1 14 executing identity management code, and electronic storage components providing secure storage. There can be multiple processors in a distributed micro processing network, or a central processing unit at a single or multiple servers. The electronic storage components can take any form and may be local or remote memory. As will be evident, the electronic storage provides both secure storage and random access writable storage 35. A first mobile application A22 is provided for hosting on a mobile device A12. The first mobile application is for scanning data items from an identity document and transmitting them to the central service A14. A second mobile application A50 is also provided for execution by a mobile device A12, the second mobile application for requesting a validation of credentials against the storage service A14. It will be appreciated that not all mobile devices necessarily have both applications A22 and A50. For example, some mobile devices may be equipped only to scan data items and transmit them to the central service A14 whereas other devices may be capable only of performing validation of credentials. It is likely however, that most mobile devices associated with uPass users will have both applications uploaded. The mobile applications (Apps) may be downloaded from a UPass server. A secure architecture is provided for communication between components of the system. This ensures that privacy is maintained, in particular when considering communications between mobile devices A12 associated with uPass users and the central service A14. A confidence framework 69 is provided for assessing the degree of confidence which can be placed in a identity profile registered at the central service A14. An automated mechanism A67 is provided for performing timely trust arbitration between users via proffered credentials (for example QR codes). Each component of the system will now be described in more detail in the following.

Figure A1 shows basic elements of an identity system in highly schematic form. There are two basic workflows, one relating to registration of user identity documents and the other to verification of identity (authentication). An electronic passport A10 or other identity document (e.g. driving licence) is read by a mobile device A12 (e.g. via NFC) and registration data is passed to the uPass service 14 in a secure manner via the Internet, as described later. The uPass service stores the registration of data in one or more profiles forming part of a digital identity A28. There are three elements in a mobile device which can be used for storage; an SD card A12a or similar removable store; the SIM-card A12b and, in some devices, an internal secure storage space A12c. Such a storage element can be used to store a credential 30 (e.g. a QR code) generated by the uPass system from a digital profile and returned to the mobile device A12.

The uPass service A14 is provided by a computer system with separate endpoints (14a, 14b) for registration and verification. Partitioning of the workflow in this manner gives confidence that a fault in the registration endpoint will not necessarily compromise the verification endpoint and vice versa. End points may be physically separate computers which can communicate via a network, or virtually separate domains at the same physical location. Figure A10 shows a block diagram of a user device A12 (e.g. a smart device such as a smartphone or tablet). The user device comprises a processor A1 104 executing digital identity software A1006, e.g. in the form of an application or "app" (uPass app/verification application), and to which is connected a camera A1 108, a wireless (e.g. NFC, Bluetooth) interface A1010 and a display A1002 for outputting visual information to a user of the device A12.

Qualification for a restricted activity One of the most common uses of photo ID is to confirm that a person meets the minimum legal age for a particular activity they wish to perform, such as entering a nightclub or purchasing alcohol. The uPass system is particularly well-suited to such a purpose as a client verification application A50 (see Figure A1 a) executing on a smartphone or tablet can be tailored both to answer the underlying query "is this person old enough" and to provide a photo confirmation that the person presenting credentials is in fact the person these credentials belong to. In the following description, the focus is on the precision of a photo. A number of use cases are discussed later. One example use case is of a music festival which chooses to offer ticket-less entry via uPass. In this scenario an attendee (bearer) offers their credential (the credential A30 they received from the registration process) on their mobile device and the venue operator (validator) checks this against the verification endpoint of the uPass service A14 to confirm that entry may be granted.

There are several ways in which the credential could be presented: a binary blob transferred by NFC; a barcode for scanning; an email address; or, some form of QR code. uPass Connect

Another use case of interest is that of authenticating login to a remote system via a local device which may lack an uPass application, removing the necessity to remember user names or passwords so long as an uPass device (such as mobile device 12) is available. In this scenario a validating device associated with an uPass scans a QR code displayed on the login form transmitted from the remote system to the local device and uses this to establish a user system. This technique can be used to establish that the owner of the uPass device is permitted to log-in, but can also allow that owner to be confident that any content they receive from the remote system carries from a valid source.

Figure A2 is a schematic block diagram of the architecture of an uPass system as functional blocks, illustrating the workflows in the system.

A registrant A20 uses an app A22 on their smartphone or tablet A12 to capture details from their passport A10 (e.g. via NFC and/or camera) and combines this with a photo 18 of themselves (a "selfie") captured with the same device to produce an electronic registration message A23. This is despatched securely to the registration endpoint 14a of the uPass system A14 which performs necessary processing (facial recognition/OCR) to extract relevant data and create an account for the registrant, as described later. Upon successful completion a confirmation message is returned to their device along with an authentication token (credential) creating a link to the new "published" uPass identity profile. Contingent trust

A feature of the uPass system is that a photo is provided as part of the "published" profile linked to the credential. However, the display of a photograph when a uPass credential is presented in a verification process only confirms that the registered user's claimed identity matches that of the person who registered the uPass in the first place, not that the registered identity is itself a valid and trustworthy record of the registrant's identity.

To address this an embodiment of the uPass system introduces the concept of contingent trust, whereby a user's identity profile has an associated profile confidence value "CV1 " n for 2,3,4 based upon the quality and source of identity documents associated with it, and its historic usage. The way this works in practice is that the multiple sources of identity data are allowed, and for each a level of trust is assigned. Responses can then be qualified where legally required.

For the purpose of explaining contingent trust, in the following, it is assumed that the identity document to be ingested is an electronic passport with the option of either an NFC interaction, an OCR-quality scan or both. In practice, the digital identity rests on primary information data items such as name, age, nationality and photograph to minimise compatibility issues.

The hierarchy of contingent trust identifies five natural levels of confidence based on the manner in which the registration data enters the system:

• presented in person to a trusted agent who confirms that it matches the presenting party;

• a trusted mobile application with additional safeguards;

• a trusted website;

· submitted via registered post;

• no registration documents The first case sets a maximum confidence level for contingent trust. The exact value assigned can be determined by statistical analysis of the risks involved, but as a rule of thumb should be no higher than 95 per cent (no data should ever be considered incontrovertible). The exact number can vary depending upon the trusted agent concerned.

An uPass can become trustworthy as a result of manual verification in this manner. So "trust" is just a fixed value based on initial registration but can vary as a set of propositions regarding the registration process for each of the multiple anchoring documents.

Additional checks can be applied to improve the standing (confidence value) of an uPass such as:

• endorsements by existing uPass users;

· NFC data reads in a trusted environment;

• random solicitation of document presentation to a trusted agent;

• random direct contact via video call to confirm uPass registrant still has registration documents

Confidence of the face verification changes with time. When users sign up they do so with their face and a passport. At this point in time there may be a very low confidence that they are who they say they are (though this depends on any anchoring document(s) they provide). Thereafter, image data is captured with every face login. Every time another selfie is captured it is added to an image database. These selfies are combined into a single Face Identification Record. The key here is that they are captured over time in a variety of different lighting conditions (because they are captured on a phone or other smart device) - and when combined provide more accurate results. In embodiments, the current facial record (which could be made up of a number of the most recent selfies, e.g. a small number such as 5) with the original passport photo captured at sign up. Note that instead of full facial images data, image data may be extracted, such as a local binary pattern (LBP) or facial template.

Where a trusted anchoring document such as a passport is used at sign up, the confidence value is reasonably high but can still grow over time in this manner. Confidence of the whole system also grows over time, due to other factors such as peer to peer verification. An important feature of the present system lies in the following combination of trust anchors:

a) phone;

b) selfie;

d) peer to peer validation.

A given confidence value is represented as a fixed point variable, to which a (variable) value between e.g. 0 and 1 (0% and 100%) is assigned.

User profiles and privacy

A registrant is providing personal identifying data items to allow an uPass credential to assert their identity at a later date. By its very nature this identifying data is confidential and the uPass system provides means by which it can be handled with the level of privacy which an uPass user will consider appropriate to the circumstances in which it is being used. To facilitate this an individual uPass (digital identity) has a number of profiles associated with it.

Reference will now be made to Figure A3a to explain the nature of an "uPass" or in other words a digital identity which is created for a user and which can be verified. Figure A3a shows diagrammatically the components which make up an uPass for a person A20. These components are stored in electronic storage of a suitable kind in the uPass system. For example, each user A20 can be associated with a database or part of a database attached to a unique identifier A26 which identifies components of the uPass for that person. For example, the electronic storage can take the form of a secure store as denoted by reference numeral A24 in Figure A2. Thus, each person A20 is associated with a unique identifier A26 which is associated with all components of the uPass for the user A20. The digital identity comprises a set of digital profiles A28a, A28b, A28c, A28d. Each profile comprises one or more key value pair, where the key identifies the nature of a data item which is stored in the profile, and the value identifies the data item itself. For example, the key may be "photo", and the value would be a photograph of the user. In fact, the value may be an address where a photograph is stored as a separate component of the uPass (see A18, A18'). Although shown schematically as individual blocks, the profiles can be constructed from linked lists of key/value pairs and confidence values, with each item in a list pointing to its ancestor. Each time a profile is "published" (described later), a new "head" of the list is created, incorporating modifications arising from use of the profile.

Another component of the uPass are the one or more anchoring documents which have been utilised to provide data items for the profiles. An example of an anchoring document is the passport A10. Multiple different anchoring documents may be stored.

As mentioned above, on successful registration, a confirmation message A25 is despatched from the registration service to the app on the smartphone including a credential. Each time a data item is added to a profile, or an uPass profile is utilised, a new credential is created for that profile and transmitted to the owner of the profile. These credentials are stored in association with the identifier A26 in the uPass for the person A20, and are bound to a profile. A new credential is one modification arising from "publishing" a profile... As the credentials are used for "unlocking" the profiles, they are shown as keys A30. In practice, each credential is a unique random digital string which keys into a database, described later with reference to Figure A3b.

Each user A20 is associated with one or more smart devices (such as a smartphone or a tablet), shown as A12 and A12a. Metadata about these devices is stored as part of the uPass for the user. Each time a transaction is conducted using an uPass, a pair of receipts is issued. This will be described in more detail later, but suffice it to say that an audit trail of receipts is stored in a local receipt book A31 e as part of a user's uPass. These receipts are illustrated diagrammatically by reference numeral A32e. Each enrolled device A12a, A12b has its own local receipt book on the device or on a remote server accessible to the device. A global master receipt book A32 (figure A3C) holds master receipts A31 , which relate to (individual) receipts A32e in the manner described below. Individual receipts issued to an entity which is a bearer or validator are labelled A32v and A32e herein respectively. As part of the authentication procedure which will be described later, when a valid credential is presented to the uPass system A14, a profile will be published according to the nature of the credential which is presented. These published profiles are shown under reference numeral A34, and are illustrated diagrammatically with keyholes which represent that a key corresponding to a credential can be utilised to unlock these profiles for publication. A profile is published by being made accessible in an addressable storage location in a memory A35 (e.g. a cache) having an address bound to the credential. A generated credential can be stored at the uPass system, which is appropriate if it is entirely random. The stored credential is compared against a presented credential, and the profile to which the credential is bound unlocked only if the stored credential matched the presented credential. However, when the credential is generated using certain "ingredients" (such as a random sequence, random number and device metadata, such as a device identifier), it is generally more efficient to store the ingredients instead as these generally have a lower bit-size than the credential itself. The ingredients can be used to generate a copy of the credential for such comparison. For example, the credential can be generated by hashing a random seed and device metadata (e.g. which is or comprises a device identifier) a random number of times - the uPass system can store the metadata, seed and random number to create another copy later.

At the time of registration three (or four) default profiles are created:

• an anonymous profile A28a which asserts uniqueness of identity and presents a photo for visual inspection;

• a photo ID profile A28b which also presents the name as listed on the registration document;

• a majority profile A28c which adds date of birth to the photo ID;

• (and an optional fourth) a nationality profile A28d which add nationality to the photo ID

Additional profiles can be created for the user which allow them to have additional personal information added or present their personal information in different ways. These profiles can be attached to them by any other user as a result of a valid uPass transaction. A profile solicitation application is used to allow for an uPass user to get another user to publish a profile on their behalf. No one can create a profile on their own behalf. Note in this respect that the uPass system comprises a controller A1 16 which acts as a third party to issue uPasses based on anchoring documents.

When new personal information is entered into a profile without the support of a registration document that profile is given the lowest level of contingent trust. For example, a third party could be an employer who enters data items into a profile solicitation application for an employee. A credential is created for the employee based on information provided by the employer, the credential is bound to the profile, and provided to the employee. To improve upon the level of contingent trust, the system allows for the uPass user to have the profile validated by other uPass users, creating a web of confidence which can be inspected. This occurs each time the owner of an uPass uses his credential in a validation procedure. The web of confidence for each profile is a social graph in which each node represents a confidence anchor. These are discussed later. The level of contingent trust placed in the document will be a function of the number and quality of validations the profile receives. Reference is made to Figures 8a and 8b to describe a situation where a person wishes to have a profile assigned to them by a third party. In the particular example which is given, the person is a new employee, and the third party is his employer. The new employee wishes to have a profile assigned to him by the employer. There are many other situations however where a person may wish to have a profile assigned by a third party. In the circumstance of Figures 8a and 8b, it is assumed that both the new employee NE and the employer E are already registered in the uPass system and have active credentials. In Step SA80, the new employee supplies his credential A30 NE to the employer. In Figure A8b, the new employee device is labelled A12NE, and the employer device is labelled A12E. In Step S82, the employer sends the new employee credential A30NE and his own credential A30E to the uPass registration service A14. In addition, the employer sends in that message a profile which he has created for the new employee. The uPass service checks that the new employee and employer credentials are valid, and if so, creates a profile for the new employee based on the information provided by the employer, and finds a new credential A30"NE to that profile. That new credential is then sent (Step S84) to the new employee device. The uPass service A14 also sends a replacement credential A30"E to the employer device, because the employer has now used up his one-time only valid credential when he sought to assign a profile for the new employee.

The profile is then stored in the uPass system (Step SA88). It will be appreciated that although shown in sequence, Step SA84, SA86 and SA88 can be carried out in any order or in parallel.

Figures 9a and 9b show the case where the new employee is not already registered with the uPass system. In this case, in Step SA90 the new employee makes a "real world" request to the employer "Can I have an uPass?" This could be done in person, by email or text, or in any way. The employer submits to the uPass registration service A14 a document which is going to be used to anchor a profile for new employee. In addition, the employee sends his credential A30E. In this case, it may be necessary to determine the authorisations attached to that credential, and to confirm that the employer has a credential which allows him to create uPasses for a third party. Note that this is one level higher in authorisations and assigning a profile to someone who already has an uPass. The assignation of a profile does not imply any particular validity to the uPass itself. However, creation of an uPass does imply a certain validity, although of course the confidence level which is attached to the uPass can be varied depending on the issuing anchor (in this case the employer). In Step SA92 the employer submits the document and his credential to the uPass registration service A14. The uPass service creates an uPass profile for the new employee, using the document as the issuing document and with a confidence level associated with the issuing anchor. A credential is bound to each profile associated with this uPass, and the credential associated with the anonymous profile is sent to the new employee as shown in Step SA96. If the new employee device has not been enrolled and is not known to the uPass, some appropriate arrangements are made to supply the credential A30" to the new employee device. In Step SA98 a replacement credential is issued to the employer. Figure A2 illustrates an account service A29 which provides a means of managing an uPass, including enrolment of devices and specification of user authorisation profiles.

Authorisation profiles

As outlined earlier, an uPass profile consists of personal data and a photograph which can be used together as a cohesive identity. Each uPass credential is anchored to a profile and an uPass user can have more than one credential active at any time. However, only one credential can be active at any specific time on any given device.

Each profile available for use with an uPass account must be assigned to it by a third- party Document Issuing Authority, of which the uPass system controller itself is an example. When an uPass account is created it has at least three profiles assigned to it by the uPass system:

1 . an anonymous profile A28a which can be used to assert identity but reveals no information;

2. a majority (age check) profile A28b which reveals the uPass user's date of birth;

3. a name profile A28c which reveals the uPass user's name as presented on their registration documents.

Whenever credentials are transmitted to a device they are always bound to a specific profile in the database in Figure A3b and the anonymous profile is the default profile for interactions unless otherwise specified by the uPass user.

To change profile credentials the uPass user must perform an enhanced authentication with their current credential against the uPass enrolment service to acquire a list of currently available profiles for their account. This does not need to be done for every change of profile as the information might be cached locally in an uPass application, so that the list only needs to be regenerated when new profiles are attached to the uPass account or the old profiles are removed. Once a list of profiles is available then changing between these profiles can be performed using a standard authentication with an existing credential, which is replaced with a new credential bound to the desired profile. All changes of profile result in security logging in the uPass system.

Profile structure

As shown in Figure A3a, a profile consists of a set of key value pairs. Either can be considered an arbitrary binary field. A set can be one or more key value pair.

Recognisable anonymity

The base on which all other profiles are constructed is the Anonymous Profile A28a which confirms that its bearer is an uPass user and provides as its data item a current photograph. When the profile is published to a third party, it allows the third party to confirm by visual inspection that the bearer of the uPass is indeed the person for whom it is valid. A profile is published in the validation procedure described later. The idea of querying an anonymous credential to ascertain identity may seem strange, however in an embodiment of the uPass system ,the system accompanies the assertion with a receipt allowing the validating party to indirectly and anonymously reference the uPass which has just been validated. Assigned profiles

The power of an uPass lies in the ability of its owner to present different views of their identity or rights in different circumstances. To avoid abuse, several restrictions can be imposed:

1 . profiles for any uPass account can only ever be created by third parties, noting that the uPass controller A1 16 is a third party in this respect;

2. when a profile is being created it must be created for a specific uPass account; 3. the assigned profile is bound to a specific profile in the creator's account (in this way, a creator's profile becomes a confidence anchor A1 10);

4. and is assigned a characteristic tag by the creator;

5. once created the profile cannot be edited;

6. however it can be deleted or replaced by its creator;

7. and when used the creator of the profile is always announced to the validator;

8. which allows the chain of trust right back to the uPass system to be interrogated.

The characteristic tag can be used to distinguish profiles from one another. For example, each tag could call a visual indicator to be displayed on the mobile device.

Profiles and privacy

Once a profile has been assigned to an uPass account the owner of that uPass account must actively choose to use the profile in a validation for it to be available to another user. That is, the credential created from that profile must cause a link to that profile to be sent to a validator. A user can have more than one profile, hence more than one credential, stored in the same or different devices, i.e. there is only one credential per device per person, [where there is more than one profile, a user can distinguish between them by the visual indicators of the characteristic tags.]

The creator of the profile may explicitly require the use of that profile when performing a validation, in which case if any other profile is used the validation will fail. This ensures that for as long as the assigned profile exists, the uPass user can only validate their identity with that profile and that use of any other profile will be rejected. This is described later in connection with uPass Connect.

There is no way for a third party to enumerate all the profiles associated with an uPass account.

Profile storage

Profile information lives in two places. The underlying data is versioned and retained in the secure store A24 whilst the current state of profile data is published in a secure key-value cache A35. This is an important underlying security premise of the Upass system - third parties are not given any access information to the secure store A24 itself. Profile publication

A profile contained in the secure store A24 is published (at a location in memory A35) whenever a credential is bound to it. The published profile has certain properties :

• expiry time (and/or publication time stamp);

· Photograph or a link to a photograph;

• Encrypted profile content (key/value pairs etc.);

• Random symmetric key;

• A URI resolving to the encrypted profile content;

• A URI resolving to the creator of the profile

Every time publication occurs the profile content is encrypted with a different randomly generated symmetric key A60, and then stored at a location in memory A35 accessible via a generated URI A62.

Vouchsafing

Each uPass account is capable of attaching profiles to other uPass accounts, allowing people to annotate each other with nicknames and other social information as well as vouching for the reliability of that information. As such each uPass itself is an example of a Document Issuing Authority with low confidence of reliability.

When an uPass user attaches a profile to another uPass user, the attachment is anchored against an existing profile (confidence anchor A1 10) on their own uPass account. Aside from attaching a profile to an uPass account, uPass users can vouch for the veracity of a profile attached to another account at the request of either the profile creator or the profile recipient. As the number of uPass users willing to vouch for an assigned profile increases, so too does the confidence which can be placed in the information contained in that profile.

Document issuing authorities

Vouchsafing provides a means by which uPass accounts can be annotated with profiles, however, these are potentially low-quality sources of gossip rather than anchored identity statement. An authorised Document Issuing Authority is a recognised source of high-quality identity information anchored to real-world documents.

Once an uPass user becomes a Document Issuing Authority they are allowed to solicit information from an uPass user and use this to annotate uPass accounts at a higher level of confidence than that afforded by the standard vouchsafe mechanism.

Lifecycle

Whilst uPass credentials are anchored by a passport A10 they can be caused to expire when the passport expires. This requires that uPass users be advised to update their registered documents as soon as their new passport is issued to ensure continuity of service.

An eight week notice period can be provided when the registered passport is due to expire to allow for the variable turnaround time.

When support is implemented for other identity documents the situation will become more complex. Each document will contribute to the contingent trust of the uPass and whilst this is above a certain level the uPass will remain active with regular warnings to the user regarding pending and actual document expiry.

Use

The initial scenario for uPass usage revolves around face-to-face encounters where a passport or equivalent document would be used to support identity. Whenever an uPass bearer wishes to authenticate their identity they must present a credential (e.g. a QR code) generated from a unique random identifier provided by the uPass system. The recipient of this credential is an uPass Validator who authenticates themselves to the uPass validation service each time they validate the information received from a Bearer. Following validation the Validator decides how to proceed.

Deletion uPass users may wish to delete particular profiles or their entire uPass identity and this is supported by the enrolment service. This involves the deletion of all personal data and device identifiers and the expiring of all issued keys.

There may be a legal requirement to maintain the auditing metadata associated with an uPass identity for a specified period of time, so deletion may involve a deferred component.

Suspension When an uPass user sees misuse they can report the offending user and a suspension of the account will be imposed whilst the matter is investigated. The uPass system can provide a 7-14 day uPass suspension. When suspended, an uPass should return that the uPass identity has been suspended. Suspension cannot occur without audited intervention and an investigation into the reasons for the suspension may be performed. Mechanisms and procedures for this are outside the scope of this document but should clearly be proportional and designed to minimise or prevent malicious suspension. Revocation

When there is the suspicion of serious misuse, an uPass may be revoked. Revocation is similar to deletion but there may be a need to record additional information about the user to prevent them from re-joining uPass within a set period of time. Expiry

At certain infrequent time periods (governed by expiration time 68) an uPass User may be asked to create a new uPass.

If all of the anchoring identity documents for an uPass user expire, this should automatically trigger a request to issue a new uPass. Multiple uPasses

Users may have more than one uPass account at a given time however the implementation of multiple profiles within an uPass should reduce the extent to which this occurs. For example a married woman who wishes to use an uPass in both her maiden name and married names could do this with multiple profiles on a single uPass rather than needing multiple uPasses.

Device enrolment Each account may have one or more devices A12a, A12b associated with it at any given time. To enrol new devices into an uPass account, an audited validation transaction must be performed between this device and a device which is already enrolled for the uPass user's account.

1 . Take a selfie;

2. Standard credential swap between the two devices (this means the validation app A52 on one device scans in the credential A30 offered by the other device, and vice versa);

3. When a new device goes online, server asks if the credential is valid;

4. If the credential is valid then the new device is enrolled.

Device re-enrolment

If the uPass account has at least one other associated device with a valid credential then re-enrolment follows the process outlined above for device enrolment. uPass account recovery

If the uPass user still has possession of a device which has been enrolled then account recovery is performed the same way as device re-enrolment with invalidated credentials. Otherwise, the uPass user can re-register using any registration document associated with the account.

Device revocation

An uPass user may revoke authorisation for any device currently enrolled for their account. This will invalidate any credential they currently have associated with the revoked device. Device revocation does not necessarily result in uPass suspension. Two factor registration

As mentioned earlier, each digital identity has data items derived from identity documents in a registration process. When obtaining data items from registration documents, one might assume that transmitting both the NFC (near field communication) and OCR (optical character reader) -quality data would be sufficient to confirm that the passport data is valid, however the acquisition of both sources of information via the same device leaves no way to confirm that the data has not been tampered with prior to transmission. To do that a second transmission vector may be utilised preferably involving a trusted agent and/or data acquisition device, and some form of standardised registrant signature which can be audited.

In one embodiment of the registration process, the registrant submits a photograph of the registrant taken with the same device used to capture registration data, time- stamped and tagged with metadata comprising device type, operating system, geolocation and network address. The same metadata will be captured for each item of registration data captured using the device. This photograph and the associated metadata provides an audit trail which can be used to help identify fraudulent registrations. A percentage of registrations are manually checked at the time of submission to ensure a visual match between the photograph and the photographic element of the registered identity document (e.g. passport photo).

Preferably, a facial verification service A40 compares these photographs in all cases and where there is a low level of confidence that the photos depict the same person this will also be flagged up for manual visual inspection. Rather than a single static photograph, frames taken from brief video clips can be used to capture a sense of liveness. In some embodiments, only a single frame is taken as it has been found that using multiple frames does not improve the accuracy of the face verification software.

Data captured by the device camera is subject to OCR processing A42 when it reaches the registration service A14a at the uPass server, to extract data items from the identity document.

A digital signature is generated on the sum of unencrypted data. Each captured data item is encrypted by encrypt block A44. The digital signature is used to annotate each separate encrypted data item before it is submitted to the registration service. These encrypted data items are decrypted by the registration service and the digital signature checked, ensuring the integrity of the entire registration submission.

In one embodiment, to further strengthen integrity the distinct registration data items are transmitted to separate end points identified by the registration application A22 and encrypted with separate symmetric keys. As with all symmetric keys issued by the system these are one-time pads - keys used only once and therefore known to be unique. To implement the two-factor authentication system the registrant requires a smartphone A12 with Internet access, which is capable of communicating over HTTPS and includes a camera of reasonable (say 5MP) quality. NFC capability is a useful optional extra. The registration process

The registration process will be described with reference to Figures 4a and 4b based on the use of mobile device A12 such as a smartphone or tablet with a native application. This application will acquire the necessary photos, NFC and metadata for packaging and submission to the registration service.

The registration workflow comprises the following steps:

S1/S2. Registrant A20 initiates a registration transaction by activating an icon on the smartphone 12, which creates (SA2) an electronic message R1 containing a random symmetric key k1 , of at least 256-bit, to be sent over HTTPS to the uPass registration service 14a. The preferred symmetric algorithm is AES-256 operated in GCM mode. S3/SS4 The registration service 14a sends a response R2 encrypted with the registrant's key:

1 . three unique 256-bit symmetric keys k2, k3, k4;

2. three distinct round-counts.

A round-count is a positive integer which tells the client how many times to iteratively perform a function seeded with a data value of interest. In this case we use the round- count to specify how many iterations to perform when generating a SHA-2 hash value which is a defence against rainbow table attacks.

This response R2 is packed in a cookie marked with the HTTP only and HSTS flags;

S5. The registrant uses their device A12 to capture data items for a registration request:

1 . device performs optional NFC chip read;

2. camera captures:

1 . scan of identity document;

2. photo of registrant (selfie).

S6. Metadata comprising timestamp, IP address and geolocation is recorded; This is then appended to each data item to be submitted along with the item count;

a digital signature DS is generated for the registration request using HMAC. Each data item is encrypted with one of the symmetric keys k2, k3, k4 to create a respective BLOB;

the distinct signature is appended to each encrypted item;

the registrant agrees to the uPass Terms and Conditions of Service;

each encrypted item is despatched to a separate network endpoint EP1 , EP2,

EP3. [ BLOBS (registration items) are collected in the registration service 14a;

geocodes and IP addresses are checked for each data item;

if all checks pass then the registration data is processed (see Figure A5 for a digital passport format):

1 . passport scan passed to OCR service to extract MRZ, photograph and signature;

2. NFC data provides DG1 , DG5 and DG7 (MRZ, photo, signature);

3. extracted photos are compared to the registrant selfie by the facial recognition service A40. If everything matches then an uPass account may be created with:

1 . an anonymous profile A28a;

2. a photo ID profile A28b;

3. a majority (age indicating) profile A28c;

4. a nationality profile (figure Aelement^**).

e cases, only the anonymous profile A28a may suffice uPass credentials are provided to the registrant application for the anonymous profile (the default profile). A credential is a random digital sequence valid for one time use only - it can be embodied as a QR code 16 for example. The registration service 14a is supported by an in-memory cache 24 in the secure store which contains a working-set of data elements related to current active registration for transactions, including: 1 . for the IP address of each active client registration

1 . device ID;

2. symmetric key;

3. registration data [k1]:

a. registration symmetric keys [k2, k3, k4]

b. encrypted registration data items received;

c. decrypted data items.

4. account creation message;

5. account credentials For enhanced security, there may be a requirement imposed that the data is transient and must never be stored to disk.

Each service-provided key is generated by the secure store A24 which ensures that all keys issued are unique. Forging registration transactions is impossible as keys provided by the registration server are randomly generated and cannot be predicted, therefore there is no way to use the keys from one transaction to guess the keys being used by another transaction. The guarantee of uniqueness ensures that attempting to reuse a prior set of keys will trigger a security event. Once all expected data items for registration have been received and decrypted, the decrypted passport scan is sent to OCR service A42 and the returned data is used as the basis for an account creation message. This is checked against any NFC data received to confirm that the two data sources present the same identity, and if this is the case then the embedded photographs are compared with the registrant's confirmation photograph in the facial recognition service A40 to ensure a visual resemblance. A percentage of incoming registrations can be manually checked at this stage to ensure that the OCR and facial recognition processes are working correctly, though this is not essential. If the registration data passes these tests then the account creation message is passed to the secure store A24 where its uniqueness is confirmed. A data store is created for the account containing identity statements, each anchored to its source document, and the three or four initial profiles A28a, A28b, A28c, A28d created for this account. Alternatively, identity statements could be achieved to the digital signature of source documents

An appropriate credential A30 is then generated for the registrant's device using the default (anonymous) profile. The credential is stored at registrant's device and allowed access to the profile. The secure store A24 now contains profile records which can be accessed using this credential.

After successful registration the device metadata, e.g. a combination of recorded device type and operating system is used to provide download links for appropriate uPass applications from the user's profile page.

To satisfy some use cases where a merchant seeks verification of a user, the merchant themselves must be registered.

The merchant registration process is similar to the standard user registration process, but using different primary documents.

For the UK jurisdiction a merchant might comprise any of:

• registered corporate entity;

• sole trader;

· partnership;

• registered charity;

• club;

• society. As a merchant registrant is an organisation, not an individual, there is a requirement to make a distinction between who owns the uPass (the merchant) and who is nominated as an administrator (one or more individuals).

A graphical illustration exemplifying the registration process is shown in figure A1 1 a

Confidence anchors

An important facet of the uPass system is the self-validating nature between uPass holders. That is, uPass holders may assert their confidence in each other's identity. Each uPass can act as a confidence anchor A1 10 for the individual profiles of other uPass users.

Internally any data item added to a profile gains a contingent trust which is a function of both the number and quality of validations performed by other uPass users to establish it.

Once entered into a profile these data items can be used in other profiles as well, but where they are, the contingent trust associated with these profiles becomes that of the least trusted data item in the profile. This way there is always a degeneration from the contingent trust represented by source registration documents which can only be offset by a statistically significant number of validations by other uPass users under profiles with a high level of contingent trust. Third-party profiles

Registration documents provide one means by which identity can be asserted with a high level of confidence. However, there are use cases where the identity which an individual might need to present does not derive from such a source but rather from their employment or membership in a particular organisation.

To allow for this an uPass can have profiles assigned to it by third parties and the contingent trust of these profiles is that mandated by the authoring party. None of the data items associated with an assigned profile is added to the set of data items available for use in creating additional profiles or modifying existing profiles, and the assigned profile can only be modified by the authoring party. To assign a profile, a third party must be an uPass user with a valid credential. He presents this credential and provided it is valid, receives a form to enter data about the new uPass profile. This is registered as before and a credential is generated and returned This can be passed to the owner of the new profile.

An assigned profile continues to exist until the authoring party cancels it, or until it passes a pre-assigned expiration date.

Social graph privacy

The uPass system contains a number of social graphs which effectively pinpoint an individual in relation to employment, friends, official documentation, transactional relationships and location. Full access to these graphs is private to the uPass system.

A primary exception is when an uPass user performs a validation based upon an assigned profile. In this case details are provided for the authoring party of the profile as an additional safeguard to the transacting party.

One application of the uPass system is to broker trust between two users of the uPass system, one an individual seeking to assert their identity and the other interested in using that assertion to validate eligibility for some service or interaction. This can be seen as a single transaction comprising authentication of the parties' identities.

This trust transaction requires two separate application modes, one on a user's mobile device for asserting their identity (app A50), the other on a merchant's device (app A52) for verifying assertion and then determining if the user is authorised to undertake a particular action.

To assert identity requires the presentation of an on-device credential A30 either in a visual form such as a QR code or barcode, or as a transmittable binary blob for use with NFC or similar technology. The uPass authentication app presents an appropriate credential A30 to an uPass reader A54 in app A52 which then despatches this to the authorisation service 14b for authentication. If this authentication operation is successful, the uPass reader app A52 will receive access to one or more uPass profiles and the user can then confirm his identity based on data items in the profile he can now view, such as a photo.

When a fresh credential is generated, it is bound [to an individual profile associated with the uPass user (see database in Figure A3b). When the credential is used the information in this profile then becomes available to the validating party in the trust transaction. For added security, the profile contains no linkage to the uPass user. This precaution ensures that gaining access to a specific profile does not provide a means whereby all of the profiles associated with the uPass user can be accessed. Only the information provided in the profile associated with the credential used is exposed to the other party, along with any information which they have published on the validated uPass in the form of a series of assigned profiles.

As an added safeguard issued credentials can be bound to the device's network address 64, so if the device changes network address the credential is also invalidated.

At no point is the asserting party's digital identity identifier A26 exposed. This is essential to the integrity of the system, even for casual use cases. Likewise, no personal information regarding the asserting party is revealed beyond that necessary to broker trust.

Summary of credential creation process

This process is carried out by the identity management code executed by processor A1 14 (or by any suitable computer mechanism) at registration of a new profile, and at each occasion the profile is used.

1 . determine the device identification number of a new device when it is registered;

2. calculate the SHA-2 HMAC of this device identification number; 3. store this device identification number securely;

4. for each credential generated:

1 . create a random salt value (preferably at least 8 bytes in length)

2. combine this with the stored device identification number to create a unique credential number;

3. perform SHA-2 hashing iteratively with the stored credential number as the seed value;

4. the number of iterations is chosen randomly within specified bounds;

5. the resulting token is the credential passed to the device.

5. a database entry is created keyed to the generated credential 30 which contains (see Figure A3b);

1 . a random reference key A60 specific to this credential;

2. a URI A62 capable of providing the profile to which the credential is bound;

3. the network address A64 of the device for which the credential is valid;

4. a link A66 to the uPass user for which this credential was generated;

5. the expiration time A68 of the credential;

6. other metadata A70 related to the credential lifecycle

Credentials are "single use" and "restricted". Each generated credential is specific to both the device and the uPass profile.

Single use credentials A feature of the uPass system is to allow a user to present a smartphone/tablet, etc. to validate their identity. One possibility is to use as an on-device credential its device identification number. However, this has the drawback that once assigned it cannot easily be changed and also reveals information about the device which could be used by an attacker. An improved alternative is to use a key which is generated based upon the serial number using a hashing algorithm such as SHA-2 iteratively. This involves creating a hash for the serial number and then creating a sequence of salted hashes with this value as the starting point. Only the HMAC of the initial hash value is ever stored, enabling the identity of a device to be described without knowing its precise device identification number and thereby preventing anyone with physical access to the secure store A24 from reversing the process to determine the device identification number and use this information maliciously.

To capture credentials from a device an uPass application either scans a generated QR code containing the credential or receives the credentials via some other means, such as NFC, iBureau, barcode, etc.

Restricted credentials

Each generated credential is specific to both a device and an uPass profile. This prevents credentials being transferred between devices and means that any given device is only able to present one profile at a time.

Credentials are generated by creating a random salt value and combining this with the device identification number. The result is then used as the initial seed value for an iteratively generated SHA-2 hash value with the number of rounds of iteration being determined at random.

Transaction receipts

Whenever a validation transaction occurs two receipts A32e are generated, one sent to the validating party (i.e. the merchant - VALIDATOR) and one to the validated party (e.g. the uPass user - BEARER). A receipt contains four pieces of information: the random reference key A60 associated with the specific credential used;

2 the profile URI A62 to which the credential presented by the other party was linked;

3 the URI of a list of all profiles currently assigned by the recipient to the other party,

4 the timestamp The random reference key A60 acts as a transaction identifier which is associated with a specific pair of receipts and thus a specific pair of credentials. When a receipt is generated the relevant profile is encrypted with the symmetric key and published to a Published Profiles Store A35 at a randomly generated URI. Both receipts generated for a transaction thus use the symmetric key to encrypt their associated profiles. These transaction receipts provide the basis for applications to interact with an uPass as will be explained subsequently in the discussion of uPass profiles.

Each device contains a receipt book A300 (Figure A1 a) which holds an arbitrary number of receipts from prior transactions. When a user wishes to prove that a transaction has occurred they can present the receipt as a QR code, etc. which contains only the random reference key A60 for the credential used. This can then be reconciled by a merchant or other uPass user with their own receipt book.

A copy of the receipt is maintained online in the master receipt book A31 which contains all receipts generated to date.

Authentication

A client device must be pre-registered and authenticate itself to perform an uPass validation for a given profile.

Standard client authentication

Each registered device contains a single one-use credential for each uPass user that it is registered to. Submitting the credential performs an implicit authentication, which is deemed to fail if the credential is unknown, expired or invalidated. There is also a small probability that a valid credential will be invalidated (as a randomised additional security check) on receipt to force an authentication failure for security purposes. An enhanced authentication can be conducted when the standard authentication interaction fails, or where the use case requires it.

Enhanced client authentication

Some transactions require a higher level of confidence than the norm. For these a full-face photo is captured and facial recognition is used to identify potentially questionable transactions. Because facial recognition is never 100% accurate standard authentication based on facial recognition failure is not prevented if credentials are otherwise valid but enhanced authentication requests are prevented.

The enhanced client authentication mode also exists to secure administrative operations and to allow an uPass user to re-authenticate after an authentication failure.

The enhanced client authentication captures a photograph of the device user which is compared to the facial recognition database for the uPass user to whom the device is registered, and if the recognition fails then a security event is triggered and logged. Credential lifecycle

Credentials have a lifecycle which involves: their creation which binds them to an uPass profile; their distribution to a specific device; and their revocation or expiration. This lifecycle is managed solely within the validation service.

When a credential is created it is recorded in the secure store and tagged with the following metadata A70 to be used as part of managing its lifecycle:

• the uPass profile for which it is valid

• the time at which the credential was requested

· the time at which the credential was issued;

• the geo- and network-locations of the requesting device at time of issue;

• the expiration time (if any);

• the device details for the validation causing the credential to be issued; • whether or not the credential has been revoked.

When the credential is subsequently received all of this tagging data can be checked to confirm if the credential is being used correctly. The record is then used to create auditing and security action records elsewhere in the secure store and then invalidated.

A credential may be revoked at any time. When revocation occurs the credential's record is flagged as revoked in the secure store but the record is not processed at that time. This allows the uPass system to monitor the use of revoked credentials and use the resulting metadata to assist in fraud analysis and prevention.

Once a credential is revoked or invalidated it cannot be reinstated as valid. Garbage collection of expired and revoked credentials may occur in one of two ways:

• when a validation query occurs for the credential;

• via a background garbage collection task which reaps expired credentials.

Handling invalidated credentials

When a credential has expired or been revoked its use (i.e. someone attempting to reuse an invalidated credential for a valid use) may indicate that the device to which it has been bound has been stolen or otherwise compromised. This represents a serious fraud risk.

In these circumstances we cannot issue a new credential to the device until it has been confirmed that it is still in the possession of the uPass user for whom the invalidated credential was originally created. To confirm this we treat the device as if it is a new device being enrolled for the first time, a use case covered in the section on Enrolment.

Validator authentication The uPass validator device is built on the same principles as a standard uPass device. To perform a validation the validator device must present a valid credential for its associated uPass device. This ensures that only users of the uPass system can run queries against the uPass trust network.

The validator credential is sent as part of the request.

Bearer authentication: asserting an identity

By limiting authentication to a single authorisation query rather than an ongoing transactional relationship uPass can be used to create a simple proof of identity system. More complex use cases based on event ticketing such as guest lists or digital festival passes can be built on top of this by allowing the merchant to assign a profile to an uPass user with an appropriate expiration date.

Figure A6 illustrates a bearer only authentication process.

When a bearer-only authentication occurs the uPass reader A54 will send the credentials A30 proffered by the customer A20 in a message A100 to the authorisation service 14b. The user's credentials are then tested for validity before being marked as used and a response A122 is returned to the uPass reader along with a link to a profile which holds a photograph to allow visual confirmation of identity by the merchant.

Figure A6 illustrates schematically a validation in its full context where the credential A30 on a device is backed both by a series of issuing anchors A107 which indicate the quality of registration documents A10 and confidence anchors A1 10 which indicate the extent to which the profile has been vouched for by other uPass users.

Because a credential A30 is single-use and potentially restricted it is possible that when proffered it will no longer be valid. When this is the case a fresh credential A30" may be automatically generated by the service 14b and pushed (A104) to the bearer's device and from there to the validator, or the uPass user may be required to re-enrol the device.

The bearer authentication process is as follows.

1 . uPass reader A54 requests credentials for authentication;

2. (optional if the uPass user has multiple profiles) the uPass user selects a profile be validated (note that validation will cause a new credential to be bound to the profile and their uPass device);

3. uPass user presents credentials to uPass reader:

4. credentials are bound to an uPass profile.

5. the credentials is despatched to the authorisation service 14b;

6. if a credential has expired, then the authorisation service:

1 . in the case that the uPass user has presented a valid identity:

1 . despatches a fresh credential A104 to the uPass user's registered device ;

2. sends a retry message to the uPass reader.

2. otherwise:

1 . send an authorisation failure message to the uPass

reader.

7. if the credential is valid:

1 . the uPass user's credential is invalidated;

2. send message A122 to uPass reader comprising a link to a profile with a photograph (or the photo itself?)

8. in all other circumstances the authorisation service sends an authorisation failure message.

9. new credentials are generated and transmitted respectively to each uPass device A12.

This whole process must be repeated to perform additional authorisations, each time authenticating the uPass user's credentials against a specified profile and leading to a cascade of credential publication. Figure A6a shows a validation process in which both the credential of the bearer and the credential of the validator are validated, and in which receipts are issued. This a more complete description of the bearer authentication process described above with reference to Figure A6. The user of the uPass device selects a profile. The uPass device A12 of the bearer sends the credential A30b bound to that profile to the uPass validator A52, e.g. as a QR code . The uPass validator reads the QR code, selects a profile to use and supplies the bearer credential A30b and its own credential A30v to the uPass validation service. The uPass validation confirms that the credential A30v is valid, and if so goes on to process the credential A30b. If the credential A30b is valid, it returns (message A1 12 in Figure A6) a link to the profile bound to the credential A30b to the validator A52. It also issues a new (fresh) bearer credential A30b" to the bearer device A12 and a new validator credential A30v" to the validator A52. Each fresh credential is returned with a receipt which is denoted A32v for the validator and A32b for the bearer. The generation of the fresh credential in each case is associated with the issuance of a pair of non-matching (individual) receipts. In each pair, one receipt is sent to the bearer and comprises a link to a newly-published published profile of the validator and the fresh bearer credential for later use by the bearer, and the other receipt of the pair is returned to the validator and comprises a link to a newly-published profile of the bearer and the fresh validator credential. Thus, in the embodiment of Figure A6a, a pair of receipts is issued for the creation of the fresh credential for the validator, and a pair of receipts is issued for the fresh credential for the bearer. The two receipts A32e, A32v comprise matching transaction identifiers identifying the transaction in which they were created and tying them together. A corresponding master receipt A32 comprises the same transaction identifier (which links it to the corresponding receipt pair) and both links but not the credentials.

The receipt A32v can include the link to the photograph for the bearer in the relevant profile.

At any time between transactions a user can choose to acquire credentials for a different profile. However, they can only ever have one credential on their device for a given uPass user. Figures 6b and 6c show additional details of the receipts A32b, A32v that are generated in the validation transaction of figure A6a. Each of the receipts A32b, A32v comprises the same transaction identifier A60, which is a symmetric encryption key for the transaction. The bearer receipt A32b comprises a link A62v to the version of the validator's provide published in the validation transaction, and a confidence value A65v associated with the profile that the bearer has just presented (i.e. to which the link A63b in the validator's receipt A32v points). Similarly, the validator receipt A32v comprises a link A62b to the published version of the bearer's profile, and a confidence value A65b associated with the profile the validator has just presented (i.e. to which the link A63v in the bearer's receipt 32b points). Each of the bearer and validator receipts A32b, A32v also comprises a respective link A63b, A63v to a list of all of their profiles currently assigned to the other of the bearer and the validator.

As noted above, in addition to the bearer and validator receipts A32b (i.e. C'B), A32V (i.e. C'v), a master receipt A32 is generated for the transaction, details of which are shown in figure A6c. The master receipt A32 comprises a hash (e.g. HMAC) of the fresh bearer credential A300b, i.e. H(C'B), and a hash of the fresh validator credential A300v, i.e. H(CV), where H denotes a cryptographic hash function (e.g. HMAC) that is applied to that credential thereby generating a hash of that credential. That is, the master receipt A32 comprises hashes of both of the fresh credentials A30b", A30v" that are issued at the end of the validation transaction. The credentials A30b", A30v" cannot be obtained from the hashes A300b, A300v alone. However, the credentials A30b", A30v" issued to the bearer and validator respectively can be used later to locate the master receipt A32, even after they have been used or have expired. In other words, the hashes A300b, A300b are first and second indexes of the master receipt A32 respectively, which can be used to located it in the master receipt book A31 when (and only when) one of the credentials A30b" or A30v" is rendered available to the uPass system. The master receipt is locate by hashing the available credential to generate a search index, which will match the corresponding index of the master receipt A32. The master receipt book A31 can be implemented in any suitable manner that allows these indexes to be searched, for example as a distributed data store.

The master receipt A32 also comprises both of the links A62b, A62v to the published profiles, their associated confidence values A65b, A65v, and both of the links A63b, A63v to the profile lists - all of which are encrypted with the transaction identifier A60. Alternatively or in addition, the published versions of the profiles to which the links point may be encrypted with the transaction identifier. In embodiments, the transaction identifier A60 is not included in the master receipt A32, nor is it stored within the uPass system. Thus, the contents of the master receipt A32 can only be accessed by the holder of either of the receipts A32b, A32v in such embodiments.

The master receipt A32 may also comprises data that matches at least part of the two previous master receipts for the bearer and validator respectively - A32' and A32" in figure A6d, respectively. This data is in the form of a hash of the now-used bearer credential 302b, i.e. H(CB), and a hash of the now-used validator credential A302v, i.e. H(Cv). The hash A302b of the now-used bearer credential A30b matches the corresponding index of the earlier master receipt A32' that was generated in the transaction in which the bearer credential A30b was first issued (first earlier master receipt) and the hash A302v of the now-used validator credential A30v matches the corresponding index of the master receipt A32" that was generated in the transaction in which the validator credential A30v was first issued (second earlier master receipt). These indexes are public, in that they are not encrypted with the transaction identifier 60.These two earlier master receipts A32', A32" can thus be located using the hashes of the bearer and validator credentials A302b (i.e. H(CB)), and A302v (i.e. H(Cv)) respectively,. Because the earlier master receipts A32', A32" have been generated in the same manner as the master receipt A32, one of the public indexes of the first earlier master receipt A32' will match the H(CB) from the current master receipt A32 - that index having been generated in the earlier transaction when CB was issued to the entity who is the bearer in the current transaction (but who may have been the bearer or the validator in that earlier transaction); likewise, one of the public indexes of the second earlier master receipt A32" will match H(Cv) from the current master receipt A32 - that index having been generated in the earlier transaction when Cv was issued to the entity who is the validator in the current transaction (but who may have been the bearer or the validator in that earlier transaction). In turn, those indexes of the earlier master receipts A32', A32" relate, in the same manner as the current master receipt A32, to receipts issued to the entities in question in the earlier transactions (as do their other indexes). These two additional hashes A320b, A302v may also be encrypted with the transaction identifier A60. This allows those earlier master receipts A32', A32" to be located in the master receipt book A31 from the current master receipt A32 only when the transaction key A60 is made available from the bearer or validator receipt A30b, A30v. Moreover, the content of the each of the earlier master receipts A32' A32", and/or the published profiles to which it links, is encrypted with its own respective transaction identifier i.e. the respective transaction identifier of the earlier transaction in which it was created (which is different from the current transaction identifier A60), and can thus only be accessed with the bearer or validator receipt created in that earlier transaction.

The master receipt A32 also comprises first and second digital signatures A304b, A304c, generated from at least a part of the earlier master respects A32', A32" respectively and/or hashes thereof. Preferably, the signatures and/or the hashes are generated from all of the data of the master receipts, including their public indexes. That is, as SIG(A32') and SIG (A32"). The signature can be generated using a private key known only the uPass system, and can be verified using a corresponding public key to verify the receipt is authentic. The signatures A304b, A304v are also encrypted with the transaction identifier A60.

The bearer and validator receipts A30b, A30v are encrypted with keys A306b, A306c previously registered with the uPass system by the bearer and validator respectively, (a user can deposit a public or symmetric key with the service if they want to, and then the system can use it for communicating with them securely). This means that only the bearer and the validator can access their content respectively.

It's also possible to have multiple signatures in a master receipt generated by different means, and to allow a master receipt to be split into more than two receipts by including additional credentials and signatures in the master receipt.

Enhanced validation

Some transactions require a higher level of confidence than the norm. For these an enhanced validation process can be adopted. 1 . The bearer sends an out of band facial image to the uPass server, accompanied with their current credential and the time that the selfie was taken.

2. The bearer sends to the validator their credential and the facial image for bearer.

3. The validator adds their credential to the message and sends this to the uPass server.

The uPass server validates the message and compares the image data which was sent from the bearer to the validator with the image data that was sent in an outer band communication between the bearer and the uPass server. If the selfie has not arrived when the validation is performed, the uPass server may compare the image data which has been sent to the validator to the bearer's previous entry in their facial image database.

The image data which is sent from the bearer to the validator can be an LBP extract from the facial image.

Note here that a selfie is a facial image captured by the bearer using the camera on their mobile device, for example.

Mutual authentication peer-to-peer trust One useful feature of the uPass system lies in its ability to establish mutual trust between two parties, allowing a broader range of interactions than those permitted by the bearer authentication mode. In this case each party presents credentials to the other for authentication by the authorisation service and an ongoing transaction is established.

The advantage of a transactional model is that transactions cannot overlap, therefore any device can only be engaged in a single transaction at any one time. If a device attempts to start a new transaction the previous transaction can be automatically terminated. When a mutual authentication occurs each party captures a credential from the other party and despatches this to the authorisation service for authentication. If both sets of credentials authenticate then a transaction is established and each party is issued a unique symmetric key which is used to encrypt their ongoing communication with the server. These keys are time-limited (for example, a limit of approximately 5 minutes) and if the transaction is ongoing will be replaced when they expire.

A transaction can remain active for an indefinite period of time, but to do so both parties must send a keep-alive message to the authentication service when their keys expire. If either party fails to provide the keep-alive message then the transaction is terminated.

As an added security measure each transaction can be tied to the specific devices used to initiate it, and to a specific profile for each party.

Once a transaction is initiated either party can test authorisation propositions against the active profile of the other party for the duration of the transaction. Anonymous authentication

The uPass system ties authentication to a specific profile (A28a....A28d) but leaves the uPass user in control of how much information they reveal to the other uPass users via their profile selection. It is therefore practical for two uPass users to broker trust for a given purpose without revealing any personal details to each other - only to confirm their physical appearance. To facilitate this every uPass user has an associated anonymous profile A28a.

Profile avatars

A second possibility for credentials is the use of a characteristic avatar (an image, movie clip or audio file), which is issued by the uPass system with a credential embedded in the data. Profile avatars with company logos can be used to embed a credential. The avatar image can then be submitted to a website or via NFC to a mobile device with the recipient authenticating it against the uPass system and receiving back the source data which can be used to confirm the identity of the user.

The avatar acts as a container for credentials which aside from the need for embedding and extraction are handled in exactly the same way as any other uPass credentials.

Each avatar is bound to an uPass profile. In some circumstances there may be a limit on the number of avatars allowed per profile, as yet to be determined.

Web-based authentication

In the above description, it is assumed that uPass credentials are stored and read by mobile devices using proprietary applications. Another use case which needs to be addressed is that of conventional web applications running inside desktop browsers.

This is referred to herein as uPass Connect and is illustrated in Figure A7.

UPASS CONNECT uPass Connect provides a protocol whereby the user of a network system wishing to login to that system can do so using their uPass credentials on a trusted device such as a phone or tablet. One use case is for websites and applications, however uPass Connect should be usable with any client/server system capable of presenting a unique token to the uPass user.

In this situation there are two trust queries being performed:

• the uPass user A20 is seeking to confirm the identity of the system (web server A80) to which they are providing a credential;

· the system (web server A80) is seeking to confirm the identity of the uPass user 20. There are actually three actors involved in this transaction as the local device A173 (e.g. a PC) being used to login to the system needs to acquire the trust which is being mediated between the uPass device A73 and the remote system A80. Server enrolment uPass Connect brokers trust between a server A80 and a client device A12. The client device 12 is already enrolled for the prospective user A20 and has a credential A30 bound to a profile. However, for the server to interact with the uPass system it needs to be enrolled as a device. This process binds (in the database of Figure A3b) an uPass profile A28 for the server operator to a credential A30 to allow interaction.

Once enrolled the server is able to create virtual devices which can then be used to manage login and registration initiated by prospective users of the server.

Virtual devices

The uPass validation transaction requires that each uPass credential is uniquely bound to both a profile and an enrolled device. Whenever a network system establishes a session by presenting a login or registration form A177 to a visiting uPass user via a client application, it needs to uniquely identify this session to the uPass system. Which introduces the need for a transient virtual device. A transient virtual device is created as part of the session establishment procedure, triggered by step 71 "I want to use URI". This device is enrolled using a standard uPass validation and assigned a unique device identifier. This device identifier needs to be unique for the uPass user providing the uPass Connect session. The same device identifier can be reused across different uPass users.

Once the virtual device has been enrolled, a credential A30 is issued to it, which is transmitted (step A72) in a webpage and forms the basis for a QR code A179. Which will be displayed in the updated webpage A177 issued after enrolment of the virtual device. The native app on the smartphone A12 can scan in this QR code and transmit it to the uPass validation server A14. Inversion of trust

In the standard uPass validation scenario described in the preceding sections, a validator requests that a client (bearer) wishing to engage with them to provide an uPass credential which can then be checked against the uPass validation server. The uPass Connect system does not take this approach as there is no guarantee that the client application will be running on a device capable of soliciting a credential from the uPass user seeking to use the network service. To get around this, the uPass validator presents the credential in visual form (such as the QR code A179) via the client application and the uPass user A20 seeking access scans this (step A73) into their own uPass-enrolled device A12. As an alternative to the QR code, the scan could be by NFC, Bluetooth, Wi-Fi, audio, or any other data transmission mechanism. This flexibility allows uPass Connect to support Internet of Things embedded use cases.

In step A74, a check is performed to a URI verification service to check that the FQDN of the URI is registered (step A75), a confirmation is returned to the smartphone (step A76). An optimal additional step for enhanced security can be conducted, wherein in step A77 the device A12 sends a receiving address with the acquired token and its old token. This receiving address is used to open a back channel, step A716. The remote service confirms validity to the smartphone A12, step A716.

This scenario can play out in one of two ways. In the most common case the uPass bearer A20 is using their mobile device A12 to gain access to a web site via a browser session running on a desktop or laptop device A173 scanning the QR code displayed in the client application.

There is however a second possibility in which the uPass user wishes to connect to the website from a browser or application on the device hosting their uPass credential. Where this is the case the QR code will be transferred from the browser application to the uPass application and thence transmitted to the validation service. Once acquired, this credential (which is annotated with the URI indicating the system to which the client application is attempting to connect) is passed (step A77) to the uPass validation service, which then determines if the URI is valid and known, by looking up the credential in the database of Figure A3b. To simultaneously validate the user of the device 20, his credential is added to the message in step A77. Assuming the credentials are validated, a receipt is sent to the URI server A80 (step A78) which determines what to do (step A710) based on the validated identity presented in this receipt. A receipt is also sent (step A79) to the device A12 with details of the server hosting the URI, for display (step A712) to the user A20.

Requiring a specific profile

A server supporting uPass Connect may wish to only ever receive profiles it has assigned. This can be reflected in the credentials used by its virtual devices.

Registration completion

When an uPass user wishes to register with a service supporting uPass Connect they have the option of performing an uPass validation. This provides the server with their current profile (providing details information for a registration form) and a link back allowing a profile to be published against their uPass account.

Business case: online age verification One of the key problems uPass Connect solves is the need to certain web-based industries to restrict access to their services in response to minimum-age legislation. This applies to sites operating in the online gambling, pornography, video and general retail sectors. Site operators can require an uPass age-check profile to determine the legal eligibility of a visitor to access their content and take appropriate action based upon this. Performing this validation also creates an audit trail so that the site owners can subsequently demonstrate their compliance with the law. Business case: virtual cookies

When a site uses uPass Connect to control access to its content, it gains the ability to annotate users' uPass accounts with site-specific profiles which can be queried on subsequent visits. These can be used to store arbitrary infornnation and therefore have a similar role to browser-based cookies, only without the inconvenience of storing them on a user's system.

Business case: restricted site membership

Many websites enforce a paywall around their content and maintain proprietary membership lists to control access through this which necessarily also require profile systems to allow user customisation. With uPass Connect both membership access and profiles can be managed via the standard uPass mechanisms.

Business case: embarrassing services

There may be cases where the nature of the service being accessed is such that an uPass user would not want their photo shared with the service for quite legitimate reasons of personal embarrassment.

Referring to Figure A2, the secure store A24 is a secured, privacy-preserving data store which contains user credentials and related metadata. It is an aim of the system design that an uPass operator should have the bare minimum access to the personal information associated with any given uPass user.

If this data store is ever compromised, so potentially are the identities of all the users. Therefore the secure store is placed on a separate internal network segment isolated from the outside world with multiple layers of hardware security to ensure this. The data link between the uPass service and the store is secured at a protocol level to further reduce the risk of internal threats.

Within the data store A24 are contained (see Figures 3a/3b):

• the registered identity documents A10 for each individual; • details of their authorised mobile device A12a, A12b;

• currently issued credentials A30;

• all previously issued and now invalid credentials A30';

• identity statements and their confidence anchors A1 10;

· identity profiles A28a...2b.

This content is stored in an encrypted form.

An encrypted database also needs a search facility and this is implemented in one embodiment by storing characteristic cryptographic hashes for each indexable data item. These have the advantage of being irreversible making it impractical to use them as a means of recovering the source data in the event that the secure store is compromised, whilst at the same time having a very low probability of collision making them good index keys. Whenever an incoming request for identity assertion is received the uPass system first checks to see if the device is authorised to make the request. If it is, then receipts will be generated for both parties which are stored in the Master Receipt Books using their provided public keys. Facial recognition database

For each user, a separate facial recognition database is maintained trained on that user's photos.

Offline usage

The standard uPass mechanism described above are predicated on the availability of network access for both uPass bearer and uPass validator.

Credentials An uPass credential is one-use and requires validation by the uPass validation service. Therefore credentials cannot be used reliably for offline usage.

Receipts

Receipts are statically published identifiers which always correctly resolve to a published profile and to a consumed credential.

Many offline use cases can be modelled in terms of a locally deployed cache of transaction receipts. The local database of transaction receipts is effectively an offline identity cache with visual user validation supported by a photo for each receipt.

The transaction identifier in the receipt will never change so this can be presented as a printed QR code, barcode or binary blob in an NFC tag.

It is the responsibility of the uPass validator to ensure that relevant profile data is successfully acquired before their access windows expires, and that charged items are properly accounted for during the event. Receipt-based usage can be reconciled later via an online mechanism to provide a concrete audit trail. e -Wallet Another possible application of uPass is a digital wallet which allows a sum of money to be associated with a particular device and used to purchase goods or services. This is essentially an extension of the qualification use case which adds a transactional exchange, requiring confirmation to the vendor that a payment has been successfully made along with the actual transfer of money between the two parties.

Confidence values - vouching

A transaction can be performed with the particular intent of increasing the confidence value assigned to a target entity's profile, in which a vouching entity vouches for the target entity. The vouching entity collects a credential from the target entity and presents it to the uPass system with their own credential in an electronic vouching message. The vouching entity's credential is bound to a profile of the vouching entity to which is allocated a relatively high confidence value (relative to the target's profile as bound to their credential). On the basis of that higher confidence value, the transaction causes the confidence value of the target entity's profile to be increased. Being a transaction, this uses up the vouching and target entity's one-time use credentials and fresh credentials, bound to the respective profiles, are issued accordingly.

When the target entity's profile is later made available to a validator through presentation of the target's fresh credential, the uPass system may in addition to revealing the (now higher) confidence value of the relevant profile, identify the vouching entity as the source of the high confidence value to the validator. For example, the validator may be a business, the vouching entity a well know customer of that business, and the target entity a new customer of that business. The profile may be a profile created specifically for the benefit of that business, whereby the initial low confidence value of the target's profile is indicative of the fact that the target is an unknown customer.

Use Cases - figures 11 B-H

In each of the use cases of figured 1 1 B-H, a validator captures a credential from a bearer. In some cases the user is a bearer and the validator a device, in others vice versa. Sometimes both are humans. Each use case is based on a uPass transaction, in which the validator captures a bearer credential A30, and present's it to the uPass system with his/her/its own credential. Both credentials are one-time only use and bound to bearer and validator profiles respectively, which may be profiles specifically created for the type of transaction in question. Subject to both credentials being valid, a version of the validator (resp. bearer) profile is published and a link to the published version provided in a receipt sent to the bearer (resp. validator). This uses up the credentials so fresh validator and bearer credentials are also issued in the validator and bearer's receipts respectively. A user A20 can verify their identity to an event owner (fig A1 1 B) by showing a valid credential A30 bound to e.g. a profile specific to the event on the display as a QR code. In this scenario, the user is the bearer. The creation of the event profile may be conditional on the user having paid an appropriate admission fee or some other predetermined admission criteria. A validator (event owner) captures the credential and presents it to the uPass system. The system publishes the relevant profile so that it is accessible to the validator. The profile may simply be a phot of the user's face A20. The validator can compare the photo to the user and thereby verify that the user A20 does indeed have a profile for the event (because they match the photo) and admit them to the event.

A credential outputted by a web page (fig A1 1 c) on a separate device A1 102 can be captured by the mobile device A12 can be used to simultaneously verify the website to the user A20 of the device A12 and the user to the website. In this scenario, the user is the validator and a Web server is the bearer. The user wishes to log in on a separate device, and captures the website's credential A30 from the separate device using their mobile device A12. That is, the credential is received at the mobile device A12 from the Web server via the separate device A1 102. The user presents their own credential and the captured credential to the uPass system. Subject to both being valid, the uPass system verifies the user to the Web server (by publishing the user's relevant profile to a location accessible to the Web server and sending a receipt with a link to that location), and the Web server to the user (by publishing the relevant profile of the Web server to a locational accessible to the user device A12 and sending a receipt with a link to that location). The web site can grant access to the user accordingly, and the user can proceed safe in the knowledge that the website is genuine. Both the Web server and the user have now used up their one time credentials for their respective profiles so fresh credentials are issued with the receipts. Figure A12D shows a similar scenario, in which the website is instead accessed on the mobile device A12 directly. Here, the credential A30 (not shown in fig A12D) comes straight to the mobile device A12 from the Web server via the Internet or other network. The underlying mechanism is otherwise the same.

Figure A1 1 E shows how a user may effect a purchase form a website hosted on a Web server presented on a separate device with their mobile device A12. After capturing the website's credential, the user is required to provide additional verification by entering a PIN or scanning their fingerprint for example before the uPass app will present the captured credential and the user's own credential to the uPass system to provide additional security. Because the website has confidence the uPass system, it allows the transaction to proceed on the basis of the receipt which is issued to it. Figure A1 1 F shows an equivalent scenario in which the website is provided to the mobile device A12 directly, and without the additional layer of security. In both figures 1 1 E and 1 1 F, a key aspect is the simultaneous verification of the web Server to the user (so the user knows they are safe to purchase goods or services form the website), and the user to the Web server (so the website knows it is safe to sell to the user). As will be apparent, an equivalent use case is a real-word use case in which Web server is substituted for a human vendor operating the separate device A1 102. Figures 1 1 G (separate device) and 1 1 F (same device A12) shows how a user may use their uPAss to donate to charity. The underlying principles are the same as the purchase scenarios only here the reward reaped by the user is intangible.

Transactions - examples

A credential bound to a profile can be used once in a uPass transaction to do e.g. one of the following:

1 . simply publish that profile to make it accessible to a validator;

2. modify that profile e.g. by adding a data item(s) to it;

3. create a new profile;

the profile to which the credential is bound is also published in 2 and 3, as that is an inherent part of a uPass transaction. In 2 and 3, a requesting entity may be e.g. an employer and a target entity an employee (see above), or the requesting entity may be a part of the uPass system itself e.g. the validation service 14b or uPass controller A1 16 - as an exception, the part of the uPass system may not have a profile or its own credential (though neither are excluded). Thus, in this case, only one profile may be published (the target's, sent to the part of the uPass system) and only one fresh credential may be generated (for and sent to the target).

A uPass transaction can be conducted between three entities (such as bearer A20, validator A52, and validation service (authenticator) 14b), as shown in figure A12. In figure A12 F represents a function to be executed. This may be a simple validation. It may also be an operation specific to the secure store A24 as expressed by a public API. A represents an authentication wrapper for F. The bearer A20 (e.g. customer) sends their credential Cc to the validator A52 (e.g. merchant) in a first electronic message. The validator sends its own credential Cm with the bearer credential Cc with an indicator of the function F to be executed to the authenticator 14b in a second electronic message ("CmF(Cc)"). The authenticator sends CmF(Cc) with an indicator of the authentication wrapper A and its own credential Ca to the secure store A24. A set of four receipts R1 , R2, R3, R4 ({Ri}) is generated. A master receipt for the transaction is stored in the master receipt book A31 , and bearer/validator receipts A32v/A32b (R2/R3) are issued to the bearer and validator A20, A52. R1 is issued to the authenticator A14b, and R4 is logged in a secure access log A1202. All of the receipts R1 , R2, R3,R4 and the master receipt share a transaction identifier which links them all together,

Figure A13 shows a similar scenario, however in this case the customer communicates directly with the authenticator A14b and receives both receipts R2, R3.

Alternative biometrics: In other embodiments, another type of biometric data (other than, or in addition to, the selfie) may be used, such as image of a fingerprint or a biometric template (e.g. LBP) derived therefrom. For this to be effective, a high resolution image of the fingerprint is needed. Where the device's camera is not equipped to provide an image with the necessary resolution, super resolution imaging can be used, whereby multiple images of the fingerprint are captured and combined using known super- resolution techniques to generate a composite fingerprint image having a greater image resolution than any of the individual images. The composite image is preferably generated at the user device, though is can be implemented by the uPass system. Accordingly, any of the above description pertaining to a selfie applies equally to a fingerprint image data (or other biometric data).

Liveness detection in Enrolment In some embodiments, during the enrolment process in which the image of the passport is captured, that same image (or images) may be used for liveness detection. That is, the uPass system may, upon receiving an image of an identity document, process it to simultaneously verify that the document is authentic and also that the hand holding it is a real, human hand (e.g. based on texture analysis). That is, document authentication and liveness detection may be performed based on the same image(s). The authenticity of the document and the liveness of the hand holding it may be prerequisites for anchoring the document within the system.

Glossary

storing a Current

Credential.

Confidence Confidence Network,

Framework? Confidence Web

Confidence anchor a uPass profile which is Another uPass used to assert the validity of user a upass profile belonging to

a different uPass user

Confidence value the numeric value assigned

to an uPass profile based on

the sum of the confidence

and issuing anchors

Contingent Trust A value indicating the

trustworthyness of a

particular profile or data

titem based upon its

confidence value and the

usage of this profile or data

item over time

Credential A token binding a specific a proflie, a

Profile to a Registered registered device, a

Device, both associated receipt

with an Identity. This token

is unique and may only be

used once. Optionally it

may also be time-limited or

invalidated.

Current Credential The Credential which is

valid for a specific Profile

and Registered Device at a

given point in time.

Data element a combination of a data

item and associated

metadata

Data Item Data Element HMAC In cryptography, a keyed- hash message

authentication code (HMAC) is a specific construction for calculating a message authentication code (MAC) involving a cryptographic hash function in combination with a secret cryptographic key. As with any MAC, it may be used to simultaneously verify both the data integrity and the authentication of a message

HSTS HTTP Strict Transport

Security (HSTS) is a web security policy mechanism which is necessary to protect secure HTTPS websites against downgrade attacks, and which greatly simplifies protection against cookie hijacking.

Identifying Anchor identifying document

Identity Assertion Any atomic key value pair representing a statement about the identity of the uPass User

Identifying document Issuing document

Identity The characteristic

information associated with a single user. An identity many consist of many profiles

Identity statement profile Issuing anchor the author of an issuing like the crown document for a passport

Issuing document a source document from profile Passport,

which a profile may be Driving Licence, created Utility Bill, ID card, Student card

Master Receipt Book A central repository of

Receipts of all uPass Users.

Merchant registered corporate entity,

sole trader, partnership,

registered charity, club,

society etc.

Profile A cohesive set of one or

more Identity Assertions

describing some aspect of

an identity, combined with

a photo and linked to the

contingent trust system

Profile History A time sequence of stored

versions of a Profile for a

given Identity along with

associated metadata.

Published Profile An instance of a Profile at a

given point in time, stored

encrypted in a randomly

selected and publicly- accessible location.

Receipt A token created subsequent

to a Validation which

contains key metadata

related to that Transaction

and links to a Published

Profile for the other party

involved in that

Transaction.

Receipt Book A time sequence of Receipts

associated with a specific

Identity Receipt Pair Receipts are generated in pairs so that each party to a Transaction receives one. The Receipt Pair are bound together by a shared Transaction ID which is used as a shared symmetric key to encrypt both associated Published Profiles.

Registered Device Any computing system

registered as valid for a given Identity

Registration data Sum of all data items

submitted for registration

Registration documents submitted issuing

documents

Registration item registration Datum

Registration Event The act of submitting or resubmitting an identity Document to the Secure Store, allowing its baseline Contingent Trust to be determined

Remote Connect The mechanism whereby an intermediary unassociated with the system is used to present a Credential from a Virtual Device hosted in a remote service such as a web server. This Credential is then acquired by a registered Device which acts as a Validator.

Security Event a message sent to a

separate security auditing and enforcement system Selfie A self-taken photo of a user,

in particular of their face

Social graph mapping and pinpointing a

uPass user in relation to

other uPass users

System Application One or more software

applications which together

use a series of Transactions

to perform a more complex

task.

Transaction ID A cryptographically random,

unique number used to

identify a given Transaction.

Transaction Key transaction ID

Trust Arbitration An automated mechanism

which establishes trust in a

timely manner between

two users via proffered

credentials

uPass User An entity registered to the Some of the uPass system that has been document type assigned at least one profile and the method of submission is contingent trust

Validation Transaction The process of confirming

that an acquired Credential

is valid and current for a

given Registered Device,

leading to the creation and

dissemination of a Receipt

Pair.

Validator A Registered Device capable

of acquiring a Credential

from another registered

Device and using this to

request a Validation via an

Authenticator. Virtual Device A notional Registered

Device which exists purely

as an embodiment in

software hosted on a

physical Registered Device.

Aspects of the subject matter and embodiments thereof Various features of the uPass system are set out below.

An aspect is directed to a method of authenticating content offered by a content source to a local device for displaying content, the method comprising: establishing a communication session between the content source and a browser executing at the local device; transmitting from the content source to the browser a validation page comprising a content authentication token which is a randomly generated one-time use only credential bound to the content source; capturing the content authentication token from the browser by a verification application; transmitting the authentication token to a validation service which determines whether the token is bound to a valid source of content; and causing the content to be displayed on the local device if the token is bound to a valid source of content

In embodiments, causing content to be displayed may comprise transmitting a content source receipt from the validation service to a mobile device with or indicating a data item relating to the valid source of content. The content source receipt may comprise a link identifying a memory location from which the data item is accessible, thereby indicating the data item. The data item may be accessed from a digital profile of the content source identified by the credential. The profile may be published by storing a version of it to an addressable memory location, and a link identifying the addressable memory location is included in the content source receipt, thereby indicating the data item.

The verification application may be executed on the mobile device which captures the content authentication token displayed on the validation page by one of: digital image capture; scanning, near field communications and Bluetooth. The content authentication token may be received by a local browser of the local device and transferred to the verification application which is executed in the local device.

Causing the content to be displayed may comprise transmitting a receipt to the local device which indicates a data item relating the valid source of content.

The token may identify an address of the source of content, the method may comprise transmitting the address to an address verification service to confirm the address is a valid address.

The data item may be displayed at the mobile device. The data item may be details of a server hosting the content. The data item may comprise details of a virtual device hosting the content and/or a physical device on which the virtual device is running.

The method may comprise the steps of transmitting from the mobile device a device authentication token which is a randomly generated one-time use only credential bound to the mobile device to the verification service with the content authentication token.

The validation service may use the device authentication token to access a digital identity profile using the credential. The validation service may generate a device identification receipt comprising or indicating a data item accessed from the digital identity profile and transmits the receipt to the content source. The content source may determine whether or not to release content based on the data item in the device identification receipt. The method may comprise transmitting in the device identification receipt a fresh device authentication token.

The method may comprise a fresh content authentication token to the content source. The device identification receipt and the content source receipt may share a common transaction identifier.

The method may comprise the steps of transmitting from the local device an authentication token which is a randomly generated one-time use only credential bound to the local device to the verification service with the content authentication token.

The source of content may comprise a server, and the token may be bound to the server. The content source may comprise a server, and the content authentication token may be bound to a transient virtual device created by the server in a session establishment procedure instigated by the local device.

A confidence value may be associated with the data item and displayed with the data item.

Another aspect is directed to a computer system comprising:

a digital identity system configured to implement a validation service;

a local device comprising a network interface and a processor configured to execute a browser which operates to:

establish a communication session between a content source and the browser via the network interface, and

receive from the content source a validation page comprising a content authentication token which is a randomly generated one-time use only credential bound to the content source;

wherein a verification application captures the content authentication token from the browser and transmits the authentication token to a validation service which determines whether the token is bound to a valid source of content; and

wherein the validation service causes the content to be displayed on the local device if the token is bound to a valid source of content.

In embodiments, the verification application may be executed on the local computing device. The computer system may comprise a mobile device, which comprises a processor and a network interface, wherein the verification application is executed on the processor of the mobile device.

Another aspect is directed to a digital identity system for creating a computer stored digital identity comprising:

a network interface configured to send and receive electronic messages; persistent electronic storage;

a profile management module configured to receive from an entity an electronic message comprising a data item, extract the data item from the electronic message and store the data item in a digital profile in the persistent electronic storage;

a credential creation module configured to generate a credential for the profile and associate the credential with the digital profile;

a receipt generation module configured to automatically generate two non- matching receipts, each receipt comprising a transaction identifier, a first of the receipts comprising a link identifying the memory location to which the profile is published, a second of the receipts comprising the credential, wherein the first receipt is stored at the digital identity system and the second receipt is transmitted to an address associated with the entity; and

a publication module configured to publish the profile by storing a version of it to an addressable memory location;

In embodiments, a master receipt comprising data of each receipt may also generated and stored in a master receipt book at the digital identity system, whereby both the first and the master receipt are stored at the digital identity system. The master receipt may comprise only part of the first receipt. The master receipt may comprise the link but not the credential. For instance, the master receipt may comprise the link and the transaction identifier, but not the credential. Alternatively, the data of each receipt in the master receipt may be encrypted with the transaction identifier, wherein the master receipt does not include the transaction identifier.

The credential may be a randomised one-time only use credential. Multiple digital profiles associated with the entity may be created each profile being associated with a credential unique to that profile, wherein each digital profile may be published by assigning a unique set of data items for each digital profile to a corresponding addressable memory location.

The data item may be shared between the unique sets. For instance, one of the sets may consist only of the data item, and the remaining sets may each comprise the data item and at least one additional data item. The data item may be a visual image of the entity.

The multiple data items may be received in the electronic message and stored in the profile. Metadata available from a computer device associated with the entity may be received with the data item and stored at the digital identify system. The credential may be generated using the metadata. For instance, the credential may be generated by a hash of the metadata and a random salt. The random salt may be stored in association with the metadata, whereby a copy of the credential can be generated from the stored random salt and stored metadata. The credential may be generated by hashing the device metadata and the random salt a random number of times, wherein the random number may be stored in association with the random salt and the metadata. The metadata may comprise an identifier of the computer device (device identifier).

The credential may be associated with the digital profile by creating an entry in a database, the entry comprising the digital profile or an indicator which enables the digital profile to be located in the persistent electronic storage, wherein the publication module may be configured to use the credential as a key to that entry in the database to access the profile for publication.

The profile may be published in response to the credential being presented to the digital identity system. The credential is presented by a validating entity other than the entity, the credential having been provided to the validating entity by the entity. The credential may be one-time only use, and the credential creation module may be configured to generate a fresh credential in response to the credential being presented to the digital identity system, whereby another version of the profile is published to a different addressable memory location by the publication module in response to the fresh credential being presented to the digital identity system.

A device identifier may be received with the data item and stored at the digital identify system, wherein publication of the profile may be conditional on a matching device identifier being presented with the credential.

The link may be generated from and/or the memory location may be selected based on a randomly generated sequence. The link may be is a Uniform Resource Indicator (URI).

The digital identity system may comprise a confidence value management module configured to allocate a confidence value to the profile based on at least one of a source of the electronic message and a type of the data item. The confidence value may be published with the profile, whereby the confidence value and the profile are available to a requesting entity.

The confidence value may be changed over time based on a clock signal. Another aspect is directed to a computer-implemented method for creating a computer stored digital identity comprising:

receiving from an entity an electronic message comprising a data item;

extracting the data item from the electronic message;

storing the data item in a digital profile in the persistent electronic storage; generating a credential for the profile and associating the credential with the digital profile;

automatically generating two non-matching receipts, each receipt comprising a transaction identifier, a first of the receipts comprising a link identifying the memory location to which the profile is published, a second of the receipts comprising the credential;

storing the first receipt at the digital identity system; and

transmitting the second receipt an address associated with the entity; and publishing the profile by storing a version of it to an addressable memory location.

Another aspect is directed to a method of registering a digital identity comprising: capturing at a computer device a data item associated with an entity;

creating an electronic message comprising the data item;

transmitting the electronic message to a registration service;

receiving a receipt from the registration service;

extracting a credential from the receipt to render the credential available for accessing the data item for authenticating the entity; and

storing the receipt in a local receipt book at a location accessible to the computer device.

In embodiments, the data item may be captured in the form of an identifying datum from an identity document.

The data item may be captured the form of a photo taken by a camera of the computer device.

The first data item may be captured by one of: scanning, near field access; and Bluetooth.

The local receipt book may be held at a server accessible to the device.

Another aspect is directed to a method implemented by executing digital identity software on a processor of a user device to:

capture with a camera of the user device an image of the face of a user of the device;

capture data from a real-world identity document, the data including an identification photograph, wherein the data is captured with the camera, from an electronic transmitter embedded in the anchoring document, or a combination of both;

transmit the image of the user and the captured data to a digital identify system; and

receive from the digital identify system a credential for the user, wherein presentation of the credential to the digital identity system renders at least part of the captured data available to a presenting entity.

In embodiments, the captured data may also comprise an attribute of the document,

The identity document may be a passport or driving licence.

The user device is may be smart device, such as a smartphone or tablet. Another aspect is directed to a user device comprising:

a camera;

a processor configured to execute digital identity software which operates to: capture with the camera of the user device an image of the face of a user of the device;

receive from the digital identify system a credential for the user, wherein presentation of the credential to the digital identity system renders at least part of the captured data available to a presenting entity. Another aspect is directed to a computer implemented method implemented by a digital identity system, the method comprising:

receiving in an electronic message from a user device: an image of the face of a user of the user device which has been captured at the user device; and data which has been captured from a real-world identity document and which comprises an identification photograph;

storing at least part of the captured data at the digital identity system in persistent electronic storage;

comparing the image of the face with the identity photograph using a facial verification algorithm; and

only if the image of the face matches the identification photograph, generating a credential for the user and transmitting the credential to the user, wherein presentation of the credential to the digital identity system renders at least part of the stored data available to a presenting entity.

In embodiments, an attribute of the document may be received in the message, and the credential may be generated and transmitted only if the attribute meets a predetermined criteria. The photograph and/or image may be made available to the presenting entity.

Another aspect is directed to a digital identity system comprising:

a network interface configured to send and receive electronic messages;

a processor configured to perform operations comprising:

comparing the image of the face with the identity photograph using a facial verification algorithm;

only if the image of the face matches the identification photograph, generating a credential for the user; and

transmitting the credential to the user, wherein presentation of the credential to the digital identity system renders at least part of the stored data available to a presenting entity. Another aspect is directed to a method of authenticating a digital credential of a bearer by a validating device, the method comprising:

capturing the bearer credential by the validating device;

transmitting to a validation service the bearer credential with a validator credential bound to the validating device;

at the validation service, validating the bearer credential and the validation credential, and if the validator credential is valid, using the bearer credential to access a data item of a digital profile and creating an electronic message for transmission to the validating device, the electronic message indicating the data item and comprising a fresh validator credential generated by the validation service;

issuing a fresh bearer credential and creating an electronic message to transmit the fresh bearer credential to an address associated with the bearer.

In embodiments, the method may comprise the step of using the validator credential to access a data item of a digital profile associated with the validating device and creating an electronic message for transmission to the bearer, the electronic message indicating a data item for verification by the bearer.

The electronic message may indicate the data item by providing a link to a version of the digital profile held at an addressable memory location identified in the link.

The electronic message which indicates the data item for verification by the bearer may indicate the data item by providing a link to a version of the digital profile associated with the validator at an addressable memory location indicated by the link.

The data item may comprise a visual image of the bearer or validator respectively.

The fresh bearer credential may be generated for transmission to the bearer is comprised in a receipt having a transaction identifier. The validation service may generate a master receipt, wherein the master receipt may be stored in a master receipt book. The validation service may generate a master receipt having the same transaction identifier as the receipt generated for transmission to the bearer, wherein the master receipt may be stored in a master receipt book. Alternatively, part of the master receipt may be encrypted with the transaction identifier, in which case the transaction identifier is not included in the master receipt.

The fresh validator credential may be comprised in a non-matching receipt having the same transition identifier.

The address associated with the bearer may comprise an address of a device previously registered by the bearer and stored in association with the bearer credential.

The step of generating a fresh credential may comprise using a randomly generated sequence to generate a fresh credential bound to the digital profile.

The credentials may be one-time only use.

Another aspect is directed to a method of providing access to digital profiles held in persistent electronic storage of a digital identity system, the method comprising: receiving from a requesting entity an electronic request message identifying a target entity;

in response to the request, publishing: (i) a digital profile of the target entity by storing a version of that profile in an addressable memory location, and (ii) a digital profile of the requesting entity by storing a version of that profile in another addressable memory location;

generating two non-matching receipts, each comprising a transaction identifier, a first of which comprises a link identifying the memory location to which the target entity's profile is published, the second of which comprises a link identifying the other memory location to which the requesting entity's profile is published;

transmitting the first receipt to an address associated with the requesting entity; and

transmitting the second receipt to an address associated with the target entity.

In embodiments, a target credential may be associated with the target entity's profile and a requestor credential may be associated with the requesting entity's profile in a database of the digital identity system, and the step of publishing may be conditional on matching target and requestor credentials being received in the electronic request message. The credentials may be one-time use only, and the method may comprise generating a fresh target and a fresh requestor credential and associating them with the target entity's profile and the requesting entity's profile in the database respectively, the fresh target and requestor credentials being included in the second and first receipt respectively.

The method may comprise storing a master receipt at the digital identity system, the master receipt comprising data of both receipts and being stored in a master receipt book. The master receipts may comprise both links but may not include the fresh

credentials. The data of both receipts in the master receipt (e.g. the links) may be encrypted with the transaction identifier, in which case the transaction identifier is not included in the master receipt. The master receipt may comprise both links and the transaction identifier but may not include the fresh credentials.

The target entity may be a bearer and the requesting entity a validator, the bearer's profile being a pre-existing digital profile which is accessed in the persistent electronic storage in response to the request.

The target entity may be a registrant and the requesting entity may be an enrolment module of the digital identity system which has created the digital profile in the persistent electronic storage.

A respective confidence value may be allocated to each profile which is published with that profile and accessible via the respective link. Another aspect is directed to a computer system comprising a network interface configured to transmit and receive electronic messages, and a processor configured to implement the method of any preceding claim. Another aspect is directed to a digital identity system comprising:

a network interface configured to send and receive electronic messages; persistent electronic storage holding a digital profile of a target entity and a digital profile of the requesting entity;

a publication module configured to receive from the requesting entity an electronic request message identifying the target entity and, in response to the request, publish: (i) the target entity's digital profile by storing a version of that profile in an addressable memory location, and (ii) the requesting entity's digital profile by storing a version of that profile in another addressable memory location;

a receipt generation module configured to generate two non-matching receipts, each comprising a transaction identifier, a first of which comprises a link identifying the memory location to which the target entity's profile is published, the second of which comprises a link identifying the other memory location to which the requesting entity's profile is published, wherein the first receipt is transmitted to an address associated with the requesting entity and the second receipt is transmitted to an address associated with the target entity.

Another aspect is directed to a digital identity system comprising:

an enrolment module configured to receive a data item from an enrolling device and to create in persistent electronic storage a digital profile comprising the data item;

a credential creation module configured to generate a credential from a random sequence, to associate the credential with the digital profile in a database, and to transmit the credential to the enrolling device;

a publication module configured, in response to later presentation of the credential to the digital identity system, to publish the digital profile by storing a version of the digital profile in a memory location accessible to a device presenting the credential. In embodiments, the enrolment module may be configured to also receive metadata of the enrolling device, which is stored in the database in association with the profile.

The credential may be generated from the random sequence and the metadata, and the credential may be associated with the profile by storing the random sequence and the metadata in the database in association with the profile, and wherein the system may comprise a validation module configured to generate a copy of the credential from the sequence and metadata stored in the database, and the publication of the profile may be conditional on the presented credential matching the copy.

The metadata may comprise an identifier of the enrolling device, and the publication of the profile may also be conditional on a matching device identifier being presented with the credential, whereby use of the credential is restricted to the enrolling device.

The credential may be associated with the profile by storing a copy of the credential in the database in association with the profile, wherein the system may comprise a validation module configured to validate the presented credential by comparing it with the copy and the publication of the profile may be conditional in the presented credential being valid.

A link identifying the addressable memory location may be transmitted to the presenting device. The link may be generated from a random sequence. The addressable memory location may be selected based on a random sequence.

Another aspect is directed to a digital identity system according to claim 1 wherein the persistent electronic storage also holds another digital profile associated with another credential and comprising a data item which has been received from the presenting device, wherein both credentials are presented by the presenting device, and in response the other profile is published to a different memory location accessible to the enrolling device. In embodiments, the digital identity system may comprise a receipt generation module configured to generated two non-matching receipts, one of which is transmitted to the presenting device and comprises a link identifying the memory location to which the profile is published, the other of which is transmitted to the enrolling device and comprises a link identifying the other memory location to which the other profile is published.

The digital identity system according may comprise a confidence value allocation module configured to allocate a confidence value to the profile based on at least one of: a type of the received data item and a source of the data item.

Another aspect is directed to a method implemented at a digital identity system and comprising:

receiving a data item from an enrolling device;

creating in persistent electronic storage a digital profile comprising the data item;

generating a credential from a random sequence;

associating the credential with the digital profile in a database;

transmitting the credential to the enrolling device, wherein later presentation of the credential to the digital identity system causes publication of the digital profile by storing a version of the digital profile in a memory location accessible to a device presenting the credential.

Another aspect is directed to a method of providing access to a digital profile comprising:

receiving a one-time only use credential associated with a digital profile in persistent electronic storage;

validating the credential and, only if the credential is valid, publishing the profile to an addressable memory location by storing a version of it at the memory location, thereby invalidating the credential;

generating a fresh one-time only use credential for the digital profile;

associating the fresh credential with the digital profile; and transmitting the fresh credential to an address associated with an entity, whereby the entity can use the fresh credential once thereafter to cause the profile to be republished to a different addressable memory location. Another aspect is directed to a computer system comprising a network interface and a processor configured to implement the method.

Another aspect is directed to a computer system comprising:

electronic storage;

a network interface configured to receive electronic messages ;

a processor configured to execute identity management code which operates to:

receive an electronic message from the network interface, the message including at least one data item to be included in a digital profile for an entity, the data item associated with the entity and uniquely identifying the entity; extract the data item from the electronic message;

create and transmit a credential to the entity, wherein presentation of the credential to the computer system renders a version of the digital profile and the confidence value available to a presenting entity.

In embodiments, the electronic may hold a plurality of digital profiles associated with the entity, each digital profile comprising a unique set of data items for that digital profile. At least some of the data items may be shared between the unique sets. In embodiments, the electronic storage may hold anchoring documents in

association with the digital profiles, wherein an anchoring document may be received in the electronic message and the data item has been extracted from the anchoring document. The confidence value may be allocated based on the type and/or age of the anchoring document.

The confidence value may be allocated based on the source of the anchoring document.

The version of the profile may be rendered available by storing it to an addressable memory location, and transmitting a link identifying the memory location to the presenting entity.

The processor may be configured to create and transmit a credential each time a data item is stored in a digital profile, wherein presentation of each credential to the computer system may cause a respective version of it to be stored to a different addressable memory location, whereby multiple versions of the profile may be published.

The memory location may be selected based on a random sequence. The link mat be generated from a random sequence. The link may be a Uniform Resource Indicator.

One of the data items may be a visual image of the entity.

The entity may be a person and the visual image is a facial image of the person.

The electronic storage may comprise a device metadata storage section which holds metadata associated with computer devices which have been used to transmit electronic messages to the network interface. The electronic storage may hold one or more digital profiles for each of multiple entities.

The digital profile may comprise multiple data items received from the entity. The identity management code may be operable to allocate a confidence value associated with a source of the electronic message, such that when the source of the electronic message is unknown to the computer system, the confidence value is low.

When the source of the electronic message is known to the computer system, the identity management code may be operable to allocate a confidence value appropriate to the status of the source of the electronic message. When the source of the electronic message is a document issuing authority, the confidence value which is allocated may be high.

The identity management code may be operable to allocate a confidence value such that when one of the multiple entities which has a digital profile held in the electronic storage is the source of the electronic message, a contingent trust value associated with that entity is used to calculate the confidence value.

The contingent trust value may be dependent on usage of the digital profile by the multiple entities in one or more authentication process.

The identity management code may be operable to update the digital profile on receipt of further data items, and wherein the allocated confidence value is changed when the profile is updated. The processor may be configured to change the allocated confidence value over time based on a clock signal.

The confidence value may be increased in response to receiving an additional visual image of the entity.

The entity may be required to present a new data item when subsequently logging on to the system, and the confidence value may be changed based on the new data item. The new data item may be a visual image of the entity.

The identity management code may be operable to receive a data item from a third party to assign a profile to the entity, and wherein the confidence value which is allocated may depend on the status of the third party.

The electronic message may be received from the entity.

The electronic message may be received from another entity different than the entity.

The data item may be one of two data items are received in the message, a first of which is an image of the entity which has been captured with a camera and the second of which is an identification photograph which has been captured from a real- world identity document, and the confidence value may be allocated by comparing the two data items and may reflect an extent to which they match, The two data items may be compared using a facial verification algorithm.

Another aspect is directed to a computer-implemented method of managing a digital profile comprising: receive an electronic message including at least one data item to be included in a digital profile for an entity, the data item associated with the entity an uniquely identifying the entity;

extracting the data item from the electronic message;

creating a digital profile using the data item in electronic storage, wherein the profile comprises the data item;

allocating a confidence value to the profile, wherein the confidence value is allocated based on at least one of a source of the electronic message and a type of the data item; and

creating and transmitting a credential to the entity, wherein presentation of the credential to the computer system renders a version of the digital profile and the confidence value available to a presenting entity.

Another aspect of the uPass system is directed to a digital identity system

comprising a data store having at least one storage location, at which identity data of an entity is held; a computer interface configured to receive an electronic message, which identifies the storage location of the entity's identity data in the data store, wherein the message comprises a one-time use only credential of the entity; and a computer system configured to validate the credential and, if the credential is valid, retrieve the entity's identity data from the identified storage location, issue a fresh one-time use only credential to the entity, and publish the retrieved identity data by storing a version of it to an addressable memory location; wherein the computer system is configured to generate in a master receipt store a master receipt, wherein the master receipt comprises a link to the addressable memory location and an index which comprises a hash of the fresh credential.

In embodiments, the master receipt may also comprise a hash of the credential received in the electronic message.

The computer system may be configured to provide to another entity, in response to receiving a grant of access by the entity to the other second entity, a receipt comprising a copy of the link whereby the other entity can access the entity's published identity data.

The receipt may comprise a transaction identifier, wherein the link in the master receipt and/or the published identity data at the addressable memory location is encrypted with the transaction identifier.

The computer system may be configured to provide the receipt to the other entity only if it has received a valid one-time only use credential of the other entity in association with the grant of access, wherein in that event a fresh one-time only use credential is issued to the other entity by the computer system, wherein the master receipt comprises another index comprising a hash of the fresh credential issued to the other entity. The computer system may be configured to provide to the entity another receipt which comprises the same transaction identifier.

The grant of access may be denoted by the electronic message comprising the credential of the entity. The electronic message comprising the credential of the entity may be received from the entity. The electronic message comprising the credential of the entity may be received from the other entity.

In response to receiving a copy of the credential at a later time in an electronic search request message via the computer interface, the computer system may be configured generate a search index comprising a hash of the credential received in the search request message, use the search index to locate the master receipt in the master receipt.

The computer system may be configured generate a search index comprising a hash of the credential received in the electronic message, use the search index to locate in the master receipt store an earlier master receipt having an index that matches the search index, and generate a hash and/or a digital signature from at least part of the earlier master receipt, wherein the master receipt also comprises the hash of the at least part of the earlier master receipt.

The hash and/or the digital signature may be generated from substantially all of the earlier master receipt, including its index.

The other entity may hold a symmetric or private key, and the computer system may be configured to encrypt the other receipt using a version of the private key or a corresponding public key available at the digital identity system.

The entity may hold a symmetric or private key, and the computer system may be configured to encrypt the other receipt using a version of the private key or a corresponding public key available at the digital identity system.

The hash of the credential in the master receipt may be encrypted with the transaction identifier. The grant of access may be denoted by a later electronic message received via the computer interface after the electronic message comprising the credential of the entity. The electronic message may be a sharing token request received from the entity, wherein the computer system is configured, if the credential is valid, to issue to the entity in response a sharing token bound to the identity data in the identified storage location, wherein the other electronic message may be received from the other entity and comprise the sharing token.

Another aspect is directed to a method comprising implementing any of the above described system, device, application or other functionality.

Another aspect is directed to a computer program product comprising code stored on a computer readable storage medium and configured to implement any method, system or device functionality disclosed herein.

Whilst the above has been described with reference to specific embodiments, these are exemplary and other variations may be apparent to the skilled person. The scope is not limited by the described embodiments but only by the following claims.

Claims

Claims:

1 . A computer system for tracking assets comprising:

an asset tracking system comprising: a profile manager and electronic storage holding an initial profile of an asset in association with an asset identifier of the asset; a digital identity system comprising: a profile manager and electronic storage configured to hold profiles of entities;

a computer interface configured to receive asset transfer notifications, each asset transfer notification identifying the asset and a respective entity participating in a transfer of the asset;

wherein the profile manager of the digital identity system is configured to, each time an asset transfer notification is received, create in the electronic storage of the digital identity system an association between the asset identifier and a profile of the respective participating entity;

wherein the profile manager of the asset tracking system is configured to, each time an asset transfer notification is received, create in the electronic storage of the asset tracking system a new profile of the asset comprising an identifier of the respective participating entity, the new profile of the asset stored in association with the asset identifier.

2. A computer system according to claim 1 comprising an association module configured to, each time a new profile of the asset is created, associate the new profile of the asset with the next most recent profile of the asset, thereby creating a temporal sequence of profiles representing a chain of transfers of the asset.

3. A computer system according to claim 2 comprising a label generation module configured to: generate a label for each new profile in the sequence by applying a hash function to input data comprising data of that new profile and/or data of another profile in the sequence, wherein that label is associated with that new profile.

4. A computer system according to claim 3 wherein the other profile is an earlier profile in the sequence.

5. A computer system according to claim 4 wherein the earlier profile is the next most recent profile in the sequence.

6. A computer system according to claim 3 wherein the label for each new profile is also generated based on a secret key.

7. A computer system according to claim 6 wherein the secret key is also included in the input data to which the hash function is applied to generate the label.

8. A computer system according to claim 3 wherein the data of the earlier profile is used as a seed input to the hash function, and the data of that new profile is used as a content input to the hash function.

9. A computer system according to claim 3 wherein the label generation module is configured to generate a label for the initial profile by applying a hash function to at least data of the initial profile.

10. A computer system according to claim 1 wherein the profile manager of the digital identity system is configured to disassociate the asset identifier from a profile of the previous participating entity in the digital identify system when it creates the association in the digital identity system.

1 1 A computer system according to claim 1 configured to store an association between the asset identifier and a first proxy asset identifier; and

wherein the association between the asset identifier and the profile of the respective participating entity in the digital identity system is created by storing the proxy asset identifier in the electronic storage of the digital identity system in association with the profile of the respective participating entity.

12. A computer system according to claim 1 configured to store an association between the asset identifier and a second proxy asset identifier, each asset transfer notification comprising the second proxy identifier and thereby identifying the asset.

13. A computer system according to claim 1 comprising an access module configured to, in response to receiving an asset owner identity request identifying the asset: generate an electronic response message identifying a current owner of the asset based on the most recent profile in the sequence and/or based on the profile of the current owner in the digital identify system, and transmit the response message to an instigator of the request.

14. A computer system according to claim 13 wherein the response message renders available to the instigator a visual image of the current owner.

15. A computer system according to claim 1 wherein the initial profile comprises an identifier of an initial owner of the asset.

16. A computer system according to claim 1 wherein at least one of the profiles of the asset comprises an identifier of a participating entity which comprises:

a visual image of the participating entity, and/or

a link to stored identity data of the participating entity, and/or

a hash of at least part of a payment account number issued to the

participating entity.

17. A computer system according to claim 16 wherein the link in the at least one profile of the asset is a link to a version of the participating entity's profile in the digital identity system.

18. A computer system according to claim 17 wherein the digital identity system comprises a publication module configured to publish the participating entity's profile by storing a copy of it to an addressable memory location, the link in the at least one profile of the asset being a link to the addressable memory location.

19. A computer system according to claim 1 wherein multiple temporal sequences of profiles are stored in the electronic storage, each representing a chain of transfers of a different asset.

20. A computer system according to claim 19 comprising an analyser configured to perform an analysis of the multiple sequences;

wherein the assets are tickets to one or more events, and the analysis is performed to detect whether a touting condition is satisfied by at least one identifier of an entity that appears in at least some of the analyzed sequences.

21 . A computer-implemented method of tracking assets comprising:

at the asset tracking system: creating in the electronic storage of the asset tracking system a new profile of the asset comprising an identifier of the respective participating entity, the new profile of the asset stored in association with the asset identifier.

22. A computer system for tracking assets comprising:

electronic storage holding an initial profile of the asset in association with an asset identifier of the asset;

a computer interface configured to receive asset transfer notifications, each asset transfer notification identifying the asset and a respective participant in a transfer of the asset;

a profile manager configured to, each time an asset transfer notification is received, create in the electronic storage a new profile of the asset comprising an identifier of the respective participant;

an association module configured to, each time a new profile of the asset is created, associate the new profile with the next most recent profile of the asset, thereby creating a temporal sequence of profiles representing a chain of transfers of the asset; and a label generation module configured to generate a label for at least one profile in the sequence by hashing input data which comprises data of the at least one profile and data of at least one other profile at a known position in the sequence, and store the label in association with the at least one profile.

23. A computer-implemented method of tracking assets comprising:

creating in the electronic storage a new profile of the asset comprising an identifier of the respective participant, and

associating the new profile with the next most recent profile of the asset, thereby creating a temporal sequence of profiles representing a chain of transfers of the asset;

wherein the method also comprises:

storing the label in association with the at least one profile.

24. A bridge system for an asset tracking system and a digital identity system, the bridge system comprising:

an input configured to receive an asset transfer notification;

a first output configured to connect to a digital identity system;

a second output configured to connect to an asset tracking system; and electronic storage configured to store an association between an asset identifier and an associated proxy identifier;

wherein the bridge system is configured, in response to the asset transfer notification, to provide the asset identifier to the asset tracking system and the associated proxy identifier to the digital identity system.

25. A bridge system according to claim 24, which includes an asset identifier generator is configured to generate the asset identifier in response to an asset identifier request.

26. A computer system comprising:

a profile manager configured to: update the past ticket usage data associated with the requesting entity's profile based on the ticket use notification, whereby the updated past ticket usage data conveys whether the requesting entity presented the ticket themselves.

27. A computer system according to claim 26, wherein the updated past ticket usage data indicates the identity data of the requesting and presenting entities, and the processor(s) is configured to use the updated past ticket usage data to compare the identity data of the presenting entity with the identity data of the requesting entity to detect whether they match, wherein the ticket controller is configured to determine whether to reject a future ticket request from the requesting entity based on said comparison.

28. A computer system according to claim 26 wherein the identity data of the requesting entity and the identity data of the presenting entity are stored in the computer system and associated with a ticket identifier of the ticket; and

wherein the ticket use notification comprises the ticket identifier and thereby indicates the identity data of the requesting entity and the identity data of the presenting entity.

29. A computer system according to claim 38 wherein the identity data of the requesting entity forms part of the requesting entity's profile.

30. A computer system according to claim 39 wherein the ticket request comprises a credential bound to the requesting entity's profile, and the processor(s) are configured to implement a validation service for validating credentials, wherein the ticket is issued only if the credential is valid.

31 . A computer system according to claim 26 wherein the identity data of the requesting entity and the identity data of the presenting entity comprise a hash of at least part of a payment account number issued to the requesting entity and a hash of at least part of a payment account number issued to the presenting entity

respectively.

32. A computer system according to claim 26 wherein the identity data of the requesting entity and the identity data of the presenting entity each comprise a string unique to that entity.

33. A computer system according to claim 32 wherein the unique string of the presenting entity is received from the validating device in the ticket use notification, having been presented to the validating device with the ticket by the presenting entity.

34. A computer system according to claim 26 configured to associate a profile identifying a true owner of the ticket with the ticket identifier, wherein an identifier of the true owner is transmitted to and outputted by the validating device in response to the ticket being presented to the validating device, and the updating of the past ticket data is conditional on a user of the validating device indicating via the validating device that the presenting entity is the true owner.

35. A computer system according to claim 34 wherein the profile of the true owner is associated with the ticket identifier in response to receiving a change of ownership notification identifying the ticket and the true owner.

36. A computer system according to claim 34 wherein the profile of the true owner is the profile of the requesting entity.

37. A computer system according to claim 26 wherein the computer system comprises an asset tracking system, and the identity data of at least one of the entities forms part of a profile of the ticket in the asset tracking system, the ticket use notification identifying the profile of the ticket.

38. A computer system according to claim 26 wherein the computer system comprises an asset tracking system, wherein a profile of the ticket in the asset tracking system comprises a link to the identity data of at least one of the entities, the ticket use notification identifying the profile of the ticket and the link being used to retrieve the identity data of the at least one entity.

39. A computer system according to claim 26 wherein the processor(s) are configured to implement an association module configured, in response to the ticket request, to create an association in the data store between the requesting entity's profile and a ticket identifier of the issued ticket, and wherein and the ticket use notification comprises the ticket identifier and thereby indicates the identity data of the requesting entity; and

wherein the profile manager is configured to use the ticket identifier received in the ticket use notification to retrieve the identity data of the requesting entity for said comparison based on the association created by the association module.

40. A computer system according to claim 27 wherein said comparison is performed in response to receiving the future ticket request.

41 . A computer system according to claim 26 wherein the ticket use notification indicates the identity data of the presenting entity by identifying a profile of the presenting entity that comprises that identity data

42. A computer system according to claim 26 wherein the ticket use notification comprises the identity data of the presenting entity and thereby indicates it.

43. A computer system according to claim 26 wherein the ticket use notification comprises the identity data of the requesting entity and thereby indicates it.

44. A method implemented by a computer system comprising a data store holding a plurality of profiles, each of a respective entity and stored in association with past ticket usage data indicating a probability that the respective entity would personally use a ticket issued to them based on a history of past ticket usage, the method comprising:

45. A computer system for detecting ticket touting comprising:

a ticket issuer configured to selectively issue tickets to ticket requesting entities; electronic storage holding, for each of multiple issued tickets, an initial profile of that ticket in association with a ticket identifier of that ticket;

a computer interface configured to receive ticket transfer notifications, each ticket transfer notification identifying a respective one of the issued tickets and a respective entity participating in a transfer of the respective ticket;

46. A method of detecting ticket touting comprising:

47. A computer program product comprising code stored on a computer readable storage medium and configured when executed to implement the method or system functionality of any preceding claim.