Patent Description:
Many security threats rely on deceiving users into believing they are accessing data provided by a trusted source. In reality, the user often finds that the data itself is or includes malware. Other times, accessing the data triggers the installation of malware on the computing device of the user.

For example, a common security threat is known as phishing, whereby a malicious actor (the "phisher") creates a fake website that is visually indistinguishable from a valid website. When individuals visit the fake website, their data may be harvested or malware may be loaded onto their browser in an attempt to exploit their computer. To guide targets to visit the fake website, the phisher may create links with network addresses that are similar to or appear to be related to network addresses for the valid website.

As a similar example, another common security threat is the distribution of files that contain malware. The malware files may be disguised as legitimate files that a user would normally open, interact with, or consume, such as a spreadsheet, presentation, report, audio file, image file, or video file. The files may also be disguised or presented as being authored or created by a trusted entity. As a result, a user could be tricked into opening a file that he or she believes is a harmless file originating from a trusted source, when in reality the user is causing malware to be loaded onto his or her computer.

<CIT> discloses a system for utilizing distributed ledger technologies, such as a blockchain data structure residing on a distributed ledger. A client may use this blockchain data structure to register the client's personal information in a data object that then may be routed to specific identified trusted individuals who verify that the information in the data object is correct. Once verification is complete, the client or other trusted individuals may use the data object as necessary to register the client for various programs or services, such as additional bank services.

<CIT> discloses a authentication system integrating blockchain technologies, independent verification, a decentralized certificate authority system implemented in the cloud, and a centralized redundant database system that together form data portability systems and data longevity systems that enable the creating of integrated lifetime health records that can be accessed by the patient, provider, and payer using public/private keys.

Aspects of the present invention are defined by the independent claims below to which reference should now be made. Optional features are defined by the dependent claims.

Various embodiments of the present disclosure include a system, comprising: a computing device comprising a processor and a memory; and machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least: generate an identity key for a data item; send a request for authentication of the data item to a security service, the request comprising the identity key and the data item; receive a verified claim for the data item from the security service; generate an identity document, the identity document comprising the identity key for the data item and the verified claim; and store the identity document in a distributed ledger. In some implementations of the system, the machine-readable instructions, when executed by the computing device, further cause the computing device to at least: receive a request for the data item; and send a response to the request, the response comprising the data item and the identity key. In some implementations of the system, the identity key is a second identity key; the identity document is a second identity document; the request for authentication of the data item is a second request for authentication; and the machine-readable instructions further cause the computing device to at least: send request for authentication of the identity of an operator of the machine-readable instructions to the authentication service; receive a first identity key and a verified claim from the authentication service; create a first identity document, the identity document comprising the identity key and the verified claim; and store the first identity document in a distributed ledger; and the second request for authentication of the data item is sent subsequent to the first identity document being stored in the distributed ledger. In some implementations of the system, the machine-readable instructions, when executed by the processor, further cause the computing device to at least: generate an asymmetric key-pair uniquely associated with the data item; and wherein the identity document further comprises a public key of the asymmetric key-pair. In some implementations of the system, the machine-readable instructions, when executed by the processor, further cause the computing device to at least: receive a validation request that comprises an encrypted token encrypted with the public key; decrypt the encrypted token using a private key of the asymmetric key-pair to generated an unencrypted token; create a cryptographic signature of the unencrypted token using the private key; and provide a validation response that comprises the unencrypted token and the cryptographic signature. In some implementations of the system, the data item is a network address. In some implementations of the system, the data item is a file.

Many aspects of the present disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, with emphasis instead being placed upon clearly illustrating the principles of the disclosure.

Disclosed are various approaches for authenticating data or content or verifying the identity of content authors, originators, or distributors. Documents used to verify data or content can be stored in a decentralized manner. Decentralization protects against a single point of failure in the authentication or verification process. For example, if a certificate authority suffered a security breach or became inaccessible, authentication approaches that relied on a certificate authority to verify a certificate associated with content or data would fail until the certificate authority were secured or became accessible again. In contrast, a decentralized approach to authentication data or content or verifying the identity of content authors, originators, or distributors is more resilient and is unlikely to become unavailable in various situations. Moreover, decentralized approaches prevent a single entity, such as an operator of a certificate authority, from monopolizing or controlling the process of authenticating data or content or verifying the identity of content authors, originators, or distributors. In the following discussion, a general description of the system and its components is provided, followed by a discussion of the operation of the same.

As illustrated in <FIG>, shown is a network environment <NUM> according to various embodiments. The network environment <NUM> includes a computing environment <NUM>, a client device <NUM>, an identity hub <NUM>, and a distributed ledger <NUM>, which are in data communication with each other via a network <NUM>. The network <NUM> includes wide area networks (WANs) and local area networks (LANs). These networks can include wired or wireless components or a combination thereof. Wired networks can include Ethernet networks, cable networks, fiber optic networks, and telephone networks such as dial-up, digital subscriber line (DSL), and integrated services digital network (ISDN) networks. Wireless networks can include cellular networks, satellite networks, Institute of Electrical and Electronic Engineers (IEEE) <NUM> wireless networks (i.e., WI-FI®), BLUETOOTH® networks, microwave transmission networks, as well as other networks relying on radio broadcasts. The network <NUM> can also include a combination of two or more networks <NUM>. Examples of networks <NUM> can include the Internet, intranets, extranets, virtual private networks (VPNs), and similar networks.

The computing environment <NUM> can include a server computer or any other system providing computing capability. Alternatively, the computing environment <NUM> can employ a plurality of computing devices that can be arranged in one or more server banks or computer banks or other arrangements. Such computing devices can be located in a single installation or can be distributed among many different geographical locations. For example, the computing environment <NUM> can include a plurality of computing devices that together can include a hosted computing resource, a grid computing resource or any other distributed computing arrangement. In some cases, the computing environment <NUM> can correspond to an elastic computing resource where the allotted capacity of processing, network, storage, or other computing-related resources can vary over time.

Various applications or other functionality can be executed in the computing environment <NUM> according to various embodiments. The components executed on the computing environment <NUM> include a hosted application <NUM>, a security service <NUM>, and other applications, services, processes, systems, engines, or functionality not discussed in detail herein. While the hosted application <NUM> and the security service <NUM> are depicted as operating in the same computing environment, it is understood that that the hosted application <NUM> and the security service <NUM> could be operated or executed in separate computing environments. Similarly, the hosted application <NUM> and the security service <NUM> could be operated and controlled by the same entity or by different entities, depending on the particular implementation.

