WO2025111216A1

WO2025111216A1 - Electronic device, identity broker, service provider, client, secure electronic interaction system, and identity brokering

Info

Publication number: WO2025111216A1
Application number: PCT/US2024/056337
Authority: WO
Inventors: Stefan Harsan FARR
Original assignee: Identity Plus Inc
Current assignee: Identity Plus Inc
Priority date: 2023-11-23
Filing date: 2024-11-18
Publication date: 2025-05-30
Anticipated expiration: 2026-05-23

Abstract

A secure electronic interaction system comprising an identity broker, a service provider, and a client, wherein a connection is established between the client and the service provider through: the client sending a certificate to the service provider; the service provider identifying an identity broker; the service provider sending certificate information to the identity broker; the identity broker using the certificate information to access information of a digital identity that is linked to the client; the identity broker sending, to the service provider, information about the digital identity; and the service provider using the information to determine whether or not to allow a connection with the client.

Description

ELECTRONIC DEVICE, IDENTITY BROKER , SERVICE PROVIDER, CLIENT , SECURE ELEC TRONIC INTERACTION S YSTEM, AND IDENTITY BROKERING METHOD

INVENTOR :

Stefan Harsan Farr

RELATED APPLICATIONS

[0001] This application claims the benefit of U. S . Provisional Application No. 63/602,410, filed November 23 , 2023 , incorporated in its entirety herein by reference.

FIELD OF THE INVENTION

[0002] This disclosure relates to a system enabling secure interactions over a network, such as the Internet, and more particularly, to a secure electronic interaction system, an electronic device used in such a system, an identity broker used in such a system, a service provider that provides a service in such a system, a client in such a system, and an identity brokering method in such a system .

BACKGROUND OF THE INVENTION

[0003] Existing systems for attempting secure communications between a client (typically a web browser or an application that is running on an electronic device, such as a computer, a smart phone, or an loT (Internet Of Things) device) that is connected to a network, such as the Internet, and a service provider (typically an application that is running on an electronic device such as a server) that is al so connected to the network is carried out through first creating a connection between the devices, followed by the service provider prompting inputting of client credentials (such as a username and password) to verify the identity of the client to the service provider. Such a system, however, has drawbacks in that the information exchange requiring inputting of client credentials is cumbersome and timeconsuming for the user. Furthermore, this system has a drawback in that the security offered thereby is limited, in that credentials are often leaked or stolen, enabling bad actors illegal access to services by the service provider, whi ch often pl aces cli ent data at ri sk and consumes resources from the service provider. Moreover, because users have a limited ability to remember multiple passwords, a password-based system incentivizes users to reuse passwords across multiple service providers, or to record passwords in nonsecured electronic files, thereby j eopardizing data security.

[0004] To combat thi s, many service providers enhance the security of transactions through requiring what is known as "two-factor authentication," requiring, in addition to a username and password, for example, a response to a message sent to a separate application or device. Although two-factor authentication indeed provides a greater level of security, it is typically substantially more inconvenient for the user, interfering with the user experience, while still not providing an adequate level of security. Moreover, because these authentication methods require the service provider to maintain a two-way connection with the client during the authentication process, the service provider must open itself up to increased vulnerability to attacks as long as the communication channel is maintained. Furthermore, because users typically interact with hundreds or thousands of service providers, having to provide password authentication or two-factor authentication for each service provider is impractical in terms of the burden on the user, causing many service providers (such as typical websites) to forgo authentication altogether, leaving many service providers open to attack. Furthermore, because typical users own multiple electronic devices (such as computers, cell phones, tablets, smart televisions, and the like) that each host applications that access services from service providers, having to perform authentication procedures on each device individually i s timeconsuming and burdensome.

[0005] What is needed, therefore, are techniques for reducing the burden on the user by eliminating the need for passwords while enhancing the security of electronic communications, enabling authentication credentials to be shared over a plurality of devices. BRIEF SUMMARY OF THE INVENTION

[0006] One embodiment provides an electronic device, comprising: a digital identity manager configured to issue, or to request from an external certificate authority, a certificate linked to a digital identity; and a connection interface configured to connect to a digital construct through handshaking authentication using the certificate without requiring an input from a user or the provision of secret information when establi shing the connection, wherein: the certificate includes information identifying an identity broker that has information for linking the certificate to the digital identity.

[0007] Another embodiment provides such an electronic device, wherein: the external certificate authority is the identity broker

[0008] A further embodiment provides such an electronic device, further comprising: a user authenticating subsystem for authenticating a user through a biometric input, input of secret information, and/or possession of a prescribed physical obj ect.

[0009] Yet another embodiment provides an identity broker, comprising: a digital identity information receiver configured to receive, from a service provider, information associated with a client, together with information of a certificate associated with the client, sent by the service provider; a brokerside digital identity registrar configured to receive, from a client or a third- party certificate issuing authority, information of a certificate of a client that i s to be regi stered; a digital identity repository configured to store information of the certificate, inputted or processed information associated with a client identified by a certificate, and information relating to the digital identity linked to that certificate; a digital identity information processor configured to process stored information associated with a digital identity that is linked to a client identified by information of a certificate; and a digital identity information sender configured to send, to a service provider, at least a subset of the stored information associated with a digital identity that i s linked to a received certificate. [0010] A yet further embodiment provides such an i dentity broker, wherein : the stored information associated with a digital identity includes information for controlling a relationship between the client and the service provider.

[0011] Still another embodiment provides such an identity, further comprising: an account transferring subsystem configured to: receive a digital identity transfer request including information indicating a first client, information indicating a second client, and information indicating an account; and modify, so as to link to the second client instead, information that links the account to the first client.

[0012] A still further embodiment provides such an identity broker, further comprising : an account bequeathing subsystem configured to: receive an account bequeathing advance directive including a first digital identity and a second digital identity; and modify information that links an account, and certificates linked thereto, to the first digital identity, doing so for all of the accounts that are linked to the first digital identity, so as to be linked instead to the second digital identity, in accordance with the digital construct bequeathing advance directive.

[0013] Even another embodiment provides such an identity broker, wherein: the account bequeathing sub system comprises an inactivity tracker to track a period of inactivity relating to a digital construct linked to the first digital identity; and the account bequeathing subsystem is further configured to modify the information that links the accounts when a predefined period of inactivity for all digital constructs that are linked to the first digital identity has elapsed.

[0014] An even further embodiment provides such an identity broker, wherein: the digital construct bequeathing subsystem is further configured to modify the information that links the accounts when a cryptographic certificate associated with the first digital identity has expired, or when a token is used.

[0015] A still even another embodiment provides such an identity broker, wherein: the digital identity information processor is configured to aggregate informati on from a plural ity of digital constructs associated with a given digital identity to produce reputation data of the digital identity; and the digital identity information sender is configured al so to send, to a service provider, the reputation data of the digital identity.

[0016] A still even further embodiment provides such an identity broker, further compri sing: a civil behavior enforcing subsystem configured to cause the reputation data of the digital identity, sent to the service provider, to indicate that a client is linked to a digital identity associated with malicious behavior or civil behavior.

[0017] Still yet another embodiment provides a service provider, comprising : a connection request receiver configured to receive, from a client, a certificate; a query sender configured to send, to an identity broker, a query based on a received certificate; a query response receiver configured to receive, from the identity broker, a response to the sent query; a policy compliance evaluator configured to evaluate whether or not to allow a connection, based on the received query response; and a connection interface configured to establi sh a connection to the client through handshaking authentication using the certificate, based on the evaluation response by the policy compliance evaluator.

[0018] A still yet further embodiment provides such a service provider, further comprising: a service processor, configured to exchange information with the client to perform a service for a client; and a service selector configured to select, based on account information included in the received query response, services to be provided by the service provider through the established connection.

[0019] Even yet another embodiment provides such a service provider, further comprising: a certificate evaluator configured to evaluate the integrity, expiry, and/or validity of the certificate.

[0020] An even yet further embodiment provides such a service provider, further comprising: a registering subsystem configured to perform the following in response to the received query response and in response to informati on from a second digital construct that i s unregi stered in an identity broker: receive a token from a first digital construct; issue a certificate to the unregi stered second digital construct; and send, to the identity broker, information of the i ssued certificate.

[0021] Still even yet another embodiment provides such a service provider, further compri sing: a Shamir recovery subsystem configured to: receive, from a client, information indicating a plurality of designated restoration deputy digital constructs or deputy digital identities, a critical count, and an identifier of the client, and to store the information, the critical count, and the identifier of the client; receive a restoration request from a deputy digital construct or a digital construct associated with a deputy digital identity; count a number of requests from designated restoration deputy digital constructs or digital identities through associated digital constructs; compare the number of requests to the critical count; and issue a certificate to the client in response to the number of requests being at least equal to the critical count.

[0022] A still even yet further embodiment provides such a service provider, further comprising: a behavior detecting subsystem configured to detect behavior of a client in respect to the service provider and to send, to an identity broker, a client behavior report together with certifi cate information of the client that has engaged in the behavior.

[0023] Yet still even another embodiment provides such a service provider, further compri sing: a personal information storing subsystem for storing personal information collected in the course of providing services, in association with a client linked to a certificate; a personal information query receiving subsystem for receiving a personal information query with a query condition regarding personal information associated with a query subj ect client, together with information of a certificate for identifying the query subj ect client; a personal information verifying subsystem for comparing, with a received query condition, the stored personal information associated with the query subj ect client, to produce an anonymized verification response rel ated thereto; and a personal informati on verifi cation result sending subsystem for returning the anonymized verification response to the source of the personal information query.

[0024] A yet still even further embodiment provides a client, comprising: a certificate storage for storing a certificate issued or requested by a digital identity manager; wherein the certificate stored in the certificate storage i s associated with the same digital identity as a digital identity associated with a certificate stored in a certificate storage of a client in another electronic device owned by the identical owner.

[0025] A yet still even further still embodiment provides such a client, further comprising: a behavior detecting subsystem configured to detect behavior of a servi ce provider in respect to the client; and a behavior reporting subsystem configured to send, to an identity broker, a service provider behavior report, together with certificate information of the service provider that engaged in the behavior.

[0026] Another further embodiment provides a secure electronic interaction system comprising: an identity broker; a service provider; and a client comprising a certificate that is linked to a digital identity, wherein: when the client is to request a service from the service provider, a connection is establi shed between the client and the service provider through: the client sending a certificate to the service provider; the service provider receiving the certificate and extracting an identity of an identity broker therefrom; the service provider sending information of the certificate to the identity broker; the identity broker using the information of the certificate to access information about a digital identity that i s linked to the client through the certificate; the identity broker sending, to the service provider, information regarding the digital identity that is linked to the client; the service provider using the received information to determine whether or not to allow a connection with the client; and the service provider establishing a connection with the client upon a positive determination. [0027] Another yet further embodiment provides a method for establi shing a secure connection between a client and a digital construct, comprising: issuing or requesting, by a digital identity manager, a certificate linked to a digital identity from an external certificate authority; connecting, by a connection interface, the client to the digital construct through handshaking authentication using the certificate, without requiring user input or secret information at the time of connecting wherein: the certificate includes information identifying an identity broker that has information linking the certificate to the digital identity.

[0028] Another embodiment provides such a method for establishing a secure connection between a client and a digital construct, wherein the external certificate authority is the identity broker.

[0029] A further embodiment provides such a method for establishing a secure connection between a client and a digital construct, further comprising : authenticating a user through a biometric input, input of secret information, and/or possession of a prescribed physical obj ect.

[0030] Yet another embodiment provides an identity brokering method in an identity broker, comprising: receiving, from a service provider, behavior information associated with a client, together with information of a certificate sent by the service provider to identify that client; storing inputted or processed behavior information associated with a client identified by the information of the certificate, and information relating to the digital identity linked to that certificate; processing stored information associated with a digital identity that is linked to a client identified by a certificate; and sending, to a service provider, at least a subset of the stored information associated with a digital identity that is linked to a received certificate.

[0031] A yet further embodiment provides such an identity brokering method, further comprising: receiving, from a client or a third-party certificate issuing authority, certificate information of a client that is to be regi stered. [0032] Still another embodiment provides such an identity brokering method, wherein: the stored information associated with a digital identity includes information for controlling a relationship between the client and the service provider.

[0033] A still further embodiment provides such an identity brokering method, further compri sing: receiving a digital identity transfer request including information indicating a first client, a second client, and an account; and modifying the information linking the account to the first client so that it links to the second client.

[0034] Even another embodiment provides such an identity brokering method, further comprising: receiving an account bequeathing advance directive including a first digital identity and a second digital identity; and modifying information linking an account, and certificates linked thereto, to the first digital identity, doing so for all of the accounts that are linked to the first digital identity, so as to be linked instead to the second digital identity, in accordance with the digital construct bequeathing advance directive.

[0035] An even further embodiment provides such an identity brokering method, further comprising: tracking a period of inactivity related to a digital construct linked to the first digital identity; and modifying the information linking the accounts when a predefined period of inactivity for all digital constructs linked to the first digital identity has elapsed.

[0036] A still even another embodiment provides such an identity brokering method, further comprising: modifying the information linking the accounts when a cryptographic certificate associated with the first digital identity has expired, or when a token is used.

[0037] A still even further embodiment provides such an identity brokering method, further comprising: aggregating information from multiple digital constructs associated with a digital identity to produce reputation data; and sending the reputation data to a service provider. [0038] Still yet another embodiment provi des such an i dentity brokering method, further comprising: causing the reputation data to indicate to the service provider whether a client is linked to a digital identity associated with malicious or civil behavior.

[0039] A still even yet further embodiment provides a method for establishing a connection by a service provider, comprising: receiving a certificate from a client; sending a query to an identity broker based on the certificate; receiving a response to the query from the identity broker; evaluating, based on the response, compliance with a policy; and establishing a connection with the client using the certificate if the evaluation is positive. [0040] Yet still even another embodiment provides such a method for establishing a connection by a service provider, further comprising: selecting services to be provided based on account information in the query response; and exchanging information with the client to perform a service .

