WO2019078879A1 - Permissions from entities to access information - Google Patents
Permissions from entities to access information Download PDFInfo
- Publication number
- WO2019078879A1 WO2019078879A1 PCT/US2017/057558 US2017057558W WO2019078879A1 WO 2019078879 A1 WO2019078879 A1 WO 2019078879A1 US 2017057558 W US2017057558 W US 2017057558W WO 2019078879 A1 WO2019078879 A1 WO 2019078879A1
- Authority
- WO
- WIPO (PCT)
- Prior art keywords
- information
- authorization
- access
- entities
- client device
- Prior art date
Links
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L67/00—Network arrangements or protocols for supporting network services or applications
- H04L67/01—Protocols
- H04L67/10—Protocols in which an application is distributed across nodes in the network
- H04L67/1097—Protocols in which an application is distributed across nodes in the network for distributed storage of data in networks, e.g. transport arrangements for network file system [NFS], storage area networks [SAN] or network attached storage [NAS]
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/321—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority
- H04L9/3213—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving a third party or a trusted authority using tickets or tokens, e.g. Kerberos
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/62—Protecting access to data via a platform, e.g. using keys or access control rules
- G06F21/6218—Protecting access to data via a platform, e.g. using keys or access control rules to a system of files or objects, e.g. local or distributed file system or database
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F21/60—Protecting data
- G06F21/64—Protecting data integrity, e.g. using checksums, certificates or signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L63/00—Network architectures or network communication protocols for network security
- H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0816—Key establishment, i.e. cryptographic processes or cryptographic protocols whereby a shared secret becomes available to two or more parties, for subsequent use
- H04L9/0819—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s)
- H04L9/0825—Key transport or distribution, i.e. key establishment techniques where one party creates or otherwise obtains a secret value, and securely transfers it to the other(s) using asymmetric-key encryption or public key infrastructure [PKI], e.g. key signature or public key certificates
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/08—Key distribution or management, e.g. generation, sharing or updating, of cryptographic keys or passwords
- H04L9/0894—Escrow, recovery or storing of secret information, e.g. secret key escrow or cryptographic key storage
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3226—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using a predetermined code, e.g. password, passphrase or PIN
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3234—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving additional secure or trusted devices, e.g. TPM, smartcard, USB or software token
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3236—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions
- H04L9/3239—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials using cryptographic hash functions involving non-keyed hash functions, e.g. modification detection codes [MDCs], MD5, SHA or RIPEMD
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/32—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials
- H04L9/3247—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols including means for verifying the identity or authority of a user of the system or for message authentication, e.g. authorization, entity authentication, data integrity or data verification, non-repudiation, key authentication or verification of credentials involving digital signatures
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
- H04L9/50—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols using hash chains, e.g. blockchains or hash trees
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2221/00—Indexing scheme relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/21—Indexing scheme relating to G06F21/00 and subgroups addressing additional information or applications relating to security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
- G06F2221/2141—Access rights, e.g. capability lists, access control lists, access tables, access matrices
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L2209/00—Additional information or applications relating to cryptographic mechanisms or cryptographic arrangements for secret or secure communication H04L9/00
- H04L2209/56—Financial cryptography, e.g. electronic payment or e-cash
Definitions
- a storage system can store information for which requests can be submitted by client devices for access to the information.
- access to the storage system can be granted by a server that manages access to the information in the storage system.
- an access control and/or policy management system determines whether a client device is allowed to access to requested information in the storage system.
- Fig. 1 is a block diagram of an arrangement according to some examples.
- Fig. 2 is a message flow diagram of a process according to some examples.
- FIG. 3 is a block diagram of a storage medium storing machine-readable instructions according to other examples.
- FIG. 4 is a block diagram of an authorization facilitator system according to further examples.
- Fig. 5 is a block diagram of a resource server system according to additional examples.
- a storage system can store information for which requests can be submitted by client devices for access to the information.
- the information stored in the storage system can include data referenced by blocks of a blockchain.
- the storage system can include a distributed arrangement of storage nodes for storing respective pieces of information referenced by the blockchain blocks.
- the distributed storage system can be operated by different entities.
- One type of distributed storage systems can be referred to as a swarm, which is used in Ethereum, one of the variants of blockchain deployment. Entities in the blockchain can dynamically upload information pertaining to transactions into the distributed storage systems, including when additional information cannot be stored in blockchain due to various constraints on the blockchain.
- a blockchain refers to a distributed collection of records (referred to as "blocks") that are linked and secured cryptographically in a distributed manner.
- a blockchain can also refer to a continuous and unbroken ledger of blocks.
- the blocks of the blockchain can be distributed across a large number of computing devices.
- Each block can include various information, including transaction data for a transaction represented by the block, a timestamp, and a reference to a previous block in the blockchain.
- new blocks are created for the new transactions and added to the blockchain.
- a blockchain (which form a distributed transaction ledger) records transactions among multiple entities in a verifiable and permanent way. Once a block is created and the data of the block recorded, the block cannot be altered without alteration of subsequent blocks.
- a blockchain network includes “nodes” (referred to as blockchain nodes, full nodes, or blockchain full nodes) that can process requests to access the information.
- nodes referred to as blockchain nodes, full nodes, or blockchain full nodes
- owners also referred to as data owner entities
- a client entity can refer to an entity that is associated with a client device.
- a client entity can refer to any of the following: the client device itself, a user of the client device, a program or component in the client device, and so forth.
- the resource server is able to grant access to the information in the distributed storage system without first consulting with the owners of the information, then unauthorized entities may potentially be able to access the information in the distributed storage system.
- the distributed storage system may contain different categories of information that can be associated with different privilege levels relating to which client entities can access the different categories of information.
- an authorization requirement can indicate that authorization tokens have to be first obtained from the owners of the corresponding information before the corresponding information can be shared with a client entity.
- an authorization requirement can specify that different categories of information have different privilege levels for which different authorizations are to be obtained.
- An authorization requirement can specify different types of requirements for approval of information access, such as based on a client entity being part of a predefined group, the client entity having certain knowledge, the client entity having made payment for accessing information, the information accessed being approved by a contract, and so forth.
- Fig. 1 is a block diagram of an example arrangement that includes a client device 102 that is able to send a request to access information stored in a distributed storage system 104, an authorization facilitator system 106, and a resource server system 108.
- client device 102 that is able to send a request to access information stored in a distributed storage system 104
- authorization facilitator system 106 an authorization facilitator system 106
- resource server system 108 a resource server system 108.
- the client device 102 can include any type of computing device that is able to communicate over a network and to submit a request for information.
- Examples of the client device 102 can include any or some combination of the following: a smartphone, a tablet computer, a notebook computer, a desktop computer, a wearable device (e.g., smart eyeglasses, a head-mounted electronic device, a smart watch, etc.), a game appliance, a home appliance, a vehicle, or any other type of electronic device.
- a smartphone e.g., a tablet computer, a notebook computer, a desktop computer, a wearable device (e.g., smart eyeglasses, a head-mounted electronic device, a smart watch, etc.), a game appliance, a home appliance, a vehicle, or any other type of electronic device.
- the client device 102 can include a blockchain-based application 103 that interacts with the authorization facilitator system 106 to request information referred to by a blockchain 1 1 1 stored in a blockchain network 1 10.
- the request for information can seek information in the distributed storage system 104 that can be associated with an authorization requirement where permissions have to be obtained from owners of the requested information.
- the client device 102 can also include a cryptographic currency wallet application 105, which can be used to make payment for a transaction or to make payment for accessing data or to make payment for any other purpose.
- the distributed storage system 104 stores data 107 that is referenced by blocks of the blockchain 1 1 1 . In examples shown according to Fig. 1 , instead of storing actual data in the blocks of the blockchain 1 1 1 , data is stored in the distributed storage system 104.
- the distributed storage system 104 can be implemented with a distributed arrangement of storage nodes that store the data 107 in a distributed manner.
- Each piece of data 107 in the distributed storage system 104 can have an owner, or alternately, can have multiple owners.
- An owner of a piece of data can refer to an entity (such as a user, an organization, a machine, a program, etc.) that is able to grant permission to access the piece of data.
- a "piece of data" can refer to any unit of data that can be separately identifiable, such as a file, an object, a chunk, and so forth.
- the authorization facilitator system 106 (implemented as a distributed arrangement of computing nodes) interacts with client devices (including the client device 102), the blockchain network 1 10, and owner systems 1 12-A and 1 12-B, to allow the client devices to obtain authorization to access information in the
- the owner systems 1 12-A and 1 12-B are associated with respective owners of information that can be stored in the distributed storage system 104.
- Each owner system can be implemented as a single computing node or a distributed arrangement of computing nodes.
- the resource server system 108 (implemented as a distributed
- the resource server system 108 can inform the authorization facilitator system 106 (and possibly the client device 102) that permissions have to first be obtained from owners of the requested information before the client device 102 is able to be granted access to the requested information. In such cases, the resource server system 108 does not make the determination of whether the client device 102 has permission to access the requested information. Rather, the resource service system 108 can provide identities of the owners, and it is the responsibility of the client device 102 and/or the authorization facilitator system 106 to obtain the permissions from the owners.
- the computing nodes of the authorization facilitator system 106 include request processing nodes 120 and blockchain nodes 122.
- the blockchain nodes 122 can be part of another system separate from the authorization facilitator system 106.
- the blockchain nodes 122 are part of the blockchain network 1 10.
- the request processing nodes 120 are able to interact with corresponding client devices 102, to receive requests from the client devices 102 and to send response information (responsive to the requests) to the client devices 102.
- the request processing nodes 120 can also interact with the owner systems 1 12-A and 1 12-B to seek permissions for client entity access of information in the distributed storage system 104.
- the blockchain nodes 122 store all blocks of the blockchain 1 1 1 and perform processing relating to the blocks of the blockchain 1 1 1 .
- the blockchain nodes 122 are able to provide distributed processing for granting access in response to requests from client devices 102.
- the computing nodes of the resource server system 108 include storage processing nodes 124 that are able to manage access of the distributed storage nodes of the distributed storage system 104.
- An authorization requirement for requested information can specify that permissions from owners have to first be obtained before access is granted to the requested information.
- different pieces of information can be associated with different privilege levels.
- the different pieces of information can include different categories of information.
- the different categories of information can include the following: a first category of information that includes information of a patient of the hospital, a second category of information that includes information of a pharmacy in the hospital, a third category of information that includes information that includes information of lab results obtained by testing done by the hospital, a fourth category of information that is associated with equipment in the hospital, and so forth. In other contexts, there can be other categories of information.
- Each category of information is associated with a corresponding privilege level. For example, for first privilege level, the owners of the respective piece of information may determine that certain client devices are allowed access, while other client devices are not allowed access. For a second privilege level, the owners can determine that more classes of client entities are allowed access to the given piece of information.
- the resource server system 108 includes a smart contract manager 1 16.
- the smart contract manager 1 16 can be implemented as a single computing node or as a distributed arrangement of computing nodes.
- the smart contract manager 1 16 has access to a smart contract database 1 18 that contains smart contracts 1 19.
- a smart contract 1 19 provides logic and rules executed by computing device(s) for a blockchain to automate terms of a contract among multiple entities.
- a smart contract can include blockchain addresses of the parties of the smart contract, information relating to terms of the smart contract, and other information.
- a smart contract can be established among multiple entities.
- a smart contract manager implements enforcement of smart contracts.
- a blockchain address refers to an identifier.
- a blockchain address is analogous to an account number.
- An entity such as a user or a device
- a blockchain address can be generated based on use of a pair of keys including a public key and a private key associated with an entity.
- the smart contract manager 1 16 can access a selected smart contract of the smart contracts 1 19 in the smart contract database 1 18. Based on the selected smart contract, the smart contract manager 1 16 is able to determine the authorization requirement (if any) for access of requested information.
- the authorization requirement for particular information in the distributed storage system 104 can indicate that permissions from owners of the particular information do not have to be first obtained before access is granted to the particular information.
- the resource server system 108 can grant access to the particular information to the client device 102 without indicating that permissions from the owners have to first be obtained.
- the authorization requirement for particular information in the distributed storage system 104 can indicate that permissions from owners of the particular information have to be first obtained before access is granted to the particular information.
- the resource server system 108 can interact with the authorization facilitator system 106 and/or the client device 102 to cause the authorization facilitator system 106 and/or the client device 102 to obtain
- the pieces of information can be tagged with identification information (in tags) that identifies the owners of the pieces of information, and privilege information indication the privilege levels required to access the respective pieces of information.
- identification information in tags
- privilege information indication the privilege levels required to access the respective pieces of information.
- the determination of owners of pieces of information can be based on which entities digitally signed the pieces of information for storage in the distributed storage system 104.
- Digitally signing a piece of information refers to an entity encrypting the piece of information with a private key of the entity, such as according to a Public Key Infrastructure (PKI) digital signing.
- PKI Public Key Infrastructure
- Multiple parties may be owners with differing levels of privilege levels for the same piece of information.
- the multiple owners can sign the piece of information.
- all ownership-related signing and privilege level- related tagging have to be done while storing the information.
- the resource server system 108 and the distributed storage system 104 are guardians of the information, with the ability to grant permission for access controlled by the owners.
- the authorization requirements e.g., the conditions or rules governing access
- the authorization requirements can be stored in smart contracts (1 19) managed by the smart contract manager 1 16. Privilege levels and multiparty ownership information are available to the smart contract manager 1 16.
- the smart contract manager 1 16 can create smart contracts for processing in the future.
- the authorization facilitator system 106 includes a logging manager 123 that logs access of certain piece of information in the distributed storage system 104 by a client entity after authorization by respective owners.
- the log of the transaction can also be made part of the blockchain 1 1 1 , or alternately, as part of the blockchain 1 1 1 and log information stored in the distributed storage system 104.
- the resource server system 108 can also include a logging manager 1 15 to log similar information as the logging manager 123.
- the resource server system 108 includes a payment manager 1 17, which can be implemented as a single computing node or a
- the payment manager 1 17 can collect payment from the client entity as part of providing the requested information to the client device 102.
- the payment manager 1 17 can interact with the cryptographic current wallet application 105 of the client device 102 to collect the payment. Additionally, the payment manager 1 17 can also collect payment from a given owner of information in response to storing the information owned by the given owner with multiparty ownership and privilege levels in the distributed storage system 104.
- Fig. 2 is a message flow diagram of a process involving components shown in Fig. 1 , according to some examples.
- the client device 102 sends an information request (at 202) to the authorization facilitator system 106, to request information stored in the distributed storage system 104.
- the information stored in the distributed storage system 104 includes data 107 referenced by respective blocks of the blockchain 1 1 1 .
- the information request submitted by the client device 102 can include a blockchain address of an entity, which can be any of the following: a product, a machine, a program, a human user, or any other type of entity.
- entity identified by the blockchain address can be associated with corresponding transactions that are represented by the blocks of the blockchain 1 1 1 .
- the blockchain address included in the information request can relate to specific transaction information of the blockchain.
- transaction information can refer to information of a single transaction or information of multiple transactions.
- the authorization facilitator system 106 (and more specifically, the blockchain full nodes 122 of Fig. 1 ) is able to check with the blockchain network 1 10 to determine (at 204) a location of the requested information.
- a "location" of the requested information can refer to a geographic location, a storage system, a resource server system that manages access of a system that includes the requested information, or any other indication of what entity the authorization facilitator system 106 is to interact with to obtain access to the requested information.
- the blockchain network 1 10 can respond with location information for the requested information.
- location information for the requested information.
- Some of the techniques can include retrieving content using a Hypertext Transfer Protocol (HTTP), a proxy scheme, Ethereum's bzz scheme, a Uniform Resource Locator (URL) scheme, path matching on manifests, an Ethereum Name Service, and so forth.
- HTTP Hypertext Transfer Protocol
- the Ethereum Name Service is similar to Domain Name System (DNS) in the Internet world.
- DNS Domain Name System
- Distributed database service providers can register for a .eth domain as well, to allow for a distributed storage system of each distributed database service provider to be located.
- the location information can include an IP address that serves as an identifier corresponding to the location of the resource server system 108 that the authorization facilitator system 106 is to contact to obtain access of the requested information.
- an identifier corresponding to the location of the server could be extracted from a location services application that calculates the position in physical space, uses a radio frequency identification (RFID) tag, calculates position from a Global Positioning Satellite (GPS) service, or some other method of establishing location.
- RFID radio frequency identification
- the authorization facilitator system 106 (e.g., one of the request processing nodes 120 of Fig. 1 ) sends an authorization request (at 206) to the resource server system 108.
- the authorization request provides an indication to the resource server system 108 that the client device 102 is seeking access to the requested information, and that authorization information is being sought to determine how to obtain authorization (if any) to access the requested information.
- storage processing node(s) of the resource server system 108 retrieves (at 207) the requested information from the distributed storage system 104.
- the smart contract manager 1 16 of the resource server system 108 checks (at 208) an authorization requirement relating to the requested information.
- the authorization requirement may have been registered by owners of the requested information, or may have been registered by the resource server system 108.
- the authorization requirement can be included as a term of a smart contract (1 19 in Fig. 1 ) in some examples.
- the smart contract manager 1 16 can check the relevant smart contract to determine the authorization requirement for the requested information.
- the resource server system 108 determines (at 210) whether owner permissions have to be obtained to grant access to the requested information. If owner permissions have to be obtained, the smart contract manager 1 16 can obtain the identities of the owners of the requested information (such as from the tags associated with the pieces of the requested information retrieved from the distributed storage system 104), and can send authorization information (at 212) to the authorization facilitator system 106.
- the authorization information 212 can include identities of the owners of the requested information from which permissions are to be obtained to grant access to the requested information.
- the authorization information 212 can also include a privilege level (or multiple privilege levels) associated with the requested information.
- the privilege level(s) can also be obtained from the tags associated with the pieces of the requested information retrieved from the distributed storage system 104.
- the authorization information 212 can specify the authorization requirement for each privilege level. For example, if the requested information includes multiple pieces of information associated with different privilege levels, the authorization information 212 can include multiple privilege levels, and authorization requirements for each of the multiple privilege levels.
- the authorization information 212 is delivered to the authorization facilitator system 106, and possibly also to the client device 102. In other examples, the authorization information 212 is sent to the authorization facilitator system 106, which in turn can either process the
- authorization information 212 itself or can forward the authorization information 212 to the client device 102.
- the authorization facilitator system 106 (such as one of the request processing nodes 120) can cause the client device 102 to obtain permissions from the identified owners (as identified by the authorization information 212).
- the authorization facilitator system 106 can send a permission message (at 214) to the client device 102, where the permission message is to cause a client entity associated with the client device 102 to seek permissions from the identified owners.
- the client device 102 performs an authorization process (at 216) with the owner systems 1 12-A and 1 12-B (assuming that the owner systems 1 12-A and 1 12-B are systems associated with the identified owners in the authorization information 212).
- the authorization process (at 216) can be performed in response to the client entity (e.g., user, program, etc.) associated with the client device 102 indicating that the authorization process is to be performed.
- the authorization process is according to the OAuth protocol, which is a standard for access delegation, to allow the owners of pieces of information to grant other entities, such as the distributed storage system 104, access to the pieces of information owned by the owners, but without giving the other entities the authorization tokens that are to be used for access to such pieces of information.
- OAuth protocol is a standard for access delegation, to allow the owners of pieces of information to grant other entities, such as the distributed storage system 104, access to the pieces of information owned by the owners, but without giving the other entities the authorization tokens that are to be used for access to such pieces of information.
- an "authorization token” (also referred to an "access token”) includes a credential (such as a password, an encryption key, or any other access information that can be used to obtain access of a particular piece of information).
- an authorization token is a context-based
- authorization tokens that restricts access based on context, as represented by one or some combination of the following context parameters: a specified time and date range, a location, an identity of a client entity, or other contextual parameter.
- the context-based authorization token can specify a specific context for access, and any request received outside the specific context can be rejected by the resource server system 108.
- the client device 102 sends the received authorization tokens (at 218) to the authorization facilitator system 106.
- the authorization facilitator system 106 (such as one of the request processing nodes 120) sends the authorization tokens (at 220) to the resource server system 108.
- the client device 102 can send the authorization tokens directly to the resource server system 108 (without first forwarding to the
- the resource server system 108 validates (at 222) the received authorization tokens.
- the validation can be based on access of the relevant smart contract by the smart contract manager 1 16 of the resource server system 108.
- Validating an authorization token can refer to confirming that the authorization token contains the correct access information (e.g., correct password, correct biometric data such as a voice- or fingerprint, correct encryption key, correct digital signature, etc.) that can be used to obtain access to the requested information.
- the correct access information e.g., correct password, correct biometric data such as a voice- or fingerprint, correct encryption key, correct digital signature, etc.
- the requested information is transmitted (at 224) to the client device 102.
- the requested information is encrypted using a public key of the client entity associated with the client device 102, where this public key is represented by KPub in Fig. 2. Encrypting the requested information with the public key of the client entity ensures that only the client entity is able to see the requested information, by decrypting the encrypted request information using a private key of the client entity. Unauthorized entities, such as sniffers, would not be able to observe the requested information.
- the resource server system 108 determines (at 210) whether permissions have to be obtained from owners to access the requested information.
- the resource server system 108 determines (at 210) from the authorization requirement that permissions do not have to be obtained from the owners of the requested information, then the resource server system 108 can send the requested information (at 224) in encrypted form to the client device 102, without performing tasks 212, 214, 216, 218, 220, and 222.
- Fig. 3 is a block diagram of a non-transitory machine-readable or computer-readable storage medium 300 storing machine-readable instructions that upon execution cause a system to perform various tasks.
- the machine-readable instructions include instructions 302 and 304 that are executed in response to a request from a client device for information relating to a transaction stored by a blockchain.
- the instructions 302 are data owner entity identifying instructions to identify, using information stored in a distributed storage system that stores data for the blockchain, multiple data owner entities from which permissions are to be obtained for access of the information.
- the instructions 304 are authorization requirement determining instructions to determine an authorization requirement for the information based on a smart contract.
- the machine-readable instructions further include authorization
- the machine-readable instructions additionally include information sending instructions 308 to send the information to the client device in response to receiving the authorization tokens.
- FIG. 4 is a block diagram of an authorization facilitator system 400 that includes a processor 402 and a non-transitory storage medium 404 storing machine- readable instructions executable on the processor 402 to perform various tasks.
- Machine-readable instructions executable on a processor can refer to machine- readable instructions executable on one processor or on multiple processors.
- a processor can include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit.
- the machine-readable instructions include request receiving instructions 406 to receive a request from a client device for information relating to a transaction stored by a blockchain.
- the machine-readable instructions further include
- permission checking instructions 408 to, in response to the request, check with a resource server system to identify, using a smart contract, entities from which permissions are to be obtained for access of the information.
- the machine-readable instructions additionally include authorization token obtaining instructions 410 to, in response to the checking, cause the client device to obtain authorization tokens from the identified entities for access of the information.
- the machine-readable instructions also include authorization token sending instructions 412 to send the authorization tokens to the resource server system to cause the resource server system to send the information in response to the resource server validating the authorization tokens.
- Fig. 5 is a block diagram of a resource server system 500 including a processor 502 and a non-transitory storage medium 504 storing machine-readable instructions executable on the processor 502 to perform various tasks.
- the machine-readable instructions include first request receiving instructions 506 to receive, from an authorization facilitator system, a first request seeking access to information relating to a transaction stored by a blockchain, the first request sent by the authorization facilitator system in response to the authorization facilitator system receiving a second request seeking access to the information from a client device.
- the machine-readable instructions further include authorization requirement determining instructions 508 to determine an authorization requirement specified by entities that are owners of the information.
- the machine-readable instructions additionally include identity sending instructions 510 to, based on the authorization requirement, send identities of the entities to the authorization facilitator system.
- the machine-readable instructions also include authorization token receiving instructions 512 to receive authorization tokens obtained from the entities in response to the identities of the entities sent to the authorization facilitator system, and information sending instructions 514 to, in response to validating the authorization tokens, send the information for receipt by the client device.
- the storage medium 300 (Fig. 3), 404 (Fig. 4), or 504 (Fig. 5) can include any or some combination of the following: a semiconductor memory device such as a dynamic or static random access memory (a DRAM or SRAM), an erasable and programmable read-only memory (EPROM), an electrically erasable and
- a semiconductor memory device such as a dynamic or static random access memory (a DRAM or SRAM), an erasable and programmable read-only memory (EPROM), an electrically erasable and
- Storage can be located on premise, off premise, at a managed service provider, in a private or public cloud, or any combination thereof.
- the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternately, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes.
- Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture).
- An article or article of manufacture can refer to any manufactured single component or multiple components.
- the storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.
Abstract
In some examples, in response to a request from a client device for information relating to a transaction stored by a blockchain, a system identifies, using information stored in a distributed storage system that stores data for the blockchain, multiple data owner entities from which permissions are to be obtained for access of the information, and determines an authorization requirement for the information based on a smart contract. The system sends authorization information based on the authorization requirement to trigger a retrieval of authorization tokens from the identified data owner entities for access of the information, and sends the information to the client device in response to receiving the authorization tokens.
Description
PERMISSIONS FROM ENTITIES TO ACCESS INFORMATION Background
[0001 ] A storage system can store information for which requests can be submitted by client devices for access to the information. In some cases, access to the storage system can be granted by a server that manages access to the information in the storage system. Traditionally, an access control and/or policy management system determines whether a client device is allowed to access to requested information in the storage system.
Brief Description of the Drawings
[0002] Some implementations of the present disclosure are described with respect to the following figures.
[0003] Fig. 1 is a block diagram of an arrangement according to some examples.
[0004] Fig. 2 is a message flow diagram of a process according to some examples.
[0005] Fig. 3 is a block diagram of a storage medium storing machine-readable instructions according to other examples.
[0006] Fig. 4 is a block diagram of an authorization facilitator system according to further examples.
[0007] Fig. 5 is a block diagram of a resource server system according to additional examples.
[0008] Throughout the drawings, identical reference numbers designate similar, but not necessarily identical, elements. The figures are not necessarily to scale, and the size of some parts may be exaggerated to more clearly illustrate the example shown. Moreover, the drawings provide examples and/or implementations
consistent with the description; however, the description is not limited to the examples and/or implementations provided in the drawings.
Detailed Description
[0009] In the present disclosure, use of the term "a," "an", or "the" is intended to include the plural forms as well, unless the context clearly indicates otherwise. Also, the term "includes," "including," "comprises," "comprising," "have," or "having" when used in this disclosure specifies the presence of the stated elements, but do not preclude the presence or addition of other elements.
[0010] A storage system can store information for which requests can be submitted by client devices for access to the information. In some cases, the information stored in the storage system can include data referenced by blocks of a blockchain. The storage system can include a distributed arrangement of storage nodes for storing respective pieces of information referenced by the blockchain blocks. In some cases, the distributed storage system can be operated by different entities. One type of distributed storage systems can be referred to as a swarm, which is used in Ethereum, one of the variants of blockchain deployment. Entities in the blockchain can dynamically upload information pertaining to transactions into the distributed storage systems, including when additional information cannot be stored in blockchain due to various constraints on the blockchain.
[001 1 ] A blockchain refers to a distributed collection of records (referred to as "blocks") that are linked and secured cryptographically in a distributed manner. A blockchain can also refer to a continuous and unbroken ledger of blocks. The blocks of the blockchain can be distributed across a large number of computing devices. Each block can include various information, including transaction data for a transaction represented by the block, a timestamp, and a reference to a previous block in the blockchain. As new transactions occur, new blocks are created for the new transactions and added to the blockchain. A blockchain (which form a distributed transaction ledger) records transactions among multiple entities in a verifiable and permanent way. Once a block is created and the data of the block recorded, the block cannot be altered without alteration of subsequent blocks.
[0012] Multiple entities can see the transaction ledger, but because of the decentralized nature of the distributed collection of blocks the records are protected against hacking or corruption by a malicious entity. The validation of each block added to the blockchain is performed by every node by applying and/or validating hashing functions. If the validation fails, then that node drops the block from the blockchain.
[0013] A blockchain network includes "nodes" (referred to as blockchain nodes, full nodes, or blockchain full nodes) that can process requests to access the information.
[0014] In some cases, "owners" (also referred to as data owner entities) of information may lose control of which client entities can access that information once the information is put under management by a resource server of a distributed storage system. A client entity can refer to an entity that is associated with a client device. A client entity can refer to any of the following: the client device itself, a user of the client device, a program or component in the client device, and so forth.
[0015] If the resource server is able to grant access to the information in the distributed storage system without first consulting with the owners of the information, then unauthorized entities may potentially be able to access the information in the distributed storage system. Moreover, the distributed storage system may contain different categories of information that can be associated with different privilege levels relating to which client entities can access the different categories of information.
[0016] In accordance with some implementations of the present disclosure, techniques or mechanisms are provided to allow owners of information stored in a distributed storage system (or multiple distributed storage systems) to specify authorization requirements to access the information. An authorization requirement can indicate that authorization tokens have to be first obtained from the owners of the corresponding information before the corresponding information can be shared with a client entity. In some cases, an authorization requirement can specify that
different categories of information have different privilege levels for which different authorizations are to be obtained. An authorization requirement can specify different types of requirements for approval of information access, such as based on a client entity being part of a predefined group, the client entity having certain knowledge, the client entity having made payment for accessing information, the information accessed being approved by a contract, and so forth.
[0017] Fig. 1 is a block diagram of an example arrangement that includes a client device 102 that is able to send a request to access information stored in a distributed storage system 104, an authorization facilitator system 106, and a resource server system 108. Although just one client device 102 is shown in Fig. 1 , it is noted that in other examples, multiple client devices 102 can be present, where the multiple client devices 102 can submit requests to access data in the distributed storage system 104. Also, there can be multiple distributed storage systems 104, and/or multiple authorization facilitator systems 106, and/or multiple resource server systems 108.
[0018] The client device 102 can include any type of computing device that is able to communicate over a network and to submit a request for information.
Examples of the client device 102 can include any or some combination of the following: a smartphone, a tablet computer, a notebook computer, a desktop computer, a wearable device (e.g., smart eyeglasses, a head-mounted electronic device, a smart watch, etc.), a game appliance, a home appliance, a vehicle, or any other type of electronic device.
[0019] The client device 102 can include a blockchain-based application 103 that interacts with the authorization facilitator system 106 to request information referred to by a blockchain 1 1 1 stored in a blockchain network 1 10. The request for information can seek information in the distributed storage system 104 that can be associated with an authorization requirement where permissions have to be obtained from owners of the requested information. The client device 102 can also include a cryptographic currency wallet application 105, which can be used to make payment for a transaction or to make payment for accessing data or to make payment for any other purpose.
[0020] The distributed storage system 104 stores data 107 that is referenced by blocks of the blockchain 1 1 1 . In examples shown according to Fig. 1 , instead of storing actual data in the blocks of the blockchain 1 1 1 , data is stored in the distributed storage system 104. The distributed storage system 104 can be implemented with a distributed arrangement of storage nodes that store the data 107 in a distributed manner.
[0021 ] Each piece of data 107 in the distributed storage system 104 can have an owner, or alternately, can have multiple owners. An owner of a piece of data can refer to an entity (such as a user, an organization, a machine, a program, etc.) that is able to grant permission to access the piece of data. A "piece of data" can refer to any unit of data that can be separately identifiable, such as a file, an object, a chunk, and so forth.
[0022] The authorization facilitator system 106 (implemented as a distributed arrangement of computing nodes) interacts with client devices (including the client device 102), the blockchain network 1 10, and owner systems 1 12-A and 1 12-B, to allow the client devices to obtain authorization to access information in the
distributed storage system 104.
[0023] The owner systems 1 12-A and 1 12-B are associated with respective owners of information that can be stored in the distributed storage system 104.
Although just two owner systems 1 12-A and 1 12-B are shown in Fig. 1 , it is noted that in other examples, there can be more than two owner systems associated with respective owners. Each owner system can be implemented as a single computing node or a distributed arrangement of computing nodes.
[0024] The resource server system 108 (implemented as a distributed
arrangement of computing nodes) manages access to the information stored in the distributed storage system 104, including the data 107. Depending upon an authorization requirement for a requested information sought by a request of the client device 102, the resource server system 108 can inform the authorization facilitator system 106 (and possibly the client device 102) that permissions have to
first be obtained from owners of the requested information before the client device 102 is able to be granted access to the requested information. In such cases, the resource server system 108 does not make the determination of whether the client device 102 has permission to access the requested information. Rather, the resource service system 108 can provide identities of the owners, and it is the responsibility of the client device 102 and/or the authorization facilitator system 106 to obtain the permissions from the owners.
[0025] The computing nodes of the authorization facilitator system 106 include request processing nodes 120 and blockchain nodes 122. In other examples, the blockchain nodes 122 can be part of another system separate from the authorization facilitator system 106. The blockchain nodes 122 are part of the blockchain network 1 10.
[0026] The request processing nodes 120 are able to interact with corresponding client devices 102, to receive requests from the client devices 102 and to send response information (responsive to the requests) to the client devices 102. The request processing nodes 120 can also interact with the owner systems 1 12-A and 1 12-B to seek permissions for client entity access of information in the distributed storage system 104.
[0027] The blockchain nodes 122 store all blocks of the blockchain 1 1 1 and perform processing relating to the blocks of the blockchain 1 1 1 . The blockchain nodes 122 are able to provide distributed processing for granting access in response to requests from client devices 102.
[0028] The computing nodes of the resource server system 108 include storage processing nodes 124 that are able to manage access of the distributed storage nodes of the distributed storage system 104.
[0029] An authorization requirement for requested information (as requested by the client device 102) can specify that permissions from owners have to first be obtained before access is granted to the requested information. In further examples,
different pieces of information can be associated with different privilege levels. For example, the different pieces of information can include different categories of information. As an example, in a hospital, the different categories of information can include the following: a first category of information that includes information of a patient of the hospital, a second category of information that includes information of a pharmacy in the hospital, a third category of information that includes information that includes information of lab results obtained by testing done by the hospital, a fourth category of information that is associated with equipment in the hospital, and so forth. In other contexts, there can be other categories of information. Each category of information is associated with a corresponding privilege level. For example, for first privilege level, the owners of the respective piece of information may determine that certain client devices are allowed access, while other client devices are not allowed access. For a second privilege level, the owners can determine that more classes of client entities are allowed access to the given piece of information.
[0030] As further shown in Fig. 1 , the resource server system 108 includes a smart contract manager 1 16. The smart contract manager 1 16 can be implemented as a single computing node or as a distributed arrangement of computing nodes. The smart contract manager 1 16 has access to a smart contract database 1 18 that contains smart contracts 1 19.
[0031 ] A smart contract 1 19 provides logic and rules executed by computing device(s) for a blockchain to automate terms of a contract among multiple entities. A smart contract can include blockchain addresses of the parties of the smart contract, information relating to terms of the smart contract, and other information. A smart contract can be established among multiple entities. A smart contract manager implements enforcement of smart contracts.
[0032] A blockchain address refers to an identifier. In some examples, a blockchain address is analogous to an account number. An entity (such as a user or a device) can include one blockchain address, or can have multiple blockchain addresses. In some examples, a blockchain address can be generated based on
use of a pair of keys including a public key and a private key associated with an entity.
[0033] In response to a request from the client device 102 to access information in the distributed storage system 104, the smart contract manager 1 16 can access a selected smart contract of the smart contracts 1 19 in the smart contract database 1 18. Based on the selected smart contract, the smart contract manager 1 16 is able to determine the authorization requirement (if any) for access of requested information.
[0034] In some cases, the authorization requirement for particular information in the distributed storage system 104 can indicate that permissions from owners of the particular information do not have to be first obtained before access is granted to the particular information. In such cases, the resource server system 108 can grant access to the particular information to the client device 102 without indicating that permissions from the owners have to first be obtained.
[0035] In other cases, the authorization requirement for particular information in the distributed storage system 104 can indicate that permissions from owners of the particular information have to be first obtained before access is granted to the particular information. In such cases, the resource server system 108 can interact with the authorization facilitator system 106 and/or the client device 102 to cause the authorization facilitator system 106 and/or the client device 102 to obtain
permissions from the owners of the particular information.
[0036] In some examples, as pieces of information are written to the distributed storage system 104 by owners of the pieces of information, the pieces of information can be tagged with identification information (in tags) that identifies the owners of the pieces of information, and privilege information indication the privilege levels required to access the respective pieces of information. In alternate examples, the determination of owners of pieces of information can be based on which entities digitally signed the pieces of information for storage in the distributed storage system 104. Digitally signing a piece of information refers to an entity encrypting the piece
of information with a private key of the entity, such as according to a Public Key Infrastructure (PKI) digital signing.
[0037] Multiple parties may be owners with differing levels of privilege levels for the same piece of information. In such cases, the multiple owners can sign the piece of information. In some examples, all ownership-related signing and privilege level- related tagging have to be done while storing the information. With such tagging or association of ownership and privilege levels with pieces of information, the resource server system 108 and the distributed storage system 104 are guardians of the information, with the ability to grant permission for access controlled by the owners.
[0038] The authorization requirements (e.g., the conditions or rules governing access) to access respective pieces of information can be stored in smart contracts (1 19) managed by the smart contract manager 1 16. Privilege levels and multiparty ownership information are available to the smart contract manager 1 16. The smart contract manager 1 16 can create smart contracts for processing in the future.
[0039] In some examples, the authorization facilitator system 106 includes a logging manager 123 that logs access of certain piece of information in the distributed storage system 104 by a client entity after authorization by respective owners. The log of the transaction can also be made part of the blockchain 1 1 1 , or alternately, as part of the blockchain 1 1 1 and log information stored in the distributed storage system 104.
[0040] The resource server system 108 can also include a logging manager 1 15 to log similar information as the logging manager 123.
[0041 ] In further examples, the resource server system 108 includes a payment manager 1 17, which can be implemented as a single computing node or a
distributed arrangement of computing nodes. The payment manager 1 17 can collect payment from the client entity as part of providing the requested information to the client device 102. The payment manager 1 17 can interact with the cryptographic current wallet application 105 of the client device 102 to collect the payment.
Additionally, the payment manager 1 17 can also collect payment from a given owner of information in response to storing the information owned by the given owner with multiparty ownership and privilege levels in the distributed storage system 104.
[0042] Fig. 2 is a message flow diagram of a process involving components shown in Fig. 1 , according to some examples. The client device 102 sends an information request (at 202) to the authorization facilitator system 106, to request information stored in the distributed storage system 104. The information stored in the distributed storage system 104 includes data 107 referenced by respective blocks of the blockchain 1 1 1 .
[0043] The information request submitted by the client device 102 can include a blockchain address of an entity, which can be any of the following: a product, a machine, a program, a human user, or any other type of entity. The entity identified by the blockchain address can be associated with corresponding transactions that are represented by the blocks of the blockchain 1 1 1 . Thus, the blockchain address included in the information request can relate to specific transaction information of the blockchain. In the present disclosure, "transaction information" can refer to information of a single transaction or information of multiple transactions.
[0044] In response to the information request, the authorization facilitator system 106 (and more specifically, the blockchain full nodes 122 of Fig. 1 ) is able to check with the blockchain network 1 10 to determine (at 204) a location of the requested information. A "location" of the requested information can refer to a geographic location, a storage system, a resource server system that manages access of a system that includes the requested information, or any other indication of what entity the authorization facilitator system 106 is to interact with to obtain access to the requested information.
[0045] Using the blockchain address specified by the information request, the blockchain network 1 10 can respond with location information for the requested information. There are a number of different techniques for locating and gathering information from the distributed storage system 104. Some of the techniques can
include retrieving content using a Hypertext Transfer Protocol (HTTP), a proxy scheme, Ethereum's bzz scheme, a Uniform Resource Locator (URL) scheme, path matching on manifests, an Ethereum Name Service, and so forth. The Ethereum Name Service is similar to Domain Name System (DNS) in the Internet world.
Distributed database service providers can register for a .eth domain as well, to allow for a distributed storage system of each distributed database service provider to be located. For other examples, the location information can include an IP address that serves as an identifier corresponding to the location of the resource server system 108 that the authorization facilitator system 106 is to contact to obtain access of the requested information. In another example, an identifier corresponding to the location of the server could be extracted from a location services application that calculates the position in physical space, uses a radio frequency identification (RFID) tag, calculates position from a Global Positioning Satellite (GPS) service, or some other method of establishing location.
[0046] Based on the location information, the authorization facilitator system 106 (e.g., one of the request processing nodes 120 of Fig. 1 ) sends an authorization request (at 206) to the resource server system 108. The authorization request provides an indication to the resource server system 108 that the client device 102 is seeking access to the requested information, and that authorization information is being sought to determine how to obtain authorization (if any) to access the requested information.
[0047] In response to the authorization request, storage processing node(s) of the resource server system 108 retrieves (at 207) the requested information from the distributed storage system 104.
[0048] The smart contract manager 1 16 of the resource server system 108 checks (at 208) an authorization requirement relating to the requested information. In some examples, the authorization requirement may have been registered by owners of the requested information, or may have been registered by the resource server system 108. The authorization requirement can be included as a term of a smart contract (1 19 in Fig. 1 ) in some examples. Thus, the smart contract manager
1 16 can check the relevant smart contract to determine the authorization requirement for the requested information.
[0049] Based on the authorization requirement, the resource server system 108 determines (at 210) whether owner permissions have to be obtained to grant access to the requested information. If owner permissions have to be obtained, the smart contract manager 1 16 can obtain the identities of the owners of the requested information (such as from the tags associated with the pieces of the requested information retrieved from the distributed storage system 104), and can send authorization information (at 212) to the authorization facilitator system 106.
[0050] The authorization information 212 can include identities of the owners of the requested information from which permissions are to be obtained to grant access to the requested information. In some examples, the authorization information 212 can also include a privilege level (or multiple privilege levels) associated with the requested information. The privilege level(s) can also be obtained from the tags associated with the pieces of the requested information retrieved from the distributed storage system 104. The authorization information 212 can specify the authorization requirement for each privilege level. For example, if the requested information includes multiple pieces of information associated with different privilege levels, the authorization information 212 can include multiple privilege levels, and authorization requirements for each of the multiple privilege levels. The authorization information 212 is delivered to the authorization facilitator system 106, and possibly also to the client device 102. In other examples, the authorization information 212 is sent to the authorization facilitator system 106, which in turn can either process the
authorization information 212 itself or can forward the authorization information 212 to the client device 102.
[0051 ] In examples where the authorization information 212 is sent to the authorization facilitator system 106, the authorization facilitator system 106 (such as one of the request processing nodes 120) can cause the client device 102 to obtain permissions from the identified owners (as identified by the authorization information 212). For example, the authorization facilitator system 106 can send a permission
message (at 214) to the client device 102, where the permission message is to cause a client entity associated with the client device 102 to seek permissions from the identified owners.
[0052] In response to the permission message 214, the client device 102 performs an authorization process (at 216) with the owner systems 1 12-A and 1 12-B (assuming that the owner systems 1 12-A and 1 12-B are systems associated with the identified owners in the authorization information 212). In some examples, the authorization process (at 216) can be performed in response to the client entity (e.g., user, program, etc.) associated with the client device 102 indicating that the authorization process is to be performed.
[0053] In some examples, the authorization process (at 216) is according to the OAuth protocol, which is a standard for access delegation, to allow the owners of pieces of information to grant other entities, such as the distributed storage system 104, access to the pieces of information owned by the owners, but without giving the other entities the authorization tokens that are to be used for access to such pieces of information. Although reference is made to the OAuth protocol, it is noted that in other examples, other types of protocols where an owner can delegate access to information owned by the owner to another party can be used.
[0054] As part of the authorization process 216, and assuming that the owner systems 1 12-A and 1 12-B have granted permissions to the client entity associated with the client device 102 access of the requested information, the owner systems 1 12-A and 1 12-B sends back authorization tokens to the client device 102. As used here, an "authorization token" (also referred to an "access token") includes a credential (such as a password, an encryption key, or any other access information that can be used to obtain access of a particular piece of information).
[0055] In some examples, an authorization token is a context-based
authorization tokens that restricts access based on context, as represented by one or some combination of the following context parameters: a specified time and date range, a location, an identity of a client entity, or other contextual parameter.
[0056] The context-based authorization token can specify a specific context for access, and any request received outside the specific context can be rejected by the resource server system 108.
[0057] The client device 102 sends the received authorization tokens (at 218) to the authorization facilitator system 106. In response to receiving the authorization tokens from the client device 102, the authorization facilitator system 106 (such as one of the request processing nodes 120) sends the authorization tokens (at 220) to the resource server system 108.
[0058] In other examples, the client device 102 can send the authorization tokens directly to the resource server system 108 (without first forwarding to the
authorization facilitator system 106).
[0059] The resource server system 108 (and more specifically the smart contract manager 1 16) validates (at 222) the received authorization tokens. The validation can be based on access of the relevant smart contract by the smart contract manager 1 16 of the resource server system 108. Validating an authorization token can refer to confirming that the authorization token contains the correct access information (e.g., correct password, correct biometric data such as a voice- or fingerprint, correct encryption key, correct digital signature, etc.) that can be used to obtain access to the requested information.
[0060] Assuming that the authorization tokens are validated, the requested information is transmitted (at 224) to the client device 102. In some examples, the requested information is encrypted using a public key of the client entity associated with the client device 102, where this public key is represented by KPub in Fig. 2. Encrypting the requested information with the public key of the client entity ensures that only the client entity is able to see the requested information, by decrypting the encrypted request information using a private key of the client entity. Unauthorized entities, such as sniffers, would not be able to observe the requested information.
[0061 ] As noted above, the resource server system 108 determines (at 210) whether permissions have to be obtained from owners to access the requested information. The foregoing explains a case where permissions have to be first obtained from the owners. However, if the resource server system 108 (and more specifically, the smart contract manager 1 16) determines (at 210) from the authorization requirement that permissions do not have to be obtained from the owners of the requested information, then the resource server system 108 can send the requested information (at 224) in encrypted form to the client device 102, without performing tasks 212, 214, 216, 218, 220, and 222.
[0062] Fig. 3 is a block diagram of a non-transitory machine-readable or computer-readable storage medium 300 storing machine-readable instructions that upon execution cause a system to perform various tasks. The machine-readable instructions include instructions 302 and 304 that are executed in response to a request from a client device for information relating to a transaction stored by a blockchain. The instructions 302 are data owner entity identifying instructions to identify, using information stored in a distributed storage system that stores data for the blockchain, multiple data owner entities from which permissions are to be obtained for access of the information. The instructions 304 are authorization requirement determining instructions to determine an authorization requirement for the information based on a smart contract.
[0063] The machine-readable instructions further include authorization
information sending instructions 306 to send authorization information based on the authorization requirement to trigger a retrieval of authorization tokens from the identified data owner entities for access of the information. The machine-readable instructions additionally include information sending instructions 308 to send the information to the client device in response to receiving the authorization tokens.
[0064] Fig. 4 is a block diagram of an authorization facilitator system 400 that includes a processor 402 and a non-transitory storage medium 404 storing machine- readable instructions executable on the processor 402 to perform various tasks. Machine-readable instructions executable on a processor can refer to machine-
readable instructions executable on one processor or on multiple processors. A processor can include a microprocessor, a core of a multi-core microprocessor, a microcontroller, a programmable integrated circuit, a programmable gate array, or another hardware processing circuit.
[0065] The machine-readable instructions include request receiving instructions 406 to receive a request from a client device for information relating to a transaction stored by a blockchain. The machine-readable instructions further include
permission checking instructions 408 to, in response to the request, check with a resource server system to identify, using a smart contract, entities from which permissions are to be obtained for access of the information.
[0066] The machine-readable instructions additionally include authorization token obtaining instructions 410 to, in response to the checking, cause the client device to obtain authorization tokens from the identified entities for access of the information. The machine-readable instructions also include authorization token sending instructions 412 to send the authorization tokens to the resource server system to cause the resource server system to send the information in response to the resource server validating the authorization tokens.
[0067] Fig. 5 is a block diagram of a resource server system 500 including a processor 502 and a non-transitory storage medium 504 storing machine-readable instructions executable on the processor 502 to perform various tasks. The machine-readable instructions include first request receiving instructions 506 to receive, from an authorization facilitator system, a first request seeking access to information relating to a transaction stored by a blockchain, the first request sent by the authorization facilitator system in response to the authorization facilitator system receiving a second request seeking access to the information from a client device. The machine-readable instructions further include authorization requirement determining instructions 508 to determine an authorization requirement specified by entities that are owners of the information.
[0068] The machine-readable instructions additionally include identity sending instructions 510 to, based on the authorization requirement, send identities of the entities to the authorization facilitator system. The machine-readable instructions also include authorization token receiving instructions 512 to receive authorization tokens obtained from the entities in response to the identities of the entities sent to the authorization facilitator system, and information sending instructions 514 to, in response to validating the authorization tokens, send the information for receipt by the client device.
[0069] The storage medium 300 (Fig. 3), 404 (Fig. 4), or 504 (Fig. 5) can include any or some combination of the following: a semiconductor memory device such as a dynamic or static random access memory (a DRAM or SRAM), an erasable and programmable read-only memory (EPROM), an electrically erasable and
programmable read-only memory (EEPROM) and flash memory; a magnetic disk such as a fixed, floppy and removable disk; another magnetic medium including tape; an optical medium such as a compact disk (CD) or a digital video disk (DVD); or another type of storage device. Storage can be located on premise, off premise, at a managed service provider, in a private or public cloud, or any combination thereof.
[0070] Note that the instructions discussed above can be provided on one computer-readable or machine-readable storage medium, or alternately, can be provided on multiple computer-readable or machine-readable storage media distributed in a large system having possibly plural nodes. Such computer-readable or machine-readable storage medium or media is (are) considered to be part of an article (or article of manufacture). An article or article of manufacture can refer to any manufactured single component or multiple components. The storage medium or media can be located either in the machine running the machine-readable instructions, or located at a remote site from which machine-readable instructions can be downloaded over a network for execution.
[0071 ] In the foregoing description, numerous details are set forth to provide an understanding of the subject disclosed herein. However, implementations may be
practiced without some of these details. Other implementations may include modifications and variations from the details discussed above. It is intended that the appended claims cover such modifications and variations.
Claims
What is claimed is: 1 . A non-transitory machine-readable storage medium storing instructions that upon execution cause a system to:
in response to a request from a client device for information relating to a transaction stored by a blockchain,
identify, using information stored in a distributed storage system that stores data for the blockchain, multiple data owner entities from which permissions are to be obtained for access of the information, and
determine an authorization requirement for the information based on a smart contract;
send authorization information based on the authorization requirement to trigger a retrieval of authorization tokens from the identified data owner entities for access of the information; and
send the information to the client device in response to receiving the authorization tokens.
2. The non-transitory machine-readable storage medium of claim 1 , wherein the instructions upon execution cause the system to:
receive the authorization tokens from the identified data owner entities for access of the information; and
validate the authorization tokens,
wherein sending the information to the client device is in response to validating the authorization tokens.
3. The non-transitory machine-readable storage medium of claim 1 , wherein the instructions upon execution cause the system to further:
in response to the request from the client device, access the blockchain to determine a location where the information is stored; and
check with a resource server associated with the location to request identities of the data owner entities from which permissions are to be obtained for access of the information.
4. The non-transitory machine-readable storage medium of claim 1 , wherein identification of the data owner entities is based on determining which data owner entities digitally signed the information in the distributed storage system that stores respective information for blocks of the blockchain.
5. The non-transitory machine-readable storage medium of claim 1 , wherein the authorization requirement specifies that the permissions are to be obtained from the data owner entities before access of the information is granted to the client device.
6. The non-transitory machine-readable storage medium of claim 5, wherein the smart contract specifies that access to information relating to a further transaction stored by the blockchain can be granted without first seeking permissions of data owner entities owning the information relating to the further transaction.
7. The non-transitory machine-readable storage medium of claim 1 , wherein identification of the data owner entities is based on tags associated with the information in the distributed storage system.
8. The non-transitory machine-readable storage medium of claim 1 , wherein the instructions upon execution cause the system to further:
identify a privilege level of a plurality of privilege levels for which the permissions are to be obtained,
wherein the authorization tokens are for the identified privilege level.
9. The non-transitory machine-readable storage medium of claim 8, wherein identifying the privilege level is based on tags associated with information in the distributed storage system.
10. The non-transitory machine-readable storage medium of claim 1 , wherein the retrieval of the authorization tokens from the data owner entities is according to an authorization protocol that allows the data owner entities to delegate access to information owned by the data owner entities to another party.
1 1 . The non-transitory machine-readable storage medium of claim 1 , wherein the instructions upon execution cause the system to further:
encrypt the information with a public key of the client device in response to validating the authorization tokens,
wherein the sending of the information to the client device comprises sending the encrypted information.
12. The non-transitory machine-readable storage medium of claim 1 , wherein the authorization tokens comprise context-based authorization tokens that restrict access according to any or a combination of the following contextual parameters: a specified time and date range, a location, or an identity of a client entity.
13. The non-transitory machine-readable storage medium of claim 1 , wherein the information relating to the transaction is stored in the distributed storage system encrypted with private keys of the entities, the distributed storage system storing respective information for blocks of the blockchain.
14. The non-transitory machine-readable storage medium of claim 1 , wherein the instructions upon execution cause the system to further:
collect payment from the client device as part of sending the information to the client device, the collecting of the payment based on interaction with a wallet application in the client device.
15. The non-transitory machine-readable storage medium of claim 1 , wherein the instructions upon execution cause the system to further:
collect payment from a given data owner entity in response to storing information owned by the given data owner entity with multiparty ownership and privilege levels in a distributed storage system.
16. The non-transitory machine-readable storage medium of claim 1 , wherein the instructions upon execution cause the system to log access of a piece of information in the distributed storage system by a client entity after authorization by respective data owner entities.
17. An authorization facilitator system comprising:
a processor; and
a non-transitory storage medium storing instructions executable on the processor to:
receive a request from a client device for information relating to a transaction stored by a blockchain;
in response to the request, check with a resource server system to identify, using a smart contract, entities from which permissions are to be obtained for access of the information;
in response to the checking, cause the client device to obtain authorization tokens from the identified entities for access of the information; and send the authorization tokens to the resource server system to cause the resource server system to send the information in response to the resource server system validating the authorization tokens.
18. The authorization facilitator system of claim 17, further comprising:
a blockchain node to access a blockchain network to determine location information for the resource server system.
19. The authorization facilitator system of claim 15, wherein the information sent by the resource server system is encrypted using a public key of a client entity associated with the client device.
20. A resource server system comprising:
a processor; and
a non-transitory storage medium storing instructions executable on the processor to:
receive, from an authorization facilitator system, a first request seeking access to information relating to a transaction stored by a blockchain, the first request sent by the authorization facilitator system in response to the authorization facilitator system receiving a second request seeking access to the information from a client device;
determine an authorization requirement specified by entities that are owners of the information;
based on the authorization requirement, send identities of the entities to the authorization facilitator system;
receive authorization tokens obtained from the entities in response to the identities of the entities sent to the authorization facilitator system, the
authorization tokens indicating permissions granted by the entities; and
in response to validating the authorization tokens, send the information for receipt by the client device.
21 . The resource server system of claim 20, wherein the determining of the authorization requirement is based on a smart contract, and the determining of the entities is based on multiparty signing of tags associated with information in a distributed storage system.
22. The resource server system of claim 20, wherein the authorization
requirement is specified in a smart contract, and the authorization requirement identifies a plurality of levels of authorizations to be obtained for different categories of information, and wherein the instructions are executable on the processor to: send, to the authorization facilitator system, authorization information for the plurality of levels of authorizations.
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2017/057558 WO2019078879A1 (en) | 2017-10-20 | 2017-10-20 | Permissions from entities to access information |
US16/757,703 US11582040B2 (en) | 2017-10-20 | 2017-10-20 | Permissions from entities to access information |
EP17929402.0A EP3698529A4 (en) | 2017-10-20 | 2017-10-20 | Permissions from entities to access information |
CN201780097500.3A CN111434084B (en) | 2017-10-20 | 2017-10-20 | Permission to access information from an entity |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
PCT/US2017/057558 WO2019078879A1 (en) | 2017-10-20 | 2017-10-20 | Permissions from entities to access information |
Publications (1)
Publication Number | Publication Date |
---|---|
WO2019078879A1 true WO2019078879A1 (en) | 2019-04-25 |
Family
ID=66174557
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
PCT/US2017/057558 WO2019078879A1 (en) | 2017-10-20 | 2017-10-20 | Permissions from entities to access information |
Country Status (4)
Country | Link |
---|---|
US (1) | US11582040B2 (en) |
EP (1) | EP3698529A4 (en) |
CN (1) | CN111434084B (en) |
WO (1) | WO2019078879A1 (en) |
Cited By (13)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110213266A (en) * | 2019-05-31 | 2019-09-06 | 联想(北京)有限公司 | A kind of information processing method and electronic equipment of the block chain across chain |
CN110457875A (en) * | 2019-07-31 | 2019-11-15 | 阿里巴巴集团控股有限公司 | Data grant method and device based on block chain |
CN110473094A (en) * | 2019-07-31 | 2019-11-19 | 阿里巴巴集团控股有限公司 | Data grant method and device based on block chain |
CN111212125A (en) * | 2019-12-27 | 2020-05-29 | 成都商通数治科技有限公司 | Data exchange method and system based on block chain |
CN111902815A (en) * | 2020-03-11 | 2020-11-06 | 合肥达朴汇联科技有限公司 | Data transfer method, system, device, electronic device, and readable storage medium |
WO2021026611A1 (en) * | 2019-08-13 | 2021-02-18 | Db Results Pty Ltd | Secure information sharing systems and methods |
WO2021086402A1 (en) * | 2019-11-01 | 2021-05-06 | Hewlett-Packard Development Company, L.P. | New permission approval authority |
US11057189B2 (en) | 2019-07-31 | 2021-07-06 | Advanced New Technologies Co., Ltd. | Providing data authorization based on blockchain |
US11252166B2 (en) | 2019-07-31 | 2022-02-15 | Advanced New Technologies Co., Ltd. | Providing data authorization based on blockchain |
US11251963B2 (en) | 2019-07-31 | 2022-02-15 | Advanced New Technologies Co., Ltd. | Blockchain-based data authorization method and apparatus |
EP3962019A1 (en) * | 2020-08-28 | 2022-03-02 | Alipay (Hangzhou) Information Technology Co., Ltd. | Trusted data transmission methods, apparatuses, and devices |
US11310051B2 (en) | 2020-01-15 | 2022-04-19 | Advanced New Technologies Co., Ltd. | Blockchain-based data authorization method and apparatus |
US20220164310A1 (en) * | 2020-11-23 | 2022-05-26 | Ford Global Technologies, Llc | Systems And Methods For Remote Storage Of Information Associated With A Distributed Ledger Network |
Families Citing this family (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
WO2020010023A1 (en) * | 2018-07-01 | 2020-01-09 | Madhu Vijayan | Systems and methods for implementing blockchain-based content engagement platforms utilizing media wallets |
US10824740B2 (en) * | 2018-07-30 | 2020-11-03 | EMC IP Holding Company LLC | Decentralized policy publish and query system for multi-cloud computing environment |
US11489816B2 (en) * | 2018-07-31 | 2022-11-01 | Ezblock Ltd. | Blockchain joining for a limited processing capability device and device access security |
CN112668043B (en) * | 2020-12-21 | 2023-08-11 | 山大地纬软件股份有限公司 | Digital data payment and storage method, client and system based on blockchain |
CN113052721B (en) * | 2021-03-18 | 2024-04-30 | 国网北京市电力公司 | Power data processing method and device |
CN113542439B (en) * | 2021-09-17 | 2021-12-07 | 深圳时空云科技有限公司 | Distributed data storage access method and device |
Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8042163B1 (en) * | 2004-05-20 | 2011-10-18 | Symatec Operating Corporation | Secure storage access using third party capability tokens |
US20160342989A1 (en) * | 2015-05-21 | 2016-11-24 | Mastercard International Incorporated | Method and system for processing blockchain-based transactions on existing payment networks |
KR101701131B1 (en) * | 2016-04-28 | 2017-02-13 | 주식회사 라피 | Data recording and validation methods and systems using the connecting of blockchain between different type |
WO2017054985A1 (en) * | 2015-09-30 | 2017-04-06 | British Telecommunications Public Limited Company | Access control |
US9648007B1 (en) * | 2015-06-17 | 2017-05-09 | Amazon Technologies, Inc. | Token-based storage service |
Family Cites Families (67)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7299492B2 (en) * | 2003-06-12 | 2007-11-20 | International Business Machines Corporation | Multi-level multi-user web services security system and method |
US7631346B2 (en) | 2005-04-01 | 2009-12-08 | International Business Machines Corporation | Method and system for a runtime user account creation operation within a single-sign-on process in a federated computing environment |
US8793509B1 (en) * | 2008-02-12 | 2014-07-29 | Google Inc. | Web authorization with reduced user interaction |
US9596237B2 (en) | 2010-12-14 | 2017-03-14 | Salt Technology, Inc. | System and method for initiating transactions on a mobile device |
US9569771B2 (en) | 2011-04-29 | 2017-02-14 | Stephen Lesavich | Method and system for storage and retrieval of blockchain blocks using galois fields |
US8694782B2 (en) | 2011-05-04 | 2014-04-08 | Marvell World Trade Ltd. | Wireless authentication using beacon messages |
US8713656B2 (en) | 2011-10-23 | 2014-04-29 | Gopal Nandakumar | Authentication method |
US10490304B2 (en) * | 2012-01-26 | 2019-11-26 | Netspective Communications Llc | Device-driven non-intermediated blockchain system over a social integrity network |
US8925059B2 (en) | 2012-06-08 | 2014-12-30 | Lockheed Martin Corporation | Dynamic trust connection |
FI126426B (en) | 2012-08-23 | 2016-11-30 | Teknologian Tutkimuskeskus Vtt Oy | METHOD AND EQUIPMENT FOR THE RECOMMENDATION SYSTEM TOKENEN EXCHANGE |
CN103051630B (en) * | 2012-12-21 | 2016-01-27 | 微梦创科网络科技(中国)有限公司 | Method, the Apparatus and system of third-party application mandate is realized based on open platform |
US8955075B2 (en) | 2012-12-23 | 2015-02-10 | Mcafee Inc | Hardware-based device authentication |
US9166796B2 (en) * | 2013-06-24 | 2015-10-20 | Prince Sattam Bin Abdulaziz University | Secure biometric cloud storage system |
CN105659558B (en) | 2013-09-20 | 2018-08-31 | 甲骨文国际公司 | Computer implemented method, authorization server and computer-readable memory |
US9424417B2 (en) | 2014-06-04 | 2016-08-23 | Qualcomm Incorporated | Secure current movement indicator |
US10375514B2 (en) | 2014-07-29 | 2019-08-06 | GeoFrenzy, Inc. | Systems, methods and apparatus for geofence networks |
EP3189414A4 (en) | 2014-08-22 | 2018-04-18 | Priv8Pay, Inc. | Verification system for secure transmission in a distributed processing network |
US10111071B2 (en) | 2014-09-19 | 2018-10-23 | Avago Technologies General Ip (Singapore) Pte. Ltd. | Bluetooth low energy automation mesh network |
US9749297B2 (en) | 2014-11-12 | 2017-08-29 | Yaron Gvili | Manicoding for communication verification |
CA2984888A1 (en) | 2015-05-05 | 2016-11-10 | ShoCard, Inc. | Identity management service using a block chain |
GB2539430A (en) | 2015-06-16 | 2016-12-21 | The Provost Fellows Found Scholars & The Other Members Of Board Of The College Of The Holy & Unidv T | Digital token exchange system |
US10445754B2 (en) | 2015-09-14 | 2019-10-15 | The Western Union Company | Multi-network transaction analysis |
KR101637854B1 (en) | 2015-10-16 | 2016-07-08 | 주식회사 코인플러그 | Certificate issuance system and method based on block chain, certificate authentication system and method based on block chain |
US20170132625A1 (en) | 2015-11-05 | 2017-05-11 | Mastercard International Incorporated | Method and system for use of a blockchain in a transaction processing network |
US20170132626A1 (en) | 2015-11-05 | 2017-05-11 | Mastercard International Incorporated | Method and system for processing of a blockchain transaction in a transaction processing network |
US10269012B2 (en) | 2015-11-06 | 2019-04-23 | Swfl, Inc. | Systems and methods for secure and private communications |
US10038723B2 (en) * | 2015-11-10 | 2018-07-31 | Telefonaktiebolaget Lm Ericsson (Publ) | Method and apparatus for reliable token revocation |
US20170132630A1 (en) | 2015-11-11 | 2017-05-11 | Bank Of America Corporation | Block chain alias for person-to-person payments |
US10805393B2 (en) | 2015-12-02 | 2020-10-13 | Olea Networks, Inc. | System and method for data management structure using auditable delta records in a distributed environment |
US9980137B2 (en) | 2015-12-11 | 2018-05-22 | Patrocinium Systems LLC | Secure beacon-based location systems and methods |
KR101661933B1 (en) | 2015-12-16 | 2016-10-05 | 주식회사 코인플러그 | Ccertificate authentication system and method based on block chain |
US10013573B2 (en) | 2015-12-16 | 2018-07-03 | International Business Machines Corporation | Personal ledger blockchain |
CN106911641A (en) | 2015-12-23 | 2017-06-30 | 索尼公司 | For authorizing the client terminal device for accessing, server unit and access control system |
WO2017127564A1 (en) | 2016-01-19 | 2017-07-27 | Priv8Pay, Inc. | Network node authentication |
EP3200167A1 (en) | 2016-01-29 | 2017-08-02 | Mastercard International Incorporated | Information transaction infrastructure |
WO2017131788A1 (en) | 2016-01-29 | 2017-08-03 | Hewlett Packard Enterprise Development Lp | Encryption of community-based security information based on time-bound cryptographic keys |
US9849364B2 (en) | 2016-02-02 | 2017-12-26 | Bao Tran | Smart device |
WO2017136527A1 (en) | 2016-02-05 | 2017-08-10 | Manifold Technology, Inc. | Blockchain-enhanced database |
US10142347B2 (en) * | 2016-02-10 | 2018-11-27 | Bank Of America Corporation | System for centralized control of secure access to process data network |
US10715531B2 (en) | 2016-02-12 | 2020-07-14 | Visa International Service Association | Network topology |
US20170236123A1 (en) | 2016-02-16 | 2017-08-17 | Blockstack Inc. | Decentralized processing of global naming systems |
US10679215B2 (en) | 2016-02-22 | 2020-06-09 | Bank Of America Corporation | System for control of device identity and usage in a process data network |
KR101637868B1 (en) | 2016-02-22 | 2016-07-08 | 주식회사 코인플러그 | Financial institution document verification system that is based on the block chain |
EP3257191B1 (en) | 2016-02-23 | 2018-04-11 | Nchain Holdings Limited | Registry and automated management method for blockchain-enforced smart contracts |
US10713693B2 (en) | 2016-03-11 | 2020-07-14 | Devnet, Inc. | Method and apparatus for advertising content management |
CA3024070A1 (en) * | 2016-05-11 | 2017-11-16 | Nasdaq, Inc. | Application framework using blockchain-based asset ownership |
US9635000B1 (en) | 2016-05-25 | 2017-04-25 | Sead Muftic | Blockchain identity management system based on public identities ledger |
KR101723405B1 (en) | 2016-07-04 | 2017-04-06 | 주식회사 코인플러그 | Certificate authentication system and method based on block chain |
WO2018019364A1 (en) * | 2016-07-26 | 2018-02-01 | NEC Laboratories Europe GmbH | Method for controlling access to a shared resource |
CN107679045B (en) * | 2016-08-01 | 2021-08-31 | 华为技术有限公司 | Copyright authorization management method and system |
WO2018039312A1 (en) * | 2016-08-23 | 2018-03-01 | BBM Health LLC | Blockchain-based mechanisms for secure health information resource exchange |
KR101767534B1 (en) | 2016-09-12 | 2017-08-14 | 주식회사 코인플러그 | Method for providing identity verification using card base on near field communication, card, verification terminal, verification support server and identity verification server using the same |
MX2019007003A (en) * | 2016-12-15 | 2019-11-28 | Walmart Apollo Llc | Apparatus and method for collaborative shopping. |
CN106953838A (en) | 2016-12-20 | 2017-07-14 | 中国银联股份有限公司 | Unattended equipment and its payment system and method based on block chain technology |
US20180182052A1 (en) * | 2016-12-20 | 2018-06-28 | Microshare, Inc. | Policy Fabric And Sharing System For Enabling Multi-Party Data Processing In An IoT Environment |
CN106796688B (en) | 2016-12-26 | 2020-12-18 | 深圳前海达闼云端智能科技有限公司 | Permission control method, device and system of block chain and node equipment |
WO2018120121A1 (en) | 2016-12-30 | 2018-07-05 | 深圳前海达闼云端智能科技有限公司 | Block chain permission control method, device, and node apparatus |
US10270599B2 (en) | 2017-04-27 | 2019-04-23 | Factom, Inc. | Data reproducibility using blockchains |
US10671733B2 (en) * | 2017-05-19 | 2020-06-02 | International Business Machines Corporation | Policy enforcement via peer devices using a blockchain |
US11226956B2 (en) | 2017-07-07 | 2022-01-18 | Visa International Service Association | System, method, and apparatus for implementing a blockchain-based entity identification network |
US10194320B1 (en) | 2017-07-30 | 2019-01-29 | Dell Products, Lp | Method and apparatus for assignment of subscription electronic SIM credentials via local service brokers |
US10361870B2 (en) | 2017-09-14 | 2019-07-23 | The Toronto-Dominion Bank | Management of cryptographically secure exchanges of data using permissioned distributed ledgers |
US10833869B2 (en) | 2018-01-05 | 2020-11-10 | International Business Machines Corporation | Securing geo-physical presence |
US10931457B2 (en) | 2018-03-09 | 2021-02-23 | Igt Global Solutions Corporation | Systems and methods for blockchain-based digital lottery ticket generation and distribution |
EP3891621A4 (en) | 2018-12-04 | 2022-08-24 | ZeU Technologies, Inc. | System and method for augmenting database applications with blockchain technology |
CN111782668A (en) | 2018-12-20 | 2020-10-16 | 阿里巴巴集团控股有限公司 | Data structure reading and updating method and device, and electronic equipment |
US11611560B2 (en) | 2020-01-31 | 2023-03-21 | Salesforce.Com, Inc. | Systems, methods, and apparatuses for implementing consensus on read via a consensus on write smart contract trigger for a distributed ledger technology (DLT) platform |
-
2017
- 2017-10-20 US US16/757,703 patent/US11582040B2/en active Active
- 2017-10-20 WO PCT/US2017/057558 patent/WO2019078879A1/en unknown
- 2017-10-20 EP EP17929402.0A patent/EP3698529A4/en not_active Withdrawn
- 2017-10-20 CN CN201780097500.3A patent/CN111434084B/en active Active
Patent Citations (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8042163B1 (en) * | 2004-05-20 | 2011-10-18 | Symatec Operating Corporation | Secure storage access using third party capability tokens |
US20160342989A1 (en) * | 2015-05-21 | 2016-11-24 | Mastercard International Incorporated | Method and system for processing blockchain-based transactions on existing payment networks |
US9648007B1 (en) * | 2015-06-17 | 2017-05-09 | Amazon Technologies, Inc. | Token-based storage service |
WO2017054985A1 (en) * | 2015-09-30 | 2017-04-06 | British Telecommunications Public Limited Company | Access control |
KR101701131B1 (en) * | 2016-04-28 | 2017-02-13 | 주식회사 라피 | Data recording and validation methods and systems using the connecting of blockchain between different type |
Non-Patent Citations (1)
Title |
---|
See also references of EP3698529A4 * |
Cited By (23)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN110213266A (en) * | 2019-05-31 | 2019-09-06 | 联想(北京)有限公司 | A kind of information processing method and electronic equipment of the block chain across chain |
CN110473094B (en) * | 2019-07-31 | 2021-05-18 | 创新先进技术有限公司 | Data authorization method and device based on block chain |
US11252166B2 (en) | 2019-07-31 | 2022-02-15 | Advanced New Technologies Co., Ltd. | Providing data authorization based on blockchain |
US11057189B2 (en) | 2019-07-31 | 2021-07-06 | Advanced New Technologies Co., Ltd. | Providing data authorization based on blockchain |
WO2021017441A1 (en) * | 2019-07-31 | 2021-02-04 | 创新先进技术有限公司 | Blockchain-based data authorization method and apparatus |
US11398914B2 (en) | 2019-07-31 | 2022-07-26 | Advanced New Technologies Co., Ltd. | Blockchain-based data authorization method and apparatus |
CN110473094A (en) * | 2019-07-31 | 2019-11-19 | 阿里巴巴集团控股有限公司 | Data grant method and device based on block chain |
US11251963B2 (en) | 2019-07-31 | 2022-02-15 | Advanced New Technologies Co., Ltd. | Blockchain-based data authorization method and apparatus |
CN110457875A (en) * | 2019-07-31 | 2019-11-15 | 阿里巴巴集团控股有限公司 | Data grant method and device based on block chain |
US11831656B2 (en) | 2019-07-31 | 2023-11-28 | Advanced New Technologies Co., Ltd. | Providing data authorization based on blockchain |
WO2021026611A1 (en) * | 2019-08-13 | 2021-02-18 | Db Results Pty Ltd | Secure information sharing systems and methods |
WO2021086402A1 (en) * | 2019-11-01 | 2021-05-06 | Hewlett-Packard Development Company, L.P. | New permission approval authority |
CN111212125A (en) * | 2019-12-27 | 2020-05-29 | 成都商通数治科技有限公司 | Data exchange method and system based on block chain |
US11310051B2 (en) | 2020-01-15 | 2022-04-19 | Advanced New Technologies Co., Ltd. | Blockchain-based data authorization method and apparatus |
CN112333175A (en) * | 2020-03-11 | 2021-02-05 | 合肥达朴汇联科技有限公司 | Data transmission method, system, equipment and storage medium based on intermediate node |
CN112333176A (en) * | 2020-03-11 | 2021-02-05 | 合肥达朴汇联科技有限公司 | Data transmission method, system, equipment and storage medium based on data receiving party |
CN112333175B (en) * | 2020-03-11 | 2023-04-18 | 合肥达朴汇联科技有限公司 | Data transmission method, system, equipment and storage medium based on intermediate node |
CN111902815B (en) * | 2020-03-11 | 2023-06-27 | 合肥达朴汇联科技有限公司 | Data transmission method, system, device, electronic device and readable storage medium |
CN111902815A (en) * | 2020-03-11 | 2020-11-06 | 合肥达朴汇联科技有限公司 | Data transfer method, system, device, electronic device, and readable storage medium |
EP3962019A1 (en) * | 2020-08-28 | 2022-03-02 | Alipay (Hangzhou) Information Technology Co., Ltd. | Trusted data transmission methods, apparatuses, and devices |
US11362815B2 (en) | 2020-08-28 | 2022-06-14 | Alipay (Hangzhou) Information Technology Co., Ltd. | Trusted data transmission methods, apparatuses, and devices |
US20220164310A1 (en) * | 2020-11-23 | 2022-05-26 | Ford Global Technologies, Llc | Systems And Methods For Remote Storage Of Information Associated With A Distributed Ledger Network |
US11748303B2 (en) * | 2020-11-23 | 2023-09-05 | Ford Global Technologies, Llc | Systems and methods for remote storage of information associated with a distributed ledger network |
Also Published As
Publication number | Publication date |
---|---|
CN111434084B (en) | 2022-07-05 |
US20210203503A1 (en) | 2021-07-01 |
US11582040B2 (en) | 2023-02-14 |
EP3698529A1 (en) | 2020-08-26 |
EP3698529A4 (en) | 2021-04-07 |
CN111434084A (en) | 2020-07-17 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11582040B2 (en) | Permissions from entities to access information | |
US11429729B2 (en) | Buckets with policy driven forced encryption | |
US11153086B2 (en) | Methods and systems for a digital trust architecture | |
US20200242218A1 (en) | Systems and methods for providing identity assurance for decentralized applications | |
US11463241B2 (en) | Transmitting or receiving blockchain information | |
US11431757B2 (en) | Access control using impersonization | |
US9519696B1 (en) | Data transformation policies | |
US10091230B1 (en) | Aggregating identity data from multiple sources for user controlled distribution to trusted risk engines | |
US20190347442A1 (en) | Method for Personal Data Administration in a Multi-Actor Environment | |
JP2019118135A (en) | Key export technology | |
US20230161898A1 (en) | Accessing information based on privileges | |
JP2012518330A (en) | Reliable cloud computing and cloud service framework | |
KR102595830B1 (en) | Location-based access to controlled access resources | |
US20210365584A1 (en) | Portable reputation brokering using linked blockchains and shared events | |
US20200134229A1 (en) | Data Processing Apparatus and Methods | |
US10931650B1 (en) | Apparatus and method for building, extending and managing interactions between digital identities and digital identity applications | |
Guo et al. | Using blockchain to control access to cloud data | |
US9344407B1 (en) | Centrally managed use case-specific entity identifiers | |
WO2019213752A1 (en) | A method and system for managing digital assets in a blockchain | |
US9251375B1 (en) | Use case-specific entity identifiers | |
Beulah et al. | Survey on security issues and existing solutions in cloud storage | |
CN113946864B (en) | Confidential information acquisition method, device, equipment and storage medium | |
Amamou et al. | Towards a Better Security in Public Cloud Computing | |
Stetsenko et al. | Provision mechanism of authenticity of data origin in cloud environment based on Blockchain technology | |
CN115021959A (en) | Block chain-based data management method and related product |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
121 | Ep: the epo has been informed by wipo that ep was designated in this application |
Ref document number: 17929402 Country of ref document: EP Kind code of ref document: A1 |
|
NENP | Non-entry into the national phase |
Ref country code: DE |
|
ENP | Entry into the national phase |
Ref document number: 2017929402 Country of ref document: EP Effective date: 20200520 |