The hosted application <NUM> can be executed to provide access to users to data stored in the hosted data store <NUM> or to perform one or more functions or initiate one or more transactions on behalf of a user. Examples of hosted applications <NUM> include web servers, mail servers, file servers, which may be used to provide for web-based applications such as electronic banking applications, electronic commerce or shopping applications, social media applications, internet or web-based electronic mail (webmail) applications, file-sharing applications or services, internet or web-based productivity applications (e.g., word-processors, spreadsheets, presentation applications, etc.), media streaming applications, etc. However, any application hosted by computing environment <NUM> which provides client devices <NUM> with content, access to content, or resolvable network addresses where data or content may be access can be considered a hosted application <NUM> for the purposes of the various embodiments of the present disclosure.

The authentication provider <NUM> can be executed to authenticate or verify the identity of a user or entity. This can include authenticating or otherwise verifying that a particular service, application, or device is operated or controlled by the user or entity. For example, the authentication provider <NUM> could be executed to determine that a website available at a particular network address (e.g., http://www. examplebank. com) is, in fact, operated by the company "ExampleBank.

The security service <NUM> can be executed to evaluate the security or authenticity of a resource. This can include, for example, verifying or certifying the authenticity of files, network addresses, or other data, as well as verifying or certifying the authenticity of the creator or provider of the files, network addresses or other data. For example, the security service <NUM> could be executed to evaluate whether a file was created or distributed by a particular person or organization. As another example, the security service <NUM> could be executed to evaluate whether a link or network address is actually for a resource under control of a particular entity. For instance, the security service <NUM> could determine whether a link for a banking website is actually a link to the real website of a bank or is instead a link to an impostor website. The security scanner <NUM> could also be executed to evaluate whether a file includes malware or whether a website available at a network address has security vulnerabilities. These evaluations can be performed automatically in response to receiving a file or network address or in response to a request received by another application.

Also, various data can be stored in a hosted data store <NUM> that is accessible to the computing environment <NUM>. The hosted data store <NUM> can be representative of a plurality of hosted data stores <NUM>, which can include relational databases, object-oriented databases, hierarchical databases, hash tables or similar key-value data stores, as well as other data storage applications or data structures. The data stored in the hosted data store <NUM> is associated with the operation of the various applications or functional entities described below. This data can include one or more authentication records <NUM> and one or more verification rules <NUM>.

An authentication record <NUM> can represent a relationship between an identity key <NUM> and a data item <NUM>. The relationship may be stored, for example, in order to use the identity key <NUM> to verify assertions about the data item <NUM> made based at least in part on one or more verification rules <NUM>.

An identity key <NUM> can represent a unique address that specifies the location where an identity document <NUM> can be found, such as a network address that specifies a network location of the identity document <NUM>. The identity key <NUM> can include the storage location where the identity document <NUM> can be found, a unique identifier of the identity document <NUM>, and potentially other information. As the identity key <NUM> can uniquely identity the identity document <NUM> with respect to other identity documents <NUM>, the identity key <NUM> can also be used as a unique identifier for an individual, entity, organization, or data item <NUM>. An illustrative example of an identity key <NUM> is a decentralized identifier (DID) as defined by the World Wide Web Consortium (W3C). However, data formats can be used as an identity key <NUM> in various embodiments of the present disclosure.

In the example of a DID, the identity key <NUM> can include a unique uniform resource identifier (URI) or unique uniform resource locator (URL) that specifies the type of identity key <NUM>, the specific distributed ledger <NUM> in which an identity document <NUM> can be located, and a identifier of the identity document <NUM>. For example, if an identity document <NUM> were stored using an implementation of the ETHEREUM protocol, an identity key <NUM> formatted as a DID has an example URL or URI schema of "did:ethereum:123456abcdefg. " This example identity key <NUM> could then be used as the key for retrieving the identity document <NUM> from the distributed ledger <NUM>.

A data item <NUM> can include any digital representation of data. For example, a data item <NUM> could be a file or a data stream. As another example, a data item <NUM> could be an address at which a file, application, or webpage is located (e.g., a URL, URI, or similar link or network address).

A verification rule <NUM> can represent a compliance rule or policy used as the basis for an assertion regarding a particular data item <NUM> or class of data items <NUM>. For example, a verification rule <NUM> may specify the requirements for making an assertion that a data item <NUM> is secure. This include a requirement that a website pass a security scan performed by the security service <NUM> or that a file be confirmed by the security service <NUM> to not include malware. As another example, a verification rule <NUM> may specify the requirements for making the assertion regarding the owner or creator of a data item <NUM>, such as the requirements for determining that a particular website owner is the originator of a particular link.

The client device <NUM> is representative of a plurality of client devices that can be coupled to the network <NUM>. The client device <NUM> can include a processor-based system such as a computer system. Such a computer system can be embodied in the form of a personal computer (e.g., a desktop computer, a laptop computer, or similar device), a mobile computing device (e.g., personal digital assistants, cellular telephones, smartphones, web pads, tablet computer systems, music players, portable game consoles, electronic book readers, and similar devices), media playback devices (e.g., media streaming devices, BluRay® players, digital video disc (DVD) players, set-top boxes, and similar devices), a videogame console, or other devices with like capability. The client device <NUM> can include one or more displays <NUM>, such as liquid crystal displays (LCDs), gas plasma-based flat panel displays, organic light emitting diode (OLED) displays, electrophoretic ink ("E-ink") displays, projectors, or other types of display devices. In some instances, the display <NUM> can be a component of the client device <NUM> or can be connected to the client device <NUM> through a wired or wireless connection.

The client device <NUM> can be configured to execute various applications such as a client application <NUM> or other applications. The client application <NUM> can be executed by the client device <NUM> to access network content served up by the computing environment <NUM> or other servers, thereby rendering a user interface <NUM> on the display <NUM>. To this end, the client application <NUM> can include a browser or a dedicated application (e.g., email applications, social networking applications, messaging applications, banking applications, shopping applications, etc.), and the user interface <NUM> can include a network page, an application screen, other user mechanism for obtaining user input.

The identity hub <NUM> can represent a service or collection of services hosted by one or more computing devices and utilized to securely store identity documentation for individual users and provide the identity documentation in response to authorized requests. For example, the identity hub <NUM> can include a credential manager <NUM> and a vault <NUM>. Although the identity hub <NUM> is depicted as separate from the computing environment <NUM> for clarity, it is understood that the functions of the identity hub <NUM>, including the vault manager <NUM> and the vault <NUM>, could be implemented within the computing environment <NUM>. Moreover, in some implementations, the identity hub <NUM>, including the vault manager <NUM> and the vault <NUM>, could be operated by the same entity or different entities, depending on the particular implementation.

The vault manager <NUM> can be executed to control access to the vault <NUM>. For example, the vault manager <NUM> can be used to add, remove, or modify various data stored in the vault <NUM>. As another example, the vault manager <NUM> can be used to authenticate individual users and limit access to the vault <NUM> to authorized users or entities.

The vault <NUM> represents a secure data store accessible to the credential manager <NUM>. Data stored in the vault <NUM> can be stored in an encrypted form that is accessible only to individual users or entities. An individual user or entity can store various types of data in the vault <NUM>, including one or more key records <NUM>. The key record <NUM> can be used to track an association or relationship between a particular identity key <NUM> and a respective key-pair <NUM>.

The key-pair <NUM> can represent an asymmetric cryptographic key-pair that includes a public key <NUM> and a private key <NUM>. The cryptographic keys in the key-pair <NUM> can be used by an entity or user to confirm or otherwise authenticate their relationship with or control over data associated with the identity key <NUM>, as described later. The key-pair <NUM> can be generated using various approaches, such as elliptic curve cryptography (ECC) approaches or using the Rivest-Shamir-Adleman (RSA) algorithm.

The distributed ledger <NUM> represents a synchronized, eventually consistent, data store spread across multiple nodes in different geographic or network locations. Each node in the distributed ledger <NUM> can contain a replicated copy of the distributed ledger <NUM>, including all data stored in the distributed ledger <NUM>. Records of transactions involving the distributed ledger <NUM> can be shared or replicated using a peer-to-peer network connecting the individual nodes that form the distributed ledger <NUM>. Once a transaction or record is recorded in the distributed ledger <NUM>, it can be replicated across the peer-to-peer network until the record is eventually recorded with all nodes. Various consensus methods can be used to ensure that data is written reliably to the distributed ledger <NUM>. Examples of a distributed ledger can include blockchains, distributed hash tables (DHTs), and similar data structures.

Various data can also be stored in a distributed ledger <NUM>. This can include one or more identity documents <NUM>. However, any other data discussed in the present disclosure could also be stored in the distributed ledger <NUM> if the public availability of the data were acceptable in that particular implementation.

An identity document <NUM> is a document that provides information for identifying and authenticating a user. An identity document <NUM> can include an identity key <NUM>, which can be used to uniquely identify the identity document <NUM> and, therefore, the individual or entity associated with the identity document <NUM>. An identity document <NUM> can also include a public key <NUM> from the asymmetric key-pair <NUM> associated with the identity key <NUM>, which can used by third-parties to verify the authenticity of the identity document <NUM>. The identity document <NUM> can also include one or more verified claims <NUM>. An illustrative example of an identity document <NUM> is a decentralized identifier document (DID Document) as defined by the W3C. However, data formats can be used as an identity document <NUM> in various embodiments of the present disclosure.

A verified claim <NUM> represents one or more verified assertions about a specific entity or data item <NUM> described by the identity document <NUM>. For example, the assertion could be that a data item <NUM> complies with one or more verification rules <NUM> (e.g., that a file does not include malware or that a link to a website is a valid link from the operator of the website). As another example, the assertion could be that a particular entity is who they claim to be or that the originator of content or author of a communication is who they purport to be. Accordingly, the verified claim <NUM> could include one or more claim <NUM> and respective signatures <NUM> for each claim <NUM>.

The claim <NUM> represents the assertion about an entity, individual, or data item <NUM>. For example, a claim <NUM> could state that a website located at a particular network address is considered secure according to the criteria set forth in one or more verification rules <NUM>. For instance, the claim <NUM> could specify that a website does not include any known security vulnerabilities or does not contain any known malware. As another example, the claim <NUM> could specify that a network address directing a user to a network service, such as a website or web application, is an authentic or valid network address provided by the operator of the website or web application. Similarly, the claim <NUM> could specify that a file does not contain malware or that the creator of the file is who they purport to be.

The signature <NUM> can include any cryptographic signature used to verify the veracity and authenticity of the claim <NUM>. For example, the signature <NUM> can identify the party making the assertion and also include both a digital signature generated by a private encryption key <NUM> in possession of the party entity and a digital fingerprint identifying the corresponding public encryption key <NUM> that can be used to verify the signature <NUM>. The signature <NUM> can also be used to determine whether the claim <NUM> has been modified without the consent of the entity making the claim <NUM>. For example, an unauthorized change to the claim <NUM> would result in a mismatch between the signature <NUM> and the claim <NUM>.

Next, a general description of the operation of the various components of the network environment <NUM> is provided. A more detailed description of the operation of individual components is provided in the discussion of <FIG>. Moreover, while the following description provides one example of the interactions between the various components depicted in the network environment <NUM> of <FIG>, they can be configured to operate in other manners, as discussed later.

To begin, the authentication provider <NUM> can first verify the identity of the hosted application <NUM>, which can include verifying the identity of the operator of the hosted application <NUM>. Accordingly, the hosted application <NUM> can either generate a key-pair <NUM> that will be used for authenticating the identity of the hosted application <NUM> or use a preexisting key-pair <NUM> previously created for that purpose. The hosted application <NUM> can also generate a new identify key <NUM> that can be used for authenticating or verifying the identity of the hosted application <NUM>.

Next, the hosted application <NUM> can send the identity key <NUM> to the authentication provider <NUM> and authentication information for the hosted application <NUM> to verify or authenticate its identity. These authentication credentials could include a username and password, cryptographic certificates, a public key <NUM> from a preexisting key-pair <NUM>, previously issued authentication tokens or cookies, biometric credentials, etc..

The authentication provider <NUM> can then authenticate the identity of the hosted application <NUM> using the authentication credentials. This could include verifying the username and password, issuing a cryptographic challenge using the certificate or public key <NUM> and verifying the cryptographic response, verifying the previously issued authentication tokens or cookies, etc. Once the identity of the hosted application <NUM> is verified, the authentication provider <NUM> can create a verified claim <NUM> containing a claim <NUM> asserting the identity of the operator of the hosted application <NUM> and a signature <NUM> for the claim <NUM>. The verified claim <NUM> can then be returned to the hosted application <NUM>, which can create and store an identity document <NUM> in the distributed ledger containing the verified claim <NUM>, the identity key <NUM>, and the public key <NUM> to be used by the hosted application <NUM> to prove its identity.

Subsequently, the hosted application <NUM> can request that the security service <NUM> validate a data item <NUM>, such as a file or a network address (e.g., a URL specifying a website or a web application). The validation could be to certify that the hosted application <NUM> is the originator for the data item <NUM> (e.g., the creator or distributor of a file or the host of a website or web application identified by a network address), or that the data item <NUM> is secure (e.g., that a file does not contain known malware or that a web site or web application located at a network address does not contain any known vulnerabilities). The request can include a newly generated key-pair <NUM> specific to the data item <NUM> and a newly created identity key <NUM> unique for the data item <NUM>, as well as the identity key <NUM> used to verify the identity of the hosted application <NUM> itself.

Upon receipt of the request from the hosted application <NUM>, the security service <NUM> can first verify the identity of the hosted application <NUM>. For instance, the security service <NUM> can retrieve from the distributed ledger <NUM> the identity document <NUM> that that contains the verified claim <NUM> regarding the identity of the hosted application <NUM> and the public key <NUM> to be used to verify the identity of the hosted application <NUM>. The security service <NUM> can then use the public key <NUM> to initiate a challenge-response exchange to verify the identity of the hosted application <NUM>. In some instances, the security service <NUM> may use a relay service or resolution service to determine which distributed ledger <NUM> contains the identity document <NUM> in those implementations where multiple distributed ledgers <NUM> are used. An example of such a relay service or resolution service is a DID Resolver, as defined by the W3C.

Once the identity of the hosted application <NUM> is verified, the security service <NUM> can then validate the data item <NUM>. For example, if the data item <NUM> is a network address (e.g., a URL) for a web site or web application, the security service <NUM> might first perform an automated threat assessment. The threat assessment could check for common web site misconfigurations or known server or application vulnerabilities. As another example, the security service <NUM> could verify that the network address was an authentic network address controlled by the operator of the web site or web application (e.g., instead of a network address pointing to a phishing site). If the data item <NUM> is a file, then the security service <NUM> might perform a malware scan to determine whether the file contains malware. As another example, the security service <NUM> could verify that the operator of the hosted application <NUM> is the creator or originator of the file. This could be done by verifying a cryptographic signature of the file created by the hosted application <NUM>.

After validating the data item <NUM>, the security service <NUM> can create one or more verified claims <NUM> related to the data item <NUM>. For example, the security service <NUM> could create a verified claim <NUM> that contains a first claim <NUM> that a network address is controlled by the operator of the hosted application <NUM> and a second claim <NUM> that the web site or web application available at the network address contains no known security vulnerabilities. The security service <NUM> could also create a first signature <NUM> for the first claim <NUM> and a second signature <NUM> for the second claim <NUM> and include these signatures in the verified claim <NUM>. However, the security service <NUM> could create multiple verified claims <NUM>, each verified claim <NUM> representing a single claim <NUM>. The security service <NUM> can then return the verified claim <NUM> for the data item <NUM> and, in some implementations, the identity key <NUM> associated with the data item <NUM>.

Once the hosted application <NUM> receives the verified claim <NUM>, it can create an identity document <NUM> that includes the identity key <NUM> associated with the data item <NUM>, the verified claim <NUM> provided by the security service <NUM>, and a public key <NUM> associated with the identity key <NUM>. The hosted application <NUM> can then store the identity document <NUM> in a distributed ledger <NUM>.

When the client application <NUM> requests a data item <NUM>, it can use the identity document <NUM> stored in the distributed ledger <NUM> to validate or otherwise verify the security or authenticity of the data item <NUM>. For example, if a browser requests a web page using a URL, the hosted application <NUM> may provide the identity key <NUM> related to the network address to the browser. The browser could then retrieve an identity document <NUM> for the URL, identify a verified claim <NUM> in the identity document <NUM> that includes a claim <NUM> that the URL is a valid network address for the web page provided by the hosted application <NUM>, and verify the claim <NUM> using the public key <NUM> and signature <NUM>. Similarly, the browser could identity a second claim <NUM> in the identity document <NUM> indicating that the web page has passed a recent security scan performed by the security service <NUM> and verify the claim <NUM> using the public key <NUM> and the signature <NUM>. If the data item <NUM> were a file, the client application <NUM> could use a similar process to verify the authorship and security of the file.

Referring next to <FIG>, shown is a sequence diagram that provides one example of the operation of the components of the network environment <NUM>. It is understood that the sequence diagram of <FIG> provides merely an example of the many different types of functional arrangements that can be employed to implement the operation of the depicted portion of the network environment <NUM>. As an alternative, the sequence diagram of <FIG> can be viewed as depicting an example of elements of a method implemented within the network environment <NUM>.

Beginning with step <NUM>, the hosted application <NUM> can generate both a key-pair <NUM> and an identity key <NUM> to be used for authenticating the identity of the hosted application <NUM> or the operator of the hosted application <NUM>. After generating the key-pair <NUM> and the identity key <NUM>, the hosted application <NUM> may store the key-pair <NUM> in the vault <NUM>. Accordingly, the hosted application <NUM> can send a request, which can include authentication credentials for the hosted application <NUM> and the identity key <NUM> and key-pair <NUM>, to the vault manager <NUM>. After verifying the authentication credentials, the vault manager <NUM> can create a key-record in the vault <NUM> that associates the identity key <NUM> with the key-pair <NUM>. Should the hosted application <NUM> require the private key <NUM> associated with the identity key <NUM>, it can request a copy of or access to the private key <NUM> from the vault manager <NUM>.

Then at step <NUM>, the hosted application <NUM> can send the key-pair <NUM> and the identity key <NUM> to the authentication provider <NUM> for verification. In some implementations, the hosted application <NUM> can also send authentication credential(s) to the authentication provider <NUM> to prove the identity of the hosted application <NUM> itself or the operators of the hosted application <NUM>.

Next at step <NUM>, the authentication provider <NUM> verifies the authentication credential(s) provided by the hosted application <NUM>. For example, the authentication provider <NUM> could verify that an authentication credential(s) provided by the hosted application <NUM>, such as a user name and password; preshared secret, token, or cookie; or other authentication credential provided by the hosted application <NUM> match the authentication credential(s) already on file with the authentication provider <NUM>.

Subsequently, at step <NUM>, the authentication provider <NUM> can create and return a verified claim <NUM> to the hosted application <NUM> if the authentication credentials are determined to be valid at step <NUM>. The verified claim <NUM> could include a claim <NUM> asserting that the authentication provider <NUM> has verified the identity of the hosted application <NUM> or the operator of the hosted application <NUM>, including that the identity key <NUM> provided by the hosted application <NUM> is controlled by the hosted application <NUM> or the operator of the hosted application <NUM>. The verified claim <NUM> could also include a respective signature <NUM> for each claim <NUM> included in the verified claim <NUM>. The signature <NUM> could be generated by the authentication provider <NUM> using a private key <NUM> controlled by the authentication provider <NUM>. As a result, third-parties could verify the claim <NUM> by comparing the signature <NUM> to the claim <NUM> using a respective public key <NUM> for the private key <NUM> controlled by the authentication provider <NUM>. If the signature <NUM> could not be verified using the public key <NUM> of the authentication provider <NUM>, this could indicate that the claim <NUM> has been altered without authorization or that the claim <NUM> was never made by the authentication provider <NUM>. The verified claim <NUM> is then returned to the hosted application <NUM>.

Next at step <NUM>, the hosted application <NUM> can create an identity document <NUM> which can allow other applications or third-parties to verify the identity of the hosted application <NUM> or the operator of the hosted application <NUM>. For example, the hosted application <NUM> can create an identity document <NUM> that includes the identity key <NUM> and the key-pair <NUM> created at step <NUM>, as well as the verified claim <NUM> created at step <NUM>. After creating the identity document <NUM>, the hosted application <NUM> can cause the identity document <NUM> to be stored in distributed ledger <NUM>.

Referring next to <FIG>, shown is a sequence diagram that provides another example of the operation of the components of the network environment <NUM>. It is understood that the sequence diagram of <FIG> provides merely an example of the many different types of functional arrangements that can be employed to implement the operation of the depicted portion of the network environment <NUM>. As an alternative, the sequence diagram of <FIG> can be viewed as depicting an example of elements of a method implemented within the network environment <NUM>.

Beginning with step <NUM>, the hosted application <NUM> creates a key-pair <NUM> and an identity key <NUM> for a respective data item <NUM> (e.g., a file, a network address or other type of data). The relationship between the identity key <NUM> and the data item <NUM> may also be recorded in the hosted data store <NUM> as an authentication record <NUM>, which can contain the identity key <NUM> and a copy of or identifier for the data item <NUM>.

Next at step <NUM>, the hosted application <NUM> can send a verification request to the security service <NUM>. The verification request can include the identity key <NUM> associated with the data item <NUM>, the data item <NUM> itself, and the identity key <NUM> that identifies the hosted application <NUM>. In some instances the hosted application <NUM> can also provide an indication of one or more verification rules <NUM> to be considered when evaluating the data item <NUM>.

Proceeding to step <NUM>, the security service <NUM> retrieves the identity document <NUM> associated with the identity key <NUM> that identifies the hosted application <NUM> in response to receiving the verification request. For example, the security service <NUM> can use the identity key <NUM> to search for the respective identity document <NUM> stored in the distributed ledger <NUM> and retrieve it. In instances where multiple distributed ledgers <NUM> are used, the security service <NUM> can send the identity key <NUM> to a relay or resolver service, such as a DID resolver, to determine which distributed ledger <NUM> contains the identity document <NUM>. In these instances, the relay or resolver service may retrieve the identity document <NUM> on behalf of the security service <NUM> and return it to the security service <NUM>.

Moving on to step <NUM>, the security service <NUM> can send an authentication challenge to the hosted application <NUM> to confirm that the hosted application <NUM> made the request at step <NUM>. Accordingly, the security service <NUM> can use the public key <NUM> in the identity document <NUM> retrieved at step <NUM> to encrypt a token or nonce for use as an authentication challenge. The authentication challenge can then be sent to the hosted application <NUM>.

Referring next to step <NUM>, the hosted application <NUM> can forward the authentication challenge to the vault manager <NUM>. The authentication challenge can be forwarded as part of a request for the vault manager <NUM> to decrypt and sign the authentication challenge using the private key <NUM> associated with the identity key <NUM> that authenticates the hosted application <NUM>. The hosted application <NUM> may also include authentication credentials to confirm with vault manager <NUM> that the operation should be performed on behalf of the hosted application <NUM>.

In response at step <NUM>, the vault manager <NUM> can decrypt and sign the authentication challenge and provide the decrypted authentication challenge and signature for the authentication challenge to the hosted application <NUM>. For example, the vault manager <NUM> can first retrieve the private key <NUM> of the key-pair <NUM> associated with the identity key <NUM> that identifies the hosted application <NUM>. The vault manager <NUM> can then decrypt the encrypted challenge to recreate the original token or nonce provided by the security service <NUM>. The vault manager <NUM> can then sign the token or nonce with the private key <NUM> to prove that the owner of the private key <NUM> for the hosted application <NUM> decrypted the challenge instead of obtaining the unencrypted token or nonce through other means. The vault manager <NUM> could then provide the unencrypted token or nonce as well as the respective signature to the hosted application <NUM>.

Next at step <NUM>, the hosted application <NUM> can send an authentication response to the security service <NUM> to prove its identity. This can include the unencrypted token or nonce from the authentication challenge as well as a signature for the unencrypted token or nonce.

Then at step <NUM>, the security service <NUM> can verify or validate the data item <NUM>. For example, the security service <NUM> can evaluate the data item <NUM> to determine whether the data item <NUM> complies with one or more verification rules <NUM> specified by the hosted application <NUM> in step <NUM>. As another example, the security service <NUM> can identify a verification rule <NUM> that applies to the data item <NUM> and evaluate the data item <NUM> for compliance. For example, if the data item <NUM> is a network address for a website, the security service <NUM> could identify all verification rules <NUM> applicable to network addresses or websites and evaluate the data item <NUM> for compliance. Similarly, if the data item <NUM> is a file, the security service <NUM> could identify all verification rules <NUM> applicable to files and evaluate the data item for compliance.

Once the security service <NUM> evaluates the data item <NUM>, the security service can create a verified claim <NUM> about the data item <NUM>. This can include a claim <NUM> about each verification rule <NUM> with which the data item <NUM> complies. This can also include a claim <NUM> about each verification rule <NUM> with which the data item <NUM> fails to comply. For example, if the security service <NUM> determines that the network address is a valid network address for the hosted application <NUM> instead of a network address for an impostor application, the security service <NUM> could make a claim <NUM> that the network address complies with a verification rule <NUM> stating that a network address should be a valid network address for reaching the hosted application <NUM>. However, if an automated security scan performed by the security service <NUM> indicate the present of vulnerabilities in the hosted application <NUM>, the security service <NUM> could make a second claim that the hosted application <NUM> is insecure and fails to comply with a verification rule <NUM> that the hosted application <NUM> should be free of vulnerabilities or specific vulnerabilities. Similar claims <NUM> can also be made about files, such as the identity of the creator or distributor of a file or whether a file contains malware. The security service <NUM> can also create a respective signature <NUM> for each claim <NUM> in the verified claim <NUM>. The verified claim(s) <NUM> can then be returned to the hosted application <NUM>.

Finally, at step <NUM>, the hosted application <NUM> can create and record an identity document <NUM> for the data item <NUM> that includes the verified claim(s) <NUM> provided by the security service <NUM>. This can allow other applications or third-parties to verify the authenticity or security of data items <NUM>, such as whether links to network addresses are genuine or fake, whether a hosted application <NUM>, website, or file contains malware or is otherwise insecure, or whether an entity that purports to be the creator, originator, or distributor of a file is actually the creator, originator or distributor of the file. According, the hosted application <NUM> can create an identity document <NUM> that includes the identity key <NUM> and the key-pair <NUM> created at step <NUM>, as well as the verified claim(s) <NUM> created at step <NUM>. After creating the identity document <NUM>, the hosted application <NUM> can cause the identity document <NUM> to be stored in distributed ledger <NUM>.

It should be noted that the sequence diagram of <FIG> is similar in scope to that of <FIG>. However, the sequence diagram of <FIG> depicts the use of a vault manager <NUM>, while the sequence diagram of <FIG> depicts an alternative implementation which omits the use of the vault manager <NUM>.

At step <NUM>, the hosted application <NUM> can decrypt and sign the authentication challenge and provide the decrypted authentication challenge and signature for the authentication challenge to the hosted application <NUM>. For example, the hosted application <NUM> can use a respective private key <NUM> of the key-pair <NUM> to decrypt the encrypted challenge to recreate the original token or nonce provided by the security service <NUM>. The hosted application <NUM> can then sign the token or nonce with the private key <NUM> to prove that the hosted application <NUM> decrypted the challenge instead of obtaining the unencrypted token or nonce through other means.

Then at step <NUM>, the hosted application <NUM> can send an authentication response to the security service <NUM> to prove its identity. This can include the unencrypted token or nonce from the authentication challenge as well as a signature for the unencrypted token or nonce.

In step <NUM>, the security service <NUM> can verify or validate the data item <NUM>. For example, the security service <NUM> can evaluate the data item <NUM> to determine whether the data item <NUM> complies with one or more verification rules <NUM> specified by the hosted application <NUM> in step <NUM>. As another example, the security service <NUM> can identify a verification rule <NUM> that applies to the data item <NUM> and evaluate the data item <NUM> for compliance. For example, if the data item <NUM> is a network address for a website, the security service <NUM> could identify all verification rules <NUM> applicable to network addresses or websites and evaluate the data item <NUM> for compliance. Similarly, if the data item <NUM> is a file, the security service <NUM> could identify all verification rules <NUM> applicable to files and evaluate the data item for compliance.

Beginning with step <NUM>, the client application <NUM> sends a request for a data item <NUM> to the hosted application <NUM>. This could include, for example, a request for a file, a request for a webpage, etc..

At step <NUM>, the hosted application <NUM> provides the data item <NUM> in response to the request, along with a respective identity key <NUM> identified in a respective authentication record <NUM>. The identity key <NUM> could be provided using various custom protocols or extensions to existing protocols. For example, additional hypertext transport protocol (HTTP) headers could be included in the response to indicate the identity key associated with the data item <NUM>.

Subsequently at step <NUM>, the client application <NUM> recognizes the identity key <NUM> in the response and retrieves the respective identity document <NUM>. For example, the client application <NUM> can use the identity key <NUM> to search for the respective identity document <NUM> stored in the distributed ledger <NUM> and retrieve it. In instances where multiple distributed ledgers <NUM> are used, the client application <NUM> can send the identity key <NUM> to a relay or resolver service, such as a DID resolver, to determine which distributed ledger <NUM> contains the identity document <NUM>. In these instances, the relay or resolver service may retrieve the identity document <NUM> on behalf of the client application <NUM> and return it to the security service <NUM>.

Then at step <NUM>, the client application <NUM> can create and send a cryptographic challenge to the hosted application <NUM>. Accordingly, the client application <NUM> can use the public key <NUM> in the identity document <NUM> retrieved at step <NUM> to encrypt a token or nonce for use as the cryptographic challenge, which can then be sent to the hosted application <NUM>.

At step <NUM>, the hosted application <NUM> can forward the cryptographic challenge to the vault manager <NUM>. The cryptographic challenge can be forwarded as part of a request for the vault manager <NUM> to decrypt and sign the cryptographic challenge using the private key <NUM> associated with the identity key <NUM> linked to the data item <NUM> by the authentication record <NUM>.

In response at step <NUM>, the vault manager <NUM> can decrypt and sign the cryptographic challenge and provide the decrypted cryptographic challenge and signature for the cryptographic challenge to the hosted application <NUM>. For example, the vault manager <NUM> can first retrieve the private key <NUM> of the key-pair <NUM> associated with the identity key <NUM> linked to the data item <NUM>. The vault manager <NUM> can then decrypt the encrypted challenge to recreate the original token or nonce provided by the client application <NUM>. The vault manager <NUM> can then sign the token or nonce with the private key <NUM> to prove that the owner of the private key <NUM> for the hosted application <NUM> decrypted the challenge instead of obtaining the unencrypted token or nonce through other approaches. The vault manager <NUM> could then provide the unencrypted token or nonce as well as the respective signature to the hosted application <NUM>.

Next at step <NUM>, the hosted application <NUM> can then send the unencrypted nonce or token and the signature for the nonce or token to the client application <NUM>. This can indicate that the identity document <NUM> retrieved by the client application <NUM> is associated with the data item <NUM> and contains valid verified claims <NUM> concerning the data item <NUM>.

Then at step <NUM>, the client application <NUM> can evaluate the verified claims <NUM> contained in the identity document <NUM> retrieved at step <NUM>. For example, the client application <NUM> may evaluate each claim <NUM> to determine what is asserted about the data item <NUM> (e.g., is it secure, does it contain malware, is the link to a valid site or an impostor site, who is the purported author of the file, etc.). The client application <NUM> may also confirm that the respective signature <NUM> for each claim <NUM> in the verified claim <NUM> is correct to ensure the each claim <NUM> is valid.

In some instances, the client application <NUM> can also determine whether it trusts the party making the assertion in the claim <NUM>. For example, the signature <NUM> may specify the security service <NUM> that made the claim <NUM>. One security service <NUM> may be more trusted by the client application <NUM> than another security service <NUM> (e.g., one security service <NUM> may have a history of being more thorough or being more accurate). Accordingly, the client application <NUM> may choose to disregard a particular claim <NUM> if it is made by a particular security service <NUM> or may require that multiple, untrusted security services <NUM> make the same assertion in their respective claims <NUM> in order for a particular assertion by an untrusted security service <NUM> be trusted.

Finally at step <NUM>, the client application <NUM> renders a user interface <NUM> based at least in part on the claims <NUM> contained in the verified claim <NUM>. In some implementations, only claims <NUM> in the verified claim <NUM> that are from trusted sources may be incorporated into the user interface <NUM>. For example, the client application <NUM> may render a user interface <NUM> that displays the data item <NUM> along with an indication of the status of the data item <NUM>. For example, the user interface could indicate that a website is secure, that a link is a valid link for a website, that a file does not contain malware, or that the author or distributor of a file is who he or she purports to be.

At step <NUM>, the hosted application <NUM> provides the data item <NUM> in response, along with a respective identity key <NUM> identified in a respective authentication record <NUM>. The identity key <NUM> could be provided using various custom protocols or extensions to existing protocols. For example, additional hypertext transport protocol (HTTP) headers could be included in the response to indicate the identity key associated with the data item <NUM>.

At step <NUM>, the hosted application <NUM> can decrypt and sign the cryptographic challenge and provide the decrypted cryptographic challenge and signature for the cryptographic challenge to the hosted application <NUM>. For example, the hosted application <NUM> can use the private key <NUM> of the key-pair <NUM> associated with the identity key <NUM> linked to the data item <NUM> to decrypt the encrypted challenge to recreate the original token or nonce provided by the client application <NUM>. The hosted application <NUM> can then sign the token or nonce with the private key <NUM> to prove that the owner of the private key <NUM> for the hosted application <NUM> decrypted the challenge instead of obtaining the unencrypted token or nonce through other means.

In some instances, the client application <NUM> can also determine whether or not it trusts the party making the assertion in the claim <NUM>. For example, the signature <NUM> may specify the security service <NUM> that made the claim <NUM>. One security service <NUM> may be more trusted by the client application <NUM> than another security service <NUM> (e.g., one security service <NUM> may have a history of being more thorough or being more accurate). Accordingly, the client application <NUM> may choose to disregard a particular claim <NUM> if it is made by a particular security service <NUM> or may require that multiple, untrusted security services <NUM> make the same assertion in their respective claims <NUM> in order for a particular assertion by an untrusted security service <NUM> be trusted.

<FIG> depicts an example of a user interface <NUM> rendered on the display <NUM> by the client application <NUM> according to various embodiments of the present disclosure. Although the user interface <NUM> depicted in <FIG> depicts one example of an implementation of the present disclosure, the principals disclosed in the user interface <NUM> of <FIG> could be adapted to other user interfaces <NUM> used for similar purposes.

The example of <FIG> depicts a user interface <NUM> rendered by a client application <NUM>, such as a browser, that incorporates the result of the verification process depicted previously in <FIG> or <FIG>. Displayed in the user interface <NUM> are multiple links that that have been verified using a process such as that depicted previously in <FIG> or <FIG>. In response to evaluation of a verified claim <NUM> for each link, a user interface element <NUM> has been inserted next to each link to indicate the status of the link. For example, some links may have an indication that they are "Approved. " This status could indicate that these links comply with all applicable verification rules <NUM>, such as whether the links would direct a user to a website that impersonates a legitimate website or whether a website reachable by the links contains security vulnerabilities. In contrast, other links may have an instruction stating "DO NOT CLICK" to warn users that these links fail to comply with at least one applicable verification rule <NUM>. All these user interface elements <NUM> contain illustrative examples of how information could be conveyed to a user, other approaches could be used as appropriate.

The example of <FIG> depicts a user interface <NUM> rendered by a client application <NUM>, such as a browser, that incorporates the result of the verification process depicted previously in <FIG> or <FIG>. Displayed in the user interface <NUM> are multiple links that that have been verified using a process such as that depicted previously in <FIG> or <FIG>. In response to evaluation of a verified claim <NUM> for file that a user is attempting to access, a dialog box <NUM> has been rendered to indicate the status of the file. Although any status could be rendered in the dialog box <NUM>, some implementations may choose to only render a dialog box <NUM> if a file fails to comply with at least one verification rule <NUM>. For example, a dialog box <NUM> might be rendered if a file contains malware or if a file appears not to originate from the purported author or distributor of the file.

A number of software components previously discussed are stored in the memory of the respective computing devices and are executable by the processor respective computing devices. In this respect, the term "executable" means a program file that is in a form that can ultimately be run by the processor. Examples of executable programs can be a compiled program that can be translated into machine code in a format that can be loaded into a random access portion of the memory and run by the processor, source code that can be expressed in proper format such as object code that is capable of being loaded into a random access portion of the memory and executed by the processor, or source code that can be interpreted by another executable program to generate instructions in a random access portion of the memory to be executed by the processor. An executable program can be stored in any portion or component of the memory, including random access memory (RAM), read-only memory (ROM), hard drive, solid-state drive, Universal Serial Bus (USB) flash drive, memory card, optical disc such as compact disc (CD) or digital versatile disc (DVD), floppy disk, magnetic tape, or other memory components.

The memory includes both volatile and nonvolatile memory and data storage components. Volatile components are those that do not retain data values upon loss of power. Nonvolatile components are those that retain data upon a loss of power. Thus, the memory can include random access memory (RAM), read-only memory (ROM), hard disk drives, solid-state drives, USB flash drives, memory cards accessed via a memory card reader, floppy disks accessed via an associated floppy disk drive, optical discs accessed via an optical disc drive, magnetic tapes accessed via an appropriate tape drive, or other memory components, or a combination of any two or more of these memory components. In addition, the RAM can include static random access memory (SRAM), dynamic random access memory (DRAM), or magnetic random access memory (MRAM) and other such devices. The ROM can include a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other like memory device.

Although the applications and systems described herein can be embodied in software or code executed by general purpose hardware as discussed above, as an alternative the same can also be embodied in dedicated hardware or a combination of software/general purpose hardware and dedicated hardware. If embodied in dedicated hardware, each can be implemented as a circuit or state machine that employs any one of or a combination of a number of technologies. These technologies can include, but are not limited to, discrete logic circuits having logic gates for implementing various logic functions upon an application of one or more data signals, application specific integrated circuits (ASICs) having appropriate logic gates, field-programmable gate arrays (FPGAs), or other components, etc. Such technologies are generally well known by those skilled in the art and, consequently, are not described in detail herein.

The sequence diagrams show the functionality and operation of an implementation of portions of the various embodiments of the present disclosure. If embodied in software, each block can represent a module, segment, or portion of code that includes program instructions to implement the specified logical function(s). The program instructions can be embodied in the form of source code that includes human-readable statements written in a programming language or machine code that includes numerical instructions recognizable by a suitable execution system such as a processor in a computer system. The machine code can be converted from the source code through various processes. For example, the machine code can be generated from the source code with a compiler prior to execution of the corresponding application. As another example, the machine code can be generated from the source code concurrently with execution with an interpreter. Other approaches can also be used. If embodied in hardware, each block can represent a circuit or a number of interconnected circuits to implement the specified logical function or functions.

Although the sequence diagrams show a specific order of execution, it is understood that the order of execution can differ from that which is depicted. For example, the order of execution of two or more blocks can be scrambled relative to the order shown. Also, two or more blocks shown in succession can be executed concurrently or with partial concurrence. Further, in some embodiments, one or more of the blocks shown in the sequence diagrams can be skipped or omitted. In addition, any number of counters, state variables, warning semaphores, or messages might be added to the logical flow described herein, for purposes of enhanced utility, accounting, performance measurement, or providing troubleshooting aids, etc. It is understood that all such variations are within the scope of the present disclosure.

Also, any logic or application described herein that includes software or code can be embodied in any non-transitory computer-readable medium for use by or in connection with an instruction execution system such as a processor in a computer system or other system. In this sense, the logic can include statements including instructions and declarations that can be fetched from the computer-readable medium and executed by the instruction execution system. In the context of the present disclosure, a "computer-readable medium" can be any medium that can contain, store, or maintain the logic or application described herein for use by or in connection with the instruction execution system.

The computer-readable medium can include any one of many physical media such as magnetic, optical, or semiconductor media. More specific examples of a suitable computer-readable medium would include, but are not limited to, magnetic tapes, magnetic floppy diskettes, magnetic hard drives, memory cards, solid-state drives, USB flash drives, or optical discs. Also, the computer-readable medium can be a random access memory (RAM) including static random access memory (SRAM) and dynamic random access memory (DRAM), or magnetic random access memory (MRAM). In addition, the computer-readable medium can be a read-only memory (ROM), a programmable read-only memory (PROM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), or other type of memory device.

Further, any logic or application described herein can be implemented and structured in a variety of ways. For example, one or more applications described can be implemented as modules or components of a single application. Further, one or more applications described herein can be executed in shared or separate computing devices or a combination thereof. For example, a plurality of the applications described herein can execute in the same computing device, or in multiple computing devices in the same computing environment.

Disjunctive language such as the phrase "at least one of X, Y, or Z," unless specifically stated otherwise, is otherwise understood with the context as used in general to present that an item, term, etc., can be either X, Y, or Z, or any combination thereof (e.g., X, Y, or Z). Thus, such disjunctive language is not generally intended to, and should not, imply that certain embodiments require at least one of X, at least one of Y, or at least one of Z to each be present.

Claim 1:
A system, comprising:
a computing device comprising a processor and a memory; and
machine-readable instructions stored in the memory that, when executed by the processor, cause the computing device to at least:
generate (<NUM>,<NUM>) an identity key (<NUM>) for a data item (<NUM>), the identity key (<NUM>) representing a unique address that specifies a location where an identity document (<NUM>) can be found;
send (<NUM>,<NUM>) a request for authentication of the data item (<NUM>) to a security service (<NUM>), the request comprising the identity key (<NUM>) and the data item (<NUM>);
receive (<NUM>,<NUM>) a verified claim (<NUM>) for the data item (<NUM>) from the security service (<NUM>), the verified claim (<NUM>) representing one or more verified assertions about the data item (<NUM>) described by the identity document (<NUM>);
generate (<NUM>,<NUM>) the identity document (<NUM>), the identity document (<NUM>) comprising the identity key (<NUM>) for the data item (<NUM>) and the verified claim (<NUM>); and
store (<NUM>,<NUM>) the identity document in a distributed ledger (<NUM>).