[0041] A yet still even further embodiment provides such a method for establishing a connection by a service provider, further comprising: evaluating the integrity, expiry, and/or validity of the certificate.

[0042] A yet still even further still embodiment provides such a method for establishing a connection by a service provider, further comprising, in response to the query response and information from an unregistered second digital construct, receiving a token from a first digital construct; issuing a certificate to the unregistered second digital construct; and sending information of the issued certificate to the identity broker.

[0043] Another further embodiment provides such a method for establishing a connection by a service provider, further comprising: receiving, from a client, information indicating designated restoration deputies, a critical count, and a client identifier; receiving a restoration request from a deputy digital construct or associated digital identity; counting restoration requests from designated deputies; comparing the number of restoration requests to the critical count; and issuing a certificate to the client if the number of restoration requests i s equal to the critical count. [0044] Another yet further embodiment provides such a method for establishing a connection by a service provider, further comprising: detecting client behavior with respect to the service provider; and sending a client behavior report and certificate information of the client to an identity broker.

[0045] Still another further embodiment provides such a method for establishing a connection by a service provider, further compri sing: storing personal information collected during service provision, linked to a client certificate; receiving a query with a condition regarding personal information associated with the client, along with certificate information; verifying the stored personal information against the query condition to produce an anonymized response; and sending the anonymized response to the query source.

[0046] Another still further embodiment provides a method for establishing secure communications in an electronic device, comprising: storing a certificate issued or requested by a digital identity manager, wherein: the stored certificate is associated with the same digital identity as a certifi cate stored in another device owned by the identical owner.

[0047] Even another further embodiment provides such a method for establi shing secure communications in a client compri sing: detecting behavior of a service provider in respect to the client; and sending a service provider behavior report, along with the service provider’ s certificate information, to an identity broker.

[0048] Another even further embodiment provides a method for secure electronic interaction involving a client, service provider, and identity broker, comprising: the client sending a certificate to the service provider; the service provider receiving the certificate and extracting an identity of an identity broke; the service provider sending certificate information to the identity broker; the identity broker accessing information about a digital identity linked to the client through the certificate; the identity broker sending information about the digital identity to the service provider; the service provider determining whether to allow a connecti on based on the received information; and the service provider establishing a connection with the client upon a positive determination.

[0049] The features and advantages described herein are not all-inclusive and, in particular, many additional features and advantages will be apparent to one of ordinary skill in the art in view of the drawings, specification, and claims. Moreover, it should be noted that the language used in the specification has been selected principally for readability and instructional purposes, and not to limit the scope of the inventive subj ect matter.

BRIEF DESCRIPTION OF THE DRAWINGS

[0050] FIG. 1 is a schematic system diagram showing components of a secure electronic interaction system, according to an embodiment.

[0051] FIG. 2 is a schematic diagram of an electronic device, according to an embodiment.

[0052] FIG. 3 is a schematic diagram of a certificate, according to an embodiment.

[0053] FIG. 4 i s a schematic diagram of an identity broker, and information exchanged with service providers and clients, according to an embodiment.

[0054] FIG. 5 is a schematic diagram of a service provider, according to anr embodiment.

[0055] FIG. 6 is a schematic diagram of a service provider, according to another embodiment.

[0056] FIG. 7 i s a schematic diagram of a service provider, according to yet another embodiment.

[0057] FIG. 8 is a schematic diagram of a service provider, according to even another embodiment.

[0058] FIG. 9 is a schematic diagram of a client, according to an embodiment.

[0059] FIG. 10 is a flow chart of a process that is performed when a client requests a connection to a service provider, according to an embodiment. [0060] FIG 11 i s a fl ow chart of a process that i s performed for regi stering a device in the identity broker, using a certificate that is issued by a digital identity manager of an electronic device, according to an embodiment.

[0061] FIG. 12 i s a flow chart of a process that i s performed for registering a device in an identity broker using a certificate that is issued by the identity broker, according to an embodiment.

[0062] FIG. 13 is a flow chart of a process that i s performed to transfer an account at a service provider to a different client, according to an embodiment.

[0063] FIG. 14 is a flow chart of a process that is performed to recover a digital identity that has been lost, according to an embodiment.

[0064] FIG 15 is a flow chart of a process that is performed to perform Shamir recovery of a digital identity that has been lost, according to an embodiment.

[0065] FIG. 16 i s a flow chart of a bequeathing process that is performed to transfer digital property from a digital identity to heirs in the case of death, incapacitation, or unavailability, according to an embodiment.

[0066] FIG. 17 is a flowchart of a process by which clients and service providers provide feedback into reputation information, according to an embodiment.

[0067] FIG. 18 is a flowchart of a process for verifying personal information while maintaining anonymity, according to an embodiment.

DETAILED DESCRIPTION OF THE INVENTION

[0068] Embodiments in the present disclosure will be explained below in reference to the drawings. Note that analogous or identical parts in different drawings are assigned analogous or identical reference numbers, and redundant explanations thereof may be omitted. Note also that the drawings, by nature, are schematic, and some components thereof may be omitted for ease in illustration and understanding. Note also that in the embodiments set forth below, numbers following hyphens indicate suffixes indicating structural elements that play anal ogous roles in the appli cable system, but do not imply that the structural elements are identical.

[0069] A secure electronic interaction system 90 according to an embodiment will be explained first in reference to FIG. 1. As depicted in

FIG. 1, a secure electronic interaction system 90 according to an embodiment comprises one or more clients 200, one or more service providers 300, and at least one identity broker 400. As will be explained below, the client 200, the service provider 300, and the identity broker 400 are all examples of digital constructs 25 that exist resident on an electronic device 100. In the present disclosure, a " digital construct" 25 refers to an actor that interacts with different actors over a network, such as the Internet. A digital construct 25 is a functional unit that acts to engage in communications by sending and receiving signals, and may perform operations in response to received signals. In embodiments a digital construct 25 may be structured from a combination of hardware, firmware, and software to achieve inputting, processing, and outputting of signals.

[0070] Each digital construct 25 i s resident on an electronic device 100, where "resident on" an electronic device 100 refers to comprising a portion of the hardware of the electronic device 100, and/or operating as software, firmware, and/or as part of an operating system on the electronic device 100. In embodiments, multiple digital constructs may be resident on a single electronic device 100. Conversely, in other embodiments a digital construct 25 may be structured spanning multiple discrete devices that together form a functional unit that may be referred to as structuring an electronic device 100

[0071] As will be described in greater detail below, in embodiments a “client” 200 refers to a digital construct 25 that is configured to request a service provider 300 to establish a connection therewith over a network (not numbered). Conversely, a “service provider” 300, in embodiments having functions and structures such as set forth in FIGS. 5 through 8, refers to a digital construct that is configured to receive, over a network, a communicati on request from a cli ent 200, and may select, based on a security policy, whether or not to respond to the request by establishing a connection with the client 200. An “identity broker” 400, in embodiments having functions and structures such as set forth in FIG. 4, refers to a digital construct that is configured to communicate with a service provider 300, to receive, from the service provider 300, a query for reputation information 40 and/or account information 50 regarding a client 200, and to respond by sending, to the service provider 300, information pertaining to the applicable client 200.

[0072] As depicted in FIG. 1 , in embodiments the secure electronic interaction system 90 may comprise a plurality of clients 200-1, 200-2, 200- 3, , 200-n, owned or controlled by one or more users. In embodiments, the clients need not necessarily be on similar electronic devices 100, where, for example, the client 200-1 may be a cellular telephone, while the client 200- 2 may be a smart refrigerator. Furthermore, multiple clients 200 may be provided in a single electronic device 100, such as, for example, a client 200-3 being a web browser on a cellular telephone and a client 200-4 being an email application on the same cellular telephone.

[0073] In embodiments, the secure electronic interaction system 90 may comprise a plurality of service providers 300-1, 300-2, 300-3, ... 300-m with functions and structures such as set forth below in reference to FIG. 5 through FIG. 8. In embodiments, the service providers 300-1 , 300-2, 300- 3, ... 300-m may each be an application running on a respective electroni c device 100, or, in other embodiments, multiple service providers 300 may be provided j ointly in a single electronic device 100, or a service provider 300 may be structured spanning a plurality of electronic devices 100. As depicted in FIG 1, in embodiments, the clients 200 may request connections, over a network, from each of the service providers 300. Note that, in FIG. 1, the lines showing connections between individual clients 200 and the individual service providers 300 indicate connections that are transitory, to be establi shed when needed. [0074] As depicted in FIG. 1 , in embodi ments the secure el ectroni c interaction system 90 further comprises an identity broker 400 with functions and structures such as described below in reference to FIG. 4. In embodiments, the secure electronic interaction system 90 may comprise multiple identity brokers 400. While in the illustrated embodiment all service providers 300 are able to connect to the same identity broker 400, there is no limitation thereto, but rather identity brokers 400 may be provided associated with respective individual service providers 300. Details of the communications between these digital constructs 25 (the clients 200, the service providers 300, and the identity brokers 400) will be described below. Note that the terms "client" and " service provider" are used for convenience in the explanations below, and do not limit the functions provided by the specific digital constructs 25 that are referenced thereby. For example, while a web browser application on a cell phone may function as a client 200 when it contacts a website (a service provider 300) to request information, that same web browser application may also act as a service provider 300 when open to peer-to-peer connections with other web browsers. Similarly, although the identity broker 400 i s illustrated for convenience as distinct from the illustrated set of service providers 300-1 through 300-m, strictly speaking the identity broker 400 is a service provider 300, albeit distinguished by the specialty services that are provided thereby, as described below.

[0075] Each digital construct 25 (each client 200, each service provider 300, and each identity broker 400) is resident on one or more electronic devices 100, which may be, for example, a cell phone, a computer, an loT device, a server, or any other electronic device that is configured so as to enable operations over a network. An embodiment of an electronic device 100 is depicted in FIG. 2. Note that for ease in illustration and understanding, the illustration in FIG. 2 omits well-known components of electronic devices (such as keyboards and other data inputting devices, display devices, memory devices, processing devices, and the like), but rather focuses on components that are more central to the present di scl osure. In FIG. 2, the electronic device 100 may be, for example, a cell phone. In the illustrated embodiment, a plurality of digital constructs 25-l a, 25-lb, 25-lc, 25-2, and 25-3 are resident on the electronic device 100. The digital constructs 25 resident on the electronic device 100 are not limited thereto, but rather an arbitrary number of digital constructs 25 may be present on the electronic device 100. The digital constructs 25-la, 25-lb, 25-lc, 25-2, and 25-3 may be formed through hardware, firmware, software, operating system functions, resources accessed remotely by the electronic device 100, or a combination thereof. In embodiments, each digital construct 25 may act as a service provider 300 or a client 200, or may switch between such functions. For example, in embodiments the digital construct 25-la may be an email application, configured using the memory, processor, input/output, and display resources provided by the electronic device 100, where this email application of the digital construct 25-la may be configured as a client for an external email service provider (not illustrated). Conversely, in embodiments the digital construct 25-l b may be configured as a service provider 300 that is a file sharing service, configured from the memory and processor of the electronic device 100, without using the display device (not illustrated), thereof. In embodiments, the digital construct 25-lc may be configured as a client 200 that is a database client. In embodiments, a digital construct 25 resident on an electronic device 100 may act as the identity broker 400. In the illustrated embodiment, a digital construct 25-2 i s configured as a social media app that is a client 200, and a digital construct 25-3 is configured as an online gaming application that is a client 200. There is no particular limitation on the nature of the digital constructs 25 that are resident on the electronic device 100.

[0076] In embodiments each digital construct 25 is associated with a digital identity 27. The digital identities 27 depicted in FIG. 2 are virtual groupings of digital constructs 25 that are illustrated for convenience in explanation. As will be explained below, in embodiments the actual function for grouping the digital constructs 25 i s carried out by the i dentity broker 400, so the groups depicted in FIG. 2 only exist as defined by the identity broker 400. In this way, these digital identities 27 are dissimilar to, for example, the multiple login accounts that are available under the Windows operating system that enable access to different local resources depending on the login credentials that are used. The significance of the digital identities 27 will be appreciated after an explanation of the identity broker 400.

[0077] As depicted in FIG. 2, in the electronic device 100, each digital construct 25 has a certificate 20 associated therewith, stored in a secure memory (not shown) of the electronic device 100, where the certificates 20 are linked, through an operating system (not shown) of the electronic device 100, to the respective digital construct 25. Details of the certificates 20 will be described below in reference to FIG. 3.

[0078] In embodiments, the electronic device 100 compri ses a user authenticating subsystem 110. In embodiments the user authenticating subsystem 110 is a subsystem configured to enable identification of a user based on, for example, a biometric input, inputting of secret information, proximity of a prescribed key device, or the like. In embodiments, the electronic device 100 i s configured so that each digital construct 25 accesses the user authenticating subsystem 110 to di scern whether or not the user has been authenticated before enabling the user to operate the digital construct 25. In other embodiments, the electronic device 100 is configured to prevent operation of all digital constructs 25 that are resident thereon until authentication of the user using the user authenticating subsystem 110. Note that, in embodiments, the electronic device 100 may include multiple user profiles or user accounts (not shown), and the user authenticating subsystem 110 may be used to log into a specific user account. The user profile or user account is managed on the local electronic device 100, through the operating system thereof, so is distinct from the digital identities 27 that are managed by the identity broker 400, described below; however in embodiments the operating system of the electronic device 100 may control access to specific digital constructs 25, and the certifi cates 20 associated therewith, depending on the user profile or user account that is authenticated using the user authenticating subsystem 110. The ability to perform the user authentication once, on the electronic device 100 using the user authenticating subsystem 110, enables access to all of the digital constructs 25 that are resident on that electronic device 100 without requiring any further user input for authentication, and enables those digital constructs 25, as clients 200, to establish secure connections 10 with service providers 300 without requiring any user input whatsoever at the time of establishing those secure connections 10, as will be described below.

