Access gateway system for accessing resources

Abstract

The access gateway may grant a requester access to a computer resource. The requester may receive a credential from an identity provider and compute a zero-knowledge proof of possession of the credential. The requester may request access to the computer resource using the proof. The identity provider may record a policy corresponding to the credential in a distributed ledger. The access gateway may retrieve the policy from the distributed ledger conditional on verifying the proof. The policy may indicate that the requester is authorized to access the computer resource. The access gateway may grant the requester access to the computer resource in accordance with the policy.

Description

[Technical Field]

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS This application claims the benefit of priority to U.S. Provisional Patent Application No. 63 / 490,038, filed March 14, 2023, entitled "CRYPTOGRAPHICALLY SECURE GLOBAL ADDRESSING LIST FOR DATA VERIFICATION AND DECLASSIFICATION," the contents of which are incorporated herein by reference in their entirety. Summary of the Invention [Means for solving the problem]

[0002] For a more complete understanding of the present disclosure, reference is now made to the following descriptions taken in conjunction with the accompanying drawings, in which: [Brief explanation of the drawings]

[0003] [Figure 1] FIG. 1 is a conceptual diagram of an exemplary environment in which an access gateway system may operate, according to an embodiment of the present disclosure. [Figure 2] 4 is a signal flow diagram illustrating an exemplary operation of an access gateway system according to an embodiment of the present disclosure. [Figure 3A] 1 illustrates operation of an access gateway system for data declassification in a first exemplary use case, according to an embodiment of the present disclosure. [Figure 3B] 4 is a signal flow diagram illustrating an example operation of a first example use case according to an embodiment of the present disclosure. [Figure 4A] 10 illustrates a second exemplary use case operation of an access gateway system for granting access to secure data for executing a workflow on a data owner system, according to an embodiment of the present disclosure. [Figure 4B] 10 is a signal flow diagram illustrating an example operation of a second example use case, according to an embodiment of the present disclosure. [Figure 5A]10 illustrates a third exemplary use case operation of an access gateway system that authorizes submission of digitally signed content to a content platform, according to an embodiment of the present disclosure. [Figure 5B] 10 is a signal flow diagram illustrating an example operation of a third example use case, according to an embodiment of the present disclosure. [Figure 6] FIG. 1 is a block diagram illustrating exemplary client devices and system components communicating over a computer network, according to embodiments of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0004] The systems and methods described herein relate to a cryptographically secure global addressing list for data validation and declassification. An access gateway system (AGS) may control requester access to computer resources. The computer resources may be, for example, resource systems and / or data stores. The requesters may be individuals, such as users, administrators, analysts, content creators, etc., requesting access to the computer resources. The requesters may seek access to the computer resources for various purposes, including, for example, declassifying data and relocating it to declassified storage, running a workflow on a data owner system, and / or uploading digitally signed content to a content platform. The AGS may verify the requester's credentials and obtain a policy corresponding to the credentials. The policy may relate to permissions for access to the computer resources and may further specify detailed permissions (e.g., read-only, write, delete, etc.) regarding the resource systems and / or data.

[0005] In some implementations, a claimant may demonstrate possession of associated credentials to an AGS using zero-knowledge proofs. This may allow the AGS to determine that the claimant possesses credentials that grant access to computer resources without knowing the claimant's exact identity and / or without revealing the claimant's identity to an observer. An identity provider system may provide the credentials to the claimant and may provide the AGS with data to verify the proofs.

[0006] A resource system may implement policies that govern, for example, which credentials correspond to which permissions. In some embodiments, the resource system may record the policies in a distributed ledger, such as a blockchain. In some embodiments, the resource system may record the policies along with credentials corresponding to requesters granted access by the policy. The tamper-resistance of a distributed ledger may represent reliable evidence that the policies and / or corresponding credentials recorded therein accurately represent what the resource system originally intended / recorded. The distributed ledger may further provide a robust, reliable, replicated record of the policies and / or credentials.

[0007] By combining zero-knowledge proofs of credentials with distributed ledger recording of policies, an AGS may control access to computer resources in a manner that can hide the requester's exact identity while showing that the access corresponded to a valid policy. Thus, an observer may not be able to identify the requester, but the observer can verify which requester was granted access based on the recorded policy. The observer may also verify that, for a particular action, the AGS verified the requester before allowing the action. Thus, the system may balance the interests of trust (e.g., on the part of the observer) with the interests of privacy (e.g., the requester's identity). Such a balance may be useful in some use cases described herein and others.

[0008] For example, a first use case (e.g., as described with reference to FIGS. 3A and 3B) may involve granting access to sensitive data to a requester. The AGS may control access to the sensitive data store, including the ability to declassify the data and / or relocate the data to the declassified data store. The AGS may allow an observer to determine who has access to view / declassify the data and / or verify that the data was properly declassified while concealing the requester's exact identity.

[0009] A second use case (e.g., as described with reference to Figures 4A and 4B) may involve granting a requester access to secure data for executing a workflow on a data owner system.

[0010] A third use case (e.g., as described with reference to Figures 5A and 5B) may involve using the system as a gateway to manage the upload of digitally signed content to a content platform. A requester (e.g., a content creator) may maintain a private key and use it to add a digital signature to the content. A corresponding public key may be published, for example, to a distributed ledger. Observers may use the public key to authenticate the signed content.

[0011] Other use cases for the described system are possible. These features may be used alone or in combination with each other and / or other features described herein. Various operations of the system and device may be contingent on user approval. The system may be implemented in a manner that ensures compliance with applicable laws, regulations, standards, etc. in the location of the system and / or device.

[0012] 1 is a conceptual diagram of an example environment 100 in which an access gateway system (AGS) 120 may operate, according to an embodiment of the present disclosure. As used herein, a "policy" may refer to rules governing overall permissions to access a computer resource and / or detailed permissions, such as to read, use, modify, and / or delete various portions or aspects of the computer resource. As used herein, a "computer resource" may refer to computational resources (e.g., hosted computer services for running applications and / or other workflows), data (e.g., proprietary, confidential, personal, and / or sensitive data), applications (e.g., software as a service), other systems (e.g., using cloud computing platforms), and / or computer-controlled electronic, electrical, and / or mechanical systems (e.g., for remotely controlling utilities, consumer systems, and / or network infrastructure), etc.

[0013] A requester 5 operating a client device 110 may generate and send a request 135 to an AGS 120 using credentials 105 provided by an identity provider system 150. The request 135 may be for access to a computer resource, such as a resource system 130 and / or an associated resource data storage component 140. The request 135 may include and / or be accompanied by proof that the requester 5 possesses the credentials 105. The client device 110 may be, for example, a computing device (e.g., a user device 600 and / or a system component 700 described below with reference to FIG. 6 ) and / or software executing on such a computing device. The AGS 120, the resource system 130, the distributed node 160, and / or the identity provider system 150 may be (and / or execute on) one or more system components (e.g., system component 700). In some embodiments, one or more of AGS 120, resource system 130, distributed node 160, and / or identity provider system 150 may be (and / or execute on) one or more user devices 600. Similarly, in some embodiments, client device 110 may be (and / or execute on) one or more system components 700. In various embodiments, the various components and / or the functions they perform may be duplicated, split, and / or shared among user device(s) 600 and / or system component(s) 700. The various user devices 600 and system components 700 implementing client device 110, AGS 120, resource system 130, resource data storage component 140, identity provider system 150, and / or distributed node 160 may communicate via one or more wired and / or wireless computer networks 199, as shown in FIG. 6 .

