Providing validated user identity declarations

Abstract

The subject matter of the application is to provide a validated user identity declaration. A device implementing a system for using a validated identity declaration includes at least one processor configured to receive a validated declaration including information for identifying a user of the device, the validated declaration is signed by the server based on verification of the information by an authentication provider separate from the server, the validated declaration being specific to the device. The at least one processor is further configured to send a request for a service provided by the service provider to the service provider, and receive a request for a validated declaration from the service provider in response to the sending. The at least one processor is further configured to, in response to receiving, send the validated declaration to a service provider.

Description

[0001] This application is a divisional application of the invention patent application with international application number PCT / US2019 / 063756, international application date November 27, 2019, application number 201980068860.X, and invention name “Providing Verified User Identity Declaration”, which entered the Chinese national phase on April 19, 2021.

[0002] CROSS-REFERENCE TO RELATED APPLICATIONS

[0003] This application claims the benefit of priority to the following U.S. Provisional Patent Applications: U.S. Provisional Patent Application No. 62 / 786,309, entitled “Providing Verified Claims of User Identity,” filed on December 28, 2018; U.S. Provisional Patent Application No. 62 / 795,528, entitled “Providing Verified Claims of User Identity,” filed on January 22, 2019; U.S. Provisional Patent Application No. 62 / 820,820, entitled “Providing Verified Claims of User Identity,” filed on March 19, 2019; U.S. Provisional Patent Application No. 62 / 822,987, entitled “Providing Verified Claims of User Identity,” filed on March 24, 2019; and U.S. Provisional Patent Application No. 62 / 822,988, entitled “Providing Verified Claims of User Identity,” filed on March 24, 2019; the disclosure of each of these applications is hereby incorporated herein in its entirety. Technical Field

[0004] This specification generally relates to providing verified user identity assertions, including providing verified user identity assertions that a user can use to confirm their identity, such as to a service provider. Background Art

[0005] Some service providers may require identity and verification to register a user. Verification can be performed by an identity provider. BRIEF DESCRIPTION OF THE DRAWINGS

[0006] Certain features of the subject technology are set forth in the appended claims. However, for purposes of explanation, several embodiments of the subject technology are set forth in the following drawings.

[0007] Figure 1An exemplary network environment for registering and / or sharing verified identity assertions according to one or more implementations is shown.

[0008] Figure 2 Exemplary electronic devices are shown that can implement the subject system for registering and / or sharing verified identity assertions in accordance with one or more implementations.

[0009] Figure 3 Exemplary processes for enrolling and / or sharing verified identity assertions in accordance with one or more implementations are shown.

[0010] Figure 4 An exemplary user interface for enrolling a verified identity assertion is shown in accordance with one or more implementations.

[0011] Figure 5 An exemplary user interface for displaying information of a verified identity assertion is shown in accordance with one or more implementations.

[0012] Figure 6 An exemplary user interface for registering with a service provider is shown in accordance with one or more implementations.

[0013] Figure 7 An example of storing verified asserted user identity information in a Merkle tree according to one or more implementations is shown.

[0014] Figure 8 Examples of registering and sharing verified identity assertions according to one or more implementations are shown.

[0015] 9A to 9D Another process for enrolling and / or sharing verified identity assertions according to one or more implementations is shown.

[0016] Fig.10 A flow chart is shown of an example process for receiving services from a service provider using verified claims in accordance with one or more implementations.

[0017] Fig.11 A flow chart of an example process for providing a confidence assessment for a verified claim in accordance with one or more implementations is shown.

[0018] Fig.12 A flow chart is shown of an example process for requesting additional information from a user based on information included in a verified claim in accordance with one or more implementations.

[0019] Fig.13A flow chart of an example process for providing services to a device based on a response vector of a verified assertion in accordance with one or more implementations is shown.

[0020] Fig.14 A flow chart of an example process for revoking a verified claim in accordance with one or more implementations is shown.

[0021] Fig.15 Exemplary electronic systems are shown that can be used to implement various aspects of the subject technology in accordance with one or more implementations. DETAILED DESCRIPTION

[0022] The specific embodiments shown below are intended as descriptions of various configurations of the subject technology and are not intended to represent the only configurations in which the subject technology can be practiced. The accompanying drawings are incorporated herein and constitute a part of the specific embodiments. The specific embodiments include specific details intended to provide a thorough understanding of the subject technology.

[0023] However, the subject technology is not limited to the specific details described herein, and can be practiced using one or more other specific implementations. In one or more specific implementations, structures and components are shown in block diagram form in order to avoid obscuring the concepts of the subject technology.

[0024] A user may wish to use their device to act as a form of digital identity for the user. For example, as described above, some service providers require identity and verification to register a user. Therefore, these service providers may need to establish their own identity and verification processes (e.g., based on the level of verification required to access their respective services). In addition, a user who registers with multiple service providers may have to go through multiple redundant identity and verification processes (e.g., one for each service provider), resulting in duplicate sharing of sensitive user data.

[0025] The subject system allows a user to obtain a verified identity claim that serves as the user's digital identity, which includes information for identifying the user (e.g., information provided by the user and verified by one or more systems), and can be reused between different service providers. Thus, a verified identity claim can correspond to a claim that information provided by the user to identify the user has been verified by one or more systems. In one or more specific implementations, the verified claim can be implemented as a data structure (e.g., a JSON data structure) that includes a claim header for identifying the verified claim, and a Merkle tree including the user's identification information.

[0026] The user's device may receive a verified statement signed by a trusted identity claim verification system based on verification of the information contained in the statement by the identity verification provider. The trusted identity claim verification system may act as an intermediary and may provide a confidence assessment (e.g., vouch for) the identity of the user indicated in the signed verified statement (e.g., after verifying the user's identity with the identity verification provider). The verified statement may be specific to the user's device by having the public key of the public-private key pair correspond to a secure hardware component of the user's device. The public key may be included as part of the verified statement.

[0027] In one or more specific implementations, when a user registers with a particular service provider, the service provider may request a verified statement from the user's device (e.g., where the request may include a random number to be signed by the user's device). For example, the user's device may sign the random number with a private key corresponding to a public key included in the verified statement, and may provide the verified statement (e.g., together with the signed random number) to the service provider for the service provider to verify the identity of the user indicated in the verified statement. Since the user's device has signed the verified statement using a private key (e.g., a private key of a private-public key pair), the service provider may use the public key included in the verified statement to confirm that the user's device holds the corresponding private key. Such a signature of the verified statement may correspond to the user's device confirming that the verified statement is specific to the device.

[0028] In addition, the user's device may have received an identity status certificate from the identity claim verification system, proving that the verified claim is valid and has not been revoked. For example, the identity claim verification system may have signed a certificate that the verified claim has not been revoked, thereby further confirming the validity of the verified claim.

[0029] In addition, the subject system may provide evaluation data (e.g., in conjunction with a verified statement) to a service provider, which may be used by the service provider to determine whether to accept a verified statement submitted by a user, e.g., for registering with the service provider. In one example, evaluation data is generated on a user device based on content stored locally on the user device, where the content may be used to determine whether a user of the device matches user information contained in the user's verified statement. For example, based on an opt-in policy (e.g., where the user opts in to allow the use of locally stored data when generating evaluation data), the user's device compares user information fields in the verified statement with corresponding user data derived from data stored locally on the user device (e.g., from emails, messages, social network content, etc.) to generate evaluation data. The service provider may use the resulting evaluation data (e.g., confidence assessment) to further analyze the verified statement submitted by the user, e.g., to determine whether to accept the verified statement.

[0030] In another example, the evaluation data may be generated based on an evaluation of user information data fields of a verified claim determined by the identity verification provider (e.g., based on user opt-in). The identity verification provider may calculate a score for each of the data fields included in the verified claim (e.g., name, address, email, etc.) by comparing the fields in the verified claim (e.g., signed by a claim verification system) to values ​​accessible to the identity verification provider (e.g., from an institutional database, public records, etc.).

[0031] In one or more specific implementations, one or more of the above examples of evaluation data may be represented as a response vector, where each data value indicates the likelihood (and / or confidence score) that the corresponding user information data field in the verified statement is accurate. Thus, the service provider may receive a first response vector with a score based on the local device data comparison, and a second response vector with a score based on the information obtained by the identity verification provider. In this way, the service provider is provided with more discrete information for verifying the user's identification information (or the portion of the user's identification information that the service provider deems important).

[0032] In another example, the assessment data may be determined based on an overall account assessment associated with the user, such as based on an existing account that the user already has with the identity assertion verification system (and / or an account accessible to the identity assertion verification system). For example, the likelihood of the user paying (e.g., based on past payment history) and / or an indication of fraudulent activity associated with the user's account attributable to the user may be determined. This indication may be provided to the service provider in its determination of whether to register the user.

[0033] In one or more specific implementations, the subject system can aggregate or triangulate different evaluation data to generate an overall evaluation of the user, such as an aggregate score for the user (e.g., where the user has opted in to providing such a score). The aggregate score can be provided to the service provider along with the user's verified statement for further analysis by the service provider.

[0034] In some cases, the subject system provides for revoking a verified statement. For example, a user may have logged into their user account (e.g., via a separate device) to report their device lost / stolen (e.g., based on a "find my phone" request) and / or requesting a remote wipe of their device. Alternatively, the user may have locally requested the removal of data on their device (e.g., via a "wipe" command). In such cases, it may be desirable that the verified statement on the user's device cannot be accessed by a third party, such as for use in a fraudulent manner (e.g., by another user who happens to find a lost phone). Therefore, the subject system provides for revoking a verified statement, such that, for example, a verified statement on a device (e.g., a lost device) can be revoked. Revocation can cause verified information (e.g., a verified statement and / or a private key) to be deleted on the user's device. Revocation can also cause the identity claim verification system to add the verified statement to a revocation list. The service provider can deny service to the device based on the verified statement appearing on the revocation list and the removal of the verified statement and / or private key on the client device (which would render the device unable to sign a random number provided by the service provider with the private key).

[0035] Furthermore, in some cases, the service provider may require additional identification information (e.g., relative to the information provided by the verified claims and assessment data) for enabling the user (based on the user's identification information that the service provider deems important). Accordingly, the service provider may request additional identification information from the user of the client device, such as by prompting the user to enter the additional identification information.

[0036] Thus, the subject system allows a user to obtain a verified identity claim that can be reused across multiple different service providers without having to repeat the identity verification process for each service provider. Although the verified identity claim is signed by the subject system (e.g., a trusted identity claim verification system that provides a confidence assessment for the user's identity after verifying the user's identity to the identity verification provider), the subject system can also provide the service provider with multiple different forms of evaluation data that can be used by the service provider to further verify the user's identity. If the service provider is still unsure of the user's identity, the service provider can prompt the user to provide additional identification information. Finally, the subject system provides a revocation system that enables the user to revoke the verified claim at any time (e.g., by the user, the service provider, and / or the identity claim verification system).

[0037] Figure 1An exemplary network environment for registering and / or sharing verified identity claims according to one or more implementations is shown. However, not all of the components depicted may be used in all implementations, and one or more implementations may include additional or different components than those shown in the figures. Changes in the arrangement and type of these components may be made without departing from the spirit or scope of the claims listed herein. Additional components, different components, or fewer components may be provided.

[0038] The network environment 100 includes electronic devices 102a, 102b, 102c, and 102d (hereinafter referred to as 102a-102d), a network 104, identity verification providers 106a-106n, an identity assertion verification system 108, and service providers 110a-110n. The network 104 may communicatively (directly or indirectly) couple, for example, any two or more of the electronic devices 102a-102d, the identity verification providers 106a-106n, the identity assertion verification system 108, and the service providers 110a-110n. In one or more specific implementations, the network 104 may be an interconnected network that may include the Internet and / or devices that are communicatively coupled to the Internet. For purposes of explanation, the network environment 100 is described in detail in detail in the accompanying drawings. Figure 1 1. The network environment 100 is illustrated as including electronic devices 102a-102d, identity authentication providers 106a-106n, identity assertion verification system 108, and service providers 110a-110n; however, the network environment 100 may include any number of electronic devices, identity authentication providers, identity assertion verification systems, and / or service providers.

[0039] One or more of the electronic devices 102a-102d may be, for example, a portable computing device such as a laptop, a smart phone, a smart speaker, a peripheral device (e.g., a digital camera, a headset), a tablet device, a wearable device such as a smart watch, a band, a head mounted display, etc., or any other suitable device including, for example, one or more wireless interfaces, such as a WLAN radio, a cellular radio, a Bluetooth radio, a Zigbee radio, a near field communication (NFC) radio, and / or other wireless radios. Figure 1 In the embodiment, by way of example, electronic device 102a is depicted as a smart phone, electronic device 102b is depicted as a smart watch, electronic device 102c is depicted as a laptop computer, and electronic device 102d is depicted as a smart speaker. Each of electronic devices 102a-102d may be and / or may include the following with respect to Figure 2 The devices discussed and / or described below with respect to Fig.15 All or a portion of the electronic system in question.

[0040] One or more of the identity verification providers 106a-106n, the identity assertion verification system 108, and / or the service providers 110a-110n may be and / or may include the following in combination: Fig.15 All or part of the electronic system described. One or more of the identity verification providers 106a-106n, the identity assertion verification system 108, and / or the service providers 110a-110n may include one or more servers, such as a server cloud. For purposes of explanation, multiple identity verification providers 106a-106n, a single identity assertion verification system 108, and multiple service providers 110a-110n are shown and discussed with respect to various operations. However, these operations and other operations discussed herein may be performed by one or more servers, and each different operation may be performed by the same or different servers.

[0041] As described herein, one or more of the electronic devices 102a-102d may obtain a corresponding verified identity claim (e.g., for the same user account and / or for different user accounts) having information for identifying the user from the identity claim verification system 108. The verified claim may be reused by the corresponding electronic device to enable one or more of the service providers 110a-110n.

[0042] Based on verification of the information contained in the verified assertion by one or more of the identity authentication providers 106a-106n, and / or additional assessment data to which the identity assertion verification system 108 has access, the verified assertion may be signed by the identity assertion verification system 108. In one or more implementations, one or more of the identity authentication providers 106a-106n may be configured to generate the verified assertion, sign the verified assertion, and send the verified assertion to the identity assertion verification system 108. The identity assertion verification system 108 may then remove the signature (signed by the respective one of the identity authentication providers 106a-106n) and re-sign the verified assertion for sending back to one or more of the electronic devices 102a-102d.

[0043] Alternatively or in addition, one or more of the identity verification providers 106a-106n may not be configured to generate a verified claim, but instead may simply send an indication that the identification information (e.g., provided by a user) has been verified. The identity claim verification system 108 may be configured to generate a verified claim, sign the verified claim, and provide the signed verified claim to one or more of the electronic devices 102a-102n.

[0044] Figure 2An exemplary electronic device is shown that can implement the subject system for registering and / or sharing verified identity claims according to one or more specific implementations. For the purpose of explanation, this document mainly refers to electronic device 102a. Figure 2 .However, Figure 2 Corresponds to Figure 1 Any of the electronic devices 102a-102d of the electronic device 102a-102d. However, not all of the depicted components may be used in all specific implementations, and one or more specific implementations may include additional or different components than those shown in the figures. Changes in the arrangement and type of these components may be made without departing from the spirit or scope of the claims listed herein. Additional components, different components, or fewer components may be provided.

[0045] The electronic device 102a may include a processor 202, a memory 204, a security hardware component 206, and a communication interface 208. The processor 202 may include appropriate logic components, circuits, and / or codes that enable processing of data and / or control of the operation of the electronic device 102a. In this regard, the processor 202 may be enabled to provide control signals to various other components of the electronic device 102a. The processor 202 may also control the transmission of data between the various parts of the electronic device 102a. In addition, the processor 202 may enable implementation of an operating system or otherwise execute code to manage the operation of the electronic device 102a.

[0046] The memory 204 may include suitable logic components, circuits, and / or code to enable storage of various types of information, such as received data, generated data, code, and / or configuration information. The memory 204 may include, for example, a random access memory (RAM), a read-only memory (ROM), flash memory, and / or a magnetic storage device.

[0047] The secure hardware component 206 may be configured to store data securely and may include its own memory and / or operating system. In one or more specific implementations, the secure hardware component 206 may correspond to a secure element, a secure area processor, a secure processor, and / or a secure execution environment. In addition, the operating system and / or execution environment of the secure hardware component 206 may be a JAVA-based operating system and / or a JAVA-based execution environment, and one or more applet instances deployed by the secure hardware component 206 may be JAVA-based applet. In other specific implementations, other operating systems, languages, and / or environments may be implemented. In addition to the one or more applet instances, the secure hardware component 206 may also include one or more additional applets for performing operations, such as a secure applet, a registry applet, etc.

[0048] In one or more specific implementations, the secure hardware component 206 may be configured to store a private key in a public-private key pair, wherein the corresponding public key binds the verified statement to the electronic device 102a (e.g., such that the public key is specific to the electronic device 102a). Alternatively or in addition, the secure hardware component 206 may have a separate key (e.g., a reference key or a master key) for encrypting data stored in the memory 204 of the electronic device 102a. Thus, the private key may instead be stored in the memory 204 of the electronic device 102a, where the private key is signed / backed up by the reference key in the secure hardware component 206. Signing the verified statement via the private key may correspond to the electronic device 102a confirming that the verified statement comes from the electronic device 102a. Therefore, the use of the verified statement is specific to the electronic device 102a. As described herein, the secure hardware component 206 may be optional. In one or more embodiments, the verified statement can be specific to the electronic device 102a via one or more of a hardware reference key (e.g., a public key in a public-private key pair that is based on a hardware component of the device), a software reference key (e.g., a key based on a software component of the device), a hardware device identifier, and / or a software device identifier.

[0049] In one or more specific implementations, the electronic device 102a may implement a secure mailbox mechanism that provides communication between the secure hardware component 206 and other devices. In the secure mailbox mechanism, other devices can transmit messages to an inbox. The secure hardware component 206 can read and interpret the message to determine the action to be taken in response to the message. The response message from the secure hardware component 206 can be transmitted through the outbox, which is also part of the secure mailbox mechanism. In one or more specific implementations, other access to the secure hardware component 206 from external devices may not be allowed.

[0050] The communication interface 208 may include suitable logic, circuitry, and / or code that enables wired or wireless communications, such as with any of the electronic devices 102b-102d, identity verification providers 106a-106n, identity assertion verification system 108, and service providers 110a-110n over the network 104. The communication interface 208 may include, for example, one or more of a Bluetooth communication interface, a cellular interface, an NFC interface, a Zigbee communication interface, a WLAN communication interface, a USB communication interface, or generally, any communication interface.

[0051] In one or more specific implementations, one or more of the processor 202, memory 204, secure hardware component 206, communication interface 208, and / or one or more portions thereof may be implemented in software (e.g., subroutines and code), in hardware (e.g., an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), a programmable logic device (PLD), a controller, a state machine, a gated logic component, a discrete hardware component, or any other suitable device), and / or a combination of both.

