METHOD AND SYSTEM FOR IDENTITY PROOFING Technical Field

[0001] The present invention generally relates to a method and system for identity proofing, and more particularly, for identity proofing under one or more identity verification assurance frameworks.

Background

[0002] An individual may be required to prove their identity to another party for various purposes. For example, some organisations, such as government agencies or financial institutions, require a person to prove their identity before delivering their services to that person. In order to access these services, a user may have to provide their personal information, e.g., in the form of identity documents, to different organisations every time proof of identity is required. This is commonly done by presenting the document to the relevant organisations in person or through an online submission process. Some organisations or institutions may require the user to prove their identity even if the identity information of the user has already been provided to the organisation or institution in a previous interaction (for example, in the acquiring of a different product or service).

[0003] The repetitive provision of identity information is not only burdensome to the user, but also increases the risk of the user's personal identity information being misused or leaked to a third-party, which in turn could lead to an increased risk of identity crime. According to a report issued by the Australian Government, identity crime is now amongst the most prevalent of all types of crime in Australia. Each year around 4 -5 percent of Australians experience identity crime resulting in a financial loss. The security of identity documents, and the way they are provided and used, have become a critical issue facing many organisations and their users.

[0004] It is desired to address or ameliorate one or more disadvantages or limitations associated with the prior art, or to at least provide a useful alternative. Summary

[0005] In at least some embodiments, the present invention provides a computer- implemented method for identity proofing , the method including the steps of:

(a) retrieving, from a data store, a group of identity attributes associated with a person;

(b) obtaining a set of identity assurance requirements;

(c) determining whether a subset of the group of identity attributes matches the set of identity assurance requirements; and

(d) notifying a computing process whether a subset of the group of identity attributes matches the set of identity assurance requirements.

Brief Description of the Drawings

[0006] Some embodiments of the present invention are hereinafter described, by way of example only, with reference to the accompanying drawings, wherein:

[0007] Fig. 1 is a schematic diagram of an exemplary system for identity proofing;

[0008] Fig. 2 is an exemplary workflow for identity proofing executed by a server 110 of Fig. 1;

[0009] Fig. 3 is an example of a digital identity profile and a set of identity assurance requirements;

[0010] Fig. 4 are examples of existing assurance frameworks;

[0011] Fig. 5 is an exemplary assurance framework including a plurality of assurance levels; [0012] Figs. 6A and 6B illustrate a detailed example of a workflow for identity proofing; [0013] Fig. 7 is a schematic diagram of an example of the server 110 shown in Fig. 1 ;

[0014] Fig. 8 is a schematic diagram of an example of a terminal computing device 120 shown in Fig. 1;

[0015] Figs. 9 - 11 are examples of Document- Attribute-LoA graphs;

[0016] Figs. 12 and Fig. 13 are examples of a user interface for registration to the identity proofing service;

[0017] Figs. 14 - 19 are examples of a user interface for identity verification based on an existing digital identity profile;

[0018] Figs. 20 - 24 are examples of a user interface for registration and verification of an digital identity profile; and

[0019] Figs. 25 - 29 are examples of a user interface for verification of identity documents through a video call.

Detailed Description

[0020] Described herein is a method and a system for identity proofing, using which a user can provide identity information to one or more parties to prove their identity in a secure and convenient manner. The provided identity information may be stored and reused in future identity proofing processes.

[0021] In some embodiments, the described method and system may automatically determine the potential "gaps" between the provided personal information of the user and the identity information required to sufficiently prove the identity of the user, and may guide the user to provide further identity information to fill these gaps.

[0022] In some further embodiments, the described method and system may be capable of applying one or more assurance frameworks to the identity information provided by the user, each of which may include different assurance levels. The described method and system may match the identity information provided by the user to one of these assurance levels. The provided method and system allows the application of the assurance frameworks to be conducted in an efficient and user-friendly manner.

General structure of the system

[0023] An example of a system for identity proofing will now be described with reference to Fig. 1.

[0024] In this example, the system 100 includes a server 110 and at least one terminal computing device 120, the terminal computing device 120 being used by a user 130. The terminal computing device 120 and the server 110 together collect and manage personal identity information about the user 130, and provide proof of identity for the user 130. The server 110 and the terminal computing device 120 are in communication with one another via at least one communication network 140. The server 110 is also in communication with at least one local or remote data store 150.

[0025] In addition, the server 110 may further be in communication with at least one verification server 170 via at least one communication network 160. The verification server 170 may be operated by an authoritative source (e.g., an issuing authority of one or more identity proofing documents, or a representative of the issuing authority) that provides an identity information verification service. The verification server 170 may be in communication with at least one local or remote data store 171 for storing identity information, e.g., identity information related to identity proofing documents issued for one or more individuals by the issuing authority.

[0026] Further, the server 110 may also be in communication with a proof-requesting server 190 via at least one communication network 180. The proof-requesting server 190 may be operated by a party that seeks proof of the identity of the user 130, e.g., a financial institution, a government organisation, a third-party merchant, or a third-party website. [0027] The communication networks 140, 160 and 180 between the server 110, the terminal computing device 120, the verification server 170 and the proof-requesting server 190 may be direct communication, or indirect communication through one or more intermediate electronic processing devices. For example, a gateway server may be provided between the server 110 and the terminal computing device 120 for controlling the data communication between the server 110 and the terminal computing device 120.

[0028] The terminal computing device 120 may be any suitable type of terminal electronic device, including, e.g., a mobile telephone handset, a portable computer, a tablet computer, a desktop personal computer, or the like. Although only one terminal computing device 120 is illustrated in Fig. 1, the server 110 may be in communication with and serve a plurality of terminal computing devices used by the same user 130 or different users.

[0029] Preferably, the terminal computing device 120 is a smart phone on which one or more mobile applications can be installed and executed.

Outline of the identity proofing process

[0030] An exemplary workflow 200 for identity proofing executed by the server 110 is illustrated in Fig. 2.

[0031] At step 210, the server 110 retrieves, from a data store, a group of identity attributes associated with a person, e.g., the user 130. Each identity attribute represents a piece of information relating to the identity of that person, for example, a person's name, gender, date of birth (DoB), residential address, nationality, identification number, passport number, or driver's license number.

[0032] At least one of the identity attributes includes:

(i) attribute type data; and

(ii) attribute metadata. [0033] The attribute type data indicates what type of personal identity information that identity attribute represents, e.g., name, gender, date of birth, or residential address.

[0034] The attribute metadata indicates other related information of that identity attribute. For example, it may include one or more of the following:

• document type data, representing the type of identity document from which the identity attribute was derived;

• recency data, representing when the identity attribute was obtained;

• collection mode data, representing how the identity attribute was obtained; and

• verification data, representing whether the identity attribute has been verified by a third party.

[0035] The document type data indicates the type of identity document an identity attribute has been extracted from, for example, an Australian passport, a foreign passport, a driver's license, a Medicare card, a bank card, a student card, a birth certificate, or a national identity card.

[0036] Identity attributes having the same attribute type data may have different attribute metadata, including different document type data. For example, identity attributes having the attribute type of "date of birth" may be extracted from a person's passport, driver's license, and birth certificate. Accordingly, the document type data indicates the type of document from which the "date of birth" information is extracted, and may indicate that it has been extracted from all three document types.

[0037] The recency data indicates when the identity attribute was obtained, which may include, for example, one or more of the following:

• a time when the identity attribute is input into the system 100 or updated by the user 130; • a time when data derived from the identity document from which the identity attribute is extracted is input into the system or updated by the user 130;

• a time of the latest verification of the identity document by a human verifier;

• a time of the latest verification of the identity attribute or aspects of the associated identity document with an authoritative source (e.g., an issuing authority);

• a time of the latest successful use of the identity attribute for identity proofing; and

• a time of the latest login of a user into the system.

[0038] The recency data may be recorded in the form of an absolute time (e.g., a date, or a time and date), or a time period since the relevant event.

[0039] In some embodiments, the recency data may also include an expiry date or renewal date of an identity document associated with an identity attribute, for example, an expiry date of a passport or a driver's license. Alternatively, in some other embodiments, the expiry date or renewal date of an identity document may be stored as a separate identity attribute.

[0040] The collection mode data indicates how the identity attribute was obtained, including for example, whether the identity attribute was manually input by a user or human verifier, retrieved from another application or a web server (e.g., a social media website that stores the user's personal information), automatically extracted from an identity document (e.g., by processing a captured image of an identity document or reading from an electronic identity document or an electronic chip embedded in an identity document via wireless communication such as NFC, RFID or Bluetooth), and/or whether the image of the identity document is captured by scanning the document, or by the user taking a digital photo of the document.

[0041] The verification data indicates whether the identity attribute has been verified, including for example, whether the identity attribute or the related identification document has been verified by or with reference to an authoritative source (e.g., an issuing authority of the related identification document), and/or whether a comparison of a person's face against a photograph on an identity document has been conducted (e.g., automatically checked using facial recognition technique, or manually checked by a human verifier meeting the user in person or through a video conversation). The verification data may further include: the time and/or location information of the conducted verification, information identifying the human verifier who has performed the verification, and/or a reference number associated with the verification conducted by or with reference to an authoritative source.

[0042] An identity attribute is not required to have all the four types of attribute metadata described hereinbefore. Some identity attributes may have one, two or three types of attribute metadata. Some other identity attributes may not have any attribute metadata. Further, in addition to or as an alternative to the types of attribute metadata described above, an identity attribute may have any other suitable type of attribute metadata.

[0043] In addition to the attribute type data and attribute metadata, an identity attribute may further include attribute value data, which represents the actual value of the identity attribute.

[0044] For example, for an identity attribute having a "date of birth" type, the attribute value data may include the actual date of the person's day of birth. For each type of identity attribute, the corresponding attribute value data may have a unified format, or different formats. For example, the "date of birth" information extracted from different identity documents may have different formats, such as dd-mm-(yy)yy, yyyy-mm-dd, or yyyymmdd.

[0045] Further, the attribute value data included in some or all identity attributes may be encrypted, and stored in an encrypted form.

[0046] For example, the attribute value data may be encrypted using a public key of a key- pair generated for a specific user or a specific terminal computing device, and can only be decrypted using the private key stored in that terminal computing device. In this way, use of the attribute value data for identity proofing would require the user's explicit authorisation to allow access to the private key for decryption. The authorisation may be performed by, e.g., the user entering a password or a personal identification number (PIN), or conducting a biometric authentication process. This may allow the user to have strict control over the use of their personal identity information (which may be confidential and sensitive), thereby enhancing the security of the identity proofing system.

[0047] An identity attribute may be in the form of a direct identity attribute or a synthetic identity attribute.

[0048] A direct identity attribute represents information directly presented by an identity document and may include, for example, the name of a person, the date of birth of a person, the nationality of a person, a passport number, or a driver's license number. Direct identity attributes may also include an indication that a certain type of identity document has been provided, e.g., that a passport has been provided, or a driver's license has been provided.

[0049] A synthetic identity attribute represents information derived from one or more direct identity attributes presented by an identity document. For example, from the date of birth information, a synthetic identity attribute may be derived to indicate whether a person is over 18 years' old. From an expiry date of a driver's license, a synthetic identity attribute may be derived to indicate whether a person is allowed to drive.

[0050] The group of identity attributes (which may include one or a plurality of identity attributes) is associated with one person, and may be stored within a digital identity profile of that person. For example, a digital identity profile may be created when a user registers with (i.e., enrols to) the identity proofing service. During registration, the user may be required to input their identity attributes or upload one or more identity documents. The attribute value data manually input by the user or automatically extracted from the captured identity documents may be encrypted, and stored together with the associated attribute type data and attribute metadata in a digital identity profile for that user.

[0051] The group of identity attributes (e.g., included in a digital identity profile) may be stored in a data store to which the server 110 has access, e.g., the local or remote data store 150. For example, the identity attributes may be generated at the terminal computing device 120, and sent from the terminal computing device 120 to the server 110 via the communication network 140 to enable storage of the identity attributes in the data store 150. [0052] An exemplary digital identity profile 310 including a group of identity attributes is illustrated in Fig. 3. The digital identity profile 310 includes ten identity attributes, No. 1 - No. 4 of which are derived from a person's driver's license, No. 5 - No. 8 of which are derived from a person's passport, while No. 9 and No. 10 are additional information manually added by a user.

[0053] Referring back to Fig. 2, at step 220, the server 110 obtains a set of identity assurance requirements, e.g., by retrieving a stored set of identity assurance requirements from a data store.

[0054] The set of identity assurance requirements may include one or a plurality of identity assurance requirements. Each identity assurance requirement represents a requirement for assessing the assurance of, or confidence in, the proof of a person's identity, which may include, for example, any of the following:

• the type of identity attribute;

• the type of identity document from which the identity attribute is obtained or derived;

• whether the identity attribute has been verified;

• whether the identity attribute is still valid;

• whether the identity attribute is sufficiently recently obtained; and

• whether the attribute value of the identity attribute meets specified requirements.

[0055] As described hereinbefore, an identity attribute may include attribute type data and attribute metadata. Correspondingly, the identity assurance requirements may include: one or more attribute type requirements, and/or one or more attribute metadata requirements.

[0056] An attribute type requirement may require a specified type of identity attribute to be provided, e.g., that the person's full name has to be included in the group of identity attributes, or that the person's date of birth has to be included in the group of identity attributes.

[0057] An attribute metadata requirement may require attribute metadata of one or more identity attribute to satisfy one or more specified conditions, for example: the identity document from which an identity attribute has been derived must be either a passport or a driver's license; the identity document from which an identity attribute is derived must have be verified by or with reference to an authoritative source (e.g., an issuing authority of that identity document); or the user must have used the identity attribute for identity proofing in the last three months.

[0058] An exemplary set of identity assurance requirements 320 including five identity assurance requirements is illustrated in Fig. 3, the five of identity assurance requirements are:

• (i) the group of identity attributes must include: a person's full name, date of birth, nationality, a Medicare card number, and residential address;

• (ii) the person's full name and date of birth must be derived from a driver's license;

• (iii) the Medicare card number must be derived from a Medicare card, provided through a digital photo or scan of the Medicare card;

• (iv) the driver's licence from which the person's full name and date of birth are derived must have been checked by a human verifier; and

• (v) the residential address has been used by the system for identity proof in the last 12 months.

[0059] In some embodiments, the set of identity assurance requirements may be received by the server 110 from a third-party server, e.g., the proof-requesting server 190 operated by a party requesting proof of the identity of the user 130, such as a financial institution, a government organisation, a third-party merchant, or a third-party website. Different third- parties may provide different sets of identity assurance requirements to the server 110. [0060] Alternatively, in some other embodiments, the set of identity assurance requirements may be retrieved from a local or remote data store accessible by the server 110, for example, the data store 150 that stores the group of identity attributes, or a different data store separate from the data store 150. As will be described in further detail hereinafter, the set of identity assurance requirements may be associated with an assurance level of an assurance framework.

[0061] Next, at step 230, the server 110 determines whether a subset of the group of identity attributes matches the set of identity assurance requirements.

[0062] This may be performed by, for example, comparing each identity assurance requirements with related identity attributes.

[0063] For example, when comparing the group of identity attributes included in the exemplary digital identity profile 310 shown in Fig. 3 with the set of identity assurance requirements 320, the server 110 would determine that those identity attributes match the identity assurance requirements (ii) and (v), but fail to match the identity assurance requirements (i), (iii) and (iv).

[0064] After the determination in step 230, the server 110 then proceeds to step 240 to notify a computing process of the determination result, i.e., whether a subset of the group of identity attributes matches the set of identity assurance requirements.

[0065] This may be followed by, for example, the computing process sending to the terminal computing device 120 a notification indicating the determination result. The computing process may be the process that requests server 110 to determine whether a subset of a group of identity attributes matches the set of identity assurance requirements. Alternatively, it could only be a process responsible for acting on the notification sent to it. It may be a process running on the server 110, on the proof-requesting server 190, or on another server or computing device connected to server 110 by a communications network or link.

[0066] Upon receiving the notification, as described above the computing process may sent to the terminal computing device 120 a notification indicating the determination result. Alternatively or in addition, the computing process may notify the proof -requesting sever 190 of the determination result, or may undertake additional computing or other steps based on the determination result. For example, an application for a loan may be dependent on the result, and based on the result, the computing process may approve or deny a loan.

[0067] As shown in Fig. 2, if no subset of the group of identity attributes matches the set of identity assurance requirements, the server 110 may further perform a gap analysis process 250, to determine the gap between the group of identity attributes and the set of identity assurance requirements.

[0068] The gap analysis process may include: determining at least one incomplete or missing identity attribute required to be added, updated, or augmented to match the set of identity assurance requirements.

[0069] This may be performed by, for example, comparing the identity assurance requirements that have not yet been met with the group of identity attributes.

[0070] For example, when comparing the group of identity attributes included in the exemplary digital identity profile 310 shown in Fig. 3 with the identity assurance requirements (i) (iii) and (iv) which have not been matched, the server 110 may determine that based on (i), at least an identity attribute of a Medicare card number needs to be added to the digital identity profile 310.

[0071] The server 110 may notify a computing process of the incomplete or missing identity attribute(s), e.g., by sending a notification to the terminal computing device 120.

[0072] For example, in the above-described example, the server 110 may send a notification to the terminal computing device 120, indicating that a Medicare card number needs to be added into the digital profile 310.

[0073] The gap analysis process may further include: determining at least one additional identity document that provides the incomplete or missing identity attribute; and notifying a computing process of the at least one additional identity document.

[0074] The determination may be performed by, for example, comparing the identity assurance requirements on identity document type with the group of identity attributes.

[0075] For example, in the example shown in Fig. 3, the server 110 may determine that based on the identity assurance requirement (iii), a Medicare card needs to be provided by the user for deriving the Medicare card number.

[0076] The server 110 may then send a notification to the terminal computing device 120, indicating that a Medicare card needs to be provided.

[0077] As described hereinbefore, the set of identity assurance requirements may include one or more attribute metadata requirements. Accordingly, the gap analysis process performed by server 110 may include: determining at least one piece of incomplete or missing attribute metadata required to match the attribute metadata requirement.

[0078] For example, in the above-described example, the server 110 may determine that according to the identity assurance requirement (iv), a driver's licence from which the person's full name and date of birth are derived must have been checked by a human verifier, which requirement has not been met by the attribute metadata associated with the identity attributes No. 1 and No. 2.

[0079] Accordingly, the server 110 may notify a computing process of the incomplete or missing attribute metadata, e.g., by sending a notification to the terminal computing device 120, indicating that the driver's licence has not been checked by a human verifier.

[0080] Further, the server 110 may determine at least one identity information collection mode that provides or completes the incomplete or missing attribute metadata, and subsequently notify a computing process of the determined identity information collection mode. [0081] For example, in the above-described example, the server 110 may determine that according to the identity assurance requirement (iii), a Medicare card needs to be provided by taking a digital photo of, or scanning, the Medicare card. The server 110 may send a notification to the terminal computing device 120 identifying the information collection modes.

[0082] In some embodiments, when a plurality of alternative identity information collection modes may be used to provide or complete incomplete or missing attribute metadata, the server 110 may select an optimised identity information collection mode from the plurality of alternative identity information collection modes. This may be performed by, for example: assigning to each possible identity information collection mode a predetermined friction value indicating how much effort it would require for a user to provide an identity attribute or identity document using that identity information collection mode; and selecting, from the plurality of alternative identity information collection modes, an identity information collection mode with the lowest friction value.

[0083] For example, an identity attribute may be provided through one or more of the following identity information collection modes:

(A) the user inputting an identity attribute;

(B) the user using an application to retrieve identity information from another application or a web server (e.g., a social media website that stores the user's personal information);

(C) the user taking a digital photo of an identity document;

(D) the user scanning an identity document;

(E) the user using the terminal computing device 120 to read an electronic chip embedded in an identity document via one or more wireless communication channels (e.g., NFC, RFID, Bluetooth, or the like); (F) a human verifier checking an identity document through a video call with the user; and

(G) a human verifier meeting the user in person at a predetermined location and checking or sighting an identity document.

[0084] For instance, the friction value assigned to each of the identity information collection modes (A) to (G) may be 1, 2, 3, 4, 5, 6, and 7, respectively. Two or more collection modes may be assigned the same friction value.

[0085] As an example, an identity attribute may be provided either by the user inputting an identity attribute (Mode A) or by a human verifier checking an identity document via a video call with the user (Mode F). Accordingly, the server 110 may select the former, as Mode A has a lower friction value than Mode F.

[0086] In the example shown in Fig. 3, the Medicare card number may be provided either by the user taking a digital photo of the Medicare card (Mode C) or scanning the Medicare card (Mode D). Accordingly, the server 110 may choose the option of taking a digital photo (Mode C), as Mode C has a lower friction value than Mode D.

[0087] Although in the above-described example the five different identity information collection modes have different friction values, in some other embodiments, at least some identity information collection modes may have the same friction value, and may be selected and provided to the user together.

[0088] In some other embodiments, the friction value may take any other suitable forms, e.g., a number between 1 and 100. In some further embodiments, the level of difficulty or onerousness of an identity information collection mode may be indicated by a ranking, rather than a numeric value.

[0089] Further, in some embodiments, the available identity information collection modes may be selected by the user, e.g., through a user input on the terminal computing device 120, or automatically selected by the terminal computing device 120. [0090] For example, when the terminal computing device 120 is a mobile phone, the terminal computing device 120 may determine whether taking a digital photo of an identity document or conducting a video call with a human verifier is an available identity information collection mode based on the hardware or software facilities of the terminal computing device 120, e.g., whether a mobile application having the video call function has been installed on the terminal computing device 120. As described hereinbefore, each identity information collection mode may be associated with a predetermined friction value.

Levels of assurance

[0091] It is not always be necessary or appropriate to confirm a person's identity with a high degree of confidence or assurance, particularly for transactions or services that have a low value or involve low risk. A number of assurance frameworks have been adopted by different organisations in different countries and regions, to provide guidelines for a risk-based approach to identity proofing using varying levels of assurance (which may also be referred to hereinafter as "assurance levels" or "LoAs").

[0092] An assurance framework typically includes a plurality of levels of assurance, each requiring a different degree of confidence in identity information provided by a person.

[0093] Some existing assurance frameworks are illustrated in the table 400 of Fig. 4, each of which includes three or four levels of assurance.

[0094] For example, the Australian National Identity Proofing Guidelines provides four levels of assurance:

• Level 1 - Low;

• Level 2 - Medium;

• Level 3 - High; and

• Level 4 - Very high. [0095] A detailed description of the specific requirements for each level of the Australian National Identity Proofing Guidelines is provided on the Australian Government's website (https://www.ag.gov.au/RightsAndProtections/IdentitySecurity /Pages/Identity-security- guidelines-and-standards.aspx).

[0096] In some embodiments, the assurance level may include a predefined assurance level rather than an assurance level in an existing assurance framework, the predefined assurance level including one or more predefined identity assurance requirements against predetermined verifiable identity attributes, e.g., a requirement of date of birth for proof of age.

[0097] In the method and system as described hereinbefore, the set of identity assurance requirements may be associated with an assurance level of an assurance framework. That is, the described embodiments may be used to match a group of identity attributes associated with a person to a level of assurance in an assurance framework. This may be performed by: retrieving stored requirement-framework relationship data representing a relationship between a plurality of identity assurance requirements and a plurality of assurance levels of a first assurance framework; and determining whether a subset of the group of identity attributes matches identity assurance requirements of an assurance level of the first assurance framework based on the requirement -framework relationship data.

[0098] The requirement-framework relationship data may indicate what identity assurance requirements each level of an assurance framework requires, e.g., in the form of a table 500 as illustrated in Fig. 5.

[0099] As shown in Fig. 5, the table 500 illustrates an exemplary assurance framework (Assurance framework No.l) having the following three assurance levels:

• Level 1 - Low;

• Level 2 - Medium; and • Level 3 - High.

[00100] Each of Level 1 to Level 3 requires a different set of identity assurance requirements: Rl-1 to Rl-2, R2-1 to R2-3, and R3-1 to R3-5, respectively.

[00101] The assurance level with which the group of identity attributes are compared may be selected from the plurality of assurance levels of the assurance framework based on at least one of: a request from a third-party server; an input from the person; or a request from the computing process.

[00102] Preferably, the assurance level with which the identity attributes are compared is determined by a third-party that seeks proof of the identity of the user, e.g., a financial institution, a government organisation, a third-party merchant, or a third-party website. The required assurance level may be determined by the server 110, e.g., by querying the proof- requesting server 190 operated by the third-party.

[00103] In some other embodiments, the assurance level may be selected by the user

130, through a user input on the terminal computing device 120, e.g., by selecting one item from a menu including multiple assurance levels.

[00104] In embodiments where the assurance level is determined by a third party (by a request from a third-party server) or a request from the computing process, an initial calculation may be made of whether a subset of the group of identity attributes matches the set of identity assurance requirements associated with the requested assurance level. If no subset of the group of identity attributes matches the set of identity assurance requirements associated with the requested assurance level, the server 110 may then proceed to perform the gap analysis process 250 to determine the gap between the group of identity attributes and the requirements in the requested assurance level that cannot be matched. In addition, the server 110 may also compare the identity attributes with the identity assurance requirements associated with assurance levels of other assurance frameworks to calculate whether any assurance levels of any other assurance frameworks can be assigned to the digital identity profile 310.

[00105] In some other embodiments, the server 110 may automatically select an assurance level in the assurance framework.

[00106] For example, the server 110 may run through the assurance levels of the assurance framework one by one, starting from the assurance level that has the lowest requirements. If a subset of the group of identity attributes matches the set of identity assurance requirements associated with the lowest assurance level, the server 110 proceeds to the second lowest assurance level, and determines whether the second lowest assurance level can also be matched.

[00107] In this way, the server 110 may perform the steps 210 - 230 of Fig. 2 for each assurance level from the lowest to the highest, until an assurance level cannot be matched by any subset of the group of identity attributes.

[00108] The server 110 may then assign the highest assurance level that a subset of the group of identity attributes of a user can match to the digital identity profile associated with that user.

[00109] For example, for the exemplary digital identity profile 310 shown in Fig. 3, the server 110 may run through Level 1 (Low) and Level 2 (Medium), and determine that the requirements of Level 3 (High) cannot be matched, therefore assigning Level 2 (Medium) of the assurance framework to the digital identity profile 310.

[00110] In some other embodiments, this level-by-level determination could be done in reverse, i.e., from the highest assurance level to the lowest assurance level, until an assurance level cannot be matched by a subset of the group of identity attributes.

[00111] In some other embodiments, when the server 110 determines that an assurance level cannot be matched, the server 110 may then proceed to perform the gap analysis process 250, to determine the gap between the group of identity attributes and the requirements in the assurance level that cannot be matched (e.g., Level 3 in the above example).

[00112] For example, the server 110 may perform one or more of the following steps which have been described in detail hereinbefore:

• determining at least one incomplete or missing identity attribute required to be added, updated, or augmented to match the set of identity assurance requirements;

• determining at least one additional identity document that provides the incomplete or missing identity attribute;

• determining at least one piece of incomplete or missing attribute metadata required to match the attribute metadata requirement(s); and

• determine at least one identity information collection mode that completes the incomplete or missing attribute metadata.

[00113] In some embodiments, the server 110 may determine a potential assurance level that the user can match by providing more identity attributes or more identity documents, and may notify the user of the identity documents to be provided to match this potential assurance level. The potential assurance level may be, e.g., an assurance level that is one level higher than the assurance level that the user's identity attributes currently match.

[00114] In some embodiments, the method and system described herein may support a plurality of different assurance frameworks, e.g., some or all the assurance frameworks shown in table 400 of Fig. 4.

[00115] The assurance framework to be used for matching the group of identity attributes may be selected from the plurality of assurance frameworks based on at least one of: a request from a third-party server; an input from the person; or a request from the computing process.

[00116] Preferably, the assurance framework is determined by a third-party that seeks proof of the identity of the user, e.g., a financial institution, a government organisation, a third-party merchant, or a third-party website. The required assurance framework may be determined by the server 110, e.g., by querying the proof-requesting server 190 operated by the third-party.

[00117] In some embodiments, the assurance framework may be selected by the user

130, through a user input on the terminal computing device 120, e.g., by selecting one item from a menu including multiple assurance frameworks.

[00118] In some other embodiments, the server 110 may automatically select an assurance framework. For example, the selection may be based on a predetermined default assurance framework.

[00119] In some further embodiments, the server 110 may compare the group of identity attributes to a plurality of assurance frameworks, and provide the result for each assurance framework respectively.

[00120] In some other embodiments, the server 110 selects a first assurance framework and the assurance level in the first assurance framework based on the request from a third- party server, e.g., the proof-requesting server 190, and determines whether the group of identity attributes matches this selected assurance level. Regardless of whether the server 110 determines that the group of identity attributes matches this assurance level in the first assurance framework selected by the third-party server, the server 110 may proceed to determine whether the group of identity attributes matches any other assurance level in other predefined assurance frameworks,

[00121] Further, in some embodiments, inter-framework relationship data representing the relationships between assurance levels of different assurance frameworks may be stored in a data store accessible by the server 110, e.g., the local or remote data store 150. [00122] When the server 110 has determined a matched assurance level in a first assurance framework for a group of identity attributes, the server 110 may retrieve the stored inter-framework relationship data from the data store, and then determine whether a subset of the group of identity attributes matches identity assurance requirements of an assurance level of a second assurance framework based on the inter-framework relationship data.

[00123] For example, when the server 110 has determined that the group of identity attributes in the digital identity profile 310 shown in Fig. 3 match the requirements of Level 2 (Medium) in Assurance framework No. 1 as shown in Fig. 5, knowing that Level 2 (Medium) in Assurance framework No. 1 corresponds to a Level 3 in another assurance framework (Assurance framework No. 2), the server 110 may then determine that the digital identity profile 310 also matches Level 3 in Assurance framework No. 2, without conducting a detailed comparison between the group of identity attributes in the digital identity profile 310 and the identity assurance requirements in Level 3 of Assurance framework No. 2.

[00124] By such mapping between different assurance frameworks, the computing efficiency and speed of assigning assurance levels from different assurance frameworks may be significantly improved.

[00125] Further, in mapping the group of identity attributes to a second assurance framework, if the server 110 determines that no subset of the group of identity attributes matches identity assurance requirements of an assurance level in the second assurance framework, the server 110 may further perform a gap analysis process, as described in detail hereinbefore, to determine the gap between the group of identity attributes and the assurance level of the second assurance framework.

[00126] The above-described process may also be applied to more than two assurance frameworks, e.g., three, four, or more assurance frameworks.

[00127] The method and process for identity proofing as described hereinbefore may be performed at any suitable time point, e.g., in response to one or more of the following events: (i) an identity authentication request is received, e.g., from the terminal computing device 120 or the proof-requesting server 190;

(ii) a new group of identity attributes is received;

(iii) a new set of identity assurance requirements is received;

(iv) at least one new identity attribute is added to the group of identity attributes;

(v) at least one identity attribute in the group of identity attributes is updated;

(vi) at least one new identity assurance requirement is added to the set of identity assurance requirements; and

(vii) at least one identity assurance requirement in the set of identity assurance requirements is updated.

[00128] An exemplary workflow 600 for identity proofing is illustrated in Figs. 6A and 6B.

[00129] In this example, the server 110 performs identity proofing for the user 130 who is using the terminal computing device 120. As shown in Figs. 6A and 6B, the identity proofing process may be carried out by four software or hardware components of the server 110:

• an identity component, for establishing a secured session with the terminal computing device 120 and creating a digital identity profile (may also be referred to as "a shell identity") for the user 130;

• an assurance component, for determining whether a set of identity assurance requirements associated with an assurance level of a first assurance framework are matched, and performing the gap analysis process if the requirements are not matched; • an evidence component, for receiving identity information and/or identity documents sent by the user 130 from the terminal computing device 120, and verifying the identity information and/or identity documents with an authoritative source, e.g., by sending a verification request to the verification server 170 and receiving a verification result from the verification server 170 operated by an authoritative source (e.g., an issuing authority of one or more identity proofing documents, or a representative of the issuing authority); and

• an attribute component, for generating and updating identity attributes based on the identity information and/or identity documents received.

[00130] Preferably, the identity component, the assurance component, the evidence component, and the attribute component are software components executed by the server 110.

[00131] As shown in Figs. 6A and 6B, at step 601, the terminal computing device 120 establishes a communication session with the server 110, for example by creating a new user account or logging into an existing user account. This may be conducted by, e.g., the terminal computing device 120 sending login information of a user account to the identity component of the server 110.

[00132] When the user has successfully logged in using their credentials, at step 602 the identity component of the server 110 returns a unique identity identifier to the terminal computing device 120. The identity identifier may be retrieved from a data store based on the login credentials provided by the user, or newly generated if the user creates a new user account. The identity component of the server 110 may also issue an access token (e.g., a JSON Web Token, which may also be referred to as the "JWT") or a cookie, and send it to the terminal computing device 120.

[00133] Next, at step 603, the user 130 selects which identity documents to provide, and provides identity information included in those identity documents at the terminal computing device 120. [00134] With the JWT and the identity identifier, the terminal computing device 120 sends an identity proofing request, including the provided identity information, to the assurance component of the server 110.

[00135] The identity information may be manually input into the terminal computing device 120 by the user 130, retrieved from another application or a web server (e.g., a social media website that stores the user's personal information), automatically extracted by the terminal computing device 120 from a digital image of one or more selected identity documents (generated by scanning or taking digital photos of the identity documents), or retrieved from an electronic identity document, or an electronic chip embedded in an identity document, via wireless communication (e.g., NFC, RFID or Bluetooth). In some embodiments, the digital image of the identity document itself may be sent to the assurance component of the server 130 as the identity information. However, sending the extracted information may allow enhancing the security and confidentiality of the user's identity information. The identity information or the identity documents may be encrypted before being sent to the server 110, which may further enhance the security of the user's identity information.

[00136] In the identity proofing request, the server 130 may further send to the server

110 channel capacity information, which indicates all identity information collection modes that are available to the user 130.

[00137] The available identity information collection modes may be selected by the user 130, e.g., through a user input on the terminal computing device 120, or automatically selected by the terminal computing device 120. For example, when the terminal computing device 120 is a mobile phone, the terminal computing device 120 may determine whether taking a digital photo of an identity document or conducting a video call with a human verifier is an available identity information collection mode based on the hardware or software facilities of the terminal computing device 120, e.g., whether a mobile application having the video call function has been installed on the terminal computing device 120. As described hereinbefore, each identity information collection mode may be associated with a predetermined friction value. In some other embodiments, the available identity information collection modes may be determined by the server 110, based on information about the terminal computing device 120, e.g., product type information.

[00138] Upon receiving the identity proofing request from the terminal computing device 120, the assurance component of the server 110 proceeds to step 604 to determine what assurance level (LoA) should be applied to the user, and what identity attributes have been or can be generated for this user.

[00139] Preferably, the assurance level (LoA) may be determined by a third-party that seeks proof of the identity of the user 130, e.g., a financial institution, a government organisation, a third-party merchant, or a third-party website. The required assurance level may be determined by the server 110, e.g., by querying the proof -requesting server 190 operated by the third-party.

[00140] In some other embodiments, the assurance level (LoA) may be determined by the server 110, e.g., based on a pre-determined default assurance level.

[00141] For an existing user account, based on the identity identifier, the server 110 may retrieve a digital identity profile associated with the user account from a data store, the digital identity profile including a group of identity attributes that have been previously generated from the user account.

[00142] Identity attributes may also be generated by the server 110 based on the identity information or identity document included in the identity proofing request received from the terminal computing device 120.

[00143] Based on these identity attributes, the assurance component determines at step

605 whether a subset of the group of identity attributes of the user 130 matches the set of identity assurance requirements of the selected assurance level. The set of identity assurance requirements of the selected assurance level may be retrieved by the server 110 from a data store, or received from the proof-requesting server 190.

[00144] If a subset of the group of identity attributes of the user 130 matches the set of identity assurance requirements of the chosen assurance level, the server 110 may proceed to step 628, notifying the terminal computing device 120 that the identity proofing process has been successfully completed.

[00145] If no subset of the group of identity attributes of the user 130 matches the set of identity assurance requirements of the chosen assurance level, the assurance component of the server 110 may perform the gap analysis process at step 606 to determine the gap between the identity attributes of the user and the set of identity assurance requirements associated with the selected assurance level, e.g., by determining at least one additional identity document that provides the incomplete or missing identity attribute.

[00146] At step 607, the server 110 notifies the terminal computing device 120 of the additional identity documents required. In addition, the server 110 may further determine and notify the terminal computing device 120 of the identity information collection modes required for the additional identity documents, if applicable.

[00147] For example, the gap analysis process may determine that, to match the required assurance level, a driver's licence and a passport of the user needs to be provided, and that both documents need to be verified by or with reference to an authoritative source (e.g., an issuing authority of one or more identity proofing documents, or a representative of the issuing authority).

[00148] At step 608, the user provides the driver's license through the terminal computing device 120, e.g., by taking a digital photo of the driver's license. The terminal computing device 120 extracts (possibly by means of an optical character recognition process) the required identity information from the driver's license - e.g., name, date of birth, residential address, licence expiry date, and license number - and sends them to the evidence component of the server 110.

[00149] At step 609, the evidence component of the server 110 verifies the provided identity information with an authoritative source, e.g., by querying the verification server 170 operated or endorsed by the issuing authority of the driver's license. [00150] After successful verification with the authoritative source at step 610, the evidence component sends the identity information to the attribute component of the server 110, which then generates at step 611 one or more identity attributes based on the identity information of the driver's license provided by the user.

[00151] At step 612, the attribute component may return a message to the evidence component, indicating that the new identity attributes have been successfully generated.

[00152] The server 110 may then notify the terminal computing device 120 at step 613 that identity information from the user's driver's license has been successfully verified and added to the user's digital identity profile.

[00153] At step 614, the terminal computing device 120 may then sends a request to the assurance component, querying whether the respective assurance level has been matched.

[00154] Again, the assurance component determines at step 615 what identity attributes have been generated for this user.

[00155] Based on the identity attributes, the assurance component determines at step

616 whether a subset of the group of identity attributes now matches the set of identity assurance requirements of the chosen assurance level.

[00156] If it remains the case that no subset of the group of identity attributes of the user 130 matches the set of identity assurance requirements of the selected assurance level, the assurance component of the server 110 again performs the gap analysis process at step

617 to determine the gap between the identity attributes of the user and the set of identity assurance requirements associated with the selected assurance level, e.g., by determining at least one additional identity document that provides the incomplete or missing identity attribute.

[00157] For example, the results of the gap analysis process may indicate that to match the required assurance level, a passport of the user needs to be provided, and needs to be verified by or with reference to an authoritative source. [00158] Accordingly, the server 110 sends a notification to the terminal computing device 120 at step 618.

[00159] At step 619, the user provides the passport through the terminal computing device 120, e.g., by taking a digital photo of the passport. The terminal computing device 120 extracts the required identity information from the passport - e.g., name, date of birth, nationality, and passport number - and sends them to the evidence component of the server 110.

[00160] At step 620, the evidence component of the server 110 verifies the provided identity information with an authoritative source.

[00161] After successful verification with the authoritative source at step 621, the evidence component sends the identity information to the attribute component of the server 110, where at step 622 one or more identity attributes are generated based on the identity information from the driver's license provided by the user.

[00162] At step 623, the attribute component may return a message to the evidence component, indicating that the new identity attributes have been successfully generated.

[00163] The server 110 may then notify the terminal computing device 120 at step 624 that identity information from the user's passport has been successfully verified and added to the user's digital identity profile.

[00164] Accordingly, at step 625, the terminal computing device 120 may then send a request to the assurance component, querying that whether the respective assurance level has been matched.

[00165] Again, the assurance component determines at step 626 the identity attributes that have been generated for this user.

[00166] Based on the identity attributes, the assurance component determines at step

627 whether a subset of the group of identity attributes now matches the set of identity assurance requirements of the chosen assurance level. [00167] If a subset of the group of identity attributes of the user 130 matches the set of identity assurance requirements of the chosen assurance level, the server 110 may proceed to step 628, notifying the terminal computing device 120 that the identity proofing process has successfully completed.

[00168] For example, the server 110 may cause the terminal computing device 120 to display a message, indicating the assurance level that has been achieved.

[00169] The digital identity profile created for the user in the process 600 may be stored by the server 110, e.g., in the data store 150, and may be reused in the future, e.g., for proving the user's identity to a third-party, or to match the digital identity profile to an assurance level in a different assurance framework.

[00170] When reusing the user's digital identity profile, different parties or assurance levels of different assurance framework may require different set of identity assurance requirements, and as described hereinbefore, if the server 110 determines that the identity attributes included in the user's digital identity profile do not match the relevant identity assurance requirements, the server 110 may perform a gap analysis process to determine which additional identity attributes or identity documents are required, and return a notification to the terminal computing device 120, to cause the terminal computing device 120 to guide the user to provide these additional identity attributes or identity documents.

[00171] Referring back to Fig. 1, in practice, the communications networks 140, 160 and 180 in Fig. 1 may take any appropriate form, such as the Internet and/or one or a number of local area networks (LANs). In practice, the various devices and data stores may communicate via any appropriate mechanism, such as via wired or wireless connections, including, but not limited to mobile networks, private networks, such as an 802.11 network, the Internet, LANs, WANs, as well as via direct or point-to-point connections, such as Bluetooth. In some embodiments, the communications networks 140, 160 and 180 may be the same communications network. In some other embodiments, the communications networks 140, 160 and 180 may be the different communications networks.

[00172] An example of a suitable server 110 of Fig. 1 is shown in Fig. 7. [00173] In this example, the server 110 includes at least one processor 710, a memory

720, an external input/output interface 730, and an input/output device 740 such as a keyboard and/or a display, interconnected via a bus 750 as shown. The external interface 730 may be utilised for connecting the server 110 to peripheral devices and/or networks, such as the communications networks 140, 160 and 170 and the local or remote data store 150. Although a single external interface 730 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless or the like) may be provided.

[00174] In use, the processor 710 may execute instructions in the form of applications software stored in the memory 720 to allow the required processes to be performed, including: communicating with the terminal computing device 120, the verification server 170, the proof-requesting server 190, the local or remote data storage 150, and other suitable databases or devices, and performing the identity proofing workflows as described hereinbefore. The applications software may include one or more software modules, such as the identity component, the assurance component, the evidence component, and the attribute component shown in Figs. 6 A and 6B, and may be executed in a suitable execution environment, such as an operating system environment, or the like.

[00175] Accordingly, it will be appreciated that the server 110 may be formed from any suitable processing system, such as a suitably programmed computer system, PC, web server, network server, or the like. In one example, the server 110 is a standard processing system such as an Intel Architecture based processing system, which executes software applications stored on non-volatile (e.g., hard disk) storage, although this is not essential. However, it will also be understood that the processing system could be any electronic processing device such as a microprocessor, microchip processor, logic gate configuration, firmware optionally associated with implementing logic such as an FPGA (Field Programmable Gate Array), or any other electronic device, system or arrangement.

[00176] An example of a suitable terminal computing device 120 of Fig. 1 is shown in

Fig. 8. [00177] In this example, the terminal computing device 120 includes at least one microprocessor 810, a memory 820, an output device 830, an input device 840, and an external input/output interface 850, interconnected via a bus 860 as shown. The terminal computing device 120 may further include a digital camera module 870 for taking digital photos of identity documents or the user 130, or conduction video calls. The external interface 850 may be utilised for connecting the terminal computing device 120 to peripheral devices and/or networks, such as the server 110, the communications networks 140, any other suitable servers, data stores or the like. Although a single external interface 850 is shown, this is for the purpose of example only, and in practice multiple interfaces using various methods (e.g. Ethernet, serial, USB, wireless or the like) may be provided.

[00178] In use, the microprocessor 810 executes instructions in the form of applications software stored in the memory 820 to allow communication with the server 110 for identity proofing. The applications software may include one or more software modules, and may be executed in a suitable execution environment, such as an operating system environment, or the like.

[00179] Accordingly, it will be appreciated that the terminal computing device 120 may be formed from any suitable processing system, such as a mobile phone (e.g., a smart phone), a portable computer, a tablet computer, or the like. In some embodiments, the terminal computing device 120 is a smart phone, on which one or more mobile applications can be installed and executed.

[00180] As described above, according to at least some embodiments, a method and a system for identity proofing is provided, which allows a user to provide identity information to one or more parties to prove their identity in a secure and convenient manner. The provided identity information may be stored and reused in future identity proofing. Using the method and system provided herein, the user need not repeatedly provide the same identity documents to prove the same identity attributes, and the provision of identity documents to different organisations may also be simplified.

[00181] In at least some embodiments, the described method and system may automatically determine the "gaps" between the provided personal information of the user and the requirements to the identity information for the purpose of identity proofing, and may guide the user to provide further identity information to fill these gaps.

[00182] In some further embodiments, the described method and system may be capable of applying one or more assurance frameworks to the identity information provided by the user, each of which may include different assurance levels. The described method and system allow efficiently matching the identity information provided by the user to one of these assurance levels for each applicable assurance framework.

Document - Attribute-LoA Graph

[00183] As described hereinbefore, in performing the identity proofing process, the server 110 may need to determine one or more of the following:

• (Ml) what identity attribute(s) can be derived from an identity document;

• (M2) what identity documents are required to derive an identity attribute;

• (M3) what identity documents are required to achieve an assurance level;

• (M4) which assurance level can be matched based on given identity attribute(s) / identity document(s); and

• (M5) which assurance level can be stepped up to based on additional identity attribute(s) / identity document(s) provided.

[00184] In some embodiments, the relationships between different identity documents, their related identity attributes, and the assurance levels supported by the system may be generated and stored in a model, one example of which is a graph data structure. For example, a Document- Attribute-LoA graph may be generated and used. [00185] Fig. 9 illustrates an example 900 of the Document-Attribute-LoA graph, which may be stored in a data store accessible by the server 110, e.g., the local or remote data store 150.

[00186] The Document- Attribute-Lo A graph includes three types of nodes: document nodes, each of which represents a type of identity document supportable by the system; attribute nodes, each of which represents a type of identity attribute that can be supported by or derived from an identity document, e.g., a direct identity attribute such as Date of Birth, or a synthetic identity attribute such as the fact that a person is over 18 years' old, whereby an attribute node may also represent an indication that a certain type of identity document has been provided, e.g., that a passport has been provided, or a driver's license has been provided; and

LoA nodes, each of which represents an assurance level of an assurance framework supportable by the system.

[00187] As shown in Fig. 10, one or more attribute nodes may be supported by or derived from a document node.

[00188] As shown in Fig. 11, one or more attribute nodes may contribute to an LoA node, or a plurality of LoA nodes, and a direct identity attribute node such as Date of Birth may contribute to a synthetic identity attribute node, such as the fact that a person is over 18 years' old.

[00189] Based on these derivation relationships between the attribute nodes and document nodes, and contribution relationships between attribute nodes and LoA nodes, a Document-Attribute-LoA graph 900 shown in Fig. 9 can be generated.

[00190] The Document-Attribute-LoA graph may be used to store a user's identity attributes, each identity attributes being stored in an attribute node, with the associated identity documents stored in the corresponding document nodes, and the LoAs matched by the user's identity attributes stored in the LoA nodes.

[00191] The Document-Attribute-LoA graph may also or alternatively be used to store one or more assurance levels, with the LoAs stored in the LoA nodes, the attribute type requirements stored in the attribute node, and the attribute metadata requirements in relation to identity documents stored in the document nodes.

[00192] The above mentioned matters (Ml) - (M5) may be determined based on the

Document-Attribute-LoA graph, and in particular, the links between the nodes in the Document-Attribute-LoA graph. This may be carried out by using existing graph database management systems, e.g., Neo4j developed by Neo Technology, Inc.

[00193] Using the Document-Attribute-LoA graph may enhance the computing efficiency in determining these matters, and thereby increase the efficiency speed of the identity proofing process.

[00194] Alternatively, the relationships between different identity documents, their related identity attributes, and the assurance levels supported by the system may be represented and stored in any other suitable manner, e.g., using any other suitable data structure or data models.

Mobile application

[00195] The method described hereinbefore for identity proofing may be implemented using an application executing on the terminal computing device 120 (e.g., a mobile phone, a tablet computer, a laptop or desktop computer, or the like). For example, the terminal computing device 120 may be a smart phone, and the method may be implemented using a mobile application installed on the smart phone, as described in further detail as follows.

[00196] Figs. 12 - 30 show exemplary user interfaces for implementing the method of identity proofing. [00197] As shown in Figs. 12 - 13, a user 130 who is using the mobile application for the first time may be required to go through a registration (i.e., enrolment) process, by providing some identity information to allow the server 110 to build up a digital identity profile for that user.

[00198] As shown in Fig. 12, the user 130 may be required to provide identity information from at least one identity document. After selecting an identity document in the user interface 1210, the user is required to input the relevant identity information included in that identity document, using the user interface 1220. Alternatively, the mobile application may allow the user to take a digital photo of their identity document, and automatically extract the relevant identity information included in that identity document from the digital image of the identity document.

[00199] As shown by user interface 1310 of Fig. 13, the user 130 may further be required to input extra identity information in addition to the information included in the provided identity document, e.g., a residential address.

[00200] Next, as shown by 1320, the user 130 is allowed to review the input identity information before the terminal computing device 120 sends this information to the server 110. The mobile application may encrypt the contents of the identity information before sending it to the server 110.

[00201] Upon receiving the identity information from the terminal computing device

120, the server 110 creates a digital identity profile for the user, and returns a notification to the terminal computing device 120, to allow the terminal computing device 120 to notify the user that the digital identity profile has been created, e.g., by displaying a message as shown by 1330. In some embodiments, upon receiving the identity information from the terminal computing device 120, the server 110 may further verify the provided information with an authoritative source (e.g., an issuing authority of one or more identity proofing documents, or a representative of the issuing authority), e.g., through the verification service 170 operated by the authoritative source. In some other embodiments, the server 110 may require the provided identity documents to be checked or sighted by a human verifier, e.g., through a video call or by the user taking the identity documents to a nearby service location. [00202] After successful registration, the user may then use the created digital identity profile to prove their identity to other parties, for example, to a third-party website.

[00203] Figs. 14 - 19 show an example of the user verifying their identity to a third- party website using their digital identity profile. In this example, the user is using a portable computer 122 to visit the third-party website, while the identity proofing mobile application is executed on the terminal computing device 120 in the form of a smart phone.

[00204] As shown in Fig. 14, the third party website provides an identity verification page 1410, in which the user may choose in which way they would like to verify their identity, e.g., through providing their identity information to the third-party website directly, or using the identity proofing service provided by the server 110.

[00205] As shown in Fig. 15, if the user chooses to use the identity proofing service, they may be allowed to either using an existing digital identity profile (i.e., to "sign in"), or to register with the identity proofing service as a new user. This selection may be conducted through a popup widget 1510.

[00206] If the user chooses to use their existing profile, as shown in Fig. 16, a unique image 1610 associated with the third-party website may be displayed in the popup widget. The image 1610 can be scanned by the terminal computing device 120. The image 1610 may be, e.g., in the form of a two-dimensional code (such as a QR code), or a bar code.

[00207] In response to scanning the image 1610 using the mobile application executing on the terminal computing device 120, the terminal computing device 120 sends a verification request to the server 110, which may include user account information to allow the server 110 to retrieve the associated digital identity profile, and may further include information indicating the third-party website.

[00208] Based on the verification request, the server 110 determines the third-party website which the user is seeking to connect with, and may cause the terminal computing device 120 to display the relevant information such as the name of the third-party website in the mobile application, as shown by 1710 of Fig. 17. This may effectively prevent a phishing site stealing the user's identity information by imitating a legitimate website.

[00209] Once the user has confirmed that the third-party website is the one with which they would like to connect, the server 110 queries a server (e.g., the server 190 of Fig. 1) associated with the third-party website to determine the identity assurance requirements requested by the third-party website, and displays the requested items for the user to confirm, as shown by 1720. The user may confirm their authorisation to provide this personal information to the third-party website, e.g., by choosing the "Allow" button 1730.

[00210] The server 110 compares the identity attributes included in the user's digital identity profile with the identity assurance requirements requested by the third party-website, and confirms that the identity attributes included in the user's digital identity profile match the requirements of the third-party website, and then shares the requested identity information with the third-party website. A notification indicating successful verification may be displayed in both the mobile application and the popup widget, as shown by 1810 and 1820 of Fig. 18. The user may then proceed to use the third-party website.

[00211] On the other hand, if the server 110 determines that the identity attributes included in the user's digital identity profile do not match the identity assurance requirements requested by the third party-website, the server 110 may perform a gap analysis process to determine which additional identity attributes or identity documents are required, and return a notification to the terminal computing device 120, to cause the terminal computing device 120 to display a message indicating the required additional identity attributes or identity documents, as shown by 1910 of Fig. 19.

[00212] In some embodiments, when the user selects from the user interface 1410 as shown in Fig. 14 that they would like to verify their identity by using the identity proofing service provided by the server 110, the user may not have used the identity proofing service before, therefore no existing digital identity profile is available to be used. In this case, the user may choose to create a new digital identity profile through the popup widget as shown in Fig. 20, e.g., by selecting the "verify your ID" button 2010. [00213] By scanning an image as shown by 1610 in Fig. 16 using the terminal computing device 120 (smart phone), the user may be guided to download and install the mobile application for identity proofing. Subsequently, by executing the mobile application, the user is guided through a registration and verification process, as illustrated in Figs. 21 - 24.

[00214] Similar to the verification process described hereinbefore, the server 110 queries a server associated with the third-party website, to determine the identity assurance requirements requested by the third-party website. The server 110 then guides the user to provide the identity attributes or identity documents to match these identity assurance requirements.

[00215] As shown in 2110 of Fig. 21, in this example, the user is requested to provide two identity documents. The user selects the first identity document as shown by 2110 of Fig. 21, and inputs the relevant identity information included in that identity document, as shown by 2120. Alternatively, the mobile application may allow the user to take a digital photo of their identity document, and automatically extract the relevant identity information included in that identity document from the digital image of the identity document.

[00216] After the first identity document is provided, as shown in Fig. 22, the user is then required to select and provide the second identity document, and to input the identity information included in the second identity document, as shown by 2210 and 2220 respectively.

[00217] In some embodiments, the user may further be required to provide additional identity information, as shown by 2230.

[00218] Next, as shown by 2310 and 2320 of Fig. 23, the user is allowed to review the input identity information before the terminal computing device 120 sends this information to the server 110. The mobile application may encrypt the contents of the identity information before sending it to the server 110. [00219] Upon receiving the identity information from the terminal computing device

120, the server 110 shares the provided identity information with the third-party website, creates a digital identity profile for the user, and returns a notification to the terminal computing device 120, to allow the terminal computing device 120 to notify the user that the digital identity profile has been created, e.g., by displaying a message as shown by 2330.

[00220] A notification indicating successful verification may also be displayed in the popup widget on the third-party website, as shown by 2410 of Fig. 24.

[00221] The user may then proceed to use the third-party website. The digital identity profile created for the user may be stored by the server 110, e.g., in the data store 150, and may be reused in the future for proving the user's identity, either to the third party website or a different party who seeks proof of the identity of the user 130.

[00222] When reusing the user's digital identity profile, different parties may require different sets of identity assurance requirements, and as described hereinbefore, if the server 110 determines that the identity attributes included in the user's digital identity profile do not match the identity assurance requirements requested, the server 110 may perform a gap analysis process to determine which additional identity attributes or identity documents are required, and return a notification to the terminal computing device 120, to cause the terminal computing device 120 to guide the user to provide these additional identity attributes or identity documents.

[00223] As described hereinbefore, the server 110 or a third -party seeking proof of the user's identity may require the provided identity document(s) to be checked or sighted by a human verifier, e.g., through a video call or by the user taking the identity documents to a nearby service location.

[00224] Figs. 25 - 29 illustrate an exemplary process of checking an identity document of the user through a video call. [00225] As shown in Fig. 25, after an identity document or identity information associated with an identity document has been provided, the user may be allowed to select one method to have the relevant identity document checked by a human verifier.

[00226] When the user selects to conduct the check by a video chat using a desktop computer, a video chat connection may be established with a verifier, as shown in Fig. 26.

[00227] During the video chat, the user may be required to:

(1) show their photo ID (as shown in Fig. 27); and

(2) show their face (as shown in Fig. 28).

[00228] After these two steps are completed, the video call may end, and a notification may be displayed to indicate that the check has been completed successfully, as shown in Fig. 29.

[00229] As described hereinbefore, in some embodiments, a group of identity attributes included in a digital identity profile may be matched to one of a plurality of assurance level in an assurance framework. After creating a digital identity profile or performing a verification of the digital identity profile, the server 110 may determine an assurance level in an assurance framework to which the a digital identity profile may be matched, e.g., the highest assurance level in that assurance framework the digital identity profile can match. The determined assurance level may be presented to the user, e.g., in the mobile application for identity proofing.

[00230] The reference in this specification to any prior publication (or information derived from it), or to any matter which is known, is not, and should not be taken as an acknowledgment or admission or any form of suggestion that that prior publication (or information derived from it) or known matter forms part of the common general knowledge in the field of endeavour to which this specification relates. [00231] Many modifications will be apparent to those skilled in the art without departing from the scope of the present invention as hereinbefore described with reference to the accompanying drawings.