[0014] Upon verifying that the requestor 5 demonstrates possession of the necessary credentials, the AGS 120 may grant the requestor 5 access to the computer resource. As used herein, a computer resource may refer to the resource system 130, the resource data storage component 140, or both. Similarly, access to the resource system 130 may refer to access to the resource system 130 itself, the resource data storage component 140, or both, unless otherwise specified. The resource system 130 may be, for example, but not limited to, a computer system such as a hosted computing service, and / or a data owner such as a secure data system. In some implementations, the AGS 120 may act as a secure gateway between the resource data storage component 140 and the resource system 130 (e.g., creating additional security for the data in the resource data storage component 140 beyond that imposed by and / or for the use of the resource system 130). Thus, the AGS 120 may control access to the operation of the resource system 130 and / or to the resource data storage component 140 itself.

[0015] The identity provider system 150 may create a credential 105 for an authenticated claimant 5 (e.g., an individual who has demonstrated a particular identity or attribute). The credential 105 may be data indicative of an attribute or attribute(s) of the claimant 5. The credential(s) 105 may be encrypted. The identity provider system 150 may verify and / or attribute the attributes of the claimant 5 and provide the corresponding credential(s) 105 to the claimant 5. For example, the credential 105 may be data representing the identity of a particular claimant (and / or group of claimants). In another example, the credential 105 may correspond to a characteristic of the claimant 5 (e.g., the claimant is over the age of 18, has a particular professional qualification, and / or resides in a particular location, etc.). The requester 5 may store the credential(s) 105 in a credential wallet 112, which may be a secure and / or encrypted memory or storage, from which the requester 5 may retrieve the credential(s) 105 for the purpose of generating a proof that is verified by the AGS 120.

[0016] The resource system 130 can create policies 115 that specify who has permission to access the resource system 130 (including the data in the resource data storage component 140) and, in some cases, the type of access a particular requester 150 has. The policies 115 may correspond to particular identities and / or attributes as reflected in the credentials 105. In some implementations, the resource system 130 can select an identity provider system 150 based on the type(s) of credentials 105 that the identity provider system 150 can issue. The resource system 130 may additionally or alternatively select an identity provider system 150 based on other information, such as the security protocols it implements, third-party reviews of its services and / or security, industry reputation, etc. The resource system 130 may create policies 115 based on the type and / or schema of the credentials 105 provided by the identity provider system.

[0017] Policy 115 may be data indicating access to perform specific type(s) of operations with respect to resource system 130 and / or resource data storage component 140. In some cases, policy 115 may indicate permission to access all aspects of resource system 130 and / or resource data storage component 140. In some cases, policy 115 may indicate detailed permissions to access a subset of the functionality of resource system 130 and / or a subset of the data in resource data storage component 140. Policy 115 may further indicate credentials or credential(s) 105 corresponding to the permissions indicated in policy 115. Resource system 130 may publish policy 115 within a distributed ledger system 165 consisting of distributed nodes 160a, 160b, 160c, etc. (collectively “distributed nodes 160”). Distributed nodes 160 may use a consensus algorithm to ensure that data stored by distributed nodes 160 is reliably replicated among themselves.

[0018] The distributed nodes 160 may implement a distributed ledger system 165. A distributed ledger represents a shared, replicated, and synchronized data store. The distributed nodes 160 may execute a consensus algorithm to determine a correct, updated ledger to represent the addition of new data (e.g., after receiving a new policy 115 from the resource system 130). Once the correct, updated ledger is determined, the distributed nodes 160 may form a peer-to-peer network (e.g., within and / or across the computer network 199) to propagate the update. Each distributed node 160 then updates itself accordingly. The result is a tamper-resistant record of received data replicated across multiple nodes with no single point of failure.

[0019] A distributed ledger can be a linear data structure (e.g., a chain such as a blockchain) or a more complex structure such as a directed acyclic graph. A directed acyclic graph in the context of a distributed ledger can consist of blocks of data and edges that indicate the adjacency of data blocks added to the distributed ledger. Each edge is directed and indicates a direction from an existing data block to new data added to the existing data block. This structure is acyclic in that it does not contain a path where a data block can cross twice following any sequence of edges according to the direction of the edges (e.g., there are no edges directed "backwards" in time). However, a data block may have multiple edges pointing to it and / or away from it.

[0020] A consensus algorithm may be a proof-of-work algorithm or a proof-of-stake algorithm. A proof-of-work algorithm is a form of cryptographic proof that can be used to prove to others that one party performed a certain computational effort. The proof is asymmetric in that a verifier can verify the proof with minimal computational effort. An example of proof-of-work in the context of distributed ledgers is cryptocurrency "mining," where mining refers to an incentive structure used to encourage nodes to expend computational effort to add data blocks to a distributed ledger. In contrast, proof-of-stake protocols allow only nodes that own a certain amount of data blocks (e.g., blockchain tokens) to validate and add new data blocks. Proof-of-stake protocols prevent attackers from hijacking validation by requiring them to obtain a majority of data blocks. Proof-of-stake protocols include, for example, committee-based proof-of-stake, delegated proof-of-stake, and liquid proof-of-stake.

[0021] A distributed ledger may be permissioned or permissionless. A permissioned distributed ledger may refer to a private system with a central authority to authorize nodes to add data blocks. In some cases, a consortium may be an agreement among participating organizations to operate the distributed ledger collaboratively to the exclusion of others. A permissionless distributed ledger may refer to an open or public network where no access control is used. Any party can add to the distributed ledger as long as they satisfy a consensus algorithm (e.g., proof of work). Examples of permissionless distributed ledgers include Bitcoin and other cryptocurrencies, which require new entries to include proof of work.

[0022] In some embodiments, distributed node 160 may be publicly available (e.g., publicly viewable) to allow observers 15 to verify which policies 115 correspond to which credentials 105. Thus, observers 15 may have a reliable indication of which requesters 5 have permission to perform various actions with respect to resource system 130. In some embodiments, AGS 120 may allow requesters 5 to provide zero-knowledge proofs of their credentials 105. This may allow requesters 5 to provide some degree of assurance to AGS 120 that a trusted party is requesting access to resource system 130 and / or to observer(s) 15 that the party accessing resource system 130 is a trusted party, while still hiding their exact identity from AGS 120 and / or observer(s) 15.

[0023] Zero-knowledge proofs allow a party to prove a claim without revealing any additional information. For example, a "prover" can share a proof of a claim with a "verifier," who can verify the accuracy of the proof. While a zero-knowledge proof may not definitively prove a claim, the proof and verification runs may be repeated until the prover demonstrates to the verifier (and possibly external observers) a statistically high probability that the claim is true, rather than a series of lucky guesses. A real-world analogy is a verifier writing a random string of characters on a piece of paper and placing it in a lockbox. The prover can prove they know the lockbox's PIN by opening the lockbox outside the verifier's view and reading the string to the verifier. The verifier can prove that they know the lockbox's PIN, but the verifier does not have any other information that can be used to identify the PIN itself.

[0024] A zero-knowledge proof of a claim may satisfy three properties: completeness, soundness, and zero-knowledge. Completeness means that if the claim is true, an honest prover can convince an honest verifier of the claim. Soundness means that if the claim is false, a dishonest prover cannot convince an honest verifier of the claim (e.g., except with a very small probability, which can be further reduced by repeated proofs). Zero-knowledge means that if the claim is true, the verifier (or observer) does not gain any information other than the fact that the claim is true.

[0025] Zero-knowledge proofs can be interactive or non-interactive. An interactive proof system may involve repeated exchanges of messages between a prover (e.g., client device 110) and a verifier (e.g., AGS 120). The client device 110 may be assumed to have access to abundant computational resources but cannot be trusted. In contrast, the AGS 120 may be assumed to be trustworthy but have limited computational resources. An interactive proof system may also include the ability of the AGS 120 to make random selections. Through the exchange of messages, the client device 110 can establish a near-certain probability that a claim is true without disclosing any information other than the fact that the claim is true. For example, the AGS 120 may determine that the probability that the client device 110 is making a false claim is extremely low by receiving N consecutive verifiable proofs from the client device 110. AGS 120 and / or identity provider system 150 may select the value of N and / or the threshold trust score (e.g., corresponding to the likelihood that client device 110 possesses the credentials 105 it claims) based on, for example, the potential damage from a malicious party gaining access to resource system 130 and / or the sensitivity of the data in resource data storage component 140. An example of a zero-knowledge protocol that can be used to perform interactive zero-knowledge proofs is Zero-Knowledge Scalable Transparent Knowledge Proofing (zk-STARK). However, some versions of zk-STARK may operate non-interactively.

