WO2023140828A1

WO2023140828A1 - Method and apparatus for controlling access to data stored on a blockchain

Info

Publication number: WO2023140828A1
Application number: PCT/US2022/012774
Authority: WO
Inventors: Yelena Helen BALINSKY; Remy HUSSON; Federico MORINI
Original assignee: Hewlett-Packard Development Company, L.P.
Priority date: 2022-01-18
Filing date: 2022-01-18
Publication date: 2023-07-27

Abstract

According to aspects of the invention, there is provided a non-transitory computer-readable storage medium comprising instructions that when executed cause a processor of a computing device to process a request, from a requesting entity, for access to data stored on a blockchain, the request comprising an indication of a blockchain view, wherein the blockchain view identifies a data unit present on the blockchain, obtain an access policy associated with the indicated blockchain view, determine whether the requesting entity is authorized to access the blockchain view based on the policy, obtain a definition of the indicated blockchain view, the definition comprising a unique identifier of the requested data unit, and in response to determining that the requesting entity is authorized to access the blockchain view, retrieve the requested data unit from the blockchain and provide the data unit to the requesting entity.

Description

METHOD AND APPARATUS FOR CONTROLLING ACCESS TO DATA STORED ON A BLOCKCHAIN

BACKGROUND

[0001 ] Data storage and handling supports many business processes and activities. Blockchain based techniques have been developed for providing distributed data services and may be applied to the enterprise environment to allow a large number of parties, including suppliers and customers, access to the data to be used to perform their roles. However, current blockchain based techniques may provide limited access control mechanism to enforce appropriate access rights for each party utilizing a blockchain based data store.

BRIEF INTRODUCTION OF THE DRAWINGS

[0002] Various features of the present disclosure will be apparent from the detailed description which follows, taken in conjunction with the accompanying drawings, which together illustrate features of the present disclosure, and wherein:

Figure 1 illustrates a relationship between actors, policies, blockchain views and atomic ledger fields according to examples;

Figure 2 is a block diagram of a blockchain node according to examples;

Figure 3 is a sequence diagram illustrating an example method of controlling access to data stored on a blockchain;

Figure 4 is a block diagram of a blockchain node according to examples;

Figure 5 is a block diagram of system including a blockchain node according to examples;

Figure 6 is a sequence diagram illustrating an example method of generating blockchain views and access policies;

Figure 7 is a flowchart illustrating an example method of controlling access to data stored on a blockchain;

Figure 8 is a flowchart illustrating an example method of generating blockchain views and access policies; and Figure 9 is an example of a device comprising a computer-readable storage medium coupled to a processor.

DETAILED DESCRIPTION

[0003] In the following description, for purposes of explanation, numerous specific details of certain examples are set forth. Reference in the specification to "an example" or similar language means that a particular feature, structure, or characteristic described in connection with the example is included in at least that one example, but not necessarily in other examples.

[0004] Further, reference in the specification to “a”, “an” or similar language in relation to a particular feature, structure or characteristic described means a single feature/structure/characteristic or at least one feature/structure/characteristic. Thus, this wording should not be construed as limiting in its use.

[0005] In recent years, secure ledger or “blockchain” technology has become increasingly applied to a range of tasks. Secure ledgers facilitate tracking of transactions whereby the veracity of transactions recorded in a blockchain may be checked based on a cryptographic relationship between blocks of the blockchain.

[0006] A secure ledger may comprise a series of blocks whereby a cryptographic hash function is applied to a block to generate a hash value used as in input to generate a next block in the chain. Transaction data may form a further input to the generation of the next block, recording the transaction details in the blockchain. This allows the integrity of any block in the chain to be checked based on the hash values, while falsifying a block in the blockchain would rely on determination of a modified block having the same hash value which is computationally difficult. Thus, blockchain based techniques may support tracking and auditing of transactions involving the secure ledger.

[0007] Many blockchains, such as those associated with cryptocurrencies, are permissionless blockchains that are open networks in which anyone may participate in the operation of the blockchain network and have full access to transactions and data stored in the blockchain. Thus, in permissionless blockchain, all information is public and there is no need for access control. In permissionless blockchain networks, a blockchain client and node roles may be combined, as information in the ledger was public.