[0079] In embodiments, the electronic device 100 further comprises a connection interface 120 configured to establish a connection with a digital construct 25 (such as a service provider 300) on a remote electronic device through the communication methods described in this disclosure, and in embodiments provides the necessary support for all seven layers of the OSI model for electronic communication. Because the OSI model for electronic communication is well understood, no additional discussion need be provided here; however, the connection interface 120 in the electronic device 100 according to embodiments is configured to facilitate the communication methods set forth below in reference to, for example, FIG. 10. In embodiments, each digital construct 25 in the electronic device 100 is connected to the connection interface 120 to carry out electronic communication through a network (not shown). As will be described below, the connection interface 120 is able to establish a secure connection 10 between digital constructs 25 using only certificates 20, described below, without requiring any inputs from the user when establishing the secure connection 10.

[0080] In embodiments, the electronic device further comprises a digital identity manager 130, configured to generate a cryptographic certificate (“certificate 20”) as will be described below in reference to FIG. 3. In other embodiments, the digital identity manager 130 is configured to request the certifi cate 20 from an external certifi cate authority. In embodiments, the cryptographic certificate 20 that is either generated by the digital identity manager 130, or requested from an external certificate authority, i s stored, through the operating system of the electronic device 100, in relation to the relevant digital construct 25, together with a "private key" cryptographic cipher that is paired with the certificate 20. The use of the private key and of the certificate 20 that are generated by the digital identity manager 130, or requested from the external certificate authority, will be described below. [0081] In embodiments, the electronic device 100 further compri ses a device-side certificate registrar 140 that is configured to interact with an identity broker 400 through a device registration process such as will be described below in reference to FIG. 11 or FIG. 12.

[0082] Note that the electronic device 100, illustrated in FIG. 2, may be embodied through a combination of hardware, software, firmware, operating system resources, and the like. The electronic device 100 may include all of the illustrated elements, or only a subset thereof, and may also include elements that are not illustrated. Elements that are known, by those who are skilled in the art, to commonly be associated with electronic devices, such as memories, processors, input/output devices, and the like, are omitted for convenience in illustration and explanation.

[0083] In embodiments, the certificate 20 that is generated by the digital identity manager 130, or requested from an external certificate authority, not shown, by the digital identity manager 130, is a digital document used in a public key infrastructure (PKI) to establish a trusted connection between digital constructs 25 over a network, comprising: a public key; information identifying an identity broker 400; a validity period; a serial number; a subj ect; a digital signature; a certificate policy; and a signature algorithm. In this certificate 20, in embodiments : the public key is a public key that is configured to be used to establish secure communication by allowing the recipient to encrypt data or to verify encrypted data; the information identifying an identity broker 400 i s, for example, a URL of the identity broker 400 with which the certifi cate 20 (and the associated digital construct 25 and associated digital identity 27) is registered; the validity period specifies the timeframe during which the certificate is valid, where, in embodiments, this period includes a start and end date outside of which the certificate is considered expired; the serial number is a unique identifier assigned to the certificate by the issuing Certificate Authority (CA), which, in embodiments, may include also an identifier that identifies the issuing certificate authority itself; the subj ect indicates the digital construct 25 that i s associated with the certificate 20; the digital signature is a cryptographic mechanism used to ensure the authenticity, integrity, and non-repudiability of the certificate; the certificate policies include a description of how the certificate is to be used; and the signature algorithm indicates the cryptographic algorithm used to create the digital signature, specifying, for example, the hashing and encryption methods (such as SHA-256 with RSA). Note that, for convenience in explanation throughout the present disclosure, a “serial number” may include a reference to the certificate authority itself, to ensure a unique identification. In embodiments, the certificate 20 plays a central role in communication between digital constructs 25 (specifically, a client 200, a service provider 300, and an identity broker 400) in the secure electronic interaction system 90.

[0084] An identity broker 400 according to embodiments, and communication with external digital constructs 25 as well as flow of information within the identity broker 400, will be described below in reference to FIG. 4. In embodiments, the identity broker 400 compri ses: a digital identity information receiver 410, a broker-side digital identity registrar 420, a digital identity repository 430, a digital identity information processor 440, a digital identity information sender 450, and an account transferring subsystem 460.

[0085] In embodiments, the digital identity information receiver 410 is configured to receive, from an external digital construct 25 that is a service provider 300, certificate information 30 of a certificate 20 that has been sent to the servi ce provider 300 by a cli ent 200 to request a connection with the client 200 where, in embodiments, the digital identity information receiver 410 is further configured to receive also information identifying the service provider 300, such as certificate information 30 of a certificate 20 that has been issued to the service provider 300. As will be explained below in reference to FIG. 10, the service provider 300 sends certificate information 30 of the certificate 20 of the client 200 as a query to the identity broker 400 to request information regarding the reputation of the digital identity 27 associated with the client 200 and/or information regarding the relationship between the service provider 300 and the client 200, and regarding the services that the service provider 300 is to provide the client 200. In embodiments, the certificate information 30 of the certificate 20 is the certificate 20 itself, while in other embodiments the certificate information 30 of the certificate 20 may be information extracted from the certificate 20, such as the serial number of the certificate 20, or information that is the result of processing information extracted from the certificate 20. In embodiments, the digital identity information receiver is configured to further receive, from service providers 300, client behavior reports 432 detailing interactions of the service providers 300 with clients 200. In embodiments, these client behavi or reports 432 may include, for example, reports of civil behavior such as when a client 200 has successfully carried out an interaction with a service provider 300, and/or reports of malicious behavior such as when a client 200 has attempted to disrupt the service by the service provider 300, has engaged in web scraping or data harvesting, has engaged in repetitive requests for service as would characterize a distributed denial of service attack, has attempted to inj ect malicious scripts or SQL commands, has attempted to access unauthorized data, has attempted to distribute malware, has attempted to engage in payment fraud such as through providing fraudulent payment credentials, or has engaged in abuse of APIs, or has engaged in click frauds, brute force attacks, violations of service provider use policies such as engaging in hate speech or comment spamming, posting of fake reviews, data leakage, or any other type of malicious behavior by the client 200 in respect to the service provider 300. In embodiments, the digital identity information receiver 410 i s configured to further receive, from a client 200, service provider behavior reports 434 detailing interactions of service providers 300 with the client 200. In embodiments, these service provider behavior reports 434 may include, for example, reports of civil behavior such as when the service provider 300 has successfully provided a desired service to the client 200 and/or malicious behavior such as when the service provider 300 attempts to engage in, for example, data harvesting and selling, serving and/or installing spyware or tracking software, unauthorized data sharing, abuse of payment means in financial transactions (including overcharging and charging hidden fees), service downgrading or throttling, the use of manipulative dark patterns to mislead or traffic the client into an unwanted action, unjustified denial of service, fal se advertising or misrepresentation, inj ection of advertisements or malware, excessive or forced upselling, abuse of privileges in cloud services such as abusing access to client data, biased algorithmic manipulation, noncompliance with data deletion requests, discriminatory service provisioning, imposing unwanted software or updates, censorship, or any other type of malicious behavior by the service provi der 300 detected by the client 200 in its interactions with the service provider 300. The digital identity information receiver 410 is further configured to provide, to the digital identity repository 430, the information and reports received from the service provider 300 and the client 200, as described above.

[0086] In embodiments, the broker-side digital identity registrar 420 is configured to receive, from an external digital construct 25 that is a registrar subsystem 480 (such as, for example, the device-side certificate registrar 140 in the electronic device 100 described in reference to FIG. 2, above), registration information for registering a digital construct 25 (such as a client 200 or a service provider 300) in the identity broker 400. This registration information may include information regarding a certificate 20, as described above. In embodiments, the regi stration informati on may be an authorization token 22, described below. In embodiments, thi s registration information may also include information regarding the digital identity 27 that i s to be associated with the certificate 20. Note that the information regarding the digital identity 27 may, in embodiments, include information that identifies the real-world identity of the user controlling the digital identity 27, or, in other embodiments, may be merely a unique identifier of the associated digital identity 27 that is agnostic as to the real-world identity of the user. In embodiments this registration information may omit any information indicating the associated digital identity 27 except for the certificate authority that issued the certificate 20. The broker-side digital identity registrar 420 is further configured to provide, to the digital identity repository 430, the information received from the registrar subsystem 480. In embodiments, the broker-side digital identity registrar 420 is configured to further receive account information 50, such as an account number from a service provider 300 that identifies an account owned by a given client 200 at the service provider 300, which identifies the services that the service provider 300 i s to provide for the given client 200 and/or digital assets associated with the given client 200 at the service provider 300. Note that thi s account information is information for controlling a relationship between the client 200 and the service provider 300. In embodiments, the service provider 300 and the client 200 may be identified uniquely through respective information relating to the respective certificates 20.

[0087] In embodiments, the digital identity repository 430 in the identity broker 400 i s configured to receive, from the digital identity information receiver 410 and the broker-side digital identity registrar 420, the information that has been received thereby, and is configured to further receive information that is generated through processing of such information by the digital identity information processor 440, described below. In embodiments, the digital identity repository 430 is configured to receive al so information from the account transferring subsystem 460, described below. Tn embodiments, the digital i dentity repository 430 i s further configured to store the information received from the digital identity information receiver 410, the broker-side digital identity regi strar 420, the digital identity information processor 440, and the account transferring subsystem 460. [0088] In embodiments, the digital identity 27 that i s associated with a service provider 300 can be identified through the certificate information 30 of the certificate 20, described above. Given this, in embodiments the client behavior reports 432 and service provider behavior reports 434, described above, are stored, in the digital identity repository 430, in relation to information for identifying the relevant digital identity 27, where, in embodiments, this identifying information may be, for example, a text string identifying the digital identity 27, or information 30 extracted from the certificate 20. The digital identity repository 430 is further configured to retrieve information stored therein and to send this information to the digital identity information processor 440 and the digital identity information sender 450 when directed to do so by a controller, not illustrated, of the identity broker 400. Retrieval of information from the digital identity repository 430 may be based on the information for identifying the digital identity 27. In embodiments, the digital identity repository 430 is configured from a memory device, such as a semiconductor memory device, di sk drive, remote cloud storage service, or the like, and may be structured as a relational database.

[0089] In embodiments, the digital identity repository 430 is configured to store also account information 50 that defines the services that are to be provided to a client 200 by a service provider 300 of digital assets owned or controlled by the client 200 at the service provider 300. Thi s account information 50 may include, for example, an account identifier for an account administered by the service provider 300. The account information 50 may be stored in the digital identity repository 430 so as to enable retrieval of the account information 50 based on information that identifies a specific combination of a specific client 200 and a specific service provider 300, which, in embodiments, may be, for example, respective information of the respective certificates 20 that link the stored account information 50 to the specific client 200 and the specific service provider 300.

[0090] In embodiments, the digital identity information processor 440 i s configured to receive, from the digital identity repository 430, information stored therein regarding a digital identity 27. In embodiments, the digital identity information processor 440 may receive, for example, reputation information 40 that is stored in the digital identity repository 430 in relation to a specific digital identity 27, together with a received client behavior report 432 or service provider behavior report 434 that is associated, through information 30 of a certificate 20, with that digital identity 27, to perform digital processing on the reputation information 40 based on the client behavior report 432 or the service provider behavior report 434. Thi s digital processing may include, for example, adding a new record to the reputation information 40, or performing a mathematical operation on a reputational score, not shown, that is included in the reputation information 40, where the nature of the mathematical operation depends on the content of the received client behavior report 432 or service provider behavior report 434. In embodiments, this reception of reputation information 40, and digital processing thereof, by the digital identity information processor 440 may be triggered by the reception of a client behavior report 432 or service provider behavior report 434, by the digital identity repository 430 through the digital identity information receiver 410, under control of the controller, not illustrated, of the identity broker 400. In embodiments, the digital identity information processor 440 i s further configured to provide, to the digital identity repository 430, the result of digital processing on the reputation information 40, enabling the digital identity repository 430 to store updated reputation information 40 in relation to the digital identity 27 that is associated therewith or in relation to the digital constructs 25 (clients 200 and/or service providers 300) that are associated therewith. [0091 ] In embodiments, the digital identity information processor 440 i s configured to further receive, through the digital identity repository 430, information regarding requested changes to account information 50 linking clients 200 (with the respective certificates 20) to accounts at service provider 300, and to modify, and save to the digital identity repository 430, that account information 50, following a procedure as described below in reference to FIG. 13, for example.

[0092] In embodiments the digital identity information sender 450 of the identity broker 400 is configured to receive, from the digital identity repository 430, reputation information 40 and/or account information 50 that is associated with information of a specific certificate 20, to forward the reputation information 40 and/or account information 50 to a service provider 300 that has, through a procedure that will be described below in reference to FIG. 10, queried the identity broker 400 by sending, to the identity broker 400, certificate information 30 of the certificate 20. In embodiments, this certificate information 30 of the certificate 20 may be the certificate 20 itself, while, in other embodiments the certificate information 30 of the certificate 20 may be information that is extracted from the certificate 20, or produced through processing such extracted information.

[0093] In embodiments, sending of the reputation information 40 by the digital identity information sender 450 to the service provider 300 is carried out in response to reception, by the digital identity information receiver 410, of a query from the service provider 300 in the form of information 30 of a certificate 20. In this way, the reputation information 40 that is sent to the service provider 300 serves as a report indicating the civility or maliciousness of the behavior of digital constructs 25 that are linked to a digital identity 27 that is associated with the client 200 that is requesting the connection to the service provider 300. Thi s allows the service provider 300 to determine whether or not to engage with the client 200 based on the reputation information 40, enabling the identity broker 400 to have the effect of a civil behavior enforcing system. [0094] In embodiments, the account transferring sub system 460 i s configured to receive information from an external digital construct 25 that is an account transfer requester 490. In embodiments this account transfer requester may be a service provider 300 or a representative thereof. The information received by the account transferring subsystem 460 may, in embodiments, include information identifying a source client 28 and information identifying a target client 29, and may further include information, such as account information 50 for an account at a service provider 300, that is to be transferred from association with the source client 28 to association with the target client 29, following a procedure as described below in reference to FIG. 13, for example. In embodiments, the account transferring subsystem 460 is further configured to generate and store, in the digital identity repository 430, information for causing the account at the service provider 300 to be associated with the target client 29 instead of the source client 28. In embodiments, the account transferring subsystem 460 i s further configured to verify, through examining the information received from the account transfer requester 490, whether or not the account transfer requester 490 has adequate authority to request the account transfer. Note that when an account is transferred from the source client 28 to the target client 29, the practical effect of this transfer i s that ownership and/or control of the account, and all digital assets stored therein or manage thereby, is transferred from the source client 28 to the target client 29.