[0026] Non-interactive zero-knowledge proofs may offer advantages over interactive proofs. For example, non-interactive proofs may be used when the prover and verifier cannot interact (e.g., communicate in real time). Thus, non-interactive proofs may be useful in a distributed system, such as a distributed ledger system 165 consisting of distributed nodes 160. The distributed nodes 160 may use zero-knowledge proofs to verify transactions (e.g., add new policies 115 to the ledger) without the oversight of a central authority. For example, the distributed nodes 160 may verify that the identity provider system 150 (and / or other components of the system) is authorized to write policies 115, public keys, and / or other data to the distributed ledger system 165. An example of a non-interactive zero-knowledge protocol is zero-knowledge succinct non-interactive proof of knowledge (zk-SNARK). Zero-knowledge proof protocols (e.g., zk-SNARK, zk-STARK, and / or others) may be transparent and / or universal. A transparent protocol is one that does not require trusted setup but may rely on public randomness. A universal protocol is one that does not require separate trusted setup for each arithmetic circuit, where an arithmetic circuit is a directed acyclic graph representing numerical operations involving addition and / or multiplication, e.g., computing a polynomial.

[0027] In some implementations, identity provider system 150 may provide the trusted setup for zero-knowledge proofs. In some implementations, a different component (e.g., independent of identity provider system 150, client device 110, and AGS 120) may provide the trusted setup. However, in the example environment 100 shown in FIG. 1, for simplicity, identity provider system 150 is shown as providing the trusted setup.

[0028] The identity provider system 150 may send the prover setup 125a to the client device 110 and the verifier setup 125b to the AGS 120. The prover setup 125a and the verifier setup 125b may collectively be referred to as a “trusted setup 125.” In some embodiments, the prover setup 125a may be, for example, data representing a prover key and / or a structured reference string. In some embodiments, the verifier setup 125b may be, for example, data representing a verifier key and / or a structured reference string. The trusted setup 125 may facilitate zero-knowledge proof between the client device 110 (e.g., the prover) and the AGS 120 (e.g., the verifier). The zero-knowledge proof may be used by the claimant 5 to prove to the AGS 120 that the claimant 5 possesses credentials 105 corresponding to a policy 115 for accessing the resource system 130. By using zero-knowledge proofs, the requester 5 can keep its exact identity hidden from the AGS 120 and / or any observer(s) 15 of the data passed between the client device 110 and the AGS 120. However, the observer 15 may be permitted to see the operation(s) performed and / or their results, and to verify that the AGS 120 authorized the operation(s) based on a policy 115 that may also be visible to the observer 15. Thus, the AGS 120 may balance the privacy interests of the requester 5 with the trust interests of the observer 15.

[0029] The following example illustrates exemplary operations for implementing trusted setup 125 and verifying zero-knowledge proofs. A requester 5 may authenticate a client device 110 with an identity provider system 150 by various means (e.g., username and password, multi-factor authentication, etc.). The identity provider system 150 may provide one or more credentials 105 to the client device 110. The client device 110 may store the credential(s) 105 in a credential wallet 112. The credential wallet 112 may be a secure (e.g., encrypted) data storage component on and / or associated with the client device 110. The credential 105 may correspond to one or more attributes related to (or assigned to) the requester 5. For each attribute (“att”), the identity provider system 150 (“IdP”) may send the following to the client device 110: σ att =sign pk(IdP) (att||pk Requestor )

[0030] A requester 5 may wish to prove a claim c about an attribute, e.g., that the requester 5 is over the age of 18, that the requester 5 is a member of organization ABC, that the requester 5 has permission to read the contents of resource data storage component 140, that the requester 5 has been granted access to Tier 2 but not Tier 1, etc. The requester 5 may prove to AGS 120 that c(att) is true, that the identity provider system 150 has proven that the requester 5 has attribute att, and that att was signed (e.g., att was used to assert claim c).

[0031] The claimant 5 may obtain a prover setup 125a from the identity provider system 150. The prover setup 125a includes a corresponding claim PK IdP,c Prover key and structured reference string SRS for IdP can be represented as:

[0032] Using the prover setup 125a, the client device 110 may construct the following proofs: P att,Requestor,IdP =Proof(σ att is valid and c(att)==true,PK IdP,c ,SRS IdP )

[0033] This verifies the following: verify(σ att ,att||pk Requestor )==true and c(att)==true)

[0034] The client device 110 receives the certificate P att,Requestor,IdP to AGS 120. AGS 120 may obtain verifier setup 125b from identity provider system 150. The verifier setup may include a verifier key VK for the corresponding claim. IdP,c and Structured Reference String (SRS) IdP Next, AGS 120 may verify the proof P from client device 110. Verify(P att,Requestor,IdP ,VK IdP,c ,SRS IdP )==valid

[0035] If the claimant's claim c accurately represents the claimant's credential(s) 105, then the proof P establishes that c(att) is true and / or that the identity provider system 150 assigned att to the claimant 5.

[0036] Once AGS 120 verifies the requester's credentials, AGS 120 may obtain corresponding policies 115 from one or more of distributed nodes 160 via computer network 199. AGS 120 may allow requester 5 to access resource system 130 as indicated by policies 115. For example, policies 115 may indicate that credentials 105 correspond to full access to resource system 130, correspond to only certain actions (e.g., read only, no write or delete), and / or correspond to a particular subset(s) of components of resource system 130 or data within resource data storage component 140. For example, components (e.g., subsystems) and / or data may be organized into tiers, and policy 115 indicates access to Tier 3 components and / or data, but not Tier 2 or Tier 1. FIGS. 3A, 3B, 4A, and 4B show examples of different types of resource systems 130 that may be accessed using AGS 120.

[0037] An additional advantage of using zero-knowledge proofs is that the AGS 120 may approve the request 135 "offline," i.e., without a real-time connection to the identity provider system 150 and / or the distributed node 160 (if the AGS 120 has a cached policy 115 previously retrieved from the distributed ledger system 165). This may be useful in high-security applications where the client device 110, the AGS 120, and / or the resource system 130 are "air-gapped" from the wider Internet, but the identity provider system 150 and / or the distributed ledger system 165 are outside this gap. It may also be useful for ensuring that the resource system 130 remains available despite interruptions in power and / or network connectivity within the wider computer network 199.

[0038] 2 is a signal flow diagram illustrating exemplary operation of various components of an exemplary environment 100 including an AGS 120, according to an embodiment of the present disclosure. A resource system 130 may create policies 115 indicating resource access corresponding to particular credentials 105, and an identity provider system (“IdP”) 150 may provide such credentials 105 to an authenticated requester 5. For example, if a client device 110 proves to the AGS 120 that it possesses the attributes represented by the credentials 105, the AGS 120 may obtain the corresponding policies 115 and grant the corresponding access. The resource system 130 may transmit 205 the policy data to one or more of the distributed nodes 160. The identity provider system 150 may transmit 210 the associated credential data to the client device 110, for example, conditional on authentication of the client device 110.

[0039] In some embodiments, identity provider system 150 may provide trusted setup 125 for zero-knowledge proofs between client device 110 and AGS 120. In some embodiments, a different system or component may provide trusted setup 125. In some embodiments, zero-knowledge proofs may be created using a transparent protocol (e.g., without trusted setup). However, in the example operation shown in FIG. 2, identity provider system 150 may send prover setup 125a to the client device (215) and verifier setup 125b to AGS 120 (220).