[0008] In enterprise environment, it may be preferable to separate the roles of blockchain client and admin/operations, for example restricting the rights of some users to participate as full nodes in the blockchain network. Permissioned blockchains have been introduced to allow roles for different users of the blockchain to be controlled.

[0009] In a permissioned blockchain, access to the blockchain network may be restricted to certain participants, and different participants may be able to perform different functions on the blockchain. For example, certain users may be limited to read access, while other users may be provided with read and write access. However, current permissioned blockchains do not provide any fine-grained access control technology to control which information on clients are able to query. Rather, using current techniques a client may be allowed to either see the full ledger or none of it.

[0010] Hyperledger fabric is an open source blockchain framework for developing blockchain-based products and applications. Hyperledger fabric includes the concept of “channels” which are independent ledgers which can be selectively relayed to nodes. For example, a specified node may be subscribed to a restricted number of channels and restricted to receiving blocks from those channels and therefore unable to see other ledgers corresponding to other channels. While this allows some control over client access to different “channels”, or ledgers, there remains no way of providing more fine-grained access control for blocks or other data units within a ledger.

[0011 ] Examples may provide a mechanism to enforce effective, fine-grained and verifiable access control to data stored on a blockchain, such as a permissioned blockchain. Examples may provide an extension to core blockchain node services to enforce access control over information stored in the ledger. In order for a blockchain client to read information from a ledger, authorization of the client (user, device, service) to a particular role may be determined and at the same time, the particular role should be granted access to the particular set of information. [0012] Examples may provide effective, fine-grained and verifiable access control to the data stored on a blockchain. This may be achieved by:

1. Identifying atomic ledger fields (ALFs): data units in a ledger (transactions, blocks, state, etc.) which can be made accessible individually and, subsequently, are either fully accessible or not accessible for queries.

2. Defining blockchain views (BCVs), as a collection of ALFs, which themselves may be stored as ledger records.

3. Providing a mechanism for an administrator to grant access to blockchain views (BCVs) or groups of BCVs to actors (individual users, roles, groups of users by an attribute, etc.). Access may be granted via direct access control lists (ACLs) or other access control models (RBAC, MAC, etc.).

4. Enforcing access control to ledger information according to administrator defined blockchain views (BCVs).

[0013] Figure 1 illustrates a relationship between actors 101 (i.e. blockchain clients); blockchain views 105; atomic ledger fields 107 and access policies 103 according to examples.

[0014] According to the example of Figure 1 , an atomic ledger field, ALF, is defined as any data unit in a blockchain global state which can be made accessible individually, i.e. a field that may be returned to a blockchain client as the result of a query. Each ALF has a unique location, or address, in either the blockchain state or another part of the blockchain. For example, the unique location may include an ALF’s start and end point, start point and field type (where end point is automatically defined by compiler for the type), or identifier.

[0015] Each ALF may be associated with a unique identifier (ALF ID), comprising a combination of workflow/use case specific parameters/attributes uniquely pointing to an ALF in a blockchain state.

[0016] Atomic ledger fields may be considered to fall into a number of different types. For example, Type 1 ALFs may be defined as any data structure (e.g. any sequence of bits, such as variables, class instances, JSON, XML, compressed data, encrypted string, file, etc.) associated with a smart contract and stored in the blockchain state by operation of the smart contract.

[0017] In some examples, smart contract code may be structured to isolate the ALFs, i.e. as a formal declaration, to allow the ALF data structures to be exported when identifying the ALFs present on the blockchain.

[0018] For example, an ALF ID could be a use case specific, unique identifier such as a product Serial Number (SN); an entity’s public key; an employee’s email address or name, etc.

[0019] Type 2 ALFs may be defined as any other blockchain related data, such as individual or groups of blockchain transactions, consensus variables, root hashes, blocks, etc.