[0052] Figure 3 An exemplary process for registering and / or sharing a verified identity claim according to one or more specific implementations is shown. For the purpose of explanation, this article mainly refers to Figure 1 The process 300 is described with reference to the electronic device 102a, the identity verification provider 106a, the identity assertion verification system 108 and the service provider 110a. However, the process 300 is not limited to Figure 1 The electronic device 102a, identity verification provider 106a, identity assertion verification system 108 and service provider 110a of process 300, and one or more operations (or multiple operations) of process 300 may be performed by one or more other components and other suitable devices (e.g., any one of electronic devices 102a-102d, identity verification providers 106a-106n and / or service providers 110a-110n). Further for the purpose of illustration, the operations of process 300 are described herein as occurring sequentially or linearly. However, multiple operations of process 300 may occur in parallel. In addition, the operations of process 300 do not have to be performed in the order shown, and / or one or more operations of process 300 do not have to be performed and / or may be replaced by other operations.

[0053] Process 300 includes a registration phase (e.g., operations 302-310) and a sharing phase (e.g., operations 312-330). During the registration phase, electronic device 102a registers the verified identity assertion, which corresponds to having the verified identity assertion generated, signed, and provided to electronic device 102a. During the sharing phase, the user of electronic device 102a can use the verified assertion with respect to registering / activating with service provider 110a.

[0054] For the enrollment phase (e.g., operations 302 to 310), the electronic device 102a sends a request for a verified claim to the identity claim verification system 108 (302). The request provided by the electronic device 102a includes information for identifying the user (e.g., personally identifiable information that the user has opted-in to provide) and is specific to the electronic device 102a. For example, the request can be specific to the electronic device 102a by one or more of a hardware reference key (e.g., corresponding to a public key in a public-private key pair signed by a reference key of the secure hardware component 206), a software reference key, a hardware device identifier, and / or a software device identifier. In one or more specific implementations, the personally identifiable information included in the request is entered by the user at the electronic device 102a.

[0055] For example, a user of the electronic device 102a may request a verified identity assertion by selecting an option (e.g., register a digital identity) presented within a user interface displayed on the electronic device 102a. The option may be displayed by an application specifically related to registering and / or maintaining a verified identity assertion, wherein the verified assertion may be used to register and / or use a service provided by the service provider 110a (and / or other service providers). Alternatively or in addition, the option may be displayed by an application corresponding to the service, wherein the user's selection of the option may redirect the user to the application to register and / or maintain a verified identity assertion.

[0056] When the option for registering a verified statement is selected, the user may be provided with an interface for providing user information to create a verified statement. In this regard, Figure 4 An exemplary user interface 400 for digital identity verification according to one or more implementations is shown. Figure 4 As shown, user interface 400 includes a plurality of input fields 402-412 corresponding to personally identifiable information. The one or more fields may include, but are not limited to, the user's: name 402, address 404, date of birth 406, identification number 408 (e.g., social security number), phone number 410, and email address 412. In one or more specific implementations, the verified statement may include image data, such as an identifying picture of the user (e.g., extracted from a physical identity document such as a driver's license, passport, college ID, venue pass, ski pass, work ID, etc.).

[0057] When filling in one or more of the fields 402-412, the user may select "Yes" at option 414 and store the digital identification for future use (e.g., generating a request for a verified identity assertion) by clicking on a submit button 416. After the user clicks on the submit button 416, the electronic device 102a sends a request for a verified identity assertion to the identity assertion verification system 108 based on the user information provided by the user in the fields 402-412. Alternatively, the user may cancel the registration process by clicking on a cancel button 418.

[0058] As described above, the request for a verified statement may also be specific to the electronic device 102a (e.g., by including a hardware reference key, a software reference key, a hardware device identifier, and / or a software device identifier). For example, the hardware / software reference key and / or the hardware / software device identifier may be a public key in a public-private key pair generated by the electronic device (e.g., based on the secure hardware component 206 and signed by a reference key or a master key of the secure hardware component 206). For example, the public-private key pair may be generated based at least in part on a device identifier (and / or other information) associated with and / or stored on the secure hardware component 206. The corresponding private key may be securely stored on the electronic device 102a (e.g., stored in the secure hardware component 206 or the memory 204). In addition, the private key may be used to sign a random number, as discussed below with respect to operation 320.

[0059] The identity assertion verification system 108 sends a request to the identity verification provider 106a for the identity verification provider 106a to verify the user information provided by the electronic device 102a (304). For example, the identity verification provider 106a may correspond to a trusted service (e.g., a system, organization, or institution) that maintains the user's identity information while providing user authentication services, such as for the service providers 110a-110n.

[0060] Thus, the identity verification provider 106a verifies the user information provided by the electronic device 102a. For example, the identity verification provider 106a may confirm that the user information (e.g., name 402, address 404, date of birth 406, identification number 408, telephone number 410, and email address 412) corresponds to a particular user, such as by checking a database (e.g., an organization and / or institution database). After verifying the user information, the identity verification provider 106a sends an indication of the verification to the identity assertion verification system 108 (306).