[0040] To prove possession of the credential and / or attribute, client device 110 may compute 225 a proof (e.g., using credential 105 and an appropriate protocol). In some implementations, client device 110 may compute 225 a proof using prover setup 125a, including, for example, a structured reference string and / or a prover key. Client device 110 may send 230 a proof of the credential(s) and / or attribute(s) to AGS 120. AGS 120 may verify 235 the proof using a protocol that matches the client device's proof. In some implementations, AGS 120 may verify 235 a proof using verifier setup 125b, including, for example, a structured reference string and / or a verifier key.

[0041] Upon verifying the proof, AGS 120 may obtain policy data corresponding to the credential(s) and / or attribute(s) from one or more of distributed nodes 160 (240). AGS 120 may grant client device 110 access to resource system 130 (245). AGS 120 may open a connection between client device 110 and resource system 130. In some embodiments, AGS 120 may act as a proxy for client device 110 to communicate with resource system 130. In some embodiments, AGS 120 authenticates client device 110, and client device 110 can proceed to communicate with resource system 130 without further involvement of AGS 120. In some embodiments, the access granted to requestor 5 may include full access to all features / functionality of resource system 130. However, in some implementations, the policy may specify detailed permissions for only individual or subsets of resource systems 130 and / or associated data (e.g., data stored in resource data storage component 140). Client device 110 may access resource system 130 to the extent permitted by AGS 120 (250).

[0042] FIG. 3A illustrates a first exemplary use case operation of the AGS 120 for data declassification, according to an embodiment of the present disclosure. The first exemplary use case may occur in the environment 300 shown in FIG. 3A , where the AGS 120 serves as a secure gateway between the sensitive data storage component 340 and the secure data system 330 and / or the declassified storage component 350. In various implementations, the secure data system 330 may include and / or communicate with the sensitive data storage component 340 and the declassified storage component 350. The sensitive data storage component 340 may be a repository of sensitive data 345 and may be subject to enhanced data security protocols, including authentication, encryption, access logging, etc. The declassified data storage component 350 may be a repository of unclassified or declassified data (e.g., declassified data 355). The declassified data storage component 350 may be publicly available or may be subject to less restrictive data security protocols than the sensitive data storage component 340.

[0043] A requester 5 may send a request 135 to the AGS 120 to access sensitive data 345 stored in the sensitive data storage component 340. The AGS 120 may act as an additional layer of security for the sensitive data storage component 340. The AGS 120 may also act as an intermediary that can verify whether the policy 115 grants the requester 5 access to the sensitive data 345 while keeping the requester's exact identity hidden from the observer 15. However, if the data is declassified, the observer 15 may be able to view the declassified data 355, the policy 115, and / or a record of the declassification and may trust that the declassification was performed by the proper authorities and through the proper procedures.

[0044] 3B is a signal flow diagram illustrating an example operation of a first example use case according to an embodiment of the present disclosure. The resource system 130 may create a policy 115 indicating resource access corresponding to a particular credential 105, and the identity provider system 150 may provide such credential 105 to an authenticated requester 5. The policy 115 may correspond, for example, to viewing access to sensitive data 345 and / or declassification of the sensitive data 345. The sensitive data storage component 340 (e.g., the owner of the sensitive data 345) may create and send 302 policy data to one or more of the distributed nodes 160. The identity provider system 150 may send 304 credential data to the client device 110, for example, conditioned on authentication of the client device 110. The requester 5 may request access to the sensitive data 345. Accordingly, the client device 110 may send 306 a declassification request 135 to the secure data system 330. The declassification request 135 may be accompanied by proof of the credential(s) and / or attribute(s), or the proof may be calculated and transmitted separately. The secure data system 330 may transmit (308) a request for sensitive data to the AGS 120. The AGS 120 may verify (310) the proof. The calculation and verification of the proof may be performed by one or more of the techniques described above.

[0045] After verifying the proof, AGS 120 may obtain (312) policy data corresponding to the credentials from one or more of distributed nodes 160. AGS 120 may grant (314) the access indicated by the policy data. If the requested operation is permitted, AGS 120 may retrieve (316) the sensitive data 345 from sensitive data storage component 340. AGS 120 may transmit (318) the declassified data 355 to secure data system 330. Secure data system 330 may store (320) the declassified data 355 in declassified data storage component 350 as declassified data 355.

[0046] FIG. 4A illustrates a second exemplary use case operation of AGS 120 granting access to secure data 445 for executing a workflow on data owner system 430, according to an embodiment of the present disclosure. The second exemplary use case may occur in environment 400 shown in FIG. 4A , where AGS 120 serves as a gateway interface to computer resources, such as data owner system 430 and / or secure data storage component 440. Data owner system 430 may include and / or communicate with secure data storage component 440. Secure data storage component 440 may be a repository of confidential, sensitive, or proprietary data and may be subject to enhanced data security protocols, including authentication, encryption, access logging, etc. AGS 120 may grant requestor 5 access to execute a workflow on data owner system 430 using secure data 445. In this manner, AGS 120 may act as a manager between a data analyst (e.g., requestor 5) and data owner system 430, controlling which programs and / or data may be exchanged.

[0047] In some embodiments, the data owner system 430 may delegate authentication of the requester 5 to the identity provider system 150. Thus, the identity provider system 150 may be delegated to verify the attributes of the requester 5 and provide the credential 105 to the requester. In some embodiments, the data owner system 430 may act as its own identity provider system and provide the credential 105 to the authenticated requester 5. The data owner system 430 may create a policy 115 specifying permissions corresponding to the credential 105 and record the policy 115 on one or more of the distributed nodes 160, which may store the policy 115 in a distributed ledger, such as a blockchain. The identity provider system 150 may provide the credential 105 to the authenticated requester 5. The identity provider system 150 may transmit the credential 105 to the client device 110 demonstrating authentication to request execution of a workflow corresponding to the policy 115, as described above.

[0048] A requestor 5 operating a client device 110 may request an action (e.g., a workflow to be executed by the data owner system 430 using the secure data 445) by sending a request 135 to the AGS 120. The request 135 may include or be accompanied by proof of credentials 105. The AGS 120 may verify the proof and obtain corresponding policies 115 from one or more of the distributed nodes 160. The AGS 120 may then authorize the client device 110 to access the secure data 445 and / or request execution of the workflow on the data owner system 430. The data owner system 430 may execute the workflow and return result data to the client device 110 and / or provide the result data to a different component or system.

[0049] In some embodiments, AGS 120 may validate request 135 to determine, for example, whether provided credential(s) 105 authorize the execution of the requested action and / or access to the requested secure data 445. AGS 120 may analyze a workflow to determine whether an operation (or a particular combination of operations) is permitted by policy(ies) 115. For example, a workflow may be a computer-executable program. In some embodiments, AGS 120 may generate an abstract syntax tree for the computer-executable program. The computer program may be written in a programming language (e.g., C, Java, Python). The computer program may be compiled by a compiler that converts the computer program from source code (i.e., human-understandable language) to machine-readable language that creates a computer-executable program. Part of the compilation process may include generating an abstract syntax tree. The abstract syntax tree may represent the structure of the source code for a given program. The structure, representation, and granularity may vary depending on the source code language and compiler. The abstract syntax tree may have, for example, nodes that represent native operations of a programming language, variable or value nodes, and / or function nodes that represent library-defined functions. In some cases, the program and / or abstract syntax tree may include user-defined functions (e.g., written by a requester using library-defined functions).