[0020] Further according to the example of Figure 1 , blockchain views 105 (BCVs) are defined. A blockchain view (BCV) is a (non-empty) collection of ALFs, which can be returned to a blockchain client in response to that client’s request for the corresponding ledger information. Each BCV contains at least one ALF. When provided to the intended recipient, a BCV is a piece of data than can be processed automatically (e. g. automated services) or visualized for humans.

[0021 ] An example of a BCV for querying information relating to an order may be as follows:

[0022] where Order, UID (unique identifier), date, and destination are use case specific parameters.

[0023] In examples, to define the BCVs, ALFs present on the blockchain may be identified, for example provided in a list to an administrator, and a set of ALFs selected to form a BCV. The BCV definition are then be stored in a way that is accessible to an access control entity, for example on the blockchain, in a separate database, or as an application module forming part of the access control entity.

[0024] All BCVs may be pre-defined once (statically) before access control is activated, or may be dynamically defined so that a BCV may be added at a later stage. At any moment, an existing BCV may be inactivated or automatically removed if there is no access policy associated with the BCV and/or it is no longer to be used for the business case.

[0025] In some examples, smart contract code may be configured to mark some ALFs as “non-queryable”, meaning that these ALFs may not be included as part of any BCV, as any query identifies a BCV as the subject of the query, it may not be possible to query an ALF which is not part of any BCV.

[0026] Further according to the example of Figure 1 , actors 101 (e.g. roles, groups, identities and/or instances) which may query the defined BCVs are defined. Each actor may be associated with a public key or other means of establishing an actor’s identity. For example, actor’s identity could be established based on an actor to proving possession of a corresponding private-key (e. g. as part of a challenge-response procedure) or shared secret, knowledge of a valid login/password pair, or ownership of a fingerprint, etc.

[0027] System policies 103 are associated with actors and BCVs and allow each actor to be selectively assigned to BCVs. Thus, a policy may indicate which actor is allowed to query certain BCVs. In examples, a BCV may be authorized to be accessed by more than one actor, and one actor may have access to multiple BCVs. If a BCV has no actor assigned it may be automatically removed from the database or the blockchain state, or deactivated with a transaction. Thus, policies may permit or forbid a query to a BCV.

[0028] In some examples, a policy 103 may further indicate that an actor is authorized to query a particular BCV for certain values of a specified ALF. Any combination of ALF values may be specified by the policy to limit authorization afforded an actor to a subset of the BCV. For example, for the example BCV Order defined above, a policy authorizing access by an actor to the BCV may be further defined to indicate that the actor is limited to querying BCV Order for orders associated with that actor, for example BCV Order for which ALF3 indicates a user ID matching an actor’s user ID, i.e. that the actor is the client that created the order. [0029] In some examples, policies 103 may be defined according to certain roles associated with actors, where performing a particular role may rely on access to certain BCVs. Actors may then be associated with policies based on the role of the actor within an organization. [0030] Polices may be dynamic and may be changed, added, or removed over time, for example by an administrator. In examples, Policies may be stored in the blockchain ledger by an administrator for a particular use case based on a transaction on the blockchain.

[0031 ] Thus, in the example of Figure 1 , actor 1 101-1 is identified in policy 1 103-1 as having authorization to query BCV1 105-1 , where BCV1 105-1 is defined as the set of ALF1 , ALF3, and ALF5 107-1 , 107-3, 107-5. Similarly actor 2 101 -2 has the same authorization under policy 1 103-1 to query BCV1 105-1 , but is also identified in policy 2 103-2 as authorized to query BCV2 105-2, where BCV2 is defined as the set of ALF2 and ALF3 107-2, 107-3. Actor 3 101 -3 is authorized to query BCV2 105-2 under policy 3 103-3 and is also identified by policy 4 103-4 as authorized to query BCV3 105-3, where BCV3 105-3 is defined as the set of ALF5 107-5.

[0032] Thus, as can be seen by the example of Figure 1 , an actor may be associated with more than one policy, each policy may give authorization to query a BCV and be associated with more than one actor. ALF4 107-4 of Figure 1 is not associated with any BCV and therefore cannot be queried by an actor.