[0061] In one or more specific implementations, the indication of verification may correspond to the verified claim itself, where the identification verification provider 106a generates the verified claim, signs the verified claim, and sends the verified claim to the identity claim verification system 108. Alternatively or in addition, the indication of verification may simply correspond to a message / confirmation from the identification provider 106a to the identity claim verification system 108 that the information identifying the user has been verified by the identity provider 106a (e.g., the user input information such as name, address, date of birth matches and / or a recent image such as a selfie matches corresponding user information stored in the organization's database).

[0062] In one or more specific implementations, more than one identity provider may be used to verify the user information. Therefore, the identity assertion verification system 108 may send corresponding requests to multiple identity verification providers. Each of the multiple identity verification providers may verify the fields of the information provided by the user based on a check of a corresponding database (e.g., an organization and / or institution database). Each of the multiple identity verification providers may send an indication of the verification to the identity assertion verification system 108.

[0063] In response to receiving the indication, the identity claim verification system 108 generates a verified claim based on the verified user information and based on an identity specific to the electronic device 102a (e.g., via a hardware / software reference key and / or a hardware / software device identifier). The identity claim verification system 108 then signs the verified claim (308). In the event that multiple identity verification providers have verified the user information, the verified claim may correspond to a composite claim.

[0064] Thus, the verified assertion corresponds to an identity assertion of the user, which has been signed by the identity assertion verification system 108 to indicate that the user information has been verified by at least one identity verification provider 106a. The verified assertion is further targeted to a specific electronic device 102a, such as a secure hardware component 206 specific to the electronic device 102a. The identity assertion verification system 108 then provides the signed verified assertion to the electronic device 102a (310).

[0065] In one or more specific implementations, a user of the electronic device 102a may create multiple verified identity claims. For example, a first type of verified claim may correspond to a digital version of a physical identity document, such as a driver's license, a passport, etc. (e.g., which may include image data, such as an identification image of the user). A second type of verified claim may correspond to a general digital certificate that stores information that identifies the user based on the verified user information. A third type of verified claim may correspond to user information that has not yet been verified by the identity provider system, for example, if the user wishes to use a pseudonym in association with certain services (e.g., a social network, a blog). Another type of verified claim may correspond to a work (and / or school) alias (or identity) rather than a personal alias (or identity).

[0066] In one or more specific implementations, a user of the electronic device 102a may request to view the verified identity claim. For example, the user may select an option presented within a user interface displayed on the electronic device 102a to view information related to the verified claim and / or information included in the verified claim. The option may be displayed by an application involved in registering and / or maintaining the verified identity claim.

[0067] When this option is selected, the user is provided with Figure 5 500 of a user interface that is an example of personally identifiable information that may be displayed with respect to a digital identity (e.g., a personal identity, a work identity, a social network identity, etc.). Figure 5 In the example of , user interface 500 includes display fields 502-514 corresponding to the verified statement. One or more fields displayed in association with the verified statement may include, but are not limited to, the user's: name 502, address 504, date of birth 506, identification number 508 (e.g., social security number), phone number 510, and email address 512.

[0068] In addition, display field 514 is a field (e.g., an optional field) indicating the name of the identity verification provider (e.g., if the verified claim is a composite claim, the identity verification provider 106a and / or other identity verification providers). Display field 514 also displays an indication of a key / identifier (e.g., a hardware / software reference key and / or a hardware / software identifier of the verified claim), a signature (e.g., a signature provided by the identity claim verification system 108), and an issued to field (e.g., which identifies the electronic device 102a).

[0069] In one or more implementations, certain display fields may simply indicate that the corresponding user information has been "verified" (e.g., verified by identity verification provider 106a) to obscure the user's private information from being displayed and / or to prevent the user's private (verified) information from being transmitted to a service provider. Figure 5 In the example of FIG. 5 , the user's date of birth 508 and identification number 510 are displayed as verified, rather than displaying the actual values ​​of these fields. The display of the actual information compared to the "verified" information may be implemented as a Merkle tree based at least in part on the verified claims, which will be described below with respect to Figure 7 Discussed in more detail. By using a Merkle tree, the electronic device 102a and / or the identity assertion verification system can selectively determine which fields of the verified assertion to provide for display and / or which fields of the verified assertion to provide to a service provider.

[0070] As described above, operations 312 - 330 may correspond to a sharing phase associated with registering for and / or participating in a service provided by the service provider 110a , wherein the electronic device 102a may share the verified claims with the service provider.

[0071] At operation 312, electronic device 102a registers to share (e.g., a verified claim) by sending a request to identity claim verification system 108. For example, the request may include a verified claim with a signature, and an indication of a service provider (e.g., 110a) with which to share the verified claim. Identity claim verification system 108 may register to share the identity status certificate (e.g., as described below in conjunction with 9A to 9D The token for evaluation may be provided to the electronic device 102a (314) along with a token for evaluation. For example, the identity status proof (e.g., corresponding to a certificate signed by the identity claim verification system 108) may prove or otherwise indicate that the verified claim is still valid (e.g., has not been revoked). In addition, the token for evaluation may be associated with device evaluation data (e.g., based on a comparison between multiple data fields in the verified claim and corresponding data stored locally on the device) and / or overall account evaluation data (e.g., an overall account evaluation service based on multiple data fields in the verified claim). In one or more specific implementations, the token for evaluation may correspond to a unique identifier for uniquely identifying a particular service provider (e.g., service provider 110a) from among the service providers 110a-110n, as further described below with respect to operation 324. By using the token, the user's device evaluation data and / or overall account evaluation data may be shared with the service provider 110a (e.g., and not shared with other service providers 110a-110n), as described below with respect to operation 326.

[0072] The electronic device 102a sends a request for a service provided by the service provider 110a (316). There are many types of services that can be provided by the service provider. Examples of such services include, but are not limited to: operating system services (e.g., podcast applications, instant messaging applications, payment applications, health applications, developer applications, wallet applications), third-party services (e.g., banking applications, travel applications), agency-based services (e.g., travel regulatory agencies, law enforcement agencies), social networking services (e.g., blogs, media, news), and / or generally any service.

[0073] Thus, the user of the electronic device 102a may invoke (e.g., or download and invoke if the application has not yet been downloaded) an appropriate application on the electronic device 102a corresponding to the corresponding service. Alternatively or in addition, the user of the electronic device 102a may invoke a web browser on the electronic device 102a and navigate to a website corresponding to the corresponding service.

[0074] In one or more specific implementations, the service provider 110a may require identity and verification to register / enable a user. Before providing services to the user, the verification process may require the user to provide information that identifies the user (e.g., in the form of a verified statement). In this regard, Figure 6 An exemplary user interface 600 for registering with a service provider 110a is shown in accordance with one or more implementations.

[0075] In one or more specific implementations, the user interface 600 includes two options for user registration services for the electronic device 102a. Based on the requirements of the service provider 110a, option 602 registers the user with the service by requiring the user to manually enter information (e.g., name, address, phone number) for identifying the user. The process may require the service provider 110a to separately verify the entered information with the identity verification provider 106a, and also require the user to provide private / sensitive data to the service provider (which may subsequently be exposed if the service provider experiences a data breach). On the other hand, option 604 provides for verifying the user by using an existing verified identity claim.

[0076] In the event that the user selects option 602 and clicks submit button 606, the user may be provided with an interface for registering with service provider 110a or for registering a digital identity independently of a service provider, such as user interface 400. For example, the interface may require the user to enter information identifying the user (e.g., name, address, date of birth, phone number). Upon completion of the service registration interface, the user may be provided with an option to request a verified claim based on the identification information entered by the user. For example, this may require verification of the input information by service provider 110a (or verification of the input information by the subject system when digital identity registration user interface 400 is presented to the user). The user may then opt-in to have a verified identity claim generated as part of the user registration for the service.

[0077] In the event that the user selects option 604 and clicks the submit button 606, the user may be provided with an interface that lists the verified identity claims available to the user. Thus, the user may select an appropriate identity claim for registering with the service provider 110a. As described above, the user may have multiple identity claims. For example, the user may have one or more identity claims that have been verified (e.g., verified by the identity authentication provider 106a) and signed (e.g., signed by the identity claim verification system 108), and / or one or more identity claims that have not been verified (e.g., corresponding to a pseudonym of the user). The listed identity claims may display one or more information fields for identifying the user (e.g., the user's name, address, telephone number) so that the user can select an appropriate identity claim for the service.

[0078] Thus, in response to receiving the request for service (316), the service provider 110a sends a request for a verified claim to the electronic device 102a (318). The request for a verified claim may include a random number. In one or more specific implementations, the random number may correspond to a security measure (e.g., for reducing the possibility of a replay attack). For example, when a digital signature is used to prove ownership of an asset (e.g., a verified claim), the random number may be requested to verify such ownership. Thus, to prove ownership of the claim, the electronic device 102a may be configured to request the random number, and the electronic device 102 may (e.g., using a private key) sign the random number to prove ownership of the verified claim.

[0079] Thus, in one or more specific implementations, the random number provided by the service provider 110a to the electronic device 102a can be used to confirm that the verified statement is specific to the electronic device 102a. The electronic device 102a signs the random number using a private key, for example, signed by a reference key of the secure hardware component 206 and stored in the secure hardware component 206 or memory 204 of the electronic device 102a (320). The signed random number indicates that the verified statement is specific to the electronic device 102a (e.g., rather than bound to / specific to another device) because the public key corresponding to the private key is included in the verified statement. The electronic device 102a then sends the verified statement along with the signed random number to the service provider 110a (322).

[0080] As described above with respect to operation 314, the electronic device 102a may have received proof of identity status (e.g., the verified claim is still valid and has not been revoked) from the identity claim verification system 108, as well as a token for evaluating the data. In one or more specific implementations, operations 312-314 may occur after the electronic device 102a has signed the random number at operation 320.

[0081] Prior to or in conjunction with operation 322, the electronic device 102a may provide a token for the evaluation data to the service provider 110a (e.g., along with an indication of the identity status proof). The service provider 110a may evaluate the evaluation data and / or the identity status proof associated with the token to determine whether to enable and / or provide services to the user of the electronic device 102a. For example, if the identity status proof indicates that the verified claim is no longer valid (e.g., the verified claim has been revoked), the service provider 110a may deny service.

[0082] In addition, the service provider 110a can verify the verified statement based at least in part on the hardware / software reference key and / or hardware / software device identifier (e.g., public key) of the verified statement and the signed random number (e.g., signed with the private key, corresponding to a confirmation that the verified statement is specific to the electronic device 102a). For example, the service provider 110a can use the public key included in the verified statement to confirm that the random number has been signed with the corresponding private key (e.g., indicating that the verified statement is specific to the electronic device 102a).

[0083] Operations 324-326 involve the identity claim verification system 108 providing assessment data (e.g., corresponding to a token provided by the electronic device 102a) to the service provider 110a. In addition to the identity status proof, the verified claim (e.g., as verified by the electronic device 102a), and the signed random number, the assessment data provides further information to the service provider 110a to determine whether to enable and / or provide services to the user of the electronic device 102a. The assessment data stored by the identity claim verification system 108 may include confidence assessments provided by the electronic device 102a, assessments provided by the identity verification providers 106a-106n, and / or assessments provided by an overall account assessment system (e.g., as described below with reference to Figure 8 and 9A to 9D described above).

[0084] In one or more specific implementations, the electronic device 102a may be configured to determine a confidence assessment of the verified statement based on a comparison between multiple data fields in the verified statement and corresponding data stored locally on the electronic device 102a. The electronic device 102a may have email content, message content, social network content, or third-party application content stored locally and corresponding to multiple data fields (e.g., name, email address, address, phone number) in the verified statement.

[0085] For example, an email stored on the electronic device 102a may indicate one or more of a user's name, email address, and / or phone number (e.g., as part of an email signature block). The electronic device 102a may be configured to extract this data from the email for comparison with multiple fields in the verified identity assertion. Similar data may be obtained from message content, social network content, or third-party application content stored on the electronic device 102a. The electronic device 102a may determine a confidence assessment of a data field of the verified assertion based on corresponding data obtained from locally stored content. For example, the electronic device 102a may determine a corresponding confidence assessment score for an appropriate data field in the verified assertion.

[0086] In addition to confidence assessments based on locally stored personally identifiable information, confidence assessments may also be based on sensor data of the device. For example, one or more sensors on the device (e.g., GPS-based sensors, motion sensors, image sensors) may be used to detect movement of the device over time. If the user is using the electronic device 102a, a predefined threshold of movement may be expected. If the device sensors indicate that the movement drops below the threshold, the device may not be being used by the user (e.g., but rather is requesting services in a fraudulent manner, such as a robot / simulation running in a data center). In such cases, it may be undesirable to provide services to the electronic device 102a.

[0087] In one or more specific implementations, the electronic device 102a may prompt the user for authorization before accessing locally stored content and / or sensor data to determine a confidence assessment of the verified claim, and / or the user may opt-in to participate. The electronic device 102a may provide the confidence assessment to the identity claim verification system 108 for transmission to the service provider 110a. Alternatively or in addition, the electronic device 102a may send the confidence assessment directly to the service provider 110a. For example, as part of operation 318, the electronic device 102a may send the confidence assessment along with the signed random number and the verified claim.

[0088] The assessment based on the local device data may be stored in the first response vector.For one or more fields of the verified assertion, the first response vector may indicate a confidence score (eg, determined by the electronic device 102a) indicating the likelihood that the corresponding field is accurate.

[0089] As described above, the identity verification provider 106a may also provide an assessment in conjunction with verifying the user information in the verified claim (e.g., in the form of a second response vector). For one or more fields of the verified claim, the second response vector may indicate a confidence score (e.g., determined by the identity verification provider 106a), which indicates the likelihood that the corresponding field is accurate. Therefore, the identity verification provider 106a may be configured to calculate a score for each of the data fields (e.g., name, address, email, etc.) included in the verified claim. For example, the identity verification provider 106a may compare multiple data fields in the verified claim with values ​​accessible to the identity verification provider 106a (e.g., from an institutional database), and determine a corresponding score based on the comparison. The corresponding score may be included in the second response vector, which may be provided by the identity verification provider 106a to the identity claim verification system 108 for sending to the service provider 110a. Alternatively or in addition, the identity verification provider 106a may send the second response vector directly to the service provider 110a.

[0090] In addition, the overall account evaluation can be determined based on the larger ecosystem associated with the electronic device 102a and / or the user. For example, the overall account evaluation can relate to one or more of the following: the likelihood of the user paying (e.g., based on past payment history) and / or fraudulent activity associated with the user's account that can be attributed to the user.

[0091] Thus, the service provider 110a receives proof of identity status, a verified statement with a signed random number that binds the verified statement to the electronic device 102a (322). The service provider 110a may also receive evaluation data (326), for example, provided that the token used for the evaluation data corresponds to the service provider 110a. Based on the received information, the service provider 110a may determine whether to provide service to the electronic device 102a. In this way, the service provider 110a may determine an overall confidence score indicating the likelihood that multiple data fields of the verified statement are accurate (e.g., based on one or more of the above-mentioned evaluations), and if the overall confidence score meets a predefined threshold, provide the service to the electronic device.

[0092] In one or more specific implementations, the service provider 110a may determine that the verified statement and / or assessment data is insufficient to identify the user for the requested service. For example, the verified statement may include fields that do not adequately identify the user based on the first response vector (e.g., based on local device data), the second response vector (e.g., institutional data from an identity verification provider), and / or the overall account assessment. Therefore, the service provider 110a may prompt the user of the electronic device 102a to enter additional information to supplement the information provided in the verified statement. The user may enter the supplemental information and provide it to the service provider 110a to re-evaluate whether to provide the service to the electronic device 102a.

[0093] Once the service provider 110a determines that the information provided is sufficient (e.g., based on the verified statement, the signed random number, the evaluation, and the supplemental data entered by the user, if any), the service provider 110a can authenticate the electronic device 102a (328). After being authenticated, the electronic device 102a can participate in the services provided by the service provider 110a (330).

[0094] In one or more specific implementations, after the electronic device 102a has been authenticated, the service provider 110a may provide the electronic device 102a with an identity certificate. The electronic device 102a may provide the identity certificate to the service provider 110a with respect to subsequent authentications with the service provider 110a (e.g., to avoid having to resend the verified statement and the signed random number to the service provider 110a). Thus, before sending the identity certificate to the service provider 110a, the electronic device 102a may require the user to authenticate via biometric recognition (e.g., on-device facial recognition, fingerprint recognition, iris recognition, signature recognition, etc.) and / or user password entry.

[0095] In one or more specific implementations, the verified claim may be revoked. For example, the electronic device 102a may be indicated as lost by the user (e.g., using a separate service for identifying lost devices). Alternatively or in addition, the electronic device 102a may present a user interface option that allows the user to cancel / revoke the verified claim as part of an application specifically related to registering and / or maintaining verified identity claims. The application may also include user interface options for displaying the contents of the verified claim (e.g., corresponding to user interface 500) and / or partially revoking the verified claim (e.g., where the user selects which data fields of the verified claim are to be revoked / deleted).

[0096] Thus, revoking a verified claim may be based on electronic device 102a being lost and / or a user explicitly requesting (in whole or in part) to revoke the verified claim. Thus, identity claim verification system 108 may receive a request to revoke a verified claim (e.g., from a "lost device" service and / or from electronic device 102a).

[0097] In response to receiving the revocation request, the identity claim verification system 108 may send instructions to the electronic device 102a for revoking the verified claim. The instructions for revoking the verified claim may include a request to the electronic device 102a to delete the verified claim itself (or appropriate fields of the verified claim if the revocation is partial). As a result, the electronic device 102a may no longer be able to provide the verified claim in response to a request for the verified claim by the service provider 110a.

[0098] Alternatively or in addition, the instruction to revoke the verified statement may include a request for the electronic device 102a to delete a private key stored on the electronic device 102a (e.g., stored in the secure hardware component 206 or the memory 204). Without the private key, the electronic device cannot correctly return the signed random number to the service provider 110a. Therefore, even if the verified statement is provided to the service provider 110a, the service will be denied, or the service provider 110a will require the user to enter additional information in order to register / use the service. In one or more specific implementations, if the user chooses to revoke only a portion of the verified statement, the deletion of the private key may not occur. Instead, the corresponding fields in the verified statement may simply be removed.

[0099] In addition to deleting content related to the verified claim on the electronic device 102a, content may also be deleted from the identity claim verification system 108. The content may include, but is not limited to, a copy of the verified claim (e.g., an encrypted copy of the verified claim stored on the identity claim verification system 108) and / or assessment data related to the verified claim (e.g., the first vector and the second vector, the overall account assessment).

[0100] In addition, the identity claim verification system 108 may maintain a list of verified claims that have been revoked (e.g., across multiple devices and multiple users). As part of the revocation process, the identity claim verification system 108 may update the revocation list to include verified claims for which revocation has been requested. For example, in response to a status request from the service provider 110a, the revocation of a verified claim may be relayed to the service provider 110a. Alternatively or in addition, updates to the revocation list may be sent from the identity claim verification system 108 to the service providers 110a-110n so that the service providers 110a-110n may check the revocation list before providing services with respect to the verified claim.

[0101] In one or more specific implementations, the identity verification provider 106a and / or the service provider 110a may be configured to communicate with the electronic device 102a in an authenticated and secure manner after successful registration (e.g., via messaging). However, some methods for providing such communications may expose the platform identity of the user and the identity verification provider 106a or the service provider 110a. In order to avoid and / or reduce the exposure of the platform identity, an elliptic curve cryptographic key pair may be generated in the AP. Using the Diffie-Hellman key exchange (DH) and the public key of the service provider 110a, an Advanced Encryption Standard (AES) key may be generated, and the message may be signed with a private key in the secure hardware component 206. Therefore, AES and elliptic curve cryptography (ECC) key pairs may be used to encrypt and sign messages between the electronic device 102a and the service provider 110a. Communication between the electronic device 102a and the identity verification provider 106a may be provided in a similar manner.

[0102] As described above, verified claims may be implemented as a Merkle tree for selective sharing of data fields. Figure 7 Examples of verified statements implemented as a Merkle tree in accordance with one or more implementations are shown.

[0103] As described above, the verified identity claim may include multiple data fields for identifying the user, such as first name, last name, date of birth, identification number (e.g., social security number), etc. However, some service providers may not require all of these data fields to register a user for a service. Therefore, the information included in the verified claim may be overly inclusive for some service providers, thereby unnecessarily exposing portions of the user's private / sensitive data to the service provider.

[0104] In one or more specific implementations, the Merkle tree 700 stores verified asserted personally identifiable information. The Merkle tree 700 is configured so that an electronic device (e.g., 102a) can select which of a plurality of fields to send in response to a request from a service provider (e.g., 110a) for information identifying a user, and filter the verified assertions accordingly. In this way, only the requested information is sent to the service provider 110a.

[0105] exist Figure 7 In the example of , Merkle tree 700 includes root node 702 and other nodes 704-774. Nodes 706, 740 and 742 represent group nodes for accessing user information in corresponding child nodes. For example, group node 706 provides a selection of data fields corresponding to user information manually entered by a user. The optional child nodes 708-738 of group node 706 include, but are not limited to, the user's: first name 716, first line 720 of address, state 724, last name 728, ID number 730 (e.g., social security number), second line 732 of address, city 734, zip code 736, and country 738.

[0106] In another example, group node 740 may include response vector information. As described above, for each data field in the data field of the verified statement, the response vector information may include a confidence score indicating the likelihood that the field is accurate. The Merkle tree may illustrate separate response vectors based on local device data and / or institutional data from the identity verification provider. In one or more specific implementations, group node 740 may have a child node (not shown) for selecting a corresponding confidence score. In one or more specific implementations, group node 742 provides a selection of data fields corresponding to user information obtained from a document identifying the user (e.g., a driver's license, passport, library card, etc.). Optional child nodes 744-774 of group node 742 may include archive response 752, corresponding to a document that is an output of a document verification process (e.g., performed by an identity verification provider such as an institution that issues identification documents). In addition, optional child nodes may include, but are not limited to, the user's: first line 756 of the address, state 760, first name 764, last name 766, second line 768 of the address, city 770, zip code 772, and country 774.

[0107] As described above, the identity assertion verification system 108 may share only a subset of the data fields within the Merkle tree 700, for example, by performing truncation on appropriate branches and / or nodes of the Merkle tree 700. Alternatively or in addition, a user of the electronic device 102a storing the verified assertions (e.g., in the form of the Merkle tree 700) may select which fields of the Merkle tree 700 to share with the service provider 110a. The user may select / deselect which fields to share and retain the cryptographic properties of the fields being shared.

[0108] Figure 8 An example of registering and sharing a verified identity claim according to one or more specific implementations is shown. For the purpose of explanation, this document mainly refers to the electronic device 102a, the identity claim verification system 108, the identity verification providers 106a-106n and the overall account evaluation server 834. Figure 8 .However, Figure 8 The components of the embodiment of the present invention may correspond to one or more other components and other suitable devices. However, not all of the components depicted may be used in all implementations, and one or more implementations may include additional or different components than those shown in the figures. Changes in the arrangement and type of these components may be made without departing from the spirit or scope of the claims listed herein. Additional components, different components, or fewer components may be provided.

[0109] like Figure 8 As shown, the electronic device 102a can register and / or participate in one or more services 826-832 using the verified statement. Examples of agency services 826 (e.g., government) include, but are not limited to, travel regulations agency services and / or law enforcement agency services. Examples of operating system services 828 (e.g., which have server-based components) include, but are not limited to, podcast applications, instant messaging applications, payment applications, health applications (e.g., for users to provide identity and / or view personal health records at hospitals), developer applications, and / or wallet applications (e.g., which provide extended credits via the operating system). Examples of third-party services 830 include, but are not limited to, banking applications and / or travel applications. Examples of social network services 832 include, but are not limited to, blogs, media, and / or news applications.

[0110] In one or more specific implementations, different types of verified claims may be used with respect to registering different services (e.g., services 826-832). As described above, the electronic device 102a may store different types of verified claims. For example, the different types of verified claims may correspond to one or more of a digital version of a physical identity document (e.g., a driver's license, a passport), a general digital certificate that stores verified identification information, and / or a digital certificate that stores identification information that has not yet been verified (e.g., corresponding to a pseudonym). As described above, a verified claim is a claim that information provided by a user to identify the user has been verified (e.g., signed by the identity claim verification system 108 based on verification of the information contained in the claim by the identity authentication provider 106a).

[0111] exist Figure 8 In the example of , operations 801-804 represent a verified statement (e.g., "Verified Statement A") corresponding to the digital version of the physical identity document. Thus, at operation 801, the identity claim verification system 108 may provide a workflow having a user interface (e.g., prompts, data fields, etc.) for a user to provide personal information. The workflow may also specify any biometric authentication requirements (e.g., on-device facial recognition, fingerprint recognition, iris recognition, signature recognition, etc.). At operation 802, the electronic device 102a may provide image data of the physical ID along with the token to the identity claim verification system 108. The identity claim verification system 108 may provide the data to one or more of the appropriate identity verification providers 106a to 106n, which may verify the image data. For example, the identity verification provider 106a (e.g., corresponding to the issuer of the physical identity document) may perform optical character recognition on the information printed on the physical identity document and compare the information with the information in the institution's database. The identity verification provider 106a may also authenticate known security features (e.g., watermarks, textures, indentations, holograms) on the ID based on the image data.

[0112] Upon verification, the identity claim verification system 108 may generate and sign a verified claim A and provide the verified claim A to the electronic device 102a at operation 804. The verified claim A (e.g., corresponding to a digital version of a physical identity document) may be provided to one or more agency services 826 (e.g., travel regulations, law enforcement) to prove the user's identity at operation 818. The verified claim A may be implemented as a Merkle tree so that only requested information (e.g., information required by a corresponding service provider) is sent to the service provider.

[0113] As another example, operations 806-810 indicate that a verified claim (e.g., "Verified Claim B") corresponds to a general digital certificate that stores identification information that has been verified by one or more of the identity providers 106a-106n. Thus, at operation 806, the identity claim verification system 108 may provide a workflow with a user interface (e.g., prompts, data fields, etc.) for a user to enter personally identifiable information and / or any biometric authentication requirements. The user may enter this information at the electronic device 102a, which in turn sends the user information (e.g., which may include an image, such image of a recent utility bill, and / or other verification document) to the identity claim verification system 108 at operation 808. The identity claim verification system 108 may provide this data to one or more of the appropriate identity verification providers 106a-106n for verification of the information.

[0114] Upon verification, the identity assertion verification system 108 may generate and sign a verified assertion B, and provide the verified assertion B to the electronic device 102a at operation 810. At operation 820, the verified assertion B may be provided to one or more of the operating system services 828, for example, in association with registering one or more of the corresponding services (e.g., podcasting, messaging, payment, health, developer, wallet). Alternatively or in addition, at operation 822, the verified assertion B may be provided to one or more of the third-party services 830, for example, in association with registering one or more of the corresponding services (e.g., banking, travel). The verified assertion B may be implemented as a Merkle tree so that only the requested information (e.g., information required by the corresponding service provider) is sent to the service provider.

[0115] In one or more specific implementations, the verified claims B and their corresponding workflows can take into account developer relationships between different regions (e.g., countries). In this regard, the identity provider can be country-specific, such that the information required to legally identify a user can vary between different countries. Therefore, the use of verified claims as described herein can be beneficial in enabling users for services provided by different countries and / or across different countries, for example, with respect to operating system services 828.

[0116] In addition, the workflow may specify a communication protocol by which the verified claim is allowed to be transmitted between the electronic device 102a and the service provider 110a. For example, with respect to a point of sale system corresponding to the service provider, the workflow may specify that one or more of near field communication (NFC) or a QR code is allowed to be used to provide the verified claim to the service provider 110a. The workflow may be country specific, with some countries allowing NFC and not allowing QR codes for verified claims, while other countries do not allow NFC and allow QR codes for verified claims.

[0117] In another example, operations 812-816 indicate that a verified claim (e.g., "Verified Claim C") corresponds to a digital certificate storing identification information that has not yet been verified by the identity providers 106a-106n. Thus, at operation 812, the identity claim verification system 108 may provide a workflow having a user interface (e.g., prompts, data fields, etc.) for a user to enter user information (e.g., a pseudo name, an email address) and / or any biometric authentication requirements. The user may enter the information at the electronic device 102a, which in turn sends the information to the identity claim verification system 108 at operation 814. In one or more specific implementations, the identity claim verification system 108 may verify that the information corresponds to a real person (e.g., not a robot) without having the identity providers 106a-106n perform further verification.

[0118] Upon verification, the identity claim verification system 108 may generate a verified claim C and provide the verified claim C to the electronic device 102a at operation 816. At operation 824, the verified claim C may be provided to one or more of the social networking services 832, for example, in association with registering one or more of the corresponding services (e.g., blogs, media, news). The verified claim C may be implemented as a Merkle tree so that only the requested information (e.g., information required by the corresponding service provider) is sent to the service provider.

[0119] like Figure 8 As shown, the identity assertion verification system may also communicate with an overall account evaluation server 834. For example, the overall account evaluation server 834 may be configured to provide an evaluation related to an overall evaluation of a user account associated with the electronic device 102a. In addition, the overall account evaluation may involve institutional data accessible to the identity verification providers 106a-106n. As described herein, a service provider (e.g., corresponding to an institutional service 826, an operating system service 828, a third-party service 830, and / or a social network service 832) may use evaluation data (e.g., including an overall account evaluation and / or other evaluation data as data provided by the overall account evaluation server 834) to determine whether to provide services to the electronic device 102a.

[0120] therefore, Figure 8An example of a user with multiple verified statements (e.g., verified statements A through C) is shown that may be stored on electronic device 102a and used in association with different types of services and / or user accounts. Alternatively or in addition, multiple users may have respective verified statements on a shared device (e.g., electronic device 102a). Each of the respective verified statements may be specific to electronic device 102a (e.g., via a hardware / software reference key and / or a hardware / software device identifier). In one or more specific implementations, different users may be required to authenticate via biometric recognition (e.g., on-device facial recognition or fingerprint recognition) and / or user password entry in order to access and / or share their respective verified statements (e.g., where biometric recognition and / or password recognition are used to identify the corresponding verified statement).

[0121] 9A to 9D Another process for registering and / or sharing a verified identity assertion according to one or more specific implementations is shown. For purposes of explanation, process 900 (e.g., across 9A to 9D ) is described herein primarily with reference to application 902, identity assertion verification client 904, secure hardware component 206, device confidence assessment client 906, identity assertion verification system 108, device confidence assessment server 908, overall account assessment server 834, service provider 110a, and identity verification provider 106a. However, process 900 is not limited to application 902, identity assertion verification client 904, identity assertion verification system 108, device confidence assessment server 908, overall account assessment server 834, service provider 110a, and identity verification provider 106a, and one or more operations (or multiple operations) of process 900 may be performed by one or more other components and other suitable devices. Further for the purpose of explanation, the operations of process 900 are described herein as occurring sequentially or linearly. However, multiple operations of process 900 may occur in parallel. In addition, the operations of process 900 do not have to be performed in the order shown, and / or one or more operations of process 900 do not have to be performed and / or may be replaced by other operations.

[0122] In one or more specific implementations, the application 902, the identity assertion verification client 904, and the device confidence assessment client 906 may reside on an electronic device (e.g., the electronic device 102a), for example, as part of an operating system of the electronic device 102a. The identity assertion verification system 108 may have corresponding client components, such as the identity assertion verification client 904. In addition, the device confidence assessment server 908 and the overall account assessment server 802 may correspond to separate servers.

[0123] In the exemplary process 900, an application 902 is used with a service provided by a service provider 110a. The process 900 may be applied to different types of services, such as, but not limited to, payment services, operating system services, third-party services, institutional services, and / or social networking services.

[0124] As referenced below 9A to 9D As described, process 900 may include one or more certifications (e.g., verifications) regarding the verified statement. For example, a first certification may correspond to a reference key (e.g., a master key) of the secure hardware component 206 being used to generate a private-public key pair (e.g., as described below with respect to operation 4), wherein the corresponding public key is signed by the reference key and provided to the identity claim verification system 108. In addition, a second certification may correspond to the identity claim verification system 108 generating / signing a certificate (e.g., an X-509 certificate) for the verified statement based on the public key to prove that the electronic device 102a is from a specific manufacturer (e.g., as described below with respect to operation 14). In addition, a third certification may correspond to the identity claim verification system 108 verifying that a previously generated and signed verified statement is still valid (e.g., has not been revoked due to device loss or due to fraudulent activity). In this regard, the identity claim verification system 108 may sign another certificate, thereby indicating the current validity status of the verified statement (e.g., as discussed below with respect to operation 33).

[0125] Go to Fig. 9A Operation 1 may occur after a user at the electronic device 102a launches the application 902. In operation 1, the service provider 110a provides the application 902 with initial access to the service so that the user may provide user information to identify the user.

[0126] At operation 2, the application 902 sends a request to the identity claim verification client 904 to initiate the generation of a verified identity claim. At operation 3, the identity claim verification client 904 sends a request to create a public-private key pair, for example, where the corresponding private key will be stored on the electronic device 102a (e.g., on the secure hardware component 206 or in the memory 204). As described above, the secure hardware component 206 may be optional in one or more specific implementations. For example, the verified claim may be specific to the electronic device 102a in various ways. For example, a hardware reference key of an indexing device, a software reference key of an indexing device, a hardware device identifier, and / or a software device identifier may be used.

[0127] exist Fig. 9AIn the example of , at operation 4, the secure hardware component 206 can use the hardware-specific reference key to generate a private-public key pair, sign the public key corresponding to the reference key pair, and present it to the server (108 or any other such service) that can issue digital certificates. As described above, such a signature performed by the secure hardware component 206 can correspond to a first proof that the certificate and / or the returned key pair was generated on the electronic device 102a and is specific to the device.

[0128] At operation 5, the identity assertion verification client 904 sends a request for a workflow for a verified assertion to the identity assertion verification system 108. As described above, the workflow may be a service that specifies a user interface (e.g., prompts, data fields, etc.) for a user to provide personally identifiable information, as well as any biometric authentication requirements and / or other instructions for enabling the user to the service.

[0129] In one or more specific implementations, the workflow may be specific to a service provider (e.g., service provider 110a), such that different service providers have different workflows for enabling users. Accordingly, the identity assertion verification system 108 may be configured to store different workflows from different service providers, update the stored workflows, and / or may request workflows (e.g., from the corresponding service providers).

[0130] At operation 6 , the identity claim verification system 108 requests the device confidence assessment server 908 for an assessment profile for assessing the verified claim.

[0131] The device confidence assessment server 908 generates an assessment profile for assessing the verified claim. For example, the assessment profile may indicate comparing the information of the verified claim with the information on the device (eg, device confidence assessment).

[0132] In one or more specific implementations, the evaluation profile can be used to assess whether the user's personally identifiable information is sufficient to provide services of different service providers. For example, a first type of service offering may require only minimal identifying information (e.g., name and phone number) in order to enable the user, while a second type of service offering may have more stringent requirements (e.g., additional identifying information, such as a photo, identification number, address, etc.). The evaluation profile can be used to determine different requirements of different service providers and / or compare those requirements with the identifying information of different users.

[0133] In one or more specific implementations, the evaluation profile may be implemented as a model (e.g., a machine learning model, a neural network, etc.) generated by a server (e.g., the identity assertion verification system 108) and provided to a device (e.g., the electronic device 102a). For example, the model may have been trained (e.g., on a server) using different data sets of user information across different types of service providers to determine whether the identification information of a particular user is sufficient to enable the user for a particular service. Thus, the model may be stored locally on the device (e.g., in the memory 204) and configured to output scores (e.g., confidence scores) for different data fields corresponding to the user's identification information. Thus, at operation 7, the device confidence assessment server 908 provides the evaluation profile to the identity assertion verification client 904.

[0134] At operation 8, the workflow and evaluation profile are transmitted to the identity assertion verification client 904 and / or application 902. At operation 9, the user enters user information associated with creating a verified assertion (e.g., by entering values ​​or pre-filling values). For example, the user may Figure 4 4. The application 302 provides input to the data fields shown in the user interface 400. At operation 10, the application 302 requests the identity assertion verification client 904 to perform verification of the field values.

[0135] Go to Fig. 9B At operations 11-12, the identity assertion verification client 904 requests and receives (e.g., from the secure hardware component 206) a signature based on a public-private key pair associated with the secure hardware component 206. (For example, where the public-private key pair is generated based on a reference key of the secure hardware component 206). At operation 13, the identity assertion verification client 904 requests identity verification (e.g., for workflow data) from the identity assertion verification system 108. For example, the identity verification may correspond to the above with respect to Figure 3 The registration phase described.

[0136] At operation 14, the identity claim verification system 108 verifies the public and private keys and other identifier information (e.g., a key pair) associated with the electronic device 102a. As described above, operation 14 may correspond to a second proof in which the identity claim verification system 108 signs a corresponding public key (e.g., previously signed by a reference key of a secure hardware component of the electronic device 102a that is associated with the first proof). The signature of the public key by the identity claim verification system 108 may correspond to a proof that the electronic device 102a is a device of a valid type configured for the verified claim (e.g., that the electronic device 102 is a device from a specific and / or trusted manufacturer, but does not specifically identify the electronic device 102). The identity claim verification system 108 may include the public key in a signed identity certificate (e.g., discussed with respect to operation 17).

[0137] At operation 15, the identity client verification system 108 sends a request to the identity verification provider 106a to verify the user information (e.g., the field value entered by the user). At operation 16, the identity verification provider 106a provides verification of the user information. For example, the verification of the user information may correspond to a verified user identity assertion.

[0138] Operation 17 involves the identity claim verification system 108 generating and signing a verified claim, for example based on the verification of the information by the identity authentication provider 106a. As described above, the verified claim may include a claim header for identifying the verified claim, and a Merkle tree including the user's identification information. The verified claim may correspond to a data blob (e.g., containing the user's identification information in the form of a Merkle tree), and the identity claim verification system 108 may further sign and return an identity certificate (e.g., an x509 certificate). The identity certificate may include a public key (e.g., a public key signed with respect to operation 14). In this way, the public key generated within the secure hardware component 206 of the electronic device 102a may be included as part of a certificate issued by the identity claim verification system 108.

[0139] Thus, the identity claim verification system 108 can provide proof (e.g., second proof) that the electronic device is a valid type of device to a verified claim that includes information used to identify the user, where the information used to identify the user has been verified by the identity verification provider 106a.

[0140] In one or more specific implementations, the identity assertion verification system 108 may store the verified assertion in an encrypted container and send the verified assertion to the identity assertion verification client 904 of the electronic device 102a at operation 18. At operations 19-20, the identity assertion verification client 904 locally decrypts the verified assertion and stores it in a memory (e.g., in the memory 204). At operation 21, the identity assertion verification client 904 sends an indication of identity authentication completion (e.g., corresponding to completion of the enrollment phase) to the application 902.

[0141] Go to Fig. 9C , operations 22-31 involve registering a share (e.g., a verified claim), and computing and storing an assessment of the verified claim. As described above, the assessment may involve a comparison of the user information included in the verified claim with local device content corresponding to the user information. In this regard, the device confidence assessment client 906 and the device confidence assessment server 908 correspond to confidence assessments associated with data stored on the device. In addition, the assessment may involve an overall assessment of the user account (e.g., corresponding to the overall account assessment server 834). In addition, the assessment may involve institutional data accessible to the identity verification providers 106a-106n.

[0142] At operation 22, the application 902 shares the verification result with the identity assertion verification client 904. At operation 23, the identity assertion verification client 904 requests device assessment data from the device confidence assessment client 906. For example, the identity assertion verification client 904 may communicate with the device confidence assessment client 906 regarding how the user information included in the verified assertion may be compared with corresponding information stored on the electronic device 102a (e.g., based on the training signal).

[0143] As described above, the evaluation profile (e.g., see operation 6) may correspond to a model trained with a data set for different service providers across multiple users. In this regard, the training signal may correspond to data provided by the electronic device 102a to the server (e.g., the identity assertion verification system 108) in order to update and / or retrain the model generated by the server (e.g., corresponding to the evaluation profile). Thus, the model can be trained based on crowdsourcing as well as continuously. In one or more specific implementations, the model can be provided to the electronic device 102a periodically and / or when the electronic device 102a requests an evaluation profile (e.g., in conjunction with operation 6). In addition, the training signal can be provided to the server by the electronic device 102a in conjunction with the user opting in to provide such training signals.

[0144] At operation 24, device confidence assessment client 906 returns the device assessment data to identity authentication client 904, which in turn sends the device assessment data to device confidence assessment server 908 at operation 25. Device confidence assessment server 908 may evaluate the device assessment data at operation 26.

[0145] At operation 27, identity assertion verification client 904 registers sharing by sending a request to identity assertion verification system 108. For example, as described above, the request may include a verified assertion with a signature, and an indication of a service provider (e.g., 110a) with which to share the verified assertion. At operation 28, identity assertion verification system 108 may verify the client's information (e.g., a signed key pair).

[0146] At operations 29-30, the identity assertion verification system 108 requests and obtains device evaluation data (e.g., corresponding to a comparison with the device data) from the device confidence evaluation server 908. At operations 31-32, the identity assertion verification system 108 requests and obtains an overall account evaluation (e.g., corresponding to an overall user account reputation) from the overall account evaluation server 834. The device evaluation data and the overall evaluation data may be stored by the identity assertion verification system 108 for provision to the service provider 110a.

[0147] As described above, the third type of proof may correspond to an identity status proof, in which the identity claim verification system 108 verifies that the verified claim is still valid (e.g., has not been revoked due to device loss or due to fraudulent activity). For example, the identity claim verification system 108 may sign another certificate to indicate the current validity status of the verified claim. Therefore, at operation 33, the identity claim verification system 108 may provide the identity status proof (e.g., the third proof) together with the token for evaluation to the electronic device 102a (314). The token for evaluation may be associated with device evaluation data and / or overall account evaluation data. As described above, the token may correspond to a unique identifier for uniquely identifying a particular service provider (e.g., service provider 110a) from among the service providers 110a-110n.

[0148] Go to Fig.9D , operations 34-45 involve the service provider 110a providing a random number for the electronic device 102a to sign in association with the service provider 110a requesting a verified claim from the electronic device 102a and the assessment data from the identity claim verification system 108. Operations 34-35 involve the service provider 110a providing the random number to the identity claim verification client 904. At operations 36-37, the identity claim verification client 904 signs the random number with a private key (e.g., stored on the secure hardware component 206).

[0149] The identity claim verification client 904 sends the verified claim and the signed random number to the service provider 110a at operation 38. As described above with respect to operation 33, the identity claim verification client 904 may have received the identity status proof (e.g., the verified claim is still valid and has not been revoked) and the token for evaluating the data from the identity claim verification system 108. Prior to or in conjunction with operation 38, the electronic device 102a may provide the identity status proof and / or an indication of the token for evaluating the data to the service provider 110a.

[0150] As described above, the workflow (e.g., provided to the electronic device at operation 8) may be specific to the service provider 110a and may indicate any biometric authentication requirements for the specific service provider (e.g., a bank may require one or more of on-device facial recognition, fingerprint recognition, iris recognition, signature recognition, etc.). Thus, if the workflow requires biometric authentication, operation 38 may be performed after the user has successfully performed such biometric authentication. The electronic device 102a embeds the specific user authentication performed during the process into the digital signature of operation 38. This will enable the service provider 110a to verify the authentication level and determine the confidence / trust level.

[0151] The service provider 110a may evaluate the identity status certificate and / or token in determining whether to enable and / or provide services to the user of the electronic device 102a. In addition, the service provider 110a may verify that the verified statement is from the electronic device 102a (e.g., not from another device) based on the signed random number (operation 39).

[0152] At operations 40-41, the service provider 110a requests and receives evaluation data determined and stored by the identity assertion verification system 108. As described above, the evaluation data may indicate a comparison of the user information in the verified assertion with the data stored locally on the device (e.g., in the form of a first response vector). The evaluation data may also be based on institutional data known to the identity authentication provider 106a (e.g., in the form of a second response vector). The evaluation data may also include an overall user account evaluation. One or more of the evaluations (e.g., aggregated evaluation data) may be used by the service provider 110a as additional information for determining whether to enable and / or provide services to the electronic device 102a. Operations 43-44 involve the service provider 110a providing corresponding identifiers to the identity assertion verification client 904 and the application 902, so that the application 902 can participate in the service with the service provider at operation 45. In one or more specific implementations, one or more of operations 1-45 may be repeated with respect to a service (e.g., provided by one or more of the service providers 110a-110n) and / or used to re-register for a service.

[0153] Fig.10 A flowchart of an exemplary process for receiving services from a service provider using a verified claim according to one or more specific implementations is shown. Figure 1 The process 1000 is described with reference to the electronic device 102a, the identity verification provider 106a, the identity assertion verification system 108 and the service provider 110a. However, the process 1000 is not limited to Figure 1 The electronic device 102a, identity verification provider 106a, identity assertion verification system 108 and service provider 110a of process 1000, and one or more boxes (or operations) of process 1000 may be performed by one or more other components and other suitable devices (e.g., any one of electronic devices 102a-102d, identity verification providers 106a-106n and / or service providers 110a-110n). Further for the purpose of explanation, the boxes of process 1000 are described herein as occurring sequentially or linearly. However, multiple boxes of process 1000 may occur in parallel. In addition, the boxes of process 1000 do not have to be performed in the order shown, and / or one or more boxes of process 1000 do not have to be performed and / or may be replaced by other operations.

[0154] Electronic device 102a receives a verified assertion (1002) including information identifying a user of electronic device 102a. The verified assertion is signed by a server (e.g., identity assertion verification system 108) based on verification of the information by an identity verification provider (e.g., identity verification provider 106a) that is separate from identity assertion verification system 108. The verified assertion is specific to electronic device 102a (e.g., via a hardware / software reference key and / or a hardware / software device identifier).

[0155] The identity claim verification system 108 may be configured to generate verified claims as part of a digital identity enrollment process.The identity verification provider 106a may be a trusted service for verifying information used to identify a user.

[0156] The verified statement may correspond to a Merkle tree having nodes storing data fields corresponding to information identifying the user. The Merkle tree may be configured to selectively share data fields based on the nodes.

[0157] The verified claim may be a composite claim. Identity claim verification system 108 may be configured to generate a composite claim based on verification of the information by identity verification provider 106a and at least one second identity verification provider (eg, one or more of identity verification providers 106b-106n).

[0158] Prior to receiving the verified claim, the electronic device 102a may generate a hardware / software reference key and / or a hardware / software device identifier based at least in part on a hardware component of the electronic device 102a (e.g., the secure hardware component 206), and transmit a request for the verified claim to the identity claim verification system 108, which is specific to the electronic device 102a.

[0159] The electronic device 102a sends a request to the service provider 110a for the services provided by the service provider 110a (1004). The electronic device 102a receives a request for a verified claim from the service provider 110a in response to sending (1006).

[0160] In response to receiving, the electronic device 102a sends the verified claim to the service provider 110a (1008). The service provider 110a may be configured to provide services to the electronic device 102a based on the verified claim.

[0161] The hardware / software reference key and / or the hardware / software device identifier may be a public key in a public-private key pair, whose corresponding private key is securely stored on the electronic device 102a (e.g., in the hardware security element 206). The request for the verified statement may include a random number, and the electronic device 102a may sign the random number with the private key and send the signed random number along with the verified statement to the service provider 110a.

[0162] The electronic device 102a may receive the identity certificate from the service provider 110a in response to the sending for sending to the service provider 110a with respect to subsequent authentication with the service provider 110a. Before sending the identity certificate to the service provider 110a, the electronic device 102a may authenticate the user via facial recognition, fingerprint recognition, and / or another user authentication mechanism.

[0163] The electronic device 102a may send a request for a second service provided by the service provider 110b to a second service provider (e.g., the service provider 110b). The electronic device 102a may receive a second request for a verified statement from the service provider 110b in response to sending the request for the second service. The electronic device 102a may send the verified statement to the service provider 110b in response to receiving the second request.

[0164] Fig.11 A flowchart of an example process for providing a confidence assessment for a verified claim according to one or more specific implementations is shown. Figure 1 The process 1100 is described with reference to the electronic device 102a, the identity verification provider 106a, the identity assertion verification system 108 and the service provider 110a. However, the process 1100 is not limited to Figure 1 The electronic device 102a, identity verification provider 106a, identity assertion verification system 108 and service provider 110a of process 1100, and one or more boxes (or operations) of process 1100 may be performed by one or more other components and other suitable devices (e.g., any one of electronic device 102a-102d, identity verification provider 106a-106n and / or service provider 110a-110n). Further for the purpose of explanation, the boxes of process 1100 are described herein as occurring sequentially or linearly. However, multiple boxes of process 1100 may occur in parallel. In addition, the boxes of process 1100 do not have to be performed in the order shown, and / or one or more boxes of process 1100 do not have to be performed and / or may be replaced by other operations.

[0165] The electronic device 102a sends a request to a service provider (e.g., service provider 110a) for services provided by the service provider (1102). In response to sending, the electronic device 102a receives a request for a verified statement from the service provider 110a (1104). The verified statement includes a plurality of data fields for identifying a user of the electronic device 102a and is signed by a server (e.g., identity statement verification system 108). The verified statement is specific to the electronic device 102a.

[0166] The electronic device 102a may receive the verified claim from the identity claim verification system 108. The identity claim verification system 108 may generate the verified claim based on verification of a plurality of data fields by an identity verification provider (eg, identity verification provider 106a).

[0167] The verified claim may correspond to a Merkle tree having nodes storing a plurality of data fields for identifying the user. The Merkle tree may be configured to selectively share the plurality of data fields based on the nodes.

[0168] In response to the receiving, the electronic device 102a determines a confidence assessment of the verified statement based on a comparison between the plurality of data fields in the verified statement and corresponding data stored locally on the electronic device 102a (1106). The locally stored data may include at least one of email content, message content, social network content, or third-party application content corresponding to the plurality of data fields in the verified statement.

[0169] Prior to determining, the electronic device 102a may prompt a user to authorize access to data stored locally on the electronic device 102a and may receive user input authorizing access to data stored locally on the electronic device 102a.

[0170] The electronic device 102a sends the confidence assessment and the verified claim to the service provider 110a (1108). The service provider 110a may be configured to authenticate the user for the service based on the verified claim and the confidence assessment. The service provider 110a may also be configured to authenticate the user for the service based on an assessment of the plurality of data fields by at least one of the identity verification provider 106a or the overall account assessment service.

[0171] Fig.12 A flowchart of an exemplary process for requesting additional information from a user based on information included in a verified statement according to one or more specific implementations is shown. Figure 1 The process 1200 is described with reference to the electronic device 102a, the identity verification provider 106a, the identity assertion verification system 108 and the service provider 110a. However, the process 1200 is not limited to Figure 1 The electronic device 102a, identity verification provider 106a, identity assertion verification system 108 and service provider 110a of process 1200, and one or more boxes (or operations) of process 1200 may be performed by one or more other components and other suitable devices (e.g., any one of electronic devices 102a-102d, identity verification providers 106a-106n and / or service providers 110a-110n). Further for the purpose of explanation, the boxes of process 1200 are described herein as occurring sequentially or linearly. However, multiple boxes of process 1200 may occur in parallel. In addition, the boxes of process 1200 do not have to be performed in the order shown, and / or one or more boxes of process 1200 do not have to be performed and / or may be replaced by other operations.

[0172] The electronic device 102a sends a request to a service provider (eg, service provider 110a) for a service provided by the service provider 110a (1202). The electronic device 102a receives a request for a verified assertion from the service provider 110a in response to sending the request for the service (1204).

[0173] The verified claim includes first information for identifying a user of the electronic device 102a. The verified claim includes information specific to the electronic device 102a. The electronic device 102a may receive the verified claim from the identity claim verification system 108. The identity claim verification system 108 may generate the verified claim based on verification of the information by the identity verification provider 106a.

[0174] The verified statement may correspond to a Merkle tree having nodes storing a plurality of data fields corresponding to the first information. The Merkle tree may be configured to selectively share the plurality of data fields based on the nodes.

[0175] The electronic device 102a sends the verified claim to the service provider 110a in response to receiving the request for the verified claim (1206). The electronic device 102a receives a request for second information for identifying the user from the service provider 110a (1208). The second information is different from the first information, and the request for the second information is based on a determination that the first information is insufficient to identify the user.

[0176] Determining that the first information is insufficient to identify the user may correspond to an indication that the electronic device 102a has been lost. The identity assertion verification system 108 may be configured to send an indication of a determination that the first information is insufficient to identify the user to the service provider 110a.

[0177] The electronic device 102a may prompt the user to input the second information. In response to the prompt, the electronic device 102a may receive the user input corresponding to the second information. The service provider 110a may be configured to authenticate the user for the service based on the first information and the second information.

[0178] Fig.13 A flowchart of an exemplary process for providing services to a device based on a response vector of a verified claim according to one or more specific implementations is shown. For the purpose of explanation, this document mainly refers to Figure 1 The process 1300 is described with reference to the electronic device 102a, the identity verification provider 106a, the identity assertion verification system 108 and the service provider 110a. However, the process 1300 is not limited to Figure 1 The electronic device 102a, identity verification provider 106a, identity assertion verification system 108 and service provider 110a of process 1300, and one or more boxes (or operations) of process 1300 may be performed by one or more other components and other suitable devices (e.g., any one of electronic device 102a-102d, identity verification provider 106a-106n and / or service provider 110a-110n). Further for the purpose of explanation, the boxes of process 1300 are described herein as occurring sequentially or linearly. However, multiple boxes of process 1300 may occur in parallel. In addition, the boxes of process 1300 do not have to be performed in the order shown, and / or one or more boxes of process 1300 do not have to be performed and / or may be replaced by other operations.

[0179] The service provider 110a receives a response vector corresponding to a verified claim of a user of the electronic device 102a (1302). The verified claim includes a plurality of data fields for identifying the user, the verified claim being specific to the electronic device 102a. For each of the plurality of data fields, the response vector includes a confidence score indicating the likelihood that the field is accurate.

[0180] The identity claim verification system 108 may generate a verified claim based on verification of the plurality of data fields by an identity verification provider (eg, identity verification provider 106a).The service provider 110a may receive the verified claim from the electronic device 102a.

[0181] The verified claim may correspond to a Merkle tree having nodes storing a plurality of data fields for identifying the user. The Merkle tree may be configured to selectively share the plurality of data fields based on the nodes.

[0182] The service provider 110a receives a request for a service from the electronic device 102a (1304). In response to receiving the request, the service provider 110a determines that the service will be provided to the electronic device 102a based on the response vector and / or the verified assertion (1306). The service provider 110a provides the service to the electronic device 102a based on the determination (1308).

[0183] Determining that a service will be provided to the electronic device 102a may include determining an overall confidence score indicating a likelihood that the plurality of data fields are accurate based on the confidence scores of the response vectors. Determining the overall confidence score may include assigning a respective weighting value to the confidence score of each of the plurality of data fields, and determining the overall confidence score based on the respective weighting values ​​applied to the confidence scores.

[0184] The service provider 110a may receive at least one of a first evaluation or a second evaluation of the verified statement. The first evaluation may be received from the electronic device 102a based on a comparison between a plurality of data fields in the verified statement and corresponding data stored locally on the electronic device 102a. The second evaluation may be received from the overall account evaluation service based on a plurality of data fields in the verified statement. Determining that a service will be provided to the electronic device 102a may also be based on at least one of the first evaluation or the second evaluation.

[0185] Fig.14 A flowchart of an example process for revoking a verified statement according to one or more specific implementations is shown. For the purpose of explanation, this article mainly refers to Figure 1 The process 1400 is described with reference to the electronic device 102a, the identity verification provider 106a, the identity assertion verification system 108 and the service provider 110a. However, the process 1400 is not limited to Figure 1 The electronic device 102a, identity verification provider 106a, identity assertion verification system 108 and service provider 110a of process 1400, and one or more boxes (or operations) of process 1400 may be performed by one or more other components and other suitable devices (e.g., any one of electronic device 102a-102d, identity verification provider 106a-106n and / or service provider 110a-110n). Further for the purpose of explanation, the boxes of process 1400 are described herein as occurring sequentially or linearly. However, multiple boxes of process 1400 may occur in parallel. In addition, the boxes of process 1400 do not have to be performed in the order shown, and / or one or more boxes of process 1400 do not have to be performed and / or may be replaced by other operations.

[0186] The identity claim verification system 108 (e.g., the identity claim verification system 108) receives a first request to revoke a verified claim, the verified claim including information for identifying a user of the electronic device 102a (1402). The verified claim is specific to the electronic device 102a and is stored on the electronic device 102a. For example, the verified claim may be specific to the electronic device 102a via a hardware / software reference key and / or a hardware / software device identifier generated by the electronic device 102a and associated with a hardware component of the electronic device 102a.

[0187] Prior to receiving the first request, the identity claim verification system 108 may receive a request for a verified claim from the electronic device 102a, the request being specific to the electronic device 102a. The identity claim verification system 108 may generate and sign the verified claim based on verification of the information by an identity verification provider (e.g., identity verification provider 106a) that is separate from the identity claim verification system 108. The identity claim verification system 108 may transmit the verified claim to the electronic device 102a.

[0188] The first request may be received from a service (e.g., a service for locating a device and / or determining whether a device is lost) based on an indication that the electronic device 102a is lost. Alternatively or in addition, the first request may be received from the electronic device 102a based on a first user input received at the electronic device 102a for revoking a verified statement.

[0189] The electronic device 102a may be configured to receive a second user input for displaying information for identifying the user, and in response to receiving the second user input, display the information for identifying the user. The electronic device 102a may also be configured to receive a second user input for partially revoking the verified statement, the second user input indicating the portion of the information to be revoked, and in response to receiving the second user input, remove the portion of the information from the verified statement.

[0190] In response to receiving the first request, identity assertion verification system 108 sends a second request to electronic device 102a to revoke the verified assertion on electronic device 102a (1404). The second request may include a request to delete the verified assertion on electronic device 102a.

[0191] The hardware / software reference key and / or the hardware / software device identifier may be a public key in a public-private key pair, the corresponding private key of which is securely stored on the electronic device 102a. The second request may include a request to delete the private key. The electronic device 102a may be configured to delete the private key securely stored on the electronic device 102a in response to receiving the second request.

[0192] The identity claim verification system 108 adds the verified claim to the revocation list (1406). The identity claim verification system 108 may receive a request for the status of the verified claim from a service provider (e.g., service provider 110a). The service provider 110a may be configured to provide services to the electronic device 102a based on the status of the verified claim. In response to receiving the request for the status, the identity claim verification system 108 may determine that the verified claim is included on the revocation list and transmit an indication to the service provider 110a that the verified claim is revoked.

[0193] Alternatively or additionally, the identity assertion verification system 108 may provide the revocation list to one or more service providers (eg, service providers 110a-110n). The service providers 110a-110n may be configured to provide services to the electronic device 102a based on the revocation list.

[0194] As described above, one aspect of the subject technology is the collection and use of data available from specific and legitimate sources for digital identity registration. The present disclosure contemplates that, in some instances, the collected data may include personal information data that uniquely identifies or can be used to identify a specific person. Such personal information data may include demographic data, location-based data, online identifiers, phone numbers, email addresses, home addresses, data or records related to a user's health or fitness level (e.g., vital signs measurements, medication information, exercise information), date of birth, or any other personal information.

[0195] The present disclosure recognizes that the use of such personal information data in the present technology can be used to benefit users. For example, personal information data can be used for digital identity registration. Therefore, the use of such personal information data can facilitate transaction processing (e.g., online transaction processing). In addition, the present disclosure also anticipates other uses of personal information data that benefit users. For example, health and fitness data can be used according to the user's preferences to provide insights into their overall health status, or can be used as positive feedback to individuals who use technology to pursue health goals.

[0196] This disclosure envisions that entities responsible for collecting, analyzing, disclosing, transmitting, storing or otherwise using such personal information data will comply with established privacy policies and / or privacy practices. Specifically, such entities will be expected to implement and consistently apply privacy practices that are generally recognized as meeting or exceeding the requirements of the industry or government that maintain user privacy. Such information about the use of personal data should be prominently and easily accessible to users, and should be updated as the collection and / or use of data changes. The user's personal information should be collected only for legitimate use. In addition, such collection / sharing should only occur after receiving user consent or other legal basis specified in applicable law. In addition, such entities should consider taking any necessary steps to defend and safeguard access to such personal information data and ensure that others who have access to personal information data comply with their privacy policies and processes. In addition, such entities may subject themselves to third-party assessments to demonstrate their compliance with widely accepted privacy policies and practices. In addition, policies and practices should be adjusted for specific types of personal information data collected and / or accessed, and applied to applicable laws and standards, including specific considerations that are exclusive to jurisdictions that can be used to impose higher standards. For example, in the United States, collection or access to certain health data may be governed by federal and / or state laws, such as the Health Insurance Portability and Accountability Act (HIPAA); while health data in other countries may be subject to other regulations and policies and should be handled accordingly.

[0197] Regardless of the foregoing, the present disclosure also contemplates implementation schemes in which users selectively block the use or access of personal information data. That is, the present disclosure contemplates that hardware elements and / or software elements may be provided to prevent or block access to such personal information data. For example, with respect to registering a digital identity, the subject technology may be configured to allow a user to choose to "opt in" or "opt out" to participate in the collection of personal information data during registration for a service or at any time thereafter. In addition to providing "opt-in" and "opt-out" options, the present disclosure contemplates providing notifications related to access or use of personal information. For example, a user may be notified that their personal information data will be accessed when downloading an application, and then be reminded again just before the personal information data is accessed by the application.

[0198] In addition, it is an object of the present disclosure that personal information data should be managed and processed to minimize the risk of unintentional or unauthorized access or use. Risks can be minimized by limiting data collection and deleting data once it is no longer needed. In addition, and when applicable, including in certain health-related applications, data de-identification can be used to protect the privacy of users. De-identification can be facilitated by removing identifiers, controlling the amount or specificity of stored data (e.g., collecting location data at a city level rather than at an address level), controlling how data is stored (e.g., aggregating data across users), and / or other methods such as differential privacy, where appropriate.

[0199] Therefore, while the present disclosure broadly covers the use of personal information data to implement one or more of the various disclosed embodiments, the present disclosure also contemplates that various embodiments may be implemented without access to such personal information data. That is, various embodiments of the present technology will not fail to function properly due to the lack of all or part of such personal information data.

[0200] Fig.15 1500 illustrates an exemplary electronic system that can be used to implement various aspects of the subject technology according to one or more specific implementations. Figure 1 One or more of the electronic devices 102a-102d, identity verification providers 106a-106n, identity assertion verification systems 108, and / or service providers 110a-110n shown, and / or may be a part thereof. The electronic system 1500 may include various types of computer-readable media and interfaces for various other types of computer-readable media. The electronic system 1500 includes a bus 1508, one or more processing units 1512, a system memory 1504 (and / or buffers), a ROM 1510, a permanent storage device 1502, an input device interface 1514, an output device interface 1506, and one or more network interfaces 1516, or subsets and variations thereof.

[0201] The bus 1508 generally represents all system, peripheral, and chipset buses that communicatively connect the many internal devices of the electronic system 1500. In one or more specific implementations, the bus 1508 communicatively connects the one or more processing units 1512 with the ROM 1510, the system memory 1504, and the permanent storage device 1502. The one or more processing units 1512 retrieve instructions to be executed and data to be processed from these various memory units in order to perform the processes disclosed in the subject matter. In different specific implementations, the one or more processing units 1512 can be a single processor or a multi-core processor.

[0202] ROM 1510 stores static data and instructions required by the one or more processing units 1512 and other modules of the electronic system 1500. On the other hand, permanent storage device 1502 can be a read-write memory device. Permanent storage device 1502 can be a non-volatile memory unit that stores instructions and data even when the electronic system 1500 is turned off. In one or more specific implementations, a mass storage device (such as a magnetic or optical disk and its corresponding disk drive) can be used as permanent storage device 1502.

[0203] In one or more implementations, a removable storage device (such as a floppy disk, a flash drive and its corresponding disk drive) may be used as the permanent storage device 1502. Like the permanent storage device 1502, the system memory 1504 may be a read-write memory device. However, unlike the permanent storage device 1502, the system memory 1504 may be a volatile read-write memory, such as a random access memory. The system memory 1504 may store any of the instructions and data that one or more processing units 1512 may need at runtime. In one or more implementations, the processes disclosed in the subject matter are stored in the system memory 1504, the permanent storage device 1502, and / or the ROM 1510. The one or more processing units 1512 retrieve instructions to be executed and data to be processed from these various memory units in order to perform the processes of one or more implementations.

[0204] The bus 1508 is also connected to an input device interface 1514 and an output device interface 1506. The input device interface 1514 enables a user to transmit information and select commands to the electronic system 1500. Input devices that can be used with the input device interface 1514 may include, for example, an alphanumeric keyboard and a pointing device (also referred to as a "cursor control device"). The output device interface 1506 may enable, for example, the display of images generated by the electronic system 1500. Output devices that can be used with the output device interface 1506 may include, for example, a printer and a display device, such as a liquid crystal display (LCD), a light emitting diode (LED) display, an organic light emitting diode (OLED) display, a flexible display, a flat panel display, a solid-state display, a projector, or any other device for outputting information. One or more specific implementations may include a device that acts as both an input device and an output device, such as a touch screen. In these specific implementations, the feedback provided to the user may be any form of sensory feedback, such as visual feedback, auditory feedback, or tactile feedback; and input from the user may be received in any form, including acoustic, voice, or tactile input.

[0205] Finally, if Fig.15 As shown, bus 1508 also couples electronic system 1500 to one or more networks and / or to one or more network nodes, such as via one or more network interfaces 1516. Figure 1 102-104 shown in . In this manner, electronic system 1500 can be part of a computer network such as a LAN, a wide area network ("WAN"), or an intranet, or can be part of a network of networks such as the Internet. Any or all components of electronic system 1500 can be used with the subject disclosure.

[0206] Implementations within the scope of the present disclosure may be implemented in part or in whole using a tangible computer-readable storage medium (or multiple tangible computer-readable storage media of one or more types) programmed with one or more instructions. Tangible computer-readable storage media may also be non-transitory in nature.

[0207] Computer-readable storage media can be any storage media that can be read, written, or otherwise accessed by a general or special computing device, including any processing electronics and / or processing circuitry capable of executing instructions. For example, without limitation, computer-readable media can include any volatile semiconductor memory, such as RAM, DRAM, SRAM, T-RAM, Z-RAM, and TTRAM. Computer-readable media can also include any non-volatile semiconductor memory, such as ROM, PROM, EPROM, EEPROM, NVRAM, flash memory, nvSRAM, FeRAM, FeTRAM, MRAM, PRAM, CBRAM, SONOS, RRAM, NRAM, racetrack memory, FJG, and Millipede memory.

[0208] In addition, the computer-readable storage medium may include any non-semiconductor memory, such as optical disk storage, magnetic disk storage, magnetic tape, other magnetic storage devices, or any other medium capable of storing one or more instructions. In one or more specific implementations, the tangible computer-readable storage medium may be directly coupled to the computing device, while in other specific implementations, the tangible computer-readable storage medium may be indirectly coupled to the computing device, for example, via one or more wired connections, one or more wireless connections, or any combination thereof.

[0209] Instructions can be directly executable, or can be used to develop executable instructions. For example, instructions can be implemented as executable or non-executable machine code, or can be implemented as high-level language instructions that can be compiled to produce executable or non-executable machine code. In addition, instructions can also be implemented as data, or can include data. Computer executable instructions can also be organized in any format, including routines, subroutines, programs, data structures, objects, modules, applications, applets, functions, etc. As recognized by those skilled in the art, the details including but not limited to the number, structure, sequence and organization of instructions can be significantly different without changing the underlying logic, function, processing and output.

[0210] Although the above discussion mainly involves microprocessors or multi-core processors that execute software, one or more implementations are performed by one or more integrated circuits such as ASICs or FPGAs. In one or more implementations, such integrated circuits execute instructions stored on the circuits themselves.

[0211] Those skilled in the art will recognize that the various illustrative frames, modules, elements, parts, methods and algorithms described herein can be implemented as electronic hardware, computer software or a combination of the two. In order to illustrate this interchangeability of hardware and software, various illustrative frames, modules, elements, parts, methods and algorithms have been generally described above according to functionality. Whether such functionality is implemented as hardware or software depends on the specific application and the design constraints imposed on the entire system. The technician can implement the described functionality in different ways for each specific application. Various parts and frames can be arranged differently (e.g., arranged in different orders, or divided in different ways) without departing from the scope of the subject technology.

[0212] It should be understood that the specific order or the hierarchical structure of the frame in the process disclosed by the present invention are the illustration of exemplary methods. Based on the design preferred requirements, it should be understood that the specific order or the hierarchical structure of the frame in the process can be rearranged or all the frames shown are executed. Any frame in these frames can be executed simultaneously. In one or more specific implementations, multitasking and parallel processing may be advantageous. In addition, the division of each system component in the above-mentioned specific implementation should not be understood as requiring such division in all specific implementations, and it should be understood that program components and systems can be generally integrated together in a single software product or encapsulated in multiple software products.

[0213] As used in this specification and any claims of this patent application, the terms "base station", "receiver", "computer", "server", "processor" and "memory" all refer to electronic devices or other technical devices. These terms exclude people or groups of people. For the purpose of this specification, the term "display" or "displaying" means displaying on an electronic device.

[0214] As used herein, the phrase "at least one of" following a list of items, any of which is separated by the terms "and" or "or", modifies the list as a whole, rather than each member (i.e., each item) of the list. The phrase "at least one of" does not require selection of at least one of each item listed; rather, the phrase allows for a meaning that includes at least one of any one item and / or at least one of any combination of items and / or at least one of each item. For example, the phrases "at least one of A, B, and C" or "at least one of A, B, or C" each refer to only A, only B, or only C; any combination of A, B, and C; and / or at least one of each of A, B, and C.

[0215] The predicate words "configured to," "operable to," and "programmed to" do not imply any particular tangible or intangible modification of a subject matter but are intended to be used interchangeably. In one or more specific implementations, a processor configured to monitor and control an operation or component may also mean that the processor is programmed to monitor and control the operation or that the processor is operable to monitor and control the operation. Likewise, a processor configured to execute code may be interpreted as a processor programmed to execute code or operable to execute code.

[0216] Phrases such as aspect, this aspect, on the other hand, some aspects, one or more aspects, a specific implementation, this specific implementation, another specific implementation, some specific implementations, one or more specific implementations, an embodiment, this embodiment, another embodiment, some embodiments, one or more embodiments, configuration, this configuration, other configurations, some configurations, one or more configurations, subject technology, disclosure, the present disclosure, other variations thereof, etc. are for convenience and do not mean that the disclosure involving such one or more phrases is essential to the subject technology, nor does it mean that such disclosure applies to all configurations of the subject technology. Disclosures involving such one or more phrases may apply to all configurations or one or more configurations. Disclosures involving such one or more phrases may provide one or more examples. Phrases such as aspect or some aspects may refer to one or more aspects and vice versa, and this applies similarly to the other aforementioned phrases.

[0217] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any implementation described herein as "exemplary" or as an "example" is not necessarily to be construed as preferred or advantageous over other implementations. Furthermore, to the extent that the terms "including," "having," and the like are used in the specification or claims, such terms are intended to be inclusive, in a manner similar to the way the term "comprising" is interpreted when used as a transitional word in a claim.

[0218] All structural and functional equivalents to the elements of the various aspects described throughout this disclosure that are known or later become known to those of ordinary skill in the art are expressly incorporated herein by reference and are intended to be covered by the claims. In addition, nothing disclosed herein is intended to be made available to the public regardless of whether the disclosure is explicitly stated in the claims. No claim element shall be interpreted under the provisions of 35 U.S.C. §112(f) unless the element is explicitly stated using the phrase “means for…” or, in the case of a method claim, the element is stated using the phrase “step for…”

[0219] The previous description is provided to enable those skilled in the art to practice the various aspects described herein. Various modifications of these aspects are apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein, but are intended to make the full scope consistent with the language claims, wherein reference to elements in singular values ​​is not intended to mean "only one", but refers to "one or more", unless specifically noted. Unless otherwise specifically stated, the term "some" refers to one or more. Male pronouns (e.g., his) include female and neutral (e.g., her and its), and vice versa. Titles and subtitles (if any) are used only for convenience and do not limit the subject disclosure.

[0220] Other aspects are set out in the following clauses:

[0221] Clause 1. A method comprising:

[0222] Sending a request to a service provider for a service provided by the service provider;

[0223] receiving, in response to the sending, from the service provider a request for a verified claim, the verified claim comprising a plurality of data fields identifying a user of a device and signed by a server, the verified claim being specific to the device; and

[0224] In response to the receiving, determining a confidence assessment of the verified claim based on a comparison between the plurality of data fields in the verified claim and corresponding data stored locally on the device, and

[0225] The confidence assessment and the verified statement are sent to the service provider.

[0226] Clause 2. The method according to clause 1, further comprising:

[0227] The verified assertion is received from the server, wherein the verified assertion is generated by the server based on verification of the plurality of data fields by an identity verification provider.

[0228] Clause 3. A method according to clause 1, wherein the locally stored data includes at least one of email content, message content, social network content, or third-party application content corresponding to the plurality of data fields in the verified statement.

[0229] Clause 4. The method according to clause 1, further comprising:

[0230] Prior to said determining, prompting said user to authorize access to said data stored locally on said device; and

[0231] In response to the prompt, user input is received authorizing access to the data stored locally on the device.

[0232] Clause 5. The method of clause 1, wherein the service provider is configured to authenticate the user for a service based on the verified claim and the confidence assessment.

[0233] Clause 6. The method of clause 5, wherein the service provider is further configured to authenticate the user to a service based on an evaluation of the plurality of data fields by at least one of an identity verification provider or an overall account evaluation service.

[0234] Clause 7. The method of clause 1, wherein the verified claim corresponds to a Merkle tree having nodes storing the plurality of data fields identifying the user.

[0235] Clause 8. The method of clause 7, wherein the Merkle tree is configured to selectively share the plurality of data fields based on the node.

[0236] Clause 9. An apparatus comprising:

[0237] at least one processor; and

[0238] a memory comprising instructions that, when executed by the at least one processor, cause the at least one processor to:

[0239] Sending a request to a service provider for a service provided by the service provider;

[0240] receiving, in response to the sending, from the service provider a request for a verified assertion, the verified assertion comprising a plurality of data fields identifying a user of a device and being a digital certificate signed by a server, the verified assertion being associated with the device;

[0241] as well as

[0242] In response to the receiving, determining a confidence assessment of the verified claim based on a comparison between the plurality of data fields in the verified claim and corresponding data stored locally on a device, and

[0243] The confidence assessment and the verified statement are sent to the service provider.

[0244] Clause 10. The apparatus of clause 9, wherein the instructions further cause the at least one processor to:

[0245] The verified assertion is received from the server, wherein the verified assertion is generated by the server based on verification of the plurality of data fields by an identity verification provider.

[0246] Clause 11. The device of clause 9, wherein the locally stored data comprises at least one of email content, message content, social network content, or third-party application content corresponding to the plurality of data fields in the verified statement.

[0247] Clause 12. The apparatus of clause 9, wherein the instructions further cause the at least one processor to:

[0248] Prior to said determining, prompting said user to authorize access to said data stored locally on said device; and

[0249] In response to the prompt, user input is received authorizing access to the data stored locally on the device.

[0250] Clause 13. The apparatus of Clause 9, wherein the service provider is configured to authenticate the user for a service based on the verified claim and the confidence assessment.

[0251] Clause 14. The apparatus of clause 13, wherein the service provider is further configured to authenticate the user to a service based on an evaluation of the plurality of data fields by at least one of an identity verification provider or an overall account evaluation service.

[0252] Clause 15. The apparatus of clause 9, wherein the verified statement corresponds to a Merkle tree having nodes storing the plurality of data fields identifying the user.

[0253] Clause 16. The apparatus of clause 15, wherein the Merkle tree is configured to selectively share the plurality of data fields based on the node.

[0254] Clause 17. A computer program product comprising code stored in a tangible computer readable storage medium, the code comprising:

[0255] code for sending a request to a service provider for a service provided by the service provider;

[0256] code for receiving, in response to the sending, from the service provider a request for a verified statement including a plurality of data fields identifying a user of a device and being a digital certificate signed by a server, the verified statement being associated with the device; and

[0257] for determining, in response to said receiving, a confidence assessment of said verified statement based on a comparison between said plurality of data fields in said verified statement and corresponding data stored locally on a device, and

[0258] The confidence assessment and the verified statement are sent to the service provider.

[0259] Clause 18. The computer program product of clause 17, wherein the code further comprises:

[0260] Code for receiving the verified claim from the server, wherein the verified claim is generated by the server based on verification of the plurality of data fields by an identity verification provider.

[0261] Clause 19. A computer program product according to Clause 17, wherein the locally stored data includes at least one of email content, message content, social network content, or third-party application content corresponding to the plurality of data fields in the verified statement.

[0262] Clause 20. The computer program product of clause 17, wherein the code further comprises:

[0263] code for prompting the user to authorize access to the data stored locally on the device prior to the determining; and

[0264] for receiving a user-entered code in response to the prompt authorizing access to the locally stored data.

[0265] Clause 21. A method comprising:

[0266] Sending a request to a service provider for a service provided by the service provider;

[0267] receiving, from the service provider, a request for a verified claim in response to sending the request for the service, the verified claim comprising first information identifying a user of a device, the verified claim being specific to the device;

[0268] sending the verified claim to the service provider in response to receiving the request for the verified claim; and

[0269] A request is received from the service provider for second information for identifying the user, the second information being different from the first information, the request for the second information being based on a determination that the first information is insufficient to identify the user.

[0270] Clause 22. The method of clause 21, wherein the determination that the first information is insufficient to identify the user corresponds to an indication that the device has been lost.

[0271] Clause 23. The method according to clause 21, further comprising:

[0272] prompting the user to input the second information; and

[0273] In response to the prompt, user input corresponding to the second information is received.

[0274] Clause 24. The method of Clause 21, wherein the service provider is configured to authenticate the user for a service based on the first information and the second information.

[0275] Clause 25. The method according to clause 21, further comprising:

[0276] The verified claim is received from a server, wherein the verified claim is generated by the server based on verification of the information by an identity verification provider.

[0277] Clause 26. The method of clause 25, wherein the server is configured to send an indication of the determination that the first information is insufficient to identify the user to the service provider.

[0278] Clause 27. The method of clause 21, wherein the verified statement corresponds to a Merkle tree having nodes storing a plurality of data fields corresponding to the first information.

[0279] Clause 28. The method of clause 27, wherein the Merkle tree is configured to selectively share the plurality of data fields based on the node.

[0280] Clause 29. An apparatus comprising:

[0281] at least one processor; and

[0282] a memory comprising instructions that, when executed by the at least one processor, cause the at least one processor to:

[0283] Sending a request to a service provider for a service provided by the service provider;

[0284] receiving, from the service provider, a request for a verified statement in response to sending the request for the service, the verified statement including first information identifying a user of a device and being a digital certificate signed by a server, the verified statement being associated with the device;

[0285] sending the verified claim to the service provider in response to receiving the request for the verified claim; and

[0286] A request is received from the service provider for second information for identifying the user, the second information being different from the first information, the request for the second information being based on a determination that the first information is insufficient to identify the user.

[0287] Clause 30. The device of clause 29, wherein the determination that the first information is insufficient to identify the user corresponds to an indication that the device has been lost.

[0288] Clause 31. The apparatus of clause 29, wherein the instructions further cause the at least one processor to:

[0289] prompting the user to input the second information; and

[0290] In response to the prompt, user input corresponding to the second information is received.

[0291] Clause 32. The apparatus of Clause 29, wherein the service provider is configured to authenticate the user for a service based on the first information and the second information.

[0292] Clause 33. The apparatus of clause 29, wherein the instructions further cause the at least one processor to:

[0293] The verified claim is received from the server, wherein the verified claim is generated by the server based on verification of the information by an identity verification provider.

[0294] Clause 34. The apparatus of clause 33, wherein the server is configured to send an indication of the determination that the first information is insufficient to identify the user to the service provider.

[0295] Clause 35. The apparatus of clause 29, wherein the verified statement corresponds to a Merkle tree having nodes storing a plurality of data fields corresponding to the first information.

[0296] Clause 36. The apparatus of clause 35, wherein the Merkle tree is configured to selectively share the plurality of data fields based on the node.

[0297] Clause 37. A computer program product comprising code stored in a tangible computer readable storage medium, the code comprising:

[0298] code for sending a request to a service provider for a service provided by the service provider;

[0299] code for receiving, in response to sending the request for the service, a request for a verified claim from the service provider, the verified claim including first information identifying a user of a device and being a digital certificate signed by a server, the verified claim being associated with the device;

[0300] code for sending the verified claim to the service provider in response to receiving the request for the verified claim; and

[0301] Code for receiving, from the service provider, a request for second information identifying the user, the second information being different than the first information, the request for the second information being based on a determination that the first information is insufficient to identify the user.

[0302] Clause 38. The computer program product of clause 37, wherein the code further comprises:

[0303] A code for prompting the user to input the second information; and

[0304] A code is provided for receiving, in response to the prompt, a user input corresponding to the second information.

[0305] Clause 39. The computer program product of Clause 37, wherein the service provider is configured to authenticate the user for a service based on the first information and the second information.

[0306] Clause 40. The computer program product of clause 37, wherein the code further comprises:

[0307] Code for receiving the verified claim from the server, wherein the verified claim is generated by the server based on verification of the information by an identity verification provider.

[0308] Clause 41. A method comprising:

[0309] receiving a response vector corresponding to a verified claim of a user of a device, the verified claim comprising a plurality of data fields for identifying the user, the verified claim being specific to the device, the response vector comprising, for each of the plurality of data fields, a confidence score indicating a likelihood that the field is accurate;

[0310] receiving a request for a service from the device;

[0311] determining, in response to receiving the request, that a service will be provided to the device based on the response vector and the verified claim; and

[0312] The service is provided to the device based on the determination.

[0313] Clause 42. The method of clause 41, wherein the determining comprises:

[0314] An overall confidence score is determined based on the confidence score for the response vector indicating a likelihood that the plurality of data fields are accurate.

[0315] Clause 43. The method of clause 42, wherein determining the overall confidence score comprises:

[0316] For each field of the plurality of data fields, assigning a respective weighted value to the confidence score of the field; and

[0317] The overall confidence score is determined based on the respective weighting values ​​applied to the confidence scores.

[0318] Clause 44. The method according to clause 41, further comprising:

[0319] receiving at least one of a first evaluation or a second evaluation of the verified statement,

[0320] wherein the first assessment is received from the device based on a comparison between the plurality of data fields in the verified statement and corresponding data stored locally on the device,

[0321] wherein the second assessment is received from an overall account assessment service based on the plurality of data fields in the verified statement, and

[0322] Wherein the determining is further based on the at least one first evaluation or the second evaluation.

[0323] Clause 45. The method of clause 41, wherein the verified assertion is generated by a server based on verification of the plurality of data fields by an identity verification provider.

[0324] Clause 46. The method according to clause 41, further comprising:

[0325] The verified claim is received from the device.

[0326] Clause 47. The method of clause 41, wherein the verified statement corresponds to a Merkle tree having nodes storing the plurality of data fields identifying the user.

[0327] Clause 48. The method of clause 47, wherein the Merkle tree is configured to selectively share the plurality of data fields based on the node.

[0328] Clause 49. A system comprising:

[0329] at least one processor; and

[0330] a memory comprising instructions that, when executed by the at least one processor, cause the at least one processor to:

[0331] receiving a response vector corresponding to a verified statement of a user of a device, the verified statement comprising a plurality of data fields identifying the user and being a digital certificate signed by a server, the verified statement being associated with the device, the response vector comprising, for each of the plurality of data fields, a confidence score indicating a likelihood that the field is accurate;

[0332] receiving a request for a service from the device;

[0333] determining, in response to receiving the request, that a service will be provided to the device based on the response vector and the verified claim; and

[0334] The service is provided to the device based on the determination.

[0335] Clause 50. The system of clause 49, wherein the determining comprises:

[0336] An overall confidence score is determined based on the confidence score for the response vector indicating a likelihood that the plurality of data fields are accurate.

[0337] Clause 51. The system of clause 50, wherein determining the overall confidence score comprises:

[0338] For each field of the plurality of data fields, assigning a respective weighted value to the confidence score of the field; and

[0339] The overall confidence score is determined based on the respective weighting values ​​applied to the confidence scores.

[0340] Clause 52. The system of clause 49, wherein the instructions further cause the at least one processor to:

[0341] receiving at least one of a first evaluation or a second evaluation of the verified statement,

[0342] wherein the first assessment is received from the device based on a comparison between the plurality of data fields in the verified statement and corresponding data stored locally on the device,

[0343] wherein the second assessment is received from an overall account assessment service based on the plurality of data fields in the verified statement, and

[0344] Wherein the determining is further based on the at least one first evaluation or the second evaluation.

[0345] Clause 53. The system of Clause 49, wherein the verified assertion is generated by the server based on verification of the plurality of data fields by an identity verification provider.

[0346] Clause 54. The system of clause 49, wherein the instructions further cause the at least one processor to:

[0347] The verified claim is received from the device.

[0348] Clause 55. The system of clause 49, wherein the verified statement corresponds to a Merkle tree having nodes storing the plurality of data fields identifying the user.

[0349] Clause 56. The system of clause 55, wherein the Merkle tree is configured to selectively share the plurality of data fields based on the node.

[0350] Clause 57. A computer program product comprising code stored in a tangible computer readable storage medium, the code comprising:

[0351] code for receiving a response vector corresponding to a verified claim of a user of a device, the verified claim comprising a plurality of data fields identifying the user and being a digital certificate signed by a server, the verified claim being associated with the device, the response vector comprising, for each of the plurality of data fields, a confidence score indicating a likelihood that the field is accurate;

[0352] code for receiving a request for a service from the device;

[0353] code for determining, in response to receiving the request, an overall confidence score based on the confidence score of the response vector indicating a likelihood that the plurality of data fields are accurate; and

[0354] Code for providing the service to the device based on the overall confidence score.

[0355] Clause 58. The computer program product of Clause 57, wherein the verified assertion is generated by the server based on verification of the plurality of data fields by an identity verification provider.

[0356] Clause 59. The computer program product of clause 57, wherein the code further comprises:

[0357] Code for receiving the verified claim from the device.

[0358] Clause 60. The computer program product of clause 57, wherein determining the overall confidence score comprises:

[0359] For each field of the plurality of data fields, assigning a respective weighted value to the confidence score of the field; and

[0360] The overall confidence score is determined based on the respective weighting values ​​applied to the confidence scores.

[0361] Clause 61. A method comprising:

[0362] The server receives a first request to revoke a verified claim, the verified claim comprising information identifying a user of a device, wherein the verified claim is specific to the device and stored on the device; and

[0363] In response to receiving the first request,

[0364] sending a second request to the device to revoke the verified statement on the device, and

[0365] The verified claim is added to a revocation list.

[0366] Clause 62. The method of clause 61, wherein the second request comprises a request to delete the verified statement on the device.

[0367] Clause 63. The method of clause 61, wherein the verified statement is specific to the device by at least one of a hardware reference key that indexes the device, a software reference key that indexes the device, a hardware device identifier, or a software device identifier.

[0368] Clause 64. The method of clause 63, wherein the hardware reference key is a public key of a public-private key pair, and the corresponding private key of the public key is securely stored on the device.

[0369] Clause 65. A method according to Clause 64, wherein the second request includes a request to delete the private key, and wherein the device is configured to delete the private key securely stored on the device in response to receiving the second request.

[0370] Clause 66. The method of clause 63, further comprising, before receiving the first request:

[0371] receiving, from the device, a request for the verified assertion, the request including the hardware reference key;

[0372] generating and signing the verified assertion based on verification of the information by an identity verification provider separate from the server; and

[0373] The verified statement is transmitted to the device.

[0374] Clause 67. The method of clause 63, wherein the hardware reference key is generated by the device in association with a hardware component of the device.

[0375] Clause 68. The method according to clause 61, further comprising:

[0376] receiving a request for a status of the verified claim from a service provider, wherein the service provider is configured to provide a service to the device based on the status of the verified claim; and

[0377] In response to receiving the request for the status,

[0378] determining that the verified statement is included on the revocation list,

[0379] An indication that the verified claim is revoked is transmitted to the service provider.

[0380] Clause 69. The method according to clause 61, further comprising:

[0381] The revocation list is provided to at least one service provider, wherein the at least one service provider is configured to provide services to the device based on the revocation list.

[0382] Clause 70. The method of Clause 61, wherein the first request is received from a service based on an indication that the device has been lost.

[0383] Clause 71. The method of clause 61, wherein the first request is received from the device based on a first user input received at the device to revoke the verified claim.

[0384] Clause 72. The method of clause 61, wherein the device is further configured to:

[0385] receiving a second user input for displaying the information for identifying the user; and

[0386] In response to receiving the second user input, the information identifying the user is displayed.

[0387] Clause 73. The method of clause 61, wherein the device is further configured to:

[0388] receiving a second user input for partially revoking the verified statement, the second user input indicating a portion of the information to be revoked; and

[0389] In response to receiving the second user input, the portion of the information is removed from the verified claim.

[0390] Clause 74. A system comprising:

[0391] at least one processor; and

[0392] a memory comprising instructions that, when executed by the at least one processor, cause the at least one processor to:

[0393] receiving a first request to revoke a verified statement, the verified statement including information identifying a user of a device,

[0394] wherein the verified statement includes a hardware reference key of the device, and

[0395] wherein the hardware reference key is a public key in a public-private key pair, and a corresponding private key of the public key is securely stored on the device; and

[0396] In response to receiving the request,

[0397] sending a second request to the device to revoke the verified statement on the device, and

[0398] The verified claim is added to a revocation list.

[0399] Clause 75. The system of clause 74, wherein the second request comprises a request to delete the verified statement on the device.

[0400] Clause 76. A system according to Clause 74, wherein the second request includes a request to delete the private key, and wherein the device is configured to delete the private key securely stored on the device in response to receiving the second request.

[0401] Clause 77. The system of clause 74, wherein the instructions further cause the at least one processor, prior to receiving the first request:

[0402] receiving, from the device, a request for the verified assertion, the request including the hardware reference key;

[0403] generating and signing the verified claim based on verification of the information by an identity verification provider separate from the system; and

[0404] The verified statement is transmitted to the device.

[0405] Clause 78. The system of Clause 74, wherein the hardware reference key is generated by the device in association with a hardware component of the device.

[0406] Clause 79. The system of clause 74, wherein the instructions further cause the at least one processor to:

[0407] receiving a request for a status of the verified claim from a service provider, wherein the service provider is configured to provide a service to the device based on the status of the verified claim; and

[0408] In response to receiving the request for the status,

[0409] determining that the verified statement is included on the revocation list,

[0410] An indication that the verified claim is revoked is transmitted to the service provider.

[0411] Clause 80. A computer program product comprising code stored in a tangible computer readable storage medium, the code comprising:

[0412] code for receiving a first request to revoke a verified statement, the verified statement comprising information identifying a user of a device, wherein the verified statement comprises a hardware reference key of the device and is stored on the device, and the hardware reference key has been generated by the device in association with a hardware component of the device; and

[0413] for sending, in response to receiving the request, to the device a second request to revoke the verified statement on the device, and

[0414] Code that adds the verified claim to a revocation list.

Claims

1. A method comprising: Sending, by the device, to a service provider, a request for a service provided by the service provider; receiving, by the device from the service provider, a request for a verified statement stored locally on the device in response to sending the request for the service, the verified statement comprising a plurality of data fields to identify a user of the device, the verified statement being signed by a server, the verified statement being specific to the device, and the verified statement being stored locally on the device prior to sending the request for the service; In response to the receiving, determining, at the device, a confidence assessment of a verified statement stored locally on the device and specific to the device based on a comparison between the plurality of data fields in the verified statement stored locally on the device and specific to the device and corresponding data stored locally on the device, the data stored locally on the device being based at least in part on use of the device by the user prior to sending the request for the service, and sending, by the device, the confidence assessment and the verified statement to the service provider; as well as The service provided by the service provider is accessed by the device based at least in part on the sending of the confidence assessment.

2. The method according to claim 1, further comprising: The verified assertion is received from the server, wherein the verified assertion is generated by the server based on verification of the plurality of data fields by an identity verification provider.

3. The method according to claim 2, further comprising: receiving, in response to sending, by the device, the confidence assessment and the verified claim to the service provider, a request from the service provider for additional information identifying the user, the additional information being different from the confidence assessment and the verified claim, the request for additional information being based on a determination by the service provider that the confidence assessment and the verified claim are insufficient to identify the user; as well as The additional information is sent by the device to the service provider before the device accesses the service provided by the service provider.

4. The method of claim 1, wherein the locally stored data comprises at least one of email content, message content, social networking content, or third-party application content corresponding to the plurality of data fields in the verified statement.

5. The method according to claim 1, further comprising: Prior to the determining, prompting the user to authorize access to data stored locally on the device; as well as In response to the prompt, user input is received authorizing access to data stored locally on the device. 6 . The method of claim 1 , wherein the service provider is configured to authenticate the user for a service based on the verified claim and the confidence assessment.

7. The method of claim 5, wherein the service provider is further configured to authenticate the user to a service based on an evaluation of the plurality of data fields by at least one of an identity verification provider or an overall account evaluation service.

8. The method of claim 1, wherein the verified claim corresponds to a Merkle tree having a node storing the plurality of data fields to identify the user.

9. The method of claim 8, wherein the Merkle tree is configured to selectively share the plurality of data fields based on the node.

10. A method comprising: receiving, by the device, the verified statement from the server; after receiving the verified statement, sending, by the device, to a service provider server a request for a service provided by the service provider server, the service provider server being independent and separate from the server; receiving, in response to sending a request for the service, from the service provider server a request for the verified claim, the verified claim comprising first information to identify a user of the device, the verified claim being specific to the device; in response to receiving the request for the verified claim, sending the verified claim to the service provider server; as well as A request is received from the service provider server for second information to identify the user, the second information being different from the first information, the request for the second information being based on a determination by the server that the first information is insufficient to identify the user. The method of claim 10 , wherein determining that the first information is insufficient to identify the user corresponds to an indication that the device has been lost.

12. The method according to claim 10, further comprising: Prompting the user to provide second information; as well as In response to the prompt, user input corresponding to the second information is received.

13. The method of claim 12, wherein the service provider server is configured to authenticate the user for the service based on the first information and the second information.

14. The method of claim 13, wherein the verified assertion is generated by the server based on verification of the information by an identity verification provider.

15. The method of claim 14, wherein the server is configured to send an indication to the service provider server of a determination that the first information is insufficient to identify the user.

16. The method of claim 10, wherein the verified statement corresponds to a Merkle tree having nodes storing a plurality of data fields corresponding to the first information.

17. The method of claim 16, wherein the Merkle tree is configured to selectively share the plurality of data fields based on the node.

18. A method comprising: receiving, from a device, a response vector corresponding to a verified assertion of a user of the device, the verified assertion comprising a plurality of user information fields to identify the user, the verified assertion being specific to the device, the response vector comprising, for each respective one of the plurality of user information fields, a respective confidence score indicating a likelihood that the respective user information field is currently accurate based at least in part on a comparison on the device between the respective user information field and a corresponding respective user identification data item stored locally on the device, the user identification data item stored locally on the device having been derived from usage of different applications on the device by the user; receiving a request for a service from the device; In response to receiving the request, determining to provide a service to the device based on the response vector and the verified claim; as well as Based on the determination, the service is provided to the device.

19. The method of claim 18, wherein the determining comprises: Based on the confidence scores for the response vectors, an overall confidence score is determined, the overall confidence score indicating a likelihood that the plurality of user information fields are accurate.

20. The method of claim 19, wherein determining the overall confidence score comprises: For each field of the plurality of data fields, assigning a respective weighted value to the confidence score of the field; as well as The overall confidence score is determined based on respective weighting values ​​applied to the confidence scores.

21. The method of claim 18, further comprising: receiving a first evaluation and a second evaluation of the verified statement, wherein the first assessment is received from the device based on a comparison between the plurality of user information fields in the verified statement and corresponding user identification data items stored locally on the device, wherein the second assessment is received from an overall account assessment service based on the plurality of user information fields in the verified statement, and Wherein the determining is further based on the first evaluation and the second evaluation.

22. The method of claim 18, wherein the verified assertion is generated by a server based on verification of the plurality of user information fields by an identity verification provider, and the verified assertion is signed by an entity other than the identity verification provider and the service provider.

23. The method of claim 18, further comprising: The verified claim is received from the device.

24. The method of claim 18, wherein the verified statement corresponds to a Merkle tree having nodes storing the plurality of user information fields to identify the user, each respective node storing a respective user information field.

25. The method of claim 24, wherein the Merkle tree is configured to selectively share the plurality of user information fields based on the node.

26. A method comprising: receiving, by a server, a first request to revoke a verified claim, the verified claim including information identifying a user of a device, wherein the verified claim is specific to the device and stored on the device, and the information identifying the user included in the verified claim is verified at least in part by an identity verification provider separate from the server; as well as In response to receiving the first request, sending to the device a second request to revoke the verified statement on the device, as well as The verified claim is added to a revocation list.

27. The method of claim 26, wherein the second request further comprises a request to delete the verified statement on the device.

28. The method of claim 26, wherein the verified statement is bound to the device by at least one of a hardware-defined reference key that indexes the device, a software-defined reference key that indexes the device, a hardware-defined device identifier, or a software-defined device identifier.

29. The method of claim 28, wherein the verified statement is bound to the device via the hardware-defined reference key, the hardware-defined reference key being a public key in a public-private key pair, the corresponding private key in the public-private key pair being securely stored on the device.

30. The method of claim 29, wherein the second request further comprises a request to delete the private key, and wherein the method further comprises deleting, by the device, the private key securely stored on the device in response to receiving the second request.

31. The method of claim 28, further comprising, before receiving the first request: receiving, from the device, a request for the verified assertion, the request for the verified assertion comprising the hardware-defined reference key; generating and signing the verified assertion based on verification of the information by the identity verification provider separate from the server; and The verified claim is transmitted to the device, wherein the verified claim is bound to the device via the hardware-defined reference key.

32. The method of claim 28, wherein the hardware-defined reference key is generated by the device in association with a hardware component of the device.

33. The method of claim 26, further comprising: receiving a request for a status of the verified claim from a service provider, wherein the service provider is configured to provide a service to the device based on the status of the verified claim; as well as In response to receiving the request for the status, determining that the verified statement is included on the revocation list, An indication that the verified claim is revoked is transmitted to the service provider.

34. The method of claim 26, further comprising: The revocation list is provided to at least one service provider, wherein the at least one service provider is configured to provide services to the device based on the revocation list.

35. The method of claim 26, wherein the first request is received from a service based on an indication that the device has been lost.

36. The method of claim 26, wherein the first request is received from the device based on a first user input received at the device to revoke the verified claim.

37. The method of claim 26, further comprising: receiving, by the device, a second user input for displaying the information for identifying the user; as well as In response to receiving the second user input, the information is used by the device to identify the user.

38. The method of claim 26, further comprising: receiving, by the device, a second user input for partially revoking the verified statement, the second user input indicating a portion of the information to be revoked; as well as In response to receiving the second user input, removing, by the device, the portion of the information from the verified claim.

39. An apparatus comprising: Memory; as well as At least one processor configured to execute the method according to any one of claims 1-38.

40. A non-transitory machine-readable medium comprising instructions that, when executed by one or more processors, cause the one or more processors to perform operations including the method of any one of claims 1-38.

Images