[0050] Action requests 135 from client devices 110 may include compiled programs and / or abstract syntax trees. AGS 120 may validate library-defined and / or user-defined functions against functions permitted by policy(ies) 115 stored on distributed nodes 160. For example, AGS 120 may traverse the abstract syntax tree to identify functions used in the program and verify that the functions are permitted by cross-referencing the functions against functions in one or more permitted lists. For example, a function library may provide a function such as "combine(int a, Int b)" that adds two parameters (e.g., integer a and integer b). A data analyst or developer may prefer to use familiar function names and thus write a function such as "addnumbers(int c, Int d)" that calls the provided "combine" function. When a program is compiled and an abstract syntax tree is generated, different naming conventions (e.g., "addnumbers") are removed, and the basic operations of the program are constructed. In other words, when "addnumbers" is called in a program, the compilation determines that it is a call to "combine," and therefore "combine" is a function included in the compiled program and abstract syntax tree. Despite the use of "addnumbers" throughout the program, the compiled program may reveal that the call to "addnumbers" is the same as "combine," and AGS120 may determine that the function is allowed.

[0051] If AGS 120 determines that the workflow meets the conditions set forth by policy(ies) 115 (e.g., policy(ies) 115 allow all functionality of the program), AGS 120 may send the workflow to data owner system 430 for execution and / or may indicate to data owner system 430 that the requested action is valid and permitted. In some embodiments, functionality attributed to identity provider system 150 and AGS 120 may be performed by a single component (e.g., identity provider system 150 or AGS 120) and / or may be shared or divided between identity provider system 150 and AGS 120.

[0052] Thus, AGS 120 may provide a secure gateway between client device(s) 110 and data owner system 430. AGS 120 may act as an intermediary that can verify that policies grant requestor(s) 5 access to execute workflows on data owner system 430 while keeping the exact identity of requestor(s) 5 hidden from observer 15. However, observer 15 may be able to verify that the data accessed and / or workflow executed was subject to proper validation of policy(s) 115.

[0053] In some embodiments, environment 400 may include one or more AGSs 120. For example, a first AGS 120 may grant a requester access to data owner system 430, and a second AGS 120 may process workflows and verify that they comply with the permissions granted to the requester 5. In some embodiments, environment 400 may additionally or alternatively include an AGS 120 that controls access to secure data storage component 440 (similar to AGS 120 of FIG. 3A ).

[0054] 4B is a signal flow diagram illustrating an example operation of a second example use case according to an embodiment of the present disclosure. In some implementations, data owner system (“DOS”) 430 may delegate 402 a claim to identity provider system 150 (or, in some embodiments, AGS 120). Identity provider system 150 may create an association between policy 115 and credential 105 for the claim. Policy 115 may correspond to, for example, access to data owner system 430, secure data 445 stored in secure data storage component 440, and / or a defined set of instructions. Identity provider system 150 may transmit 404 associated credential data to client device 110, for example, contingent on authentication of client device 110. Data owner system 430 may transmit 406 the policy data to one or more of distributed nodes 160.

[0055] The requestor 5 may request (408) the performance of an action performed using the secure data 445, for example, on the data owner system 430. The request 135 may be accompanied by proof of the credential(s) and / or attribute(s), or the proof may be computed and transmitted separately. The AGS 120 may verify (410) the proof. The calculation and verification of the proof may be performed by one or more of the techniques described above. After verifying the proof, the AGS 120 may obtain (412) policy data corresponding to the credential from one or more of the distributed nodes 160.

[0056] In some embodiments, AGS 120 may validate 414 the request 135, for example, to determine whether the provided credential(s) 105 authorize the performance of the requested action and / or access the requested secure data 445. AGS 120 may analyze the workflow to determine whether an operation (or a particular combination of operations) is permitted by policy(ies) 115.

[0057] AGS 120 may grant access as indicated by the policy data. If the policy(ies) indicate that the requested action is permitted (e.g., all functions in the workflow are permitted by the policy(ies)), AGS 120 may send a request 135 for workflow execution to the owner system 430 (416). After receiving the workflow, the data owner system 430 may retrieve (418) secure data 445 from the secure data storage component 440. The data owner system 430 may execute (420) the workflow using the retrieved data and send (422) result data back to AGS 120. AGS 120 may send (424) the results to the client device 110 that requested the action and / or another authorized recipient.

[0058] FIG. 5A illustrates a third exemplary use case of AGS 120 operating to authorize the submission of digitally signed content 555 to a content platform 530, in accordance with an embodiment of the present disclosure. The third exemplary use case may occur in the environment 500 illustrated in FIG. 5A , where AGS 120 serves as a gateway to computing resources such as content platform 530. Content platform 530 may be, for example, but not limited to, a document hosting website and / or platform, a video hosting website and / or platform, a file sharing website and / or platform, a social media website and / or platform, etc. In some implementations, content platform 530 may make content (signed and unsigned) publicly available and / or available subject to authentication. Thus, in some cases, the third exemplary use case may be considered the inverse of the first exemplary use case. That is, rather than AGS 120 managing the deletion of data from a repository, AGS 120 may manage the placement of data into a repository. A third use case may be useful in scenarios where it is desirable to authenticate and authorize content uploaded to the content platform 530 while maintaining the anonymity of the requester 5 (e.g., content creator, journalist, internal auditor, etc.).

[0059] The environment 500 may include an identity provider system 150 that may manage identities within the environment 500 (e.g., by enforcing identity access management and / or identity verification guidelines). For example, the identity provider system 150 may provide credentials 105 to authenticated requesters 105. The identity provider system 150 may also create anonymized account identifiers for the requesters 5 (and possibly additional requesters 5). The account identifiers may correspond, for example, to organizations, pseudonyms, anonymous and / or collectively operated social media accounts, etc. The identity provider system 150 and / or requesters 5 may use the account identifiers to indicate the source of the content. An observer 15 may use the account identifier to identify a public key 545 for authenticating an item of signed content. The public key 545 may correspond to the private key 535 of a private-public key pair that the requester 5 may use to implement digital signatures. Digital signatures may be an application of asymmetric cryptography that may use a cryptographic key pair to authenticate and verify content. The requestor 5 may possess a private key 535 and a corresponding public key 545. The requestor 5 may use the private key 535 and the content to generate signed content 555. The requestor 5 may publish the public key 545 to, for example, the distributed ledger system 165. In some cases, the requestor 5 may send the public key 545 to the identity provider system 150, which may publish the public key 545 and, in some implementations, associate the public key 545 with an account identifier.

[0060] A requester 5 may use the AGS 120 to access the content platform 530. The AGS 120 may also act as an intermediary that can verify that a policy 115 (e.g., set by the content platform 530) grants the requester 5 access to the content platform 530, while keeping the requester's exact identity hidden from observers 15. The AGS 120 may allow a requester 5 that proves it has the appropriate credentials 105 to upload signed content 555. The observer 15 may be able to view the signed content 555, the policy 115, and / or the public key 545 and use the public key 545 to verify that the content was properly signed. The observer 15 can trust that the AGS 120 allowed the upload of the signed content 555, conditional on verifying that the uploader proved they had the appropriate credentials 105.

[0061] In some embodiments, an observer 15 may be able to identify an account identifier corresponding to the signed content 555. The observer 15 may use the account identifier to obtain the corresponding public key 545. In some embodiments, the public key 545 may be stored in the distributed ledger system 165. In some embodiments, the public key may be hosted by the content platform 530. In some embodiments, the identity provider system 150 may host the public key 545. The observer 15 can use the public key 545 to verify whether the signature matches the content and therefore verify that the signed content properly belongs to the account identifier. However, a potential counterfeiter would be unable to find a content-signature pair that passes verification by the public key 545. Thus, the observer 15 can use the public key 545 to verify that the item of signed content 555 is authentic. The observer 15 may also trust that the AGS 120 has verified the proof of the requester's credential(s) 105 and that the requester 5 is authorized to upload the signed content 555. However, the observer 15 may not be able to determine the exact identity of the requester 5 by observing either the signed content 555, the public key 545, and / or the interaction between the requester 5 and the AGS 120. This may allow members of an organization or other group to upload signed content 555 anonymously or quasi-anonymously.