[0033] In order to apply the policies illustrated in Figure 1 , examples include an access control enforcer entity. The Access Control Enforcer is a component and service placed in front of the blockchain ledger which receives queries from actors and enforces application of the policies for example as defined in the example of Figure 1.

[0034] Figure 2 illustrates a blockchain node 200 according to examples. According to the example of Figure 2, the blockchain node 200 includes an access control enforcer (ACE) 202 in communication with a database 204 storing blockchain view definitions. Blockchain node 200 further includes a secure ledger 206 on which are stored ALFs 208 and access policies 210. An actor 101 wishing to query data stored on the blockchain sends the query to the ACE 202 and if the query is authorized, the results are returned to the actor 101 by the ACE 202.

[0035] Figure 3 is a sequence diagram illustrating a method of performing a query, for example on the blockchain node 200 of Figure 2. In particular, the example of Figure 3 illustrates a method in response to actor 101 -1 of Figure 1 attempting to query BCV1 105-1 , although it will be recognized that the disclosed method is generally applicable to any other actor making a query to any BCV. As illustrated in Figure 3, actor 101 -1 sends a query 220 to the ACE 202. The query 220 identifies the BCV 105-1 which the actor 101 -1 wishes to query. In response to receiving the query 220, the ACE 202 accesses a corresponding policy 103-1 associated with the actor 101 -1 , for example in the form of a request 302 to access the policy and receiving 304 the policy 103-1. As illustrated in Figure 1 , multiple policies may be associated with an actor, and more than one policy may give authorization to access a BCV. Thus, the ACE 202 may retrieve a plurality of policies corresponding to the actor.

[0036] ACE 202 also requests 306 BCV database 204 to provide a definition of the BCV 105-1 identified in the query, i.e. identifiers of the ALFs 107-1 , 107-3, 107-5 assigned to the BCV 105-1 , and receive 308 the BCV definition from the database 204. The ACE 202 determines 310 based on the policy 103-1 and the identity of the actor 101 -1 making the query 220 whether the actor 101-1 is authorized to query the identified BCV 105-1. In the case that the actor 101 -1 is authorized, the ACE 202 requests the ALFs 107-1 , 107-3, 107-5 assigned to the BCV 105-1 and receives 314 these ALFs from the ALF store 208 on the ledger 206. The ACE 202 then returns 316 the results of the query 220 to the actor 101 - 1.

[0037] As discussed above, policy 103-1 may further limit authorization based on an ALF value to allow authorized access to a BCV by a user to be limited to specific instances, or a subset of instances, based on the ALF value. For example, limiting authorization for an actor to querying entries associated with that actor. When determining 310 based on the policy 103-1 and the identity of the actor 101 -1 making the query 220 whether the actor 101 -1 is authorized, the ACE 202 may further take into account any ALF based authorization rules provided in the policy 103-1. In some such examples, the ACE 202 may request 312 ALF values prior to confirming 310 that the query was authorized to allow the ALF values to be used in the authorization determination. The ACE 202 may then be able to return he results without a further request to retrieve the ALFs specified by the BCV definition for the query. Alternatively, in the case that further ALFs are specified by the BCV definition for the query that have not been retrieved to be used for the authorization determination, the ACE 202 may further request 312 ALF values having confirmed 310 that the query was authorized, to allow the result of the query to be returned to the actor 101 -1.

[0038] In some examples, the BCVs 105 may be stored on the blockchain, e.g. as part of the secure ledger 206. Figure 4 illustrates blockchain node 300 similar to the blockchain node 200 of Figure 2 in which BCVs 404 are stored on ledger 206.

[0039] In some examples, ACE 202 may not be located on the blockchain node, for example ACE 202 may be hosted as a cloud application separate to the blockchain node. Figure 5 illustrates an arrangement similar to the blockchain node 200 of Figure 2, wherein ACE 502 and BCV database 504 are located external to but communicatively coupled with the blockchain node 500, e.g. via a network, to allow the ACE 502 to retrieve policy and ALF information from the blockchain 206 in line with the method outlined in Figure 3.