[0095] In embodiments, the account transferring subsystem 460 i s further configured to receive and store an advance directive (account bequeathing advance directive) 31. In embodiments the advance directive may include information for identifying a source digital identity 32 and one or more target digital identity 33, along with a condition for transferring, from the source digital identity 32 to target digital identities 33 in the digital identity repository 430, some or all accounts that are associated with the source digital identity 32. In embodiments, the account transferring subsystem 460 may further comprise an inactivity tracker 465 that is configured to track time that has elapsed since the last query, from a service provider 300 to the identity broker 400, regarding any digital construct 25 that i s associated with the source digital identity 32 in the information stored in the digital identity repository 430. In embodiments, the inactivity tracker may comprise a table listing digital identities 27 and the last time a digital construct 25 associated with any given digital identity 27 has been the subj ect of a query. In embodiments, the advance directive 31 may include an elapsed time of inactivity, and the condition for transferring may be that of an elapsed time of inactivity for a given source digital identity 32 exceeding the elapsed time of inactivity in an advance directive 31 associated with that source digital identity 32. In embodiments, the account transferring subsystem 460 may be configured to generate and store, in the digital i dentity repository 430, information for causing all accounts associated with the source digital identity 32 to be associated with digital constructs 25 associated with preselected target digital identities 33 instead of the source digital identity 32, conditional upon the time of inactivity, in the inactivity tracker 465, for the source digital identity 32 exceeding the elapsed time of inactivity in the advance directive 31. Thi s enables all accounts that are associated with the source digital identity 32 to be transferred to the target digital identity 33 in, for example, the event that a real-world user who owns or control s the source digital identity 32 ceases to be active for an extended period of time, such as could result from death or disability. In embodiments, conditions in the advance directive 31 for executing the transfer may include a directive from a system operator of the identity broker 400. In further embodiments, conditions in the advance directive 31 for executing the transfer may include the presence of a prescribed token, or the expiration of a certificate associated with the source digital identity 32.

[0096] In yet other embodiments the identity broker 400 compri ses an identity restoring subsystem 470 and a certificate authority subsystem 475. As will be described below, the identity restoring subsystem 470 is to enable a user who has lost access to all digital constructs 25 that are associated with a digital i dentity 27 to regai n access through an identity restoring process as shown in FIG. 14, below. Note that the loss of access to all digital constructs 25 may be through, for example, expiration of all of the certificates 20 for all of the digital constructs 25 associated with a given digital identity 27. In embodiments the identity restoring sub system 470 is configured to receive an identity restoration request from a trusted identity restoring agent 471, where, in embodiments, the trusted identity restoring agent may be, for example, a service provider 300 with which a user has had trusted personal interaction, such as a bank or government institution, that i s in the position to verify the physical identity of the user through familiarity or documentation. In embodiments, the identity restoration request may include certificate information 30 of a certificate 20 or other information that identifies the trusted identity restoring agent 471, along with account information 50 indicating an account owned by the user at the service provider 300 that is the trusted identity restoring agent 471. The identity restoring subsystem 470 is further configured so that, upon receipt of the identity restoration request, the identity restoring subsystem 470 accesses the digital identity repository 430 to identify the digital identity 27 that is associated with that account information 50 at the service provider 300, and further configured so as to send, to the client 200 that i s associated with the account information 50 at the service provider 300, a “token” (encrypted information that includes information about the client 200 and the applicable service provider 300) that can be used by the client 200 to request issuing of a new certificate 20. In embodiments, the client 200 uses the token to interact with a digital identity manager 130, as depicted in FIG. 2, to receive a new certificate 20, and then uses the device-side certificate regi strar 140, depicted in FIG. 2, to act as the registrar subsystem 480 that is depicted in FIG 4 to send information (including information, included in the token, about the certificate 20 and about the relationship with the service provider 300) to the broker-side digital identity registrar 420, depicted in FIG. 4, to thereby register the client 200, and its relationship with the service provider 300, in the digital identity repository 430 of the identity broker 400. In other embodiments, the client 200 sends the token to the certificate authority subsystem 475, depicted in FIG. 4, to receive a new certificate from the certificate authority subsystem 475 that is part of the identity broker 400, and similar information is sent (by the client 200 or the certificate authority subsystem 475) to the broker-side digital identity registrar 420, to thereby register the client 200, and its relationship with the service provider 300, in the digital identity repository 430 of the identity broker 400. The client 200, having received a certificate 20, and having registered that certificate 20, along with information regarding the client 200 and the applicable digital identity 27, can then be used to restore the other digital constructs 25 that are associated with the applicable digital identity 27, through a process such as illustrated in FIG. 15.

[0097] In yet another embodiment, the identity restoring subsystem 470 may be configured to perform Sharmir recovery through receiving, from the client 200, prior to losing access to the digital constructs 25 associated with the digital identity 27, a li st of one or more identity restoration deputies 472, selected by the client 200 in advance, to be authorized to assist in recovery of a lost digital identity 27. In embodiments, the identity restoring subsystem 470 is further configured to receive, from the client 200, a a minimum deputy count value 35 (a critical count) for a number of identity restoration deputies 472 that will be required in order to recover a lost digital identity 27. In embodiments, the identity restoring subsystem 470 is configured to receive identity restoration requests from identity restoration deputies 472, in the same manner as described above, and further configured to compare, to the minimum deputy count value 35, the number of identity restoration deputies 472 from which identity restoration requests have been received, and, in the event that the number of identity restoration deputies 472 that have made identity restoration requests is no less than the minimum deputy count value 35, to perform the same identity restoration process as described above. This enables a lost digital identity 27 to be restored while providing greater security by requiring a plurality of i dentity restoration deputi es 472 rather than only a single trusted identity restoring agent 471. The greater security is provided through the need for action by multiple identity restoration deputies 472 before restoration of the lost digital identity 27, where security can be increased even further through a selection of identity restoration deputies 472 that are unaware of each other and therefore unable to engage in fraudulent collusion.

[0098] Note that the identity broker 400, illustrated in FIG. 4, may be embodied through a combination of hardware, software, and firmware, resident on one or more electronic devices such as the electronic device 100 as illustrated in FIG. 1. The identity broker 400 may include all of the illustrated elements, or only a subset thereof, and may also include elements that are not illustrated. Elements that are known by those who are skilled in the art to commonly be associated with electronic devices, such as memories, processors, input/output devices, and the like, are omitted for convenience in illustration and explanation.