[0062] In some implementations, identity provider system 150 may provide credential(s) 105, trust setup 125 for zero-knowledge proofs, and / or public and private key pairs. In some implementations, these features / functions may be performed by different components and / or entities in environment 500. In some implementations, credential(s) 105 may be the same as private key 535. For example, to upload to content platform 530, client device 110 can use zero-knowledge proofs to prove to AGS 120 that the requester possesses private key 535 without revealing private key 535 to AGS 120. Due to the nature of digital signature schemes, when client device 110 sends signed content 555 to content platform 530 via AGS 120, AGS 120 cannot determine private key 535 from signed content 555.

[0063] 5B is a signal flow diagram illustrating an example operation of a third example use case according to an embodiment of the present disclosure. The identity provider system 150 may create an association between a policy 115 and a credential 105. The policy 115 may correspond to, for example, authorization to use a private key 535 and / or to upload signed content 555 to the content platform 530. The content platform 530 may send 502 the policy data to one or more of the distributed nodes 160. The identity provider system 150 may send 504 the associated credential data to the client device 110, for example, contingent on the client device 110's authentication. The requestor 5 may create 506 and / or obtain a public-private key pair for digitally signing content. The requestor 5 may send 508 the public key 545 to one or more of the distributed nodes 160 for recording in the distributed ledger. In some cases, requestor 5 may send public key 545 to identity provider system 150, which may publish public key 545 to distributed node(s) 160. In some cases, identity provider system 150 may associate public key 545 with an account identifier.

[0064] A requester 5 may create content (510). The content may be, for example, a document, a media file, a social media post, etc. The requester 5 may digitally sign the content (512) using a private key 535. Signing the content may include performing a mathematical function on the private key 535 and the unsigned content to generate a digital signature, which may be added to the content. The resulting signed content 555 may be authenticated by the person who owns the signed content 555 and the public key 545 (which may be obtained, for example, from one of the distributed nodes 160). The requester 5 may send the signed content 555 and / or a request to publish the signed content 555 to the AGS 120 (514). The AGS 120 may verify the proof (516). After verifying the proof, the AGS 120 may obtain policy(ies) from one or more of the distributed nodes 160 (518).

[0065] In some embodiments, AGS 120 can additionally or alternatively verify the digital signature. AGS 120 may, for example, obtain (520) a public key from one or more of distributed nodes 160. In some embodiments, one or both of the policy data and the public key may be stored in a distributed ledger. In some embodiments, the policy data and the public key may be stored in the same distributed ledger. In other embodiments, the policy data and the public key may be stored in separate distributed ledgers. AGS 120 may use public key 545 to verify (522) the digital signature applied to signed content 555. Once AGS 120 verifies the attestation and / or digital signature, AGS 120 may enable client device 110 to publish (524) the signed content 555 to content platform 530. In some embodiments, AGS 120 may transmit the signed content 555 to content platform 530. In some embodiments, AGS 120 may provide client device 110 with a token or other data that client device 110 can use to access content platform 530 to directly upload signed content 555.

[0066] 6 is a block diagram illustrating an exemplary user device 600 and system components 700 communicating over a computer network 199, according to an embodiment of the present disclosure. In some implementations, client device 110 may be user device 600 shown in FIG. 6. In some implementations, client device 110 may be system component 700 shown in FIG. 6 and / or a virtual machine running on one or more system components 700. One or more system components 700 may comprise one or more of the components described in exemplary environments 100, 300, 400, and / or 500. For example, AGS 120, resource system 130, resource data storage component 140, identity provider system 150, and / or distributed node 160 may be comprised of (and / or run on) one or more system components 700.