[0040] According to examples, to perform a query a user, or actor 101 , sends a query 220 to the access control enforcer 202, and requests access to a blockchain view 105. The access control enforcer 202 queries the blockchain 206 for both the access control policy 105 for that blockchain view 105, and the result of the query 220. The blockchain 206 returns the result of query 220 and the access control enforcer 202 applies the access control policy 103 received to evaluate if the user 101 is authorized or not to access the blockchain view 105. If the user 101 is authorized to access the blockchain view 105, then the result of the query 220 is returned, otherwise an error is returned.

[0041] In some examples, the query 220 may include one or more parameters, or search values, to identify the desired query results as a subset of all possible results defined by the blockchain view. For example, for the example BCV Order discussed above, a query may include a parameter indicating a user ID of the client that created the order, date, order UID, etc. allowing the actor 101 to specify a particular order, all orders placed on a specified date, etc. Search values may relate to any atomic ledger field [0042] The access control enforcer 202 receiving a query including a search value may first determine that the actor 101 is authorized to access the blockchain view 105, as discussed above, and if so select results from all of the results defined by the blockchain view that match the search value to return as the results of the query 220.

[0043] Figure 6 is a sequence diagram illustrating a method to be performed by an administrator module 600 to set up access control to ledger information according to an example. According to the method of Figure 6, administrator module 600 performs actions 602 on the ALFs 208 stored on the ledger 206 to generate a list of all available ALFs. As described above, some ALFs may be marked as non-queryable and may not appear on the list of available ALFs received 604 by the administrator module 600. The list of available ALFs identifies all information present on the blockchain that can be returned to users as the result of a query.

[0044] Administrator module 600 then combines 606 ALFs into BCV definitions and stores 608 the BCV definitions, e.g. in database 204 or as information 404 on the blockchain ledger 206. Administrator module 600 identifies actors 101 that may query the ledger and creates 610 access policies that associate each actor 101 with one or more BCVs that actors 101 are authorized to query. The administrator module 600 may then store 612 the policies on the ledger 206, e.g. as a blockchain transaction.

[0045] Rules may be set in a smart contract for policy creation and updating that specify that the ability to set and update policies may be limited to certain actors, identified as policy providers.

[0046] Once the BCV definitions and policies have been created and stored, they may be accessed by the ACE 202 as described above to allow the ACE 202 to authenticate an actor attempting to query the blockchain to ensure that the actor is authorized to perform the query on the identified BCV.

[0047] In some examples, administrator access to data units, ALFs, on the blockchain may be enforced by the ACE. BCV definitions and policy information stored on the blockchain may itself be identified as ALFs and a policy defined to authorize actors authorized to perform administrative tasks to access those ALFs. [0048] In examples, policy creation, deletion, and/or modification may be performed using blockchain smart contracts. Changes to policies and BCV definitions may be enacted using a blockchain transaction providing an immutable record of changes to access policies and the identification of actors initiating those changes, allowing for accurate auditing of security changes.

[0049] Figure 7 illustrates a method 700 that may be performed by an ACE 202 to enforce access control for authorized actors querying data units, e.g. ALFs, stored on a blockchain. According to the method 700 of Figure 7, the ACE 202 receives 702 a query from a requesting entity, e.g. an actor, to access data stored on the blockchain, the query identifying a blockchain view that identifies the data unit present on the blockchain. In response to receiving the query, the ACE 202 obtains 704 an access policy associated with the BCV indicated in the query and determines 706, based on an identity of the requesting entity, whether the entity is authorized to access the blockchain view based on the policy. As discussed above, authorization may be further based on one or more ALF values defined in the access policy.

[0050] If it is determined that the requesting entity is not authorized, the query request is refused 708 and an error may be returned. In response to determining that the requesting entity is authorized, the ACE retrieves 710 the data units associated with the BCV and returns the query result to the requesting entity.