[0099] A service provider 300 according to an embodiment will be described next in reference to FIG. 5. As depicted in FIG. 5, a service provider according to an embodiment comprises a connection request receiver 305, a certificate evaluator 310, a query sender 315, a behavior detecting subsystem 320, a service processor 325, an account selector 330, a policy compliance evaluator 335, a query response receiver 340, and a connection interface 350. [00100] The connection request receiver 305, depicted in FIG. 5, is configured to receive, from a client 200, a request to establish a connection to carry out interactions. In embodiments, the connection request from the client 200 may be in the form of the client 200 sending a certificate 20 to the connection request receiver 305. The connection request receiver 305 in embodiments is configured so as to carry out appropriate handshaking, such as the client hello, server hello, server certificate presentation and authentication, and client certificate request steps, as are known to those skilled in the art for a TLS/S SL handshake, with the client 200, prior to receiving the certificate 20. In embodiments, the connection request receiver 305 is further configured to be in operative communication with the certificate evaluator 310 and the behavior detecting subsystem 320. In embodiments, the connection request receiver 305 i s further configured to collect information regarding behavior of the client 200, such as malicious behavior characterized by an excessively high frequency of repeated connection requests. The connection request receiver 305 is configured so as to use resources of the electronic device 100, upon which the service provider 300 is resident, to carry out the handshaking with the cli ent 200. [OOlOlJIn embodiments, the certificate evaluator 310 is configured to receive certificate information 30 of the certificate 20 from the connection request receiver 305, and to perform evaluations regarding the validity of the certificate 20, through, for example, extracting the period of validity and comparing it against the current date, checking for revocation through referencing a certificate revocation list or following an online certificate status protocol, verifying the certificate signature, and verifying the chain of trust, as is known to those skilled in the art for certificates of the X.509 standard. Although it can be appreciated that the certificate evaluator 310 must communicate with the outside to, for example, check for the revocation status, the standard physical and logical structures by which to do so are omitted from FIG. 5 for convenience in illustration and for brevity in explanation. The certificate evaluator 310 is further configured to provide the result of the evaluation to the query sender 315 and to the behavior detecting subsystem 320.

[00102]As illustrated in FIG. 5, in embodiments the query sender 315 is configured to receive, from the certificate evaluator 310, a result of evaluation, and, upon a result indicating the validity of the certificate 20, to send, to the identity broker 400, a query regarding the reputation of the digital identity 27 that is associated with the client 200, and/or a query regarding account information 50 for the account of the client 200 at the service provider 300. The query sender 315 i s configured to use resources of the el ectroni c device 100 on which the service provider 300 i s resi dent in order to carry out communication with the identity broker 400.

[00103]As illustrated in FIG. 5, the behavior detecting subsystem 320 is configured so as to receive inputs from the connection request receiver 305, the certificate evaluator 310, and the service processor 325, so as to detect civil or malicious behavior by the client 200 during the interactions, and so as to report such behavior, along with information identifying the client 200, to the identity broker 400. The behavior detecting subsystem 320, in embodiments, comprises memory and a processor, not illustrated, to compile information regarding the behavior of the client 200, such as civil behavior versus malicious behavior. In embodiments, the behavior detecting subsystem 320 may be configured to detect civil behavior based on normal connection patterns with requests spread out over time or matching typical user activity, accessing data or resources at a typical human-readable rate and in alignment with user permissions, a small number of login attempts with correct credentials, limited or typical use of API calls within expected rates following an API usage policy, data transfers within reasonable limits based on typical usage for the specific service, consistent interaction patterns including familiar login locations and times, adherence to standard protocol requests and responses such as proper use of HTTPS with expected packet structures and orderly requests, use of normal requests that do not attempt to probe the system for weaknesses, use of common web browsers or client identifiers matching standard versions and configurations, regular session patterns including orderly login and logout with a single session per user, and the like. Conversely, in embodiments the behavior detecting subsystem 320 may be configured to detect malicious behavior based on excessively high frequencies of requests, rapid repeated connection attempts, irregular patterns that are indicative of brute force attacks, denial of service, or attempts to overwhelm the server, excessive or unusual requests for sensitive data, unauthorized attempts to access restricted areas, or patterns that resemble scraping where a bot systematically extracts large amounts of data, multipl e rapi d login attempts with incorrect credential s, excessive or high-frequency API calls violating rate limits indicative of attempts to exploit or abuse APIs, large or unusually frequent file uploads or downloads that are potentially indicative of data exfiltration or unauthorized bulk data access, sudden changes in access locations such as logging in from different countries within minutes of each other, use of suspicious devices or access during unusual hours, unusual packet types, malformed requests, or attempts to exploit known protocol vulnerabilities that are indicative of probing for weaknesses, detection of automated scripts or bots performing actions at unnatural speeds such as rapid form submissions or repeated actions faster than humanly possible, excessive resource usage that exceeds normal levels, attempts to exploit known vulnerabilities such as SQL inj ection, cross-site scripting, and other inj ection attacks, use of suspicious or spoofed client identifiers such as outdated browsers with known vulnerabilities, fake user agents, or IP addresses attempting to mask location or identity, multiple simultaneous sessions or frequent session resets, and the like.

[00104]In embodiments the query response receiver 340 is configured to receive, from the identity broker 400, a response to a query that has been sent by the query sender 315. In embodiments, the response received by the query response receiver 340 may be reputation information 40 regarding the digital identity 27 that is associated with the client 200, information about the client 200 that the service provider 300 had previously provided to the identity broker 400, public information about the client 200 or about the digital identity 27 associated therewith, account information 50 regarding an account maintained by the client 200 at the service provider 300, such as an account number or identifier, specific privileges to be provided to the specific client 200, and the like. In embodiments, the query response receiver i s further configured to extract specific information from the response from the identity broker 400, to provide the extracted information to the account selector 330 and the policy compliance evaluator 335. [00105]In embodiments, the account selector 330 i s configured to receive account information 50 from the query response receiver 340, and to thereby select the account of the client 200 in the service provider 300, to provide, to the service processor 325, control information for controlling processing by the service processor 325 in accordance with the privileges and digital assets of the account of the client 200 at the service provider 300. Thus the account selector 330 functions as a service selector, to select, based on the account information 50 included in the query response, the services to be provided by the service provider 300 through the established connection 10. [00106]In embodiments, the service processor 325 is configured to receive control information from the account selector 330 and to interact through a mutually authenticated connection 10 with the cli ent 200 so as to perform the actual processing of the services that are to be provided by the service provider 300 to the client 200, such as retrieving and serving information, carrying out calculations, structuring and manipulating databases, providing audio, video, or text information, or any other services typically provided through electronic interactions.

[00107]In embodiments, the policy compliance evaluator 335 is configured to receive reputation information 40 from the query response receiver 340, and to compare that information against security polici es of the service provider 300 so as to evaluate whether or not to allow the client 200 to connect to the service provider 300. For example, in embodiments the reputation information 40 from the identity broker 400 may include a reputation score, and the policy compliance evaluator 335 may be configured to compare that reputation score against security standards, to issue a connection prohibition to the connection interface 350 if the reputation score fail s to sati sfy a minimum standard.

[00108]In embodiments, the connection interface 350 is configured to complete the handshaking with the client 200, through performing mutual authentication through exchanging keys and through generating session keys to establish a mutually-authenticated connection 10 to enable secure communicati ons by which the client 200 and the servi ce processor 325, of the service provider 300, can interact safely and securely to transact business. The service provider 300 in embodiments, configured in this way, when used with an identity broker 400 as depicted in, for example, FIG. 4, enables increased convenience for the user, by not requiring manual entry of account information and passwords, and the like, while providing for substantially improved security through only establi shing the communication connection 10, beyond the minimum requirements of the X.500 standard handshaking, or the like, after having first carried out full authentication including a reputation check.

[00109]In embodiments, a service provider 300 in the secure electronic interaction system 90, depicted in FIG. 1 , may be configured as depicted in FIG. 6 to enable a first client 200-1 to register a second client 200-2 with the identity broker 400, where the service provider 300 may comprise a registering subsystem 355 configured to receive operations from a first client 200-1 through a secure connection 10, to generate (or request from an external certificate authority) and i ssue a certificate 20 to the second client 200-2, and further configured to send, to the identity broker 400, registration information, such as serial number information for the newly issued certificate 20, to thereby register the second client 200-2 into the identity broker 400. This enables a service provider 300, as illustrated in FIG. 6, for example, to act as the registrar subsystem 480 that is depicted in FIG. 4.

[OOl l OJIn yet another embodiment, a service provider 300 in the secure electronic interaction system 90, depicted in FIG. 1, may be configured comprising a Shamir recovery subsystem 360 that is configured to perform Sharmir recovery through receiving, from the client 200, prior to losing access to the digital constructs 25 associated with the digital identity 27, a list of one or more identity restoration deputies 472, selected by the client 200 in advance, to be authorized to assist in recovery of a lost digital identity 27, or to generate Shamir restoration deputy tokens 34, as described below, to enable the identity restoration deputies 472 to assi st in restoring the lost digital identity 27. In embodiments, the Shamir recovery subsystem 360 i s further configured to receive, from the client 200, a minimum deputy count value 35 for a number of identity restoration deputies 472 that will be required in order to recover a lost digital identity 27. In embodiments, the Shamir recovery subsystem 360 is configured to receive identity restoration requests from identity restoration deputies 472, in the same manner as described above, and further configured to compare, to the critical count, the number of identity restoration deputies 472 from which identity restoration requests have been received, and, in the event that the number of identity restoration deputies 472 that have made identity restoration requests exceeds the critical count, to perform the same identity restoration process as was described for the identity restoring subsystem 470 which was explained above in reference to FIG. 4. This embodiment illustrates how a system that has been explained as provided in the identity broker 400 may instead be provided as a separate service provider 300, increasing the convenience and flexibility of the system.

[00111JA first service provider 300-1 of yet another embodiment, as illustrated in FIG. 8, may be configured as an anonymized personal information verification system . In embodiments, the first service provider 300-1 provides a service that requires, during the course of the service, exchange of personal information. The first service provider 300-1 may be, for example, configured to provide services, such as banking services or healthcare-related services that require personal information such as a legal name, birth date, residence, and the like, in the course of ordinary business. In embodiments, the first service provider 300-1 compri ses a service processor 325, a personal information storing subsystem 365, a personal information query receiving subsystem 370, a personal information verification subsystem 375, and a verification result sending subsystem 380. In embodiments, the service processor 325 may be configured to receive, during the course of business, personal information from a client 200, and further configured to store the personal information in the personal information storing subsystem 365. The personal information storing subsystem 365 i s configured to receive the personal information from the service processor 325 and provide the personal information, when required, to the personal information verification subsystem 375. The personal information query receiving sub system 370 is configured to receive, from a second service provider 300-2, a query for verifying that personal information of an anonymous real-world user satisfies some criterion required for the second service provider 300-2 to provide services to the client 200. Note that here the identity broker 400, which is not part of the first service provider 300-1, receives certificate information 30 of a certificate 20, to retrieve, from the digital identity repository 430 that is depicted in FIG. 4, account information 50 that is associated with the digital identity 27 that is associated with the certificate 20. The personal information query receiving subsystem 370 i s further configured to receive the account information 50 from the identity broker 400, and configured to send the criterion and the account information 50 to the personal information verification subsystem 375. The personal information verification subsystem 375 is configured to receive the required criterion and the account information 50 from the personal information query receiving subsystem 370, to retrieve, from the personal information storing subsystem 365, the relevant personal information that i s associated with the account information 50, and to evaluate whether or not the required criterion is satisfied by the retrieved personal information, sending an anonymized Boolean evaluation result to the verification result sending subsystem 380. In embodiments, the verification result sending subsystem 380 is configured to receive the evaluation results from the personal information verification subsystem 375 and return the result to the second service provider 300-2 that had placed the query for anonymized personal information verification. Although in this system the first service provider 300-1 has access to personal information of the real-world user that has a digital identity 27 that is associated with the client 200, the first service provider 300-1 has no vi sibility into the specific service requested by the cli ent 200 from the second servi ce provi der 300-2. In addition, the second service provider 300-2 will have no access to any information regarding the real-world user except for whether or not the criterion in the query was satisfied. Although the identity broker 400 is able to link between the certificate information 30 of the certificate 20 and the digital identity 27, in embodiments the identity broker 400 is unaware of the real-world identity of the user, and unaware of the nature of the service provided by the second service provider 300-2. When combined with the security measures described in earlier embodiments, use of anonymized personal information verification through the first service provider 300-1 , depicted in FIG. 8, enables a high level of security and an extremely high level of privacy simultaneously, while still enabling verification of compliance with specific personal information requirements. An example of a scenario where this anonymous personal information verification system is useful would be, for example, in verifying that the real-world user of the client 200 that is requesting services from the second service provider 300- 2 is at least 21 years old. In embodiments, the personal information receiving subsystem 370 i s further configured to accept only inquiries regarding specific predetermined personal information categories, thereby preventing leakage of personal information through random probing.

[00112]Note that all aspects and elements of the service providers 300 (300- 1 ), illustrated in FIG. 5 through 8 may be combined together in a single service provider, and not all elements illustrated are necessarily required. Note also that the service providers 300 (300-1), illustrated in FIGS. 5 through 8, may be embodied through a combination of hardware, software, and firmware resident on one or more electronic devices such as the electronic device 100 that is depicted in FIG. 2. The service provider 300 may include all of these elements, or only a subset thereof, and may also include elements that are not illustrated. Elements that are known, by those who are skilled in the art, to commonly be associated with service providers, such as memories, processors, input/output devi ces, and the like, are omitted for convenience in illustration and explanation.

[00113JA client 200 that may be used in the secure electronic interaction system 90 of an embodiment will be described next in reference to FIG. 9. As illustrated in FIG. 9, in embodiments the client 200 comprises : a secure certificate storage 210, a processing system 220, a behavior detecting subsystem 230, and a behavior reporting subsystem 240. The secure certificate storage 210 is configured to store a certificate 20, and a private key associated therewith, securely. The secure certificate storage 210 may be achieved through any of a variety of known techniques such as a hardware security module, a trusted platform module, a secure enclave or a trusted execution environment, encryption of the private key through key wrapping, or the like, or any other suitable technique. Note that the certificate 20 that is stored in the secure certificate storage 210 of a digital construct 25 that is present in one electronic device 100 may be associated with the same digital identity 27 that is associated with another certificate 20 that is stored in a secure certificate storage 210 of another digital construct 25 that is present in another electronic device 100. That is, digital constructs 25 that are present on different electronic devices 100 may be associated with the same digital identity 27.

[00114] The processing system 220 i s configured to receive a certificate 20 from the secure certificate storage 210 and to communicate with a service provider 300, using, for example, a method such as described in FIG. 10, to receive services from the service provider 300. The processing system 220 is further configured to monitor the behavior of the service provider 300, to provide information to the behavior detecting subsystem 230. The behavior detecting subsystem 230 i s configured to detect civil or malicious behavior of the service provider 300 in the interactions with the client 200 where, in embodiments, civil behavior i s detected when the service provider 300 provides the desired service smoothly and as anticipated, and malicious behavior is detected when the service provider 300 attempts to engage in, for example, data harvesting and selling, serving and/or instal ling spyware or tracking software, unauthorized data sharing, abuse of payment means in financial transactions (including overcharging and charging hidden fees), service downgrading or throttling, the use of manipulative dark patterns to mislead or traffic a client into an unwanted action, unjustified denial of service, fal se advertising or misrepresentation, inj ection of advertisements or malware, excessive or forced upselling, abuse of privileges in cloud services such as abusing access to client data, biased algorithmic manipulation, noncompliance with data deletion requests, discriminatory service provisioning, imposing unwanted software or updates, censorship, or any other type of malicious behavior. The behavior reporting subsystem 240 i s configured to receive, from the behavior detecting subsystem 230, a result of detection of the behavior of the service provider 300 by the behavior detecting subsystem 230, and to report, to an identity broker 400, the civil or malicious behavior that has been detected. Thi s client 200, when used with the identity broker 400 such as described in reference to FIG. 4, provides incentives for service providers 300 to avoid malicious behavior and to engage in civil behavior, given that malicious behavior will be identified and tracked, which could adversely affect one’ s ability to interact with others service providers 300 on the Internet.

[00115JA method by which the secure electronic interaction system 90, such as depicted in FIG. 1, enables secure and convenient electronic interaction between a client 200 and a service provi der 300 through the mediation of an identity broker 400 will be described next in reference to FIG. 10. First a client 200, which wi shes to conduct business with a service provider 300, requests 1000 a connection 10 by sending a certificate 20 to the service provider 300. Following this, the service provider 300 validates 1010 the validity of the certificate 20, through, for example, extracting the period of validity and comparing it against the current date, checking for revocation through referencing a certificate revocation list or following an online certificate status protocol, verifying the certificate signature, and verifying the chain of trust. If the certificate 20 i s invalid, expired, or revoked, the service provider 300 refuses 1020 the connection attempted by the client 200, and terminates further processing. Conversely, if the certificate 20 is valid and non-revoked, the service provider 300 extracts 1030 address information for the applicable identity broker 400 from the certificate 20. In embodiments, this address information may be a URL. The service provider 300 then references 1040 a list of trusted identity brokers 400, to verify that the identity broker 400 listed in the certificate 20 is trusted. If at this point the identity broker 400 is not on the list of trusted identity brokers 400, in embodiments the service provider 300 refuses 1020 the connection attempted by the client 200, and terminates further processing. Conversely, if the identity broker 400 i s included in the list of trusted identity brokers 400, the service provider 300 then forwards 1060 certificate information 30 of the certificate 20 of the client 200, together with certificate information 30 of the certificate 20 of the service provider 300, to the identity broker 400. Note that this certificate information 30 of the certificate 20 may be the certificate 20 itself, or may be information extracted from the certificate 20, or may be the result of processing information that is extracted from the certificate 20. [00116]Based on the certificate information 30, the identity broker 400 extracts 1070 reputation information 40 associated with the digital identity 27 that i s associated with the certificate information 30 of the certificate 20, and also account information 50 that is associated with the client 200 at the service provider 300. The identity broker 400 then sends 1080 thi s reputation information 40 and account information 50 to the service provider 300.

[00117]Based on the reputation information 40 and on a security policy 60 of the service provider 300, the service provider 300 evaluates 1085 whether or not to allow the client 200 to connect. In embodiments, thi s evaluation 1090 is achieved through evaluating whether or not the reputation information 40 complies with the security policy 60. If the reputation information 40 does not comply with the security policy 60, the service provider 300 refuses 1090 the connection attempted by the client 200, and terminates processing. Conversely, if the reputation informati on 40 complies with the security policy 60, the service provider 300 and the client 200 establish 1095 a mutually authenticated connection 10, and carry out business based on the account information 50.

[00118] The method for secure electronic interaction described in reference to FIG. 10 enables highly secure communication between the client 200 and the service provider 300, while providing the service provider 300 with enhanced security because no operating connection i s made with the client 200 until after verifying the reputation of the digital identity associated with the client 200, while still providing the convenience of not requiring “logging in” using, for example, a user name and a password, or dealing with the inconvenience of multifactor authentication. That is, at the time of establishing the connection, no input is required from the user, and no secret information need be provided.

[00119JA process whereby an electronic device 100 (a first electronic device 100-1) issues a certificate to a client 200, according to an embodiment, will be explained next in reference to FIG. 11. A process such as thi s is performed when, in an embodiment, a first (registered) client 200-1 requests, from a certificate authority (which, in embodiments may be the digital identity manager 130 of the first electronic device 100-1), issuing of a certificate 20, along with the private key 21 that is paired therewith, to a second client 200-2. This process may be performed when, for example, the first client 200-1 is to register, in the i dentity broker 400, a second (unregistered) client 200-2 (which may be present on a second electronic device 100-2). Note that in embodiments this process may be initiated by the unregistered second client 200-2 instead, by the unregistered second client 200-2 sending a " challenge token" to the first client 200-1 requesting registration, where the challenge token includes information about the second client 200-2 that provides information to the first client 200-1 enabling the first client 200-1 to issue an authorization token 22 to the second client 200-2. [00120]Tn embodiments, the first cli ent 200-1 sends 1 100 an authorization token 22 to the second client 200-2. In embodiments, this authorization token may include certificate information 30-1 of the certificate 20-1 of the first client 200-1, which includes information identifying the first client 200-1 , the certificate authority of the first client 200-1 , and authorization to issue a certificate 20-2, along with the private key 21-2 that i s paired therewith, to the second client 200-2.

[00121] The second client 200-2 receives 1110 the authorization token 22, and sends 1120 the authorization token 22, along with a pseudonym (unnumbered) for identifying the second client 200-2, to the certificate authority, which in embodiments may be a digital identity manager 130 of the electronic device 100-1 where the first client 200-1 is resident. In other embodiments, the certificate authority may be an identity broker 400 such as described in reference to FIG. 4. The digital identity manager 130 or the identity broker 400 receives 1130 the authorization token 22, along with the pseudonym (unnumbered).

[00122]In an embodiment wherein the digital identity manager 130 of the electronic device 100 i s used as the certificate authority, the digital identity manager 130 examines the authorization token 22 to establish the validity thereof through, for example, examining 1140 the validity of the certificate 20-1 of the first client 200-1 that is sent as a portion of the authorization token 22. Note that in embodiments the digital identity manager 130 compri ses a portion of the operating system of the first electronic device 100-1. If the authorization token 22 is found to be invalid, the authorization token 22 is ignored and the process is terminated 1145. Conversely, upon validation of the authorization token 22, in embodiments the digital identity manager 130 issues 1150 a certificate package 19 that includes a certificate 20-2 and the private key 21-2 that is paired therewith, and generates a certificate signing request 23 that includes certificate information 30-2 of the certificate 20-2 (including a pseudonym for identifying the second client 200-2, public key information for the certificate 20-2, and a serial number of the certifi cate 20-2), and al so certifi cate information 30-1 of the certificate 20-1 of the first client 200-1 that is requesting registration of the second client 200-2. In other embodiments, the digital identity manager 130 may request, from a third-party certificate authority, that a certificate 20-2, and a private key 21-2 that is paired therewith, be issued. The digital identity manager 130 sends 1155 the certificate signing request 23 to the broker-side digital identity registrar 420 of the identity broker 400. In embodiments, the broker-side digital identity registrar 420 receives 1160 the certificate signing request 23 and compares 1165 the serial number thereof to serial numbers already stored in the digital identity repository 430 thereof to determine whether or not the serial number is unique. If, in embodiments, the serial number is unacceptable, the broker-side digital identity registrar 420 provides notification 1170, to the digital identity manager 130 of the first electronic device 100-1, that the serial number is unacceptable. In response to such a notification, the digital identity manager 130 generates a new certificate package 19 and certificate signing request 23, and processing repeats from 1150. Note that in embodiments, negotiations regarding the serial number may be carried out between the digital identity manager 130 and the identity broker 400 in advance, prior to sending of the certificate signing request 23.

[00123]If, in the determination 1165, the identity broker 400 determines that the serial number is acceptable, the broker-side digital identity registrar 420, in embodiments, stores 1175, in the digital identity repository 430 thereof, certificate information 30-2 of the certificate 20-2, including information linking the certificate 20-2, the second client 200-2, and the digital identity 27 that is identified, using the digital identity repository 430, as being associated with the certificate information 30 of a certificate 20-1 of the first client 200-1, thereby registering the second client 200-2 in the identity broker 400. In embodiments, the broker-side digital identity regi strar 420 provides 1180 notification to the digital identity manager 130 that the serial number is acceptable, and the digital identity manager 130 then sends 1185 the certifi cate package 19, which includes the certificate 20-2 and the private key paired therewith, to the second client 200-2, which stores 1190 the certificate 20-2 and the private key paired therewith securely for future use. [00124] The identity broker 400 identifies, from the certificate information 30-1 of the certificate 20-1 that is included in the authorization token 22, that both the first client 200-1 that issued the authorization token 22, and the second client 200-2, that will receive the second certificate 20-2 and the private key 21-2, are both associated with a specific digital identity 27. Thus, in embodiments, the identity broker 400 stores, in the digital identity repository 430 thereof, information of the second certificate 20-2, associated with that specific digital identity 27, thereby registering the second client 200-2 in the identity broker 400.

[00125]Note that in the process set forth above, the private key is never sent to the identity broker 400, ensuring a high level of security. Note also that, in embodiments, the certificate 20-2 includes, therein, information that indicates that the digital identity manager 130 of the electronic device 100- 1 is the certificate authority.

[00126JA process used in embodiments wherein the identity broker 400 is used as the certificate authority for i ssuing the certificate package 19 (including the certificate 20-2 and the private key 21-2), will be explained in reference to FIG. 12. As with the process described in reference to FIG . 11, in embodiments : the first client 200-1 sends 1200 an authorization token 22 to the second client 200-2; and the second client 200-2 receives 1210 the authorization token 22. However, unlike the process described in reference to FIG. 11 wherein the digital identity manager 130 was used as the certificate authority, when the identity broker 400 is used as the certificate authority the second client 200-2 sends 1220 the authorization token 22 to the broker-side digital identity registrar 420 of the identity broker 400, where, in embodiments, the authorization token includes the same information as described above. The broker-side digital identity registrar 420 receives 1230 the authorization token 22, and authenticates 1240 the certifi cate 20-1 , of the first client 200-1 , included therein to establi sh the validity of the authorization token 22. If the authorization token 22 is not valid, processing is terminated 1245. If the authorization token 22 is valid, the certificate authority subsystem 475 issues 1250 a certificate package 19 (including a certificate 20-2 and a private key 21-2 paired therewith), or requests the certificate package 19 from an external third-party certificate authority, and sends 1255 the certificate package 19 to the second client 200- 2. In embodiments, the digital identity information processor 440 of the identity broker 400 retrieves 1260, from the digital identity repository 430, the identifier for the digital identity 27 that is associated with the certificate 20-1 of the previously registered first client 200-1, and stores, in the digital identity repository 430, certificate information 30-2 of the certificate 20-2, linked to the pseudonym from the authorization token and the digital identity 27 that is now associated with both the certificate 20-1 and the certificate 20-2, to thereby register 1265 the second client 200-2 in the digital identity repository 430 of the identity broker 400. The newly registered second client 200-2 receives the certificate package 19, and stores the certificate 20-2, and the private key 21-2 that is paired therewith, for future use. Note that while in the embodiment described in reference to FIG. 12 the broker-side digital identity regi strar received the authorization token 22 and the certificate authority subsystem 475 of the identity broker 400 issued the certificate package, there is no limitation to these functional units being within the identity broker 400, but rather these functions may be achieved in, for example, a registering sub system 355 of a service provider 300, as depicted in FIG 6

[00127JA process that i s performed to transfer an account at a service provider to a different client in an embodiment will be explained below in reference to FIG. 13. As depicted in FIG. 13, a first client 200-1 connects 1300 to a service provider 300 using, for example, the process that was explained in reference to FIG. 10. The first client 200-1 informs 1310 the service provider 300 that the account of the first client 200-1 at the service provi der 300 i s to be transferred to a second client 200-2. In embodiments thi s may be achieved through a user interacting with a screen served by the service provider 300 and displayed on an electronic device 100. The service provider 300 securely connects 1320 to the i dentity broker 400 through, for example, the same process as described above in reference to FIG. 10, and sends 1330, to the account transferring subsystem 460 of the identity broker 400, a transfer request token 24 which, in embodiments, includes certificate information 30-1 of the certificate 20-1 of the first client 200. The account transferring subsystem 460 retrieves 1340, from the digital identity repository 430, account information 50 that indicates the relationship between the first client 200-1 and the service provider 300, and returns 1350, to the first client 200-1 or the service provider 300 (the account transfer requester 490 in FIG. 4), a transfer token 26 which, in embodiments, includes information identifying the service provider 300 and account information 50 for the account that is to be transferred. The first client 200-

1 or the service provider 300 provides 1355 the transfer token 26 to a second client 200-2, manually, through a QR code, electronically, or the like. The second client 200-2 sends 1360, either directly or through the service provider 300, the transfer token 26 along with certificate information 30-2 of the certificate 20-2 to the broker-side digital identity registrar 420 of the identity broker 400. The broker-side digital identity registrar 420 receives 1370 the transfer token along with, or including, certificate information 30-

2 of the certificate 20-2 of the second client, and updates 1380, in the digital identity repository 430, information that links the certificate 20-2 of the second client 200-2 to the applicable account of the service provider 300, and removes 1390 the link between the certificate 20-1 of the first client 200-1 to that account. The account (and all digital assets therein) is transferred thereby from the first client 200-1 to the second client 200-2.

[00128JA process, in an embodiment, for recovering a digital identity 27 to which access has been lost will be explained next in reference to FIG. 14. The ability to recover a digital identity 27 may be important when, for example, all certificates 20 for all digital constructs 25 associ ated with the digital identity 27 have expired simultaneously, after, for example, a period of di suse. As depicted in FIG. 14, in embodiments, a user, who is an owner of a digital identity 27 to which access has been lost, proves 1400 his or her identity to a service provider 300 (a trusted identity restoring agent 471 in FIG. 4) through, for example, a personal visit to a real-world service provider (such as a bank that provides services to the user, at which the user is known). The proof of identity may be through providing real-world credentials, such as a driver's license, through personal recognition by a staff member, through providing secret information (such as a password), through biometric identification, or through any other means. In other embodiments, the proof of identity may be through, for example, an interview in a teleconference, presentation of a third-party affidavit, a government order, or the like, without limitation. In embodiments, the service provider 300 identifies 1410, based on records maintained by the service provider 300, account information 50 of the account owned or controlled by the user. In embodiments, the service provider 300 that is the trusted identity restoring agent 471 i s trusted by the identity broker 400 due to a special service relationship that has been established in advance between the identity broker 400 and the service provi der 300 given the nature of the service provider 300 as a well-known and reputable financial institution, government agency, or the like. Conversely, in embodiments the owner of a digital identity 27 may provi de information in advance to the identity broker 400 indicating a service provider 300 selected by the owner of the digital identity 27 to act as the trusted identity restoring agent 471. In other embodiments, the service provider 300 may be a service provider that has rigorous identity verification protocols, established for the specific purpose of acting as a trusted identity restoring agent 471.

[00129] The service provider 300 sends 1420, to the identity restoring subsystem 470 of the identity broker 400, a request for recovery, including certificate information 30 of the certificate 20 of the service provider 300 and account informati on 50 of the user account. The i dentity broker 400 receives 1430 the request for recovery, and retrieves 1440, from the digital identity repository 430, the identifier of the digital identity 27 that is associated with the account information 50 at the service provider 300. The identity broker 400 issues 1450 an authorization token 22, as described above in relation to FIG. 11, and transfers 1455 the authorization token 22 to a client 200 on an electronic device 100 that is possessed by the user. Note that this transfer may either be direct or through the service provider 300, and, in embodiments, may be achieved manually, through a QR code, through an NFC, through an electronic communication, or the like. In embodiments, the client 200 uses 1460 this authorization token 22 in performing the processes described above in reference to FIG. 11 or FIG. 12 to regi ster the client 200 that has received the authorization token 22.

[00130JA process, in an embodiment, for using Shamir recovery to recover a digital identity 27 to which access has been lost will be explained next in reference to FIG. 15. As depicted in FIG. 15, prior to losing control of the digital identity 27, the user, through a client 200, selects 1500 a plurality of service providers 300, or a plurality of digital identities 27, to serve as identity restoration deputies 472. In embodiments this may be achieved through providing, to the identity restoring subsystem 470 of the identity broker 400, information designating a plurality of identity restoration deputies 472, in addition to a minimum deputy count value (critical count) 35, described below. In embodiments, this information may be certificate information 30 of the certificates 20 of each of the identity restoration deputies 472, obtained in the course of client-service provider interactions with those service providers 300 where the certificate information 30 of the certificates 20 may be stored, in the identity restoring sub system 470, together with the critical count that is the minimum deputy count value 35 and the certificate 20 of the client 200, as an identifier of the client 200. In other embodiments, the client 200 may issue, to each of the service providers 300 selected to serve as an identity restoration deputy 472, a Shamir restorati on deputy token 34 that the designated identity restoration deputy 472 is able to forward to the identity restoring subsystem 470 of the identity broker 400. In embodiments, the Shamir restoration deputy token 34 includes certificate information 30 of the certificate 20 of the client 200, along with a minimum deputy count value 35 that indicates a minimum deputy count, explained below. In such embodiments, the Shamir restoration deputy tokens 34 store an identifier of the client 200, have the effect of storing information indicating digital constructs 25 of the identity restoration deputies 472, and store the critical count that is the minimum deputy count value 35. Note that the number of service providers 300 designated as identity restoration deputies 472 must be no less than the minimum deputy count value 35.

[00131]Up on loss of access to his or her digital identity, the user proves 1510 hi s or her real-life identity to a plurality of the identity restoration deputies 472 in the same manner as was described for the digital identity recovery that was explained in reference to FIG. 14. The individual identity restoration deputies 472 provide 1520 information to the identity restoring subsystem 470 of the identity broker 400 that a digital identity 27 is to be restored to the user. In embodiments thi s may be through an identity restoration deputy 472 sending a Shamir restoration deputy token 34, including or together with account information 50 regarding the account of the user with the service provider 300 that is the identity restoration deputy 472, to the identity restoring sub system 470. In other embodiments wherein the identity restoring subsystem 470 has been informed, by the user in advance, of the identities of the identity restoration deputies 472, the identity restoration deputies 472 merely provide information of the respective certificates 20, thereof, along with account information 50 for the respective accounts owned by the digital identity 27 of the user.

[00132]Upon receipt of the information, from each identity restoration deputy, that the digital identity 27 is to be restored, the identity restoring subsystem 470 validates 1530 the information that has been received. In embodiments, this may be through validation of the Shamir restoration deputy token 34, while in other embodiments thi s may be through comparing the received certificate information 30 of the certificate 20 of the service provider 300 to the certificate information 30 of the certificates 20 that had been sent in advance to the identity restoring sub system 470 by the user. Upon validation of the information from the identity restoration deputy 472, the identity restoring subsystem 470 totals 1540 the number of identity restoration deputies 472 that have provided the information indicating that the digital identity 27 is to be restored. The identity restoring subsystem 470 compares 1545, to the minimum deputy count value 35, the number of identity restoration deputies 472 that have requested restoration. If the comparison is not equal, the process is terminated 1550. If this total number of identity restoration deputies 472 is equal to the previously stored minimum deputy count value 35, the identity restoring subsystem 470 determines that the digital identity 27 is to be restored, and accordingly issues 1555 an authorization token 22 that authorizes restoration of the digital identity 27.

[00133]In embodiments, the identity restoring subsystem 470 transfers 1560 the authorization token 22 to a client 200 on an electronic device 100 that is possessed by the user, in the same manner as was described in reference to FIG 14 In embodiments, the authorization token 22 may be sent directly to the client 200. The client 200 then uses 1570 this authorization token 22 in a regi stration process such as described above in reference to FIG. 11 or FIG. 12, to reregister the client 200 in the digital identity repository 430 of the identity broker 400, thereby restoring the digital identity 27 to the user, enabling the user to use the reregistered client 200 to then reregister the rest of the digital constructs 25 that are associated with that digital identity 27. [00134] The Shamir recovery process, as described above for an embodiment, allows greater security for the digital identity 27, given that a plurality of identity restoration deputies 472 is required in order to perform the restoration process. Because the identity restoration deputies 472 need not know of each other's existence, the possibility of fraudulent collusion between service providers 300 designated as identity restorati on deputi es 472 will be low.

[00135JA method for bequeathing accounts belonging to a first digital identity 27-1 to a second digital identity 27-2 in the event that the owner of the first digital identity 27-1 is deceased or otherwise unavailable will be described next in reference to FIG. 16. As depicted in FIG. 16, in embodiments the owner of a first digital identity 27-1 provides 1600, to the account transferring subsystem 460 of the identity broker 400, an advance directive 31. In embodiments, this advance directive 31 includes an heir, being a second digital identity 27-2, for each of some or all of the accounts owned by the first digital identity 27-1, associated with clients 200, owned by the first digital identity 27-1, at service providers 300. In embodiments, the heirs are each clients 200 that have accounts at the respective service providers 300. In embodiments the advance directive 31 also includes a transfer condition for triggering the designated accounts to be transferred to the clients 200 that are respective heirs, where, in embodiments, the transfer conditions in the advance directive 31 may be, for example, a certain period of inactivity of all of the digital constructs 25 belonging to the first digital identity 27-1. In other embodiments, the advance directive 31 may include conditions such as a trusted authority, such as a service provider 300 that is controlled by an attorney having proper power of attorney contacting the identity broker 400 to declare, as permanently unavailable, the first digital identity 27-1 that is the owner of an account at the service provider 300. In other embodiments, the transfer condition in the advance directive 31 may be that a cryptographic certificate associated with the first digital identity 27-1 has expired, while in other embodiments the transfer condition may be the use of a token that is held by, for example, an attorney, with proper power of attorney, who has been retained by the user that owns the first digital identity 27-1.

[00136]In embodiments, the account transferring subsystem 460 monitors 1610 the state of sati sfaction of the transfer condition in the advance directive 31. In embodiments, thi s may be through the inactivity tracker 465 in the account transferring subsystem 460 monitoring and recording the time that has elapsed since the most recent interaction between a client 200 belonging to the first digital identity 27-1 and a service provider 300, where, in embodiments, the interactions can be identified through a service provider 300 sending certificate information 30 of a certificate 20, associated with the first digital identity 27-1 , to the digital identity information receiver 410 of the identity broker 400 in the course of business of a client 200 of the first digital identity 27-1 requesting a connection with the applicable service provider 300. In other embodiments, this monitoring may be in the form of monitoring whether or not the service provider 300 of the trusted authority, as an account transfer requester 490, has requested execution of the advance directive 31 .

[00137]Upon satisfaction of the transferring conditions in the advance directive 31, the account transferring sub system 460 transfers 1620 the accounts associated with the designated clients 200-1, belonging to the first digital identity 27-1 , to the clients 200-2 of the respective heirs in the advance directive 31. In embodiments this is achieved through a procedure similar to that which was described above in reference to FIG. 13, where the account transferring subsystem 460 generates transfer tokens 26, as described above, and provides them to the respective service providers 300, based on the advance directive 31. In embodiments, the service providers 300 provide the transfer tokens 26 to the respective second clients 200-2, and the second clients 200-2 send the transfer tokens 26, along with certificate information 30-2 of their respective certificates 20-2, to the broker-side digital identity registrar 420 of the identity broker 400. The broker-side digital identity registrar 420 receives the transfer tokens 26 along with certificate information 30-2 of the certificates 20-2, as has been described above in reference to FIG. 13. In embodiments, the broker-side digital identity registrar 420 updates, in the digital identity repository 430, information that links the certificates 20-2 of the second clients 200-2 to the applicable accounts of the service providers 300, and removes, from the digital identity repository 430, information that links the certificates 20-1 to the applicable accounts of the service provider 300. This process enables some or all of the accounts belonging to a first digital identity 27-1 to be transferred to the control of other digital identities if the first digital identity 27-1 becomes unavailable through death, incapacitation, or the like. In embodiments, multiple accounts between identical service providers 300 and identical second clients 200-2 may or may not be combined.

[00138JA procedure for reporting malicious or civil behavior by a client 200 or a service provider 300, to encourage civil behavior through the impact of malicious or civil behavior on a reputational score will be described next in reference to FIG. 17. As depicted in FIG. 17, a first digital construct 25-1 (a client 200 or a service provider 300) detects 1700 malicious or civil behavior by a second digital construct 25-2 during the course of clientservice provider interactions through a behavior detecting sub system 320 of a service provider 300, as depicted in FIG. 5, or a behavior detecting subsystem 230 of a client 200, as depicted in FIG. 9, detecting behaviors the other digital construct 25-2. The behavior detecting subsystem 320 sends 1710, to the digital identity information receiver 410, depicted in FIG. 4, of the identity broker 400, a client behavior report 432 together with certificate information 30 of the certificate 20 that had been presented, during handshaking, by that client 200, or the behavior detecting subsystem 230 sends, to the digital identity information receiver 410, a service provider behavior report 434 together with certificate information 30 of the certificate 20 that had been presented, during handshaking, by that service provider 300. In embodiments, the contents of the client behavior report 432 and of the service provider behavior report 434 may be as described above in relation to FIG. 5 and FIG. 9, respectively. In embodiments, the contents of the respective reports include both reports on the behaviors of the opposite digital constructs 25, but also identifying information (certificate information 30 of the certificates 20) for both the reporting digital constructs 25 and the digital construct 25 that i s being reported. In embodiments, the digital identity information receiver 410 receives 1720 the client behavior report 432 or service provider behavior report 434, and uses the certificate information 30 of the certificate 20 to retrieve 1730, from the digital identity repository 430, information identifying the digital identity 27 associated with the certificate information 30 of the certificate 20 that has been received.

[00139] The digital identity information processor 440 retrieves 1740, from the digital identity repository 430, previously reported or processed reputation information 40, and performs 1750 processing to combine the newly received information with the previously reported or processed reputation information 40. In embodiments thi s processing may include appending the newly received client behavior report 432 or service provider behavior report 434 to the existing reputation information 40, quantifying, into a behavioral score, the content of the newly received reports and then mathematically combining with quantitative reputation information 40 through performing weighted averaging, or the like, or any other procedure, without limitation, for combining the newly received information with the previously stored information. In embodiments, the digital identity information processor 440 then stores 1760 the updated reputation information 40 in the digital identity repository 430. This enables the updated reputation information 40 to be retrieved when a service provider 300 sends a query, to the digital i dentity information receiver 410 of the identity broker 400, regarding the reputation of a client 200 that has requested a connection. In embodiments, publicly available information may al so be included in the reputation information 40. The process described above in reference to FIG. 17 enables information from a plurality of digital constructs 25 (clients 200 and service providers 300) that interact with a plurality of different clients 200 and service providers 300 that are all related to a given digital identity 27 to be aggregated and reported, without the clients 200 and service providers 300 being aware of the digital identity 27. Reporting of reputation informati on 40 in thi s way not only enables cli ents 200 and service providers 300 to access information that can be used to evaluate the risk of interactions with an unknown actor, thereby increasing security of an electronic interaction system, but also discourages malicious behavior while encouraging civil behavior, thereby creating a more civil, safe, and trustworthy society in cyberspace. Thus the identity broker 400 i s provided with a civil behavior enforcing subsystem, comprising the digital identity information receiver 410, the digital identity repository 430, the digital identity information processor 440, and the digital identity information sender 450, which acts to enforce civil behavior by clients 200 and service providers 300. The clients 200 and service providers 300 that provide reports of behavior of digital constructs 25 being unaware of the digital identities 27 of the subj ects of the reports prevents fake or bias reporting.

[00140JA process for verifying personal information while maintaining anonymity, according to an embodiment, will be described next in reference to FIG. 18. As depicted in FIG. 18, a client 200 sends 1800, to a second service provider 300-2, the certificate 20 of the client 200, and requests, from the second service provider 300-2, a service that requires verification of personal information relating to the real-life owner of the client 200. In embodiments, this verification might be, for example, that the owner is of at least a certain age, or of a specific sex, race, income level, political group membership, political donor status, nationality or citizenship, employment status, self-employment status, or whether or not the owner has a criminal record, or felony conviction or is a sex offender, or lives within a specific geographic area, is of a given voter registration status, possesses a driver's license or another specific license or professional credential, is a college graduate or has graduated from a specific institution or holds a specific degree, has a credit rating above or below a specific level, has had a credit card for at least a prescribed amount of time, meets a minimum income requirement, has health insurance, has received the COVID- 19 vaccination, has a specific di sability, takes specific medications (such as antidepressants or antipsychotics), has a specific medical history, is married, has children, is a homeowner, has consented to data collection or terms and conditions of specific services, has consent of a parent or guardian, has an active automobile and/work health insurance policy, has been found at fault in an automobile accident within a specific time period, or the like.

[00141] The second service provider 300-2, upon receipt of the certificate 20 and the request for services, sends 1810, to a personal information query receiving subsystem 370 of a first service provider 300-1, as described above in reference to FIG. 8, certificate information 30 of the certificate 20. The certificate information 30 of the certificate 20 may be information extracted from the certificate 20, such as the serial number of the certificate 20. The second service provider 300-2 also sends a personal information query criterion 372 to the personal information query receiving subsystem 370. In embodiments this personal information query criterion 372 may be a single criterion, or a logical combination of multiple criteria, relating to, for example, any of the personal information listed above, in a form that can be answered with a yes/no answer. For example, the personal information query criterion 372 may be equivalent to, for example, "is the owner of the digital identity 27 associated with the client 200 a homeowner under the age of 35?" or "is the owner of the digital identity 27 associated with the client 200 over the age of 21." In embodiments, the personal information query receiving subsystem 370 evaluates 1820 whether or not the personal informati on query criterion 372 that has been received i s appropriate where, in embodiments, thi s may be based on policies of the first service provider 300-1 , on contractual relationships between the first service provider 300-1 and the second service provider 300-2, on legal considerations depending on local regulations, on past history of interactions with the second service provider 300-2 or reputation information 40 of the second service provider 300-2, or the like, without limitation. If the personal information query criterion 372 i s inappropriate, the personal information query receiving subsystem 370 refuses 1825 the query, and the anonymous personal informati on verification process is terminated.

[00142] The personal information query receiving subsystem 370, having received an appropriate personal information query criterion 372 along with certificate information 30 of the certificate 20 of the client 200 sends 1830, in embodiments, an account identification query 373 to the identity broker 400. In embodiments, this is done through sending certificate information 30 of the certificates 20 of both the client 200 and of the first service provider 300-1. The identity broker 400, having received the account identification query 373, which includes identifying information for the clients 200, from the certificate 20 thereof, and identifying information for the first service provider 300-1, from the certificate 20 thereof, retrieves 1840, from the digital identity repository 430, account information 50 for identifying the account of the client 200 with the first service provider 300-1. In embodiments, the identity broker 400 sends 1850 the account information 50 to the personal information query receiving subsystem 370 of the first service provider 300-1. In embodiments, the personal information query receiving subsystem 370 forwards 1860 the account information 50 to the personal information verification subsystem 375.

[00143]Note that, in embodiments, the first service provider 300-1 i s a service provider that is granted, by the client 200, personal information of the owner of the client 200 in the course of providing services to the client 200. For example, in embodiments the first service provider 300-1 may be a financial institution that has access to credit scores, income levels, homeownership data, residence information, age, or the like. In other embodiments, the first service provider 300-1 may be a governmental institution or law enforcement agency, with access to a variety of personal information, or a credit reporting agency that has, based on information provided thereto by the owner of the client 200, accessed third-party information databases to gather further information regarding the owner of the client 200. Thus in embodiments the first servi ce provider 300-1 may be in possession of a rich set of personal informati on pertaining to the owner of the client 200. In embodiments, the personal information verification subsystem 375 retrieves 1870, from the personal information storing subsystem 365 that i s depicted in FIG. 8, the personal information that is required in order to verify whether or not the personal information query criterion 372 i s sati sfied. The personal information verification subsystem 375, upon receiving the necessary personal information, compares 1880 the received personal information to the personal information query criterion 372, to verify whether or not the personal information satisfies the personal information query criterion 372, where the verification result is returned, by a verification result sending subsystem 380 to the second service provider 300-2. The second service provider 300-2 may then determine, based on the verification result, whether or not to provide a service to the client 200, or may determine constraints or limitations to place on a service that is provided to the client 200.

[00144]Note that in the process for verifying personal information as illustrated in FIG. 18, the identity broker 400 remains agnostic as to all personal information relating to the client 200, knowing only that the client 200 has an account with the first service provider 300-2, without knowing the nature of that account. The second service provider 300-2 remains unaware of all personal information of the client 200 (including the identity of the client 200), except for the anonymous yes/no information returned in response to the personal information query criterion 372. The first service provider 300-1 also remains uninformed as to the specific services provided to the client 200 by the second service provider 300-2. Thi s enables deep privacy for the client 200 when receiving services from the second service provider 300-2.

EFFECTS OF THE INVENTION

[00145] The secure electronic interaction system set forth in the embodiments described above, compri sing at least one identity broker 400 configured such as described in the embodiments, a plurality of clients 200 configured such as described in the embodiments, and a plurality of service provi ders 300 configured such as described in the embodiments, each resident on an electronic device 100 configured such as described in the embodiments, enables extremely private and secure interactions between clients and service providers, with greatly reduced vulnerability to a variety of malicious attacks. Thus the present invention, such as set forth in the foregoing embodiments, is anticipated to have great value when applied in industry.

[00146]It should be noted that while aspects of the present invention include an electronic device, an identity broker, a client, and a service provider, optimal effects in the secure electronic interaction system of the present disclosure are achieved only through a synergistic combination of these elements. Hence it i s to be understood that the unique interactions enabled by these synergistic combinations constitute a single general inventive concept shared by all of these elements, where the modes of secure authentication afforded by the combination of all of these elements, particularly in the interaction of all elements with the identity broker set forth above, constitutes a special technical feature that contributes to the novelty and inventive step that sets this electronic interaction system apart from the prior art, where the presence of this special technical feature across multiple claims indicates unity of invention.

[00147] The foregoing description of the embodiments of the invention has been presented for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise form disclosed. Many modifications and variations are possible in light of this disclosure. It is intended that the scope of the invention be limited not by this detailed description, but rather by the claims appended hereto.

[00148] Although terms such as “first” and “second” are used herein to describe various features or elements, the features or elements are not to be limited by these terms unless the context explicitly indicates otherwise. These terms are used merely to distinguish one feature or element from another. Therefore, a "first" feature or element described herein could be referred to instead as a " second" feature or element, and vice versa, without departing from the teachings of the present disclosure. Additionally, the presence of a feature or element termed “second” does not necessarily imply the exi stence of a “first” feature or element in that embodiment or claim. Unless an ordinal relationship is explicitly stated, terms such as “first” and “second” are to be interpreted as mere arbitrary nominal identifiers with no implications regarding sequence or quantity.

[00149]In the foregoing description, certain terms have been used for brevity, clearness, and understanding. No unnecessary limitations are to be implied therefrom, as such terms are used for descriptive purposes and are intended to be broadly construed.

[00150]Moreover, the descriptions and illustration of various embodiments of the disclosure are examples and the disclosure is not limited to the exact details shown or described.

[00151]As used herein in the specification and in the claims, references to receiving a signal, or the like, should be understood to mean receiving that signal, or the like, either directly or indirectly.

[00152] The components, elements, and processes described throughout this specifi cation are intended to be illustrative and not restrictive. Unl ess explicitly stated otherwise, each of these elements may be implemented in hardware, software, or firmware, alone or in any combination thereof. The specific structure of the elements may vary based on implementation requirements or technological advancements.

[00153]It is understood that the embodiments and examples described herein are not intended to limit the disclosure, and the various components and functions can be recombined, modified, substituted or omitted without departing from the scope of the disclosure. The elements in different embodiments may be arranged or integrated in different ways, and may operate independently or in conjunction with one another to perform the desired functionality. [00154]Furthermore, the flow charts and process steps illustrated and described in this specification are presented as exemplary methods of operation. Unless a specific temporal order is required for the functionality to be achieved, the illustrated steps and actions can be performed in any logical sequence or reordered, combined, or omitted as necessary. The scope of the disclosure includes any practical sequence or arrangement of steps that achieves the functionality described, except where explicitly stated that a particular sequence is necessary .

Claims

CLAIMS What is claimed is :

1. An electronic device, comprising: a digital identity manager configured to issue, or to request from an external certificate authority, a certificate linked to a digital identity; and a connection interface configured to connect to a digital construct through handshaking authentication using the certificate without requiring an input from a user or the provision of secret information when establi shing the connection, wherein : the certificate includes information identifying an identity broker that has information for linking the certificate to the digital identity.

2. An electronic device of claim 1 , wherein: the external certificate authority i s the identity broker.

3. An electronic device of claim 1 or 2, further comprising: a user authenticating subsystem for authenticating a user through a biometric input, input of secret information, and/or possession of a prescribed physical obj ect.

4. An identity broker, comprising: a digital identity information receiver configured to receive, from a service provider, information associated with a client, together with information of a certificate associated with the client, sent by the service provider; a broker-side digital identity registrar configured to receive, from a client or a third-party certificate issuing authority, information of a certificate of a client that is to be registered; a digital identity repository configured to store information of the certificate, inputted or processed information associated with a client identified by a certificate, and information relating to the digital identity linked to that certificate; a digital i dentity information processor configured to process stored information associated with a digital identity that is linked to a client identified by information of a certificate; and a digital identity information sender configured to send, to a service provider, at least a subset of the stored information associated with a digital identity that is linked to a received certificate.

5. An identity broker of claim 4, wherein: the stored information associated with a digital identity includes information for controlling a relationship between the client and the service provider.

6. An identity broker of claim 4 or 5, further comprising: an account transferring subsystem configured to: receive a digital identity transfer request including information indicating a first client, information indicating a second client, and information indicating an account; and modify, so as to link to the second client instead, information that links the account to the first client.

7. An identity broker of any of claims 4 through 6, further compri sing : an account bequeathing subsystem configured to: receive an account bequeathing advance directive including a first digital identity and a second digital identity; and modify information that links an account, and certificates linked thereto, to the first digital identity, doing so for all of the accounts that are linked to the first digital identity, so as to be linked instead to the second digital identity, in accordance with the digital construct bequeathing advance directive.

8. The identity broker of claim 7, wherein: the account bequeathing subsystem comprises an inactivity tracker to track a period of inactivity relating to a digital construct linked to the first digital identity; and the account bequeathing subsystem i s further configured to modify the information that links the accounts when a predefined period of inactivity for all digital constructs that are linked to the first digital identity has elapsed.

9. An identity broker of claim 7 or 8, wherein: the digital construct bequeathing subsystem is further configured to modify the information that links the accounts when a cryptographic certificate associated with the first digital identity has expired, or when a token is used.

10. An identity broker of any of claims 4 through 9, wherein: the digital identity information processor is configured to aggregate information from a plurality of digital constructs associated with a given digital identity to produce reputation data of the digital identity; and the digital identity information sender is configured also to send, to a service provider, the reputation data of the digital identity.

11. The identity broker of claim 10, further comprising: a civil behavior enforcing subsystem configured to cause the reputation data of the digital identity, sent to the service provider, to indicate that a client is linked to a digital identity associated with malicious behavior or civil behavior.

12. A service provider, comprising: a connection request receiver configured to receive, from a client, a certificate; a query sender configured to send, to an identity broker, a query based on a received certificate; a query response receiver configured to receive, from the identity broker, a response to the sent query; a policy compliance evaluator configured to evaluate whether or not to allow a connection, based on the received query response; and a connection interface confi gured to establi sh a connecti on to the cli ent through handshaking authentication using the certificate, based on the evaluation response by the policy compliance evaluator.

13. The service provider of claim 12, comprising: a service processor, configured to exchange information with the client to perform a service for a client; and a service selector configured to select, based on account information included in the received query response, services to be provided by the service provider through the established connection.

14. A service provider of claim 12 or 13 , further comprising: a certificate evaluator configured to evaluate the integrity, expiry, and/or validity of the certificate.

15. A service provider of any of claims 12 through 14, further comprising: a registering subsystem configured to perform the following in response to the received query response and in response to information from a second digital construct that is unregistered in an identity broker: receive a token from a first digital construct; issue a certificate to the unregistered second digital construct; and send, to the identity broker, information of the issued certificate.

16. A service provider of any of claims 12 through 15, further comprising: a Shamir recovery subsystem configured to: receive, from a client, information indicating a plurality of designated restorati on deputy digital constructs or deputy digital identities, a critical count, and an identifier of the client, and to store the information, the critical count, and the identifier of the client; receive a restoration request from a deputy digital construct or a digital construct associated with a deputy digital identity; count a number of requests from designated restoration deputy digital constructs or digital identities through associated digital constructs; compare the number of requests to the critical count; and i ssue a certificate to the cli ent in response to the number of requests being at least equal to the critical count.

17. A service provider of any of claims 12 through 16, further comprising: a behavior detecting subsystem configured to detect behavior of a client in respect to the service provider and to send, to an identity broker, a client behavior report together with certificate information of the client that has engaged in the behavior.

18. A service provider of any of claims 12 through 17, further comprising: a personal information storing subsystem for storing personal information collected in the course of providing services, in association with a client linked to a certificate; a personal information query receiving subsystem for receiving a personal information query with a query condition regarding personal information associated with a query subj ect client, together with information of a certificate for identifying the query subj ect client; a personal information verifying subsystem for comparing, with a received query condition, the stored personal information associated with the query subj ect client, to produce an anonymized verification response related thereto; and a personal information verification result sending subsystem for returning the anonymized verification response to the source of the personal information query.

19. A client, comprising: a certificate storage for storing a certificate issued or requested by a digital identity manager; wherein the certificate stored in the certificate storage is associated with the same digital identity as a digital identity associated with a certificate stored in a certificate storage of a client in another electronic device owned by the identical owner.

20. The client of claim 19, further comprising : a behavior detecting subsystem configured to detect behavior of a service provider in respect to the client; and a behavior reporting subsystem configured to send, to an identity broker, a service provider behavior report, together with certificate information of the service provider that engaged in the behavior.

21. A secure electronic interaction system comprising: an identity broker; a service provider; and a client comprising a certificate that is linked to a digital identity, wherein: when the client is to request a service from the service provider, a connection is established between the client and the service provider through : the client sending a certificate to the service provider; the service provider receiving the certificate and extracting an identity of an identity broker therefrom; the service provider sending information of the certificate to the identity broker; the identity broker using the information of the certificate to access information about a digital identity that is linked to the client through the certificate; the identity broker sending, to the service provider, information regarding the digital identity that is linked to the client; the service provider using the received information to determine whether or not to allow a connection with the client; and the service provider establishing a connection with the client upon a positive determination.

22. A method for establishing a secure connection between a client and a digital construct, comprising: issuing or requesting, by a digital identity manager, a certificate linked to a digital identity from an external certificate authority; connecting, by a connection interface, the cli ent to the digital construct through handshaking authentication using the certificate, without requiring user input or secret information at the time of connecting wherein: the certificate includes information identifying an identity broker that has information linking the certificate to the digital identity .

23. The method of claim 22, wherein the external certificate authority is the identity broker.

24. A method of claim 22 or 23, further comprising: authenticating a user through a biometric input, input of secret informati on, and/or possession of a prescribed physical obj ect.

25. An identity brokering method in an identity broker, comprising: receiving, from a service provider, behavior information associated with a client, together with information of a certificate sent by the service provider to identify that client; storing inputted or processed behavior information associated with a client identified by the information of the certificate, and information relating to the digital identity linked to that certificate; processing stored information associated with a digital identity that is linked to a client identified by a certificate; and sending, to a service provider, at least a subset of the stored information associated with a digital identity that is linked to a received certificate.

26. The method of claim 25, further comprising: receiving, from a client or a third-party certificate issuing authority, certificate information of a client that is to be registered.

27. A method of claim 25 or 26, wherein: the stored information associated with a digital identity includes information for controlling a relationship between the client and the service provider.

28. A method of any of claims 25 through 27, further comprising: receiving a digital identity transfer request including information indicating a first client, a second client, and an account; and modifying the information linking the account to the first client so that it links to the second client.

29. A method of any of claims 25 through 28, further comprising: receiving an account bequeathing advance directive including a first digital identity and a second digital identity; and modifying information linking an account, and certificates linked thereto, to the first digital identity, doing so for all of the accounts that are linked to the first digital identity, so as to be linked instead to the second digital identity, in accordance with the digital construct bequeathing advance directive.

30. The method of claim 29, further comprising: tracking a period of inactivity related to a digital construct linked to the first digital identity; and modifying the information linking the accounts when a predefined period of inactivity for all digital constructs linked to the first digital identity has elapsed.

31. A method of claim 29 or 30, further comprising: modifying the information linking the accounts when a cryptographic certificate associated with the first digital identity has expired, or when a token is used.

32. A method of any of claims 25 through 3 1 , further comprising: aggregating information from multiple digital constructs associated with a digital identity to produce reputation data; and sending the reputation data to a service provider.

33. A method of any of claims 25 through 32, further comprising: causing the reputation data to indicate to the service provider whether a client is linked to a digital identity associated with malicious or civil behavior.

34. A method for establishing a connection by a service provider, comprising : receiving a certificate from a cli ent; sending a query to an identity broker based on the certificate; receiving a response to the query from the identity broker; evaluating, based on the response, compliance with a policy; and establishing a connection with the client using the certificate if the evaluation is positive.

35. The method of claim 34, further comprising: selecting services to be provided based on account information in the query response; and exchanging information with the client to perform a service.

36. A method of claim 34 or 35, further comprising: evaluating the integrity, expiry, and/or validity of the certificate.

37. A method of any of claims 34 through 36, further comprising, in response to the query response and information from an unregistered second digital construct, receiving a token from a first digital construct; issuing a certificate to the unregistered second digital construct; and sending information of the issued certificate to the identity broker.

38. A method of any of claims 34 through 37, further comprising: receiving, from a client, information indicating designated restoration deputies, a critical count, and a client identifier; receiving a restorati on request from a deputy digital construct or associated digital identity; counting restoration requests from designated deputies; comparing the number of restoration requests to the critical count; and issuing a certificate to the client if the number of restoration requests is equal to the critical count.

39. A method of any of claims 34 through 38, further comprising: detecting client behavior with respect to the service provider; and sendi ng a cli ent behavior report and certifi cate information of the client to an identity broker.

40. A method of any of claims 34 through 39, further comprising: storing personal information collected during service provision, linked to a client certificate; receiving a query with a condition regarding personal information associated with the client, along with certificate information; verifying the stored personal information against the query condition to produce an anonymized response; and sending the anonymized response to the query source.

41. A method for establi shing secure communications in an electronic device, comprising: storing a certificate i ssued or requested by a digital identity manager, wherein: the stored certificate is associated with the same digital identity as a certificate stored in another device owned by the identical owner.

42. A method for establishing secure communications in a client comprising: detecting behavior of a service provider in respect to the client; and sending a service provider behavior report, along with the service provider’ s certificate information, to an identity broker.

43. A method for secure electronic interaction involving a client, service provider, and identity broker, comprising: the client sending a certificate to the service provider; the service provider receiving the certificate and extracting an identity of an identity broke; the service provider sending certificate information to the identity broker; the identity broker accessing information about a digital identity linked to the client through the certificate; the identity broker sending information about the digital identity to the service provider; the service provider determining whether to allow a connection based on the received information; and the service provider establishing a connection with the client upon a positive determination.