[0067] The user device 600 may operate locally relative to the requestor 5 (e.g., in the same environment so that the device can receive input and playback output for the requestor), while the system component(s) 700 may be located remotely from the user device 600 because their operation may not require proximity to the requestor. The system component(s) may be located in an entirely different location than the user device 600 (e.g., as part of a cloud computing system, etc.), or may be located in the same environment as the user device 600 but physically separated (e.g., a home server or similar device present in the requestor's home or office, but perhaps installed in a closet, basement, attic, etc.). In some implementations, the system component(s) 700 may also be a type of user device 600 that includes different (e.g., higher) processing capabilities than the other user device(s) 600 in the home / office. One advantage of having the system component(s) 700 located within the requester's home / office is that the data used to process commands / return responses can be kept within the requester's home / office, mitigating potential privacy concerns.

[0068] The user device 600 may include one or more controllers / processors 604, each of which may include a central processing unit (CPU) for processing data and computer-readable instructions and a memory 606 for storing the device's data and instructions. The memory 606 may separately include volatile random access memory (RAM), nonvolatile read-only memory (ROM), nonvolatile magnetoresistive RAM (MRAM), and / or other types of memory. The user device 600 may also include data storage components 608 for storing data and controller / processor-executable instructions. Each data storage component 608 may separately include one or more nonvolatile storage types, such as magnetic storage, optical storage, solid-state storage, etc. The user device 600 may also be connected to removable or external nonvolatile memory and / or storage (e.g., removable memory cards, memory key drives, network-attached storage, etc.) through respective input / output device interfaces 602.

[0069] Computer instructions for operating the user device 600 and its various components may be executed by the respective device's controller(s) / processor(s) 604, using the memory 606 as temporary "working" storage during execution. The device's computer instructions may also be stored in a non-transitory manner in the non-volatile memory 606, the data storage component 608, or on an external device(s). Alternatively, in addition to or instead of software, some or all of the executable instructions may be embedded in hardware or firmware on the respective device.

[0070] The user device 600 includes an input / output device interface 602. Various components may be connected through the input / output device interface 602, as further described below. Additionally, the user device 600 may include an address / data bus 610 for communicating data between the respective device components. Each component within the user device 600 may also be directly connected to other components in addition to (or instead of) being connected to other components via the bus 610.

[0071] The user device 600 may include an input / output device interface 602 for connecting to various components, such as an audio output component such as a speaker 612, a wired or wireless headset (not shown), or other component capable of outputting audio. The user device 600 may also include an audio capture component, such as a microphone 620, an array of microphones, a wired or wireless headset (not shown), or the like. If a microphone array is included, the approximate distance to the source of a sound may be determined by sound source localization based on the time and amplitude differences between sounds captured by different microphones in the array. The user device 600 may further include a display 616 for displaying content. The user device 600 may further include a camera 618.

[0072] Via antenna(s) 622, input / output device interface 602 may connect to one or more computer networks 199 via wireless local area network (WLAN) (e.g., WiFi) radio, Bluetooth®, and / or wireless network radios, such as Long Term Evolution (LTE) networks, WiMAX networks, 3G networks, 4G networks, 5G networks, etc. Wired connections, such as Ethernet®, may also be supported. Through network(s) 199, the system may be distributed throughout a network environment. I / O device interface 602 may also include communications components that allow data to be exchanged between devices, such as different physical servers, among a group of servers or other components.

[0073] The system component 700 may include one or more physical devices and / or one or more virtual devices, such as a virtual system running on a cloud server or similar environment. The system component 700 may include one or more input / output device interfaces 702 and a controller / processor 704. The system component 700 may further include storage 706 and memory 708. A bus 710 may enable the input / output device interface 702, the controller / processor 704, the storage 706, and the memory 708 to communicate with each other. Alternatively, or in addition, the components may be directly connected to each other or may be connected via different buses.

[0074] Various components may be connected through an input / output device interface 702. For example, the input / output device interface 702 may be used to connect to a computer network 199. Additional components include a keyboard, a mouse, a display, a touchscreen, a microphone, a speaker, and any other type of user input / output device. Components may further include a USB drive, a removable hard drive, or any other type of removable storage.

[0075] The controller / processor 704 can process data and computer-readable instructions and may include a general-purpose central processing unit, an application-specific processor such as a graphics processor, a digital signal processor, an application-specific integrated circuit, a microcontroller, or any other type of controller or processor. The memory 708 may include volatile random-access memory (RAM), non-volatile read-only memory (ROM), non-volatile magnetoresistive RAM (MRAM), and / or other types of memory. The storage 706 may be used to store data and controller / processor-executable instructions in one or more non-volatile storage types, such as magnetic storage, optical storage, solid-state storage, etc.

[0076] Computer instructions for operating system component 700 and its various components may be executed by controller(s) / processor(s) 704 during execution, using memory 708 as temporary "working" storage. The computer instructions may also be stored in a non-transitory manner in non-volatile memory 708, storage 706, and / or external device(s). Alternatively, in addition to or instead of software, some or all of the executable instructions may be embedded in hardware or firmware on the respective device.

[0077] The material herein may also be understood in light of the following clauses.

[0078] 1. A computer-implemented method comprising: receiving, by an access gateway system, a first request to access a computer resource from a first client device; receiving first data from the first client device representing a zero-knowledge proof of possession of a first credential; using the first data to verify that the first client device likely corresponds to the first credential; in response to verifying that the first client device likely possesses the first credential, obtaining policy data corresponding to the first credential from a distributed ledger system; determining that the policy data grants an owner of the first credential access to the computer resource; and in response to determining that the policy data grants the owner of the first credential access to the computer resource, enabling the first client device to access the computer resource.

[0079] 2. The computer-implemented method of clause 1 or 2, further comprising: receiving from the first client device a second request to upload second data for hosting by the computer resource, the second data representing digitally signed content; determining that the policy data authorizes the owner of the first credential to upload the second data to the computer resource; and causing the computer resource to receive the second data in response to determining that the policy data authorizes the owner of the first credential to upload the second data to the computer resource.

[0080] 3. The computer-implemented method of clause 2, further including: determining that the second request corresponds to an account identifier; obtaining, from the distributed ledger system, third data representing a public cryptographic key corresponding to the account identifier; and authenticating the second data using the third data, wherein causing the computer resource to receive the second data is further based on authenticating the second data.

[0081] 4. The computer-implemented method of clause 1, 2, or 3, further comprising: receiving a second request to declassify a secure data item from the first client device; determining that the policy data authorizes the owner of the first credential to declassify the secure data item; and, in response to determining that the policy data authorizes the owner of the first credential to declassify the secure data item, causing the computer resource to move the secure data item from a first data storage component to a second data storage component, the first data storage component representing a secure data store.

[0082] 5. The computer-implemented method of clause 1, 2, 3, or 4, further comprising: receiving from the first client device a second request for the computer resource to execute a computer program using second data stored by the computer resource; determining that the policy data authorizes the owner of the first credential to access the second data; and, in response to determining that the policy data authorizes the owner of the first credential to access the second data, causing the computer resource to execute the computer program using the second data to generate result data and transmit the result data to the first client device.

[0083] 6. The computer-implemented method of clause 5, further comprising: analyzing the computer program to identify at least a first function to be performed using the second data; and determining that the policy data authorizes the owner of the first credential to perform the at least first function, wherein causing the computer resource to execute the computer program is further based on determining that the policy data authorizes the at least first function.

[0084] 7. The computer-implemented method of clause 1, 2, 3, 4, 5, or 6, further including: receiving second data representing a verifier key from an identity provider system, wherein the identity provider system sends third data representing a prover key corresponding to the verifier key to the first client device; causing the first client device to generate the first data using the third data; and processing the first data and the second data to determine that the first data is likely to represent a true claim.

[0085] 8. The computer-implemented method of clause 1, 2, 3, 4, 5, 6, or 7, further including: sending to the distributed ledger system the policy data indicating a first association between the first credential and the policy data regarding the computer resource; and sending to the first client device first credential data representing the first credential.

[0086] 9. The computer-implemented method of clause 8, further comprising transmitting second credential data representing the first credential to a second client device.

[0087] 10. The computer-implemented method of clause 1, 2, 3, 4, 5, 6, 7, 8, or 9, further including receiving a second request to access the computer resource from the first client device, the first request corresponding to a first operation and the second request corresponding to a second operation different from the first operation; determining that the policy data allows the first operation but does not allow the second operation; and rejecting the second request by the access gateway system in response to determining that the policy data does not allow the second operation.

[0088] 11. A system comprising at least one processor and at least one memory containing instructions that, when executed by the at least one processor, cause the system to: receive, via an access gateway system, a first request to access a computer resource from a first client device; receive, from the first client device, first data representing a zero-knowledge proof of possession of a first credential; use the first data to verify that the first client device likely corresponds to the first credential; in response to verifying that the first client device likely possesses the first credential, retrieve policy data corresponding to the first credential from a distributed ledger system; determine that the policy data grants an owner of the first credential access to the computer resource; and in response to determining that the policy data grants the owner of the first credential access to the computer resource, enable the first client device to access the computer resource.

[0089] 12. The system of clause 11, wherein the instructions further cause the system to receive from the first client device a second request to upload second data for hosting by the computer resource, the second data representing digitally signed content; determine that the policy data authorizes the owner of the first credential to upload the second data to the computer resource; and cause the computer resource to receive the second data in response to determining that the policy data authorizes the owner of the first credential to upload the second data to the computer resource.

[0090] 13. The system of clause 12, wherein the instructions further cause the system to: determine that the second request corresponds to an account identifier; receive from the distributed ledger system third data representing a public cryptographic key corresponding to the account identifier; and authenticate the second data using the third data, wherein causing the computer resource to receive the second data is further based on authenticating the second data.

[0091] 14. The system of clause 11, 12, or 13, wherein the instructions further cause the system to: receive a second request to declassify a secure data item from the first client device; determine that the policy data authorizes the owner of the first credential to declassify the secure data item; and, in response to determining that the policy data authorizes the owner of the first credential to declassify the secure data item, cause the computer resource to move the secure data item from a first data storage component to a second data storage component, the first data storage component representing a secure data store.

[0092] 15. The system of clause 11, 12, 13, or 14, wherein the instructions further cause the system to: receive a second request from the first client device for the computer resource to execute a computer program using second data stored by the computer resource; determine that the policy data authorizes the owner of the first credential to access the second data; and, in response to determining that the policy data authorizes the owner of the first credential to access the second data, cause the computer resource to execute the computer program using the second data to generate result data and send the result data to the first client device.

[0093] 16. The system of clause 15, wherein the instructions further cause the system to: analyze the computer program to identify at least a first function to be performed using the second data; and determine that the policy data authorizes the owner of the first credential to perform the at least first function, wherein causing the computer resource to execute the computer program is further based on determining that the policy data authorizes the at least first function.

[0094] 17. The system of clause 11, 12, 13, 14, 15, or 16, wherein the instructions further cause the system to receive second data representing a verifier key from an identity provider system, wherein the identity provider system sends third data representing a prover key corresponding to the verifier key to the first client device; cause the first client device to generate the first data using the third data; and process the first data and the second data to determine that the first data is likely to represent a true claim.

[0095] 18. The system of clause 11, 12, 13, 14, 15, 16, or 17, wherein the instructions further cause the system to: send to the distributed ledger system the policy data indicating a first association between the first credential and the policy data regarding the computer resource; and send to the first client device first credential data representing the first credential.

[0096] 19. The system of clause 18, wherein the instructions further cause the system to send second credential data representing the first credential to a second client device.

[0097] 20. The system of clause 11, 12, 13, 14, 15, 16, 17, 18, or 19, wherein the instructions further cause the system to: receive a second request to access the computer resource from the first client device, the first request corresponding to a first operation and the second request corresponding to a second operation different from the first operation; determine that the policy data allows the first operation but does not allow the second operation; and deny the second request by the access gateway system in response to determining that the policy data does not allow the second operation.

[0098] The foregoing aspects of the present disclosure are intended to be illustrative. They have been selected to illustrate the principles and applications of the present disclosure and are not intended to be exhaustive or to limit the present disclosure. Many modifications and variations of the disclosed aspects may be apparent to those skilled in the art. Those of ordinary skill in the computer and data processing arts will recognize that the components and process steps described herein may be interchangeable with other components or steps, or combinations of components or steps, and still achieve the benefits and advantages of the present disclosure. Moreover, those skilled in the art will recognize that the present disclosure may be practiced without some or all of the specific details and steps disclosed herein.

[0099] Aspects of the disclosed system may be implemented as a computer method or as an article of manufacture, such as a memory device or non-transitory computer-readable storage medium. The computer-readable storage medium may be readable by a computer and may contain instructions that cause a computer or other device to perform the processes described in this disclosure. The computer-readable storage medium may be implemented by volatile computer memory, non-volatile computer memory, a hard drive, a solid-state memory, a flash drive, a removable disk, and / or other media. Furthermore, one or more components of the modules and engines may be implemented as firmware or hardware.

[0100] As used herein, conditional language, such as "can," "could," "may," "may," "for example," and the like, among others, is generally intended to convey that certain embodiments include certain features, elements, and / or steps, and that other embodiments do not, unless specifically stated otherwise or understood otherwise within the context of use. Thus, such conditional language is generally not intended to imply that features, elements, and / or steps are required in any way with respect to one or more embodiments, or that one or more embodiments necessarily include logic for determining, with or without other input or prompts, whether these features, elements, and / or steps are included in or should be performed in any particular embodiment. The terms "comprise," "include," "have," and the like are synonymous and used inclusively in an open-ended manner and do not exclude additional elements, features, acts, operations, etc. Additionally, the term "or" is used in its inclusive (not exclusive) sense; for example, when used to connect a list of elements, the term "or" refers to one, some, or all of the elements in the list.

[0101] Disjunctive language, such as the phrase "at least one of X, Y, Z," is generally used to indicate that an item, term, etc. can be either X, Y, or Z, or any combination thereof (e.g., X, Y, and / or Z), unless specifically stated otherwise, and will be understood otherwise depending on the context. Thus, such disjunctive language is generally not intended, and should not be intended, to imply that a particular embodiment requires that at least one of X, at least one of Y, or at least one of Z, respectively, be present. As used in this disclosure, the terms "a" or "an" may include one or more items unless otherwise specified. Additionally, the phrase "based on" is intended to mean "based at least in part on," unless otherwise specified.

Claims

1. 1. A computer-implemented method comprising: receiving, by the access gateway system, a first request to access a computer resource from a first client device; receiving first data from the first client device representing a zero-knowledge proof of possession of a first credential; using the first data to verify that the first client device likely corresponds to the first credential; In response to verifying that the first client device likely possesses the first credential, obtaining policy data corresponding to the first credential from a distributed ledger system; and determining that the policy data grants the owner of the first credential access to the computer resource; and enabling the first client device to access the computer resource in response to determining that the policy data grants the owner of the first credential access to the computer resource.

2. receiving, from the first client device, a second request to upload second data for hosting by the computer resource, the second data representing digitally signed content; determining that the policy data authorizes the owner of the first credential to upload the second data to the computer resource; 3. The computer-implemented method of claim 1, further comprising: in response to determining that the policy data authorizes the owner of the first credential to upload the second data to the computer resource, causing the computer resource to receive the second data.

3. determining that the second request corresponds to an account identifier; obtaining, from the distributed ledger system, third data representing a public encryption key corresponding to the account identifier; 3. The computer-implemented method of claim 2, further comprising: authenticating the second data using the third data, wherein causing the computer resource to receive the second data is further based on authenticating the second data.

4. receiving a second request to declassify a secure data item from the first client device; determining that the policy data authorizes the owner of the first credential to declassify the secure data item; 4. The computer-implemented method of claim 1, further comprising: in response to determining that the policy data authorizes the owner of the first credential to declassify the secure data item, causing the computer resource to move the secure data item from a first data storage component to a second data storage component, the first data storage component representing a secure data store.

5. receiving a second request from the first client device for the computer resource to execute a computer program using second data stored by the computer resource; determining that the policy data authorizes the owner of the first credential to access the second data; 5. The computer-implemented method of claim 1, further comprising: in response to determining that the policy data authorizes the owner of the first credential to access the second data, causing the computer resource to execute the computer program using the second data to generate result data and transmit the result data to the first client device.

6. analyzing the computer program to identify at least a first function to be performed using the second data; 6. The computer-implemented method of claim 5, further comprising: determining that the policy data authorizes the owner of the first credential to perform the at least a first function, wherein causing the computer resource to execute the computer program is further based on determining that the policy data authorizes the at least a first function.

7. receiving second data representing a verifier key from an identity provider system, the identity provider system sending third data representing a prover key corresponding to the verifier key to the first client device; causing the first client device to generate the first data using the third data; 7. The computer-implemented method of claim 1, further comprising: processing the first data and the second data to determine that the first data is likely to represent a true claim.

8. sending, to the distributed ledger system, the policy data indicating a first association between the first credential and the policy data regarding the computer resource; 8. The computer-implemented method of claim 1, further comprising: transmitting first credential data representing the first credential to the first client device.

9. The computer-implemented method of claim 8 , further comprising transmitting second credential data representing the first credential to a second client device.

10. receiving a second request to access the computer resource from the first client device, the first request corresponding to a first operation and the second request corresponding to a second operation different from the first operation; determining that the policy data permits the first operation but does not permit the second operation; 10. The computer-implemented method of claim 1, further comprising: in response to determining that the policy data does not allow the second operation, rejecting the second request by the access gateway system.

11. 1. A system comprising: at least one processor; at least one memory containing instructions that, when executed by the at least one processor, cause the system to: receiving, by the access gateway system, a first request to access a computer resource from a first client device; receiving first data from the first client device representing a zero-knowledge proof of possession of a first credential; using the first data to verify that the first client device likely corresponds to the first credential; In response to verifying that the first client device likely possesses the first credential, obtaining policy data corresponding to the first credential from a distributed ledger system; and determining that the policy data grants the owner of the first credential access to the computer resource; and enabling the first client device to access the computer resource in response to determining that the policy data grants the owner of the first credential access to the computer resource.

12. The instructions may include: receiving, from the first client device, a second request to upload second data for hosting by the computer resource, the second data representing digitally signed content; determining that the policy data authorizes the owner of the first credential to upload the second data to the computer resource; 12. The system of claim 11, further causing the computer resource to receive the second data in response to determining that the policy data authorizes the owner of the first credential to upload the second data to the computer resource.

13. The instructions may include: determining that the second request corresponds to an account identifier; receiving third data from the distributed ledger system representing a public encryption key corresponding to the account identifier; 13. The system of claim 12, further causing the computer resource to receive the second data by authenticating the second data using the third data, the authenticating being further based on authenticating the second data.

14. The instructions may include: receiving a second request to declassify a secure data item from the first client device; determining that the policy data authorizes the owner of the first credential to declassify the secure data item; 14. The system of claim 11, 12, or 13, further causing the computer resource to move the secure data item from a first data storage component to a second data storage component in response to determining that the policy data authorizes the owner of the first credential to declassify the secure data item, the first data storage component representing a secure data store.

15. The instructions may include: receiving a second request from the first client device for the computer resource to execute a computer program using second data stored by the computer resource; determining that the policy data authorizes the owner of the first credential to access the second data; 15. The system of claim 11, 12, 13, or 14, further causing the computer resource to execute the computer program using the second data to generate result data and transmit the result data to the first client device in response to determining that the policy data authorizes the owner of the first credential to access the second data.

Images