[0051 ] Figure 8 illustrates a method 800 that may be performed to allow an ACE 202 to enforce access control for authorized actors querying data units, e.g. ALFs, stored on a blockchain. According to the method 800 of Figure 8, all data units, e.g. ALFs, that are available on the blockchain to be queries are identified 802, e.g. provided in a list to an administrator. A Blockchain view is then generated comprising non-empty set of ALFs, and the BCV are recorded 804 on the blockchain. For example, this may be achieved as a blockchain transaction. An access policy identifying users, or actors, authorized to access the blockchain view is then generated and stored 806 on the blockchain.

[0052] Certain methods and systems as described herein may be implemented by one or more processors that processes program code that is retrieved from a non-transitory storage medium. Figure 9 shows an example 900 of a device comprising a computer-readable storage medium 930 coupled to at least one processor 920. The computer-readable media 930 can be any media that can contain, store, or maintain programs and data for use by or in connection with an instruction execution system. Computer-readable media can comprise any one of many physical media such as, for example, electronic, magnetic, optical, electromagnetic, or semiconductor media. More specific examples of suitable machine-readable media include, but are not limited to, a hard drive, a randomaccess memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory, or a portable disc.

[0053] In Figure 9, the computer-readable storage medium comprises program code to perform a method corresponding to the example shown in Figure 7, that is: receive 702 a query to access a BCV; obtain 704 an access policy; determine 706 whether a querying entity is authorized to query the BCV; if not authorized refusing 708 the query; and if authorized retrieving 710 the ALFs according to the BCV and returning the query result to the requesting entity.

[0054] In other examples, computer-readable storage medium 930 may comprise program code to perform a method 800 as illustrated in Figure 8.

[0055] All of the features disclosed in this specification (including any accompanying claims, abstract, and drawings) may be combined in any combination, except combinations where some of such features are mutually exclusive. Each feature disclosed in this specification, including any accompanying claims, abstract, and drawings), may be replaced by alternative features serving the same, equivalent, or similar purpose, unless expressly stated otherwise. Thus, unless expressly stated otherwise, each feature disclosed is one example of a generic series of equivalent or similar features.

[0056] According to an example, there is provided a non-transitory machine- readable storage medium encoded with instructions executable by a processor, to process a request, from a requesting entity, for access to data stored on a blockchain, the request comprising an indication of a blockchain view, wherein the blockchain view identifies a data unit present on the blockchain, obtain an access policy associated with the indicated blockchain view, determine whether the requesting entity is authorized to access the blockchain view based on the policy, obtain a definition of the indicated blockchain view, the definition comprising a unique identifier of the requested data unit, and in response to determining that the requesting entity is authorized to access the blockchain view, retrieve the requested data unit from the blockchain and providing the data unit to the requesting entity.

[0057] In an example, the blockchain view identifies a first plurality of data units.

[0058] In an example, a block of the blockchain comprises a second plurality of data units different from the first plurality of data units.

[0059] In an example, the instructions are further executable to obtain the access policy by retrieving the access policy from the blockchain.

[0060] In an example, the instructions are further executable to obtain the definition of the indicated blockchain view by retrieving the definition of the blockchain view from the blockchain.

[0061 ] In an example, the instructions are further executable to obtain the definition of the indicated blockchain view by retrieving the definition of the blockchain view from a database.

[0062] In an example, the instructions are further executable to generate a new transaction record reflecting the executed request for access to the data unit and adding the new transaction record to a secure ledger of the blockchain.

[0063] In an example, the instructions are further executable to, in response to determining that the requesting entity is not authorized to access the blockchain view provide an indication to the requesting entity that access is not authorized, and generate a new transaction record reflecting the unauthorized request for access to the data unit and adding the new transaction record to the secure ledger.

[0064] In an example, the data unit comprises an atomic ledger field, each atomic ledger field having a unique location in one of a blockchain state or another part of the blockchain.

[0065] In an example, the blockchain view comprises a plurality of identifiers identifying a plurality of atomic ledger fields, and the instructions further executable to retrieve the identified data unit from the blockchain and provide the data unit to the requesting entity by retrieving the plurality of atomic ledger fields from the blockchain. [0066] In an example, the atomic ledger field comprises a data structure associated with a smart contract on the blockchain.

[0067] According to an example, there is provided a system comprising an access control entity for controlling access to data stored on a blockchain, and a secure ledger of the blockchain, wherein the access control entity is to receive a request from a requesting entity to query data stored on the blockchain, the request indicating a blockchain view identifying one or more atomic ledger fields, the atomic ledger fields comprising uniquely identifiable data units located in one of a blockchain state or the secure ledger, obtain an access policy associated with the indicated blockchain view, determine whether the requesting entity is authorized to access the blockchain view based on the access policy, obtain a definition of the indicated blockchain view, the definition comprising one or more unique identifiers identifying the one or more atomic ledger fields, and in response to determining that the requesting entity is authorized to access the blockchain view, retrieve the one or more atomic ledger fields from the blockchain and provide a response based on the one or more atomic ledger fields to the requesting entity.

[0068] In an example, the system further comprises a database to store a plurality of definitions corresponding to a plurality of blockchain views, each definition identifying one or more atomic ledger units associated with a particular blockchain view.

[0069] In an example, the access control entity and the secure ledger are comprised within a blockchain node; or wherein the secure ledger is comprised within a blockchain node and the access control entity is not comprised within the blockchain node.

[0070] In an example, the access control entity is further to in response to determining that the requesting entity is authorized to access the blockchain view, generate a new transaction record reflecting the executed request for access to the blockchain view and add the new transaction record to the secure ledger of the blockchain, and in response to determining that the requesting entity is not authorized to access the blockchain view provide an indication to the requesting entity that access is not authorized, and generate a new transaction record reflecting the unauthorized request for access to the blockchain view and add the new transaction record to the secure ledger.

[0071 ] According to an example, there is provided a non-transitory machine- readable storage medium encoded with instructions executable by a processor, to process a request, from a requesting entity, for access to data stored on a blockchain, the request comprising an indication of a blockchain view, wherein the blockchain view identifies a data unit present on the blockchain, obtaining an access policy associated with the indicated blockchain view, determining whether the requesting entity is authorized to access the blockchain view based on the policy, obtaining a definition of the indicated blockchain view, the definition comprising a unique identifier of the requested data unit, andin response to determining that the requesting entity is authorized to access the blockchain view, retrieving the requested data unit from the blockchain and providing the data unit to the requesting entity.

[0072] According to an example, there is provided a method comprising identifying a plurality of atomic ledger fields comprising uniquely identifiable data units stored on a blockchain, recording a blockchain view on the blockchain, the blockchain view comprising a plurality of identifiers, the plurality of identifiers identifying a subset of the plurality of atomic ledger fields, recording, on the blockchain, an access policy identifying a user authorized to access the blockchain view.

[0073] In an example, the method further comprises obtaining a second plurality of identifiers identifying a modified subset of the plurality of atomic ledger fields for the blockchain view, and updating the blockchain view based on the second plurality of identifiers recording the updated blockchain view on the blockchain, and generating a new transaction record reflecting the update of the blockchain view and adding the new transaction record to the secure ledger.

[0074] In an example, the method further comprises obtaining an indication of a further user authorized to access the blockchain view, updating the access policy based on the indication of the further user authorized to access the blockchain view, recording the updated access policy on the blockchain, and generating a new transaction record reflecting the update of the access policy and adding the new transaction record to the secure ledger.

[0075] In an example, obtaining a second plurality of identifiers identifying a modified subset of the plurality of atomic ledger fields comprises receiving a request to modify data stored on the blockchain, the request comprising an indication of a second blockchain view, the second blockchain view identifying the record of the blockchain view on the blockchain, obtaining an access policy associated with the second blockchain view, determining whether the requesting entity is authorized to modify the second blockchain view based on the policy, obtaining a definition of the second blockchain view identifying the record of the blockchain view on the blockchain, and in response to determining that the requesting entity is authorized to modify the second blockchain view, performing the recording the updated blockchain view on the blockchain.

[0076] The present teachings are not restricted to the details of any foregoing examples. Any novel combination of the features disclosed in this specification (including any accompanying claims, abstract, and drawings) may be envisaged. The claims should not be construed to cover merely the foregoing examples, but also any variants which fall within the scope of the claims.

Claims

1. A non-transitory machine-readable storage medium encoded with instructions executable by a processor, to: process a request, from a requesting entity, for access to data stored on a blockchain, the request comprising an indication of a blockchain view, wherein the blockchain view identifies a data unit present on the blockchain; obtain an access policy associated with the indicated blockchain view; determine whether the requesting entity is authorized to access the blockchain view based on the policy; obtain a definition of the indicated blockchain view, the definition comprising a unique identifier of the requested data unit; and in response to determining that the requesting entity is authorized to access the blockchain view, retrieve the requested data unit from the blockchain and provide the data unit to the requesting entity.

2. The non-transitory machine-readable storage medium of claim 1 , wherein the blockchain view identifies a first plurality of data units.

3. The non-transitory machine-readable storage medium of claim 1 , the instructions further executable to obtain the access policy by retrieving the access policy from the blockchain.

4. The non-transitory machine-readable storage medium of claim 1 , instructions further executable to obtain the definition of the indicated blockchain view by retrieving the definition of the blockchain view from the blockchain.

5. The non-transitory machine-readable storage medium of claim 1 , instructions further executable to obtain the definition of the indicated blockchain view by retrieving the definition of the blockchain view from a database.

6. The non-transitory machine-readable storage medium of claim 1 , wherein the data unit comprises an atomic ledger field, each atomic ledger field having a unique location in one of a blockchain state or another part of the blockchain.

7. The non-transitory machine-readable storage medium of claim 6, wherein the blockchain view comprises a plurality of identifiers identifying a plurality of atomic ledger fields; and the instructions further executable to: retrieve the identified data unit from the blockchain and provide the data unit to the requesting entity by retrieving the plurality of atomic ledger fields from the blockchain.

8. The non-transitory machine-readable storage medium of claim 6, wherein the atomic ledger field comprises a data structure associated with a smart contract on the blockchain.

9. A system comprising: an access control entity for controlling access to data stored on a blockchain; and a secure ledger of the blockchain; wherein the access control entity is to: receive a request from a requesting entity to query data stored on the blockchain, the request indicating a blockchain view identifying a data unit, located in one of a blockchain state or the secure ledger; obtain an access policy associated with the indicated blockchain view; determine whether the requesting entity is authorized to access the blockchain view based on the access policy; obtain a definition of the indicated blockchain view, the definition comprising a unique identifiers identifying the data unit; and in response to determining that the requesting entity is authorized to access the blockchain view, retrieve the data unit from the blockchain and provide a response based on the data unit to the requesting entity.

10. The system of claim 9, wherein the data unit comprises an atomic ledger field, each atomic ledger field having a unique location in one of a blockchain state or another part of the blockchain.

11 . The system of claim 10, further comprising a database to store a plurality of definitions corresponding to a plurality of blockchain views, each definition identifying a plurality of atomic ledger units associated with a particular blockchain view.

12. The system of claim 9, wherein the access control entity and the secure ledger are comprised within a blockchain node; or wherein the secure ledger is comprised within a blockchain node and the access control entity is not comprised within the blockchain node.

13. A method comprising: identifying a plurality of atomic ledger fields comprising uniquely identifiable data units stored on a blockchain; recording a blockchain view on the blockchain, the blockchain view comprising a plurality of identifiers, the plurality of identifiers identifying a subset of the plurality of atomic ledger fields; recording, on the blockchain, an access policy identifying a user authorized to access the blockchain view.

14. The method of 13 comprising: obtaining a second plurality of identifiers identifying a modified subset of the plurality of atomic ledger fields for the blockchain view; and updating the blockchain view based on the second plurality of identifiers; recording the updated blockchain view on the blockchain; and generating a new transaction record reflecting the update of the blockchain view and adding the new transaction record to the secure ledger.

15. The method of 13, comprising: obtaining an indication of a further user authorized to access the blockchain view; updating the access policy based on the indication of the further user authorized to access the blockchain view; recording the updated access policy on the blockchain; and generating a new transaction record reflecting the update of the access policy and adding the new transaction record to the secure ledger.