Permissions

Abstract

The invention relates to a system of access control where permissions 900 stored in databases can be translated into permission assertions 914 which are distributed to requesting / relying resource enti

Description

FIELD [1] The disclosure relates to various methods, apparatus, and computer-readable media for permissions for use in, particularly but not exclusively, managing and facilitating access to a resource. BACKGROUND [2] Data representative of permissions are used by access control systems to facilitate user access to resources such as internet-based services. An admin may define a permission level for each of a set of users and the resource may be accessed by the set of users based on their individual permission level specified by the permission data. Example access control systems include Relationship-based Access Control (ReBAC). SUMMARY [3] Current systems for facilitating access control via permissions rely heavily on centralized databases, which are inherently insecure due to their susceptibility to unauthorized access and manipulation. These databases allow for rows of data to be accessed, edited, or amended, thereby compromising the integrity and truthfulness of the information stored. [4] Certain aspects of the disclosure and their embodiments may provide solutions to one or more of these or other challenges. As such, techniques are described that involve implementing improved permissions referred to herein as “provable permissions”. [5] In a first aspect, a computer-implemented method performed by an Asserting Entity is described. The method comprises: producing permission data for controlling access by a Client Entity to a Resource based on an access right associated with the Client Entity, wherein the permission data comprises proof data indicative of one or both of a provenance and an integrity of the permission data. [6] In a second aspect, a computer-implemented method performed by an Endorsing Entity is described. The method comprises: endorsing permission data for controlling access by a Client Entity to a Resource based on an access right associated with the Client Entity, wherein the permission data comprises proof data indicative of one or both of a provenance and an integrity of the permission data. [7] In a third aspect, a computer-implemented method performed by a Requesting Entity is described. The method comprises: sending a request to a Verifying Entity to verify one or both of a provenance and an integrity of permission data for controlling access to a Resource, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data; and receiving, from the Verifying Entity, an indication of whether the proof data proves one or both of the provenance and the integrity of the permission data. [8] In a fourth aspect, a computer-implemented method performed by a Verifying Entity is described. The method comprises receiving a request from a Requesting Entity to verify one or both of a provenance and an integrity of permission data for controlling access to a Resource, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data; and sending, to the Requesting Entity, an indication of whether the proof data proves one or both of the provenance and the integrity of the permission data. [9] In a fifth aspect, a computer-implemented method performed by an Access Control Entity is described. The method comprises receiving a request from a Client Entity to access a Resource; determining an access right associated with Client Entity based on permission data in response to one or both of a provenance and an integrity of the permission data being verified, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data; and determining whether to authorize access to the Resource based on the access right.

[10] In a sixth aspect, a computer-implemented method performed by a Client Entity is described. The method comprises: sending a request to an Access Control Entity to access a Resource; and receiving an indication that the Access Control Entity has determined an access right associated with the Client Entity based on permission data in response to one or both of a provenance and an integrity of the permission data being verified, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data.

[11] In a seventh aspect, a computer-implemented method performed by a Controlling Entity is described. The method comprises: receiving a control instruction from a Client Entity authorized to access a Resource associated with the Controlling Entity in response to a verification of one or both of a provenance and an integrity of permission data associated with the Client Entity, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data; and causing the Resource to perform an action based on the control instruction.

[12] In an eighth aspect, a computer-implemented method performed by a Controlling Entity is described. The method comprises: receiving a control instruction to interact with a Resource associated with the Controlling Entity, wherein the control instruction is associated with permission data accessible to the Controlling Entity, wherein the permission data is indicative of an access right associated with the control instruction, and wherein the permission data comprises proof data indicative of one or both of a provenance and an integrity of the permission data; determining whether to grant access to the Resource based on verification that an origin of the control instruction is associated with the permission data and based on verification of one or both of the provenance and the integrity of the permission data; and causing the Resource to perform an action in accordance with the control instruction based on access being granted.

[13] In a ninth aspect, an apparatus is described. The apparatus comprises: a memory; and a processor coupled to the memory and configured to perform the method of any of the first aspect, second aspect, third aspect, fourth aspect, fifth aspect, sixth aspect, seventh aspect, and eighth aspect.

[14] The summary is not intended to be used in isolation to determine the scope of the claimed subject matter, nor identify key or essential features of the claimed subject matter. The disclosed subject matter can be understood with reference to any part of this entire disclosure, including one or more parts of the description, one or more claims, and / or one or more drawings. The foregoing, along with other described subject matter, will be described in more detail below in the following description, claims, and accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[15] Exemplary embodiments of the disclosure will now be described, by way of example only, with reference to the following drawings, in which:

[16] Fig. 1 is schematic diagram of a system in which one or more embodiments may be implemented;

[17] Fig. 2 is a schematic diagram depicting an implementation of a key hierarchy used in one or more embodiments described herein;

[18] Fig. 3 is a schematic diagram depicting certain Interactions in a Community according to one or more embodiments described herein;

[19] Fig. 4 is a schematic diagram depicting a system for implementing assertions and endorsements according to one or more embodiments described herein;

[20] Fig. 5 is a schematic diagram of an example permission management system;

[21] Fig. 6 is a schematic diagram of a permission management system according to one or more techniques provided by this disclosure;

[22] Fig. 7 depicts a representation of example data structures based on ReBAC such as may be used by the example permission management system of Fig. 5;

[23] Fig. 8 depicts a representation of example data structures according to one or more techniques provided by this disclosure;

[24] Fig. 9 is a schematic diagram of an approach for producing an Assertion based on a tuple according to one or more techniques provided by this disclosure;

[25] 10 is a sequence diagram depicting a flow of data between various entities in a permission system according to one or more techniques provided by this disclosure;

[26] Fig. 11 is a flowchart of a method according to a technique of this disclosure;

[27] Fig. 12 is a flowchart of a method according to a technique of this disclosure;

[28] Fig. 13 is a flowchart of a method according to a technique of this disclosure;

[29] Fig. 14 is a flowchart of a method according to a technique of this disclosure;

[30] Fig. 15 is a flowchart of a method according to a technique of this disclosure;

[31] Fig. 16 is a flowchart of a method according to a technique of this disclosure;

[32] Fig. 17 is a flowchart of a method according to a technique of this disclosure;

[33] Fig. 18 is a flowchart of a method according to a technique of this disclosure;

[34] Fig. 19 is a schematic drawing of a computer-readable medium for implementing various techniques and embodiments described herein;

[35] Fig. 20 is a schematic drawing of apparatus for implementing various techniques and embodiments described herein; and

[36] Fig. 21 is a schematic diagram of a system implementing one or more techniques relating to provable permissions and depicts various scenarios that may play out. DETAILED DESCRIPTION

[37] One or more aspects or embodiments referred to herein will now be described more fully with reference to the accompanying drawings. Aspects and embodiments are provided by way of example to convey the scope of the subject matter to those skilled in the art.

[38] The disclosure relates to various methods, apparatus, and computer-readable media for permissions for use in, particularly but not exclusively, managing and facilitating access to a resource.

[39] As explained previously, current systems for facilitating access control via permissions rely heavily on centralized databases, which are inherently insecure due to their susceptibility to unauthorized access and manipulation. These databases allow for rows of data to be accessed, edited, or amended, thereby compromising the integrity and truthfulness of the information stored.

[40] Certain aspects of the disclosure and their embodiments may provide solutions to one or more of these or other challenges. As such, techniques are described that involve implementing improved permissions referred to herein as “provable permissions”.

[41] The following discussion provides some initial information on a system that implements what are termed “Entity Interactions” to support certain embodiments that relate to provable permissions. The “Entity Interactions” system has not been publicly disclosed previously. Certain techniques of the present disclosure may make use of the “Entity Interactions” system but are not limited to using such a system. Indeed, certain embodiments do not need to make use of the system. The discussion on provable permissions is provided after the discussion on Entity Interactions. ENTITY INTERACTIONS

[42] As indicated above, there are some embodiments that may leverage certain mechanisms that facilitate interactions between entities associated with a community. These mechanisms are based on a system under the heading of “entity interactions” that facilitates improvements to one or more of the following concepts: Digital Identity, Provenance, Social Proof, and Security of Assets, among many other possible concepts in cyber security. In an example, the system may allow members of a community to endorse data associated with other members of the community in a cryptographically provable manner to facilitate interactions between those members of the community.

[43] To help with understanding the social proof system, some definitions are given below.

[44] As used herein, the term ‘Entity’ is a term used to describe a comprehensive system that includes everything within the universe, including living organisms, inanimate objects, digital avatars, artificial intelligence, or any being.

[45] This 'Entity' is a distinct unit that holds relevance in a particular context. It can be a concrete or abstract thing that exists, can be identified uniquely, and can create interactions. Wherein the Entity comprises one or more of, but not exclusively:

[46] 'Person': An individual human being.

[47] ‘Asset’: A ‘Physical Asset’ or a ‘Digital Asset’, such as described below.

[48] 'Physical Asset': Tangible items of value such as, but not limited to, property, vehicles, or luxury items.

[49] 'Business': An organization or company engaged in commercial, industrial, or professional activities.

[50] 'Community': A group of individuals who share common values, interests, or goals.

[51] 'Digital Asset': Non-tangible items of value that exist in digital form, such as, but not limited to data, NFTs (Non-Fungible Tokens), SFTs (Semi-Fungible Tokens), or Metadata / JSON.

[52] 'AI': Artificial Intelligence, which refers to systems or machines that mimic human intelligence to perform tasks, and may be able to iteratively improve themselves based on the information they collect.

[53] 'Event': An organized activity such as a gig, conference, or sporting event.

[54] An Entity may be considered to be ‘controlling’ or ‘controlled’, depending on the context. For example, a person may be a controlling Entity of something such as an Asset owned or controlled by that person. Such an Asset in this context is an example of a ‘controlled Entity’. A person or an AI are examples of a ‘user’ or ‘member’. Any reference herein to a user or member may be considered to refer to any other appropriate type of Entity, where allowed by the context of the discussion.

[55] Thus, the term ‘Entity’ and the plural form ‘Entities’ are to be construed broadly in line with the above and any further discussion below, and are not limited to the specifically listed Entities.

[56] As used herein, an ‘Interaction’ refers to any action, communication, transaction, or exchange that occurs between individual Entities or Entities within the digitally-enabled or physical platform, system, or Community environment. An Interaction may include a wide range of activities such as accessing and using applications, engaging in dialogue or collaboration among users, initiating and completing transactions, sharing or exchanging information, services, or goods, and / or any other form of participative engagement facilitated by the Community's infrastructure. Interactions are governed by the established protocols, standards, and security measures, ensuring they are conducted in a secure, authenticated, and efficient manner. Details of how certain Interactions are governed are the subject of one or more aspects or embodiments of this disclosure. An example purpose of Interactions is to foster a vibrant ecosystem of exchange, collaboration, and innovation, enhancing the value and utility of the Community for all participating Entities. Through leveraging technologies like blockchain, digital signatures, and encryption, the Community may ensure the integrity, authenticity, and, where applicable, confidentiality of these interactions, thereby cultivating a trusted environment for Entities to operate and engage with each other.

[57] As used herein, ‘Live Data,’ also known as real-time data, refers to information that is delivered immediately after collection from an Interaction between Entities. There is no practical delay in the timeliness of the information provided. The Live Data may be streamed continuously through the internet due to constant updates from various Entities. This data may be processed and analyzed immediately upon receipt for tasks that may include real-time decision-making, live reporting, and instant alerting systems.

[58] As used herein, a ‘Community’ refers to a digitally-enabled or physical platform, system, or environment that serves as a central hub or nexus point for the facilitation, authentication, and notarization of interactions and transactions among a diverse set of Entities, including but not limited to applications (software, tools, platforms), individuals (users, participants), organizations (corporations, institutions, associations, government departments, non-profits, etc.), and a community of Communities. This Community framework is designed to enable secure, verified, and / or efficient exchanges or collaborations, leveraging technologies related to blockchain such as digital signatures and encryption techniques to ensure the integrity, authenticity, and, where applicable, confidentiality of the Interactions. An example function of this Community is to foster a trusted ecosystem where these Entities can interact, transact, or exchange information, services, or goods under a common set of rules, protocols, or standards, thereby facilitating a seamless, interoperable, and secure environment for digital or physical engagements. Another example of the Community framework provided by techniques according to this disclosure includes facilitating Interactions between two or more Entities associated with the Community. For example, a first Entity associated with a Community could be an individual or an organization such as a business. A second Entity associated with the Community could be another individual or another organization such as a business. Thus, in an example, a Community could be formed to facilitate Interactions between two or more individuals. In another example, a Community could be formed to facilitate Interactions between one or more individuals and one or more organizations (e.g., an individual could interact with a business). In another example, a Community could be formed to facilitate Interactions between two or more organizations (e.g., two or more businesses could interact with each other). These are given as examples only, and many other types, numbers, and combinations of Entities could interact with each other as part of a Community.

[59] In some cases, an Entity may be considered to be represented by or associated with one or more computing nodes or computing devices. Such a computing node or computing device may be local or remote to an interface (e.g., user interface) through which an Entity (e.g., individual, organization, etc.) associated with the Community causes Interactions to be performed with one or more other Entities (e.g., another individual, organization, etc.) associated with the Community. These other Entities may also be represented by or associated with one or more computing nodes or computing devices. Thus, at a high level, techniques described here may facilitate an Entity (e.g., an individual, organization, etc.) associated with a Community to perform one or more Interactions with respect to one or more other Entities associated with the Community. At a lower level, such Entities may be associated with or may comprise one or more computing nodes or computing devices that perform data processing and / or transmit / receive signals to / from other nodes / computing devices. One or more interfaces (e.g., a user interface, an application programming interface (API), etc.) may be provided to enable an Entity to interact with (at the high level) one or more other Entities. Such Interactions may involve one or more data communications between the Entities (represented at the lower level by computing nodes and / or computing devices) that correspond to or represent the Interactions between the Entities.

[60] For example, a Community may group a set of Interactions that all have a common purpose. The Community may form a nexus point of notarization or verification for that common purpose. In an example, if the Community is an Application, for everything under that Application, the Community may represent a notary for a common purpose of all the Interactions that are then done under the auspices of that Community.

[61] As used herein, an ‘Asset’ refers to any digital or physical item, resource, or property (e.g., a type of Entity such as a controlled Entity) that may hold value within a Community. An Asset may encompass a broad spectrum of Entities including, but not limited to, digital currencies, tokens, intellectual property and intellectual property rights (such as inventions, patents, trademarks, designs, copyrighted work, creative works, trade secrets, knowhow, etc.), contracts, data, software, tools, and physical items represented in digital form. Assets in this framework may be characterized by their ability to be owned, transferred, shared, or otherwise managed through digital means, facilitated by the Community's infrastructure. Utilizing Origin Handle technology (as described below), Entities and Communities can ensure the secure, verified, and efficient handling of Assets, maintaining their integrity, authenticity, and confidentiality as required. Assets within this ecosystem can be leveraged for a variety of purposes, such as transactions, collaborations, investments, or as part of the exchange of goods and services, potentially making them central to the interactions and value exchange within the Community. In some cases, an ‘Asset’ may be a type of Entity which may be referred to herein as a ‘controlled Entity’.

[62] As used herein, a ‘Handle’ refers to a unique identifier or digital Alias used by an individual or Entity within a ‘Community’ to facilitate identification, interaction, and / or communication. The Handle may be referred to herein as an ‘Origin Handle’. The term ‘Origin’ is non limiting and may be used to indicate that an Entity with a Handle has a socially-provable Origin to allow that Entity to interact as part of / in association with a Community. This identifier may be distinctively chosen by the user or automatically assigned by the system, serving as a representation or virtual identity in the digital ecosystem. Handles as described herein are used for enabling secure, efficient, and / or personalized interactions within the community, allowing users to engage in transactions, collaborations, and / or communications while maintaining a level of privacy or anonymity if desired. Additionally, a Handle may be linked to an Entity’s (e.g., user's) digital identity, credentials, and access rights within the community, ensuring that interactions and transactions are securely managed and authenticated according to the Community's protocols and the Entity’s (e.g., user's) role or authorization level.

[63] As used herein, an ‘Alias’ is a pseudonym, handle, or identifier used by an Entity - in place of its real name or identifier. This Alias can be used to interact, transact, or communicate in various contexts while preserving the Entity's privacy and security. An Alias may act like a virtual mask, allowing the Entity to engage in activities without revealing its actual identity, thereby serving as a mechanism for privacy protection and firewalling. The Alias can create modified Profiles from the original Origin Handle, thereby creating a unique identifier that may allow for adjusted public or private profile settings for the Alias Entity to use when Interacting with other Entities.

[64] As used herein, the term “Origin Standard” (OS) may be used to denote that a described solution uses or implements one or more techniques discussed herein. Thus, when referring to OS, this may refer to the functionality provided by one or more embodiments described herein. The OS has solved one or more issues of Digital Interactions related to interoperability of Digital Identity, Provenance, Social Proof and Security of Assets by underpinning all technology as one standard. The OS may become a common standard for the aforementioned interoperability subjects within Blockchain, Web 3.0, Web X and the Metaverse. Within this disclosure, Blockchain (Private or Public), Web X (Covering Web 2.0, 3.0, 4.0, 5.0 and any others in the future), Metaverse (Meta owned or some other version of alternative reality) shall be collectively referred to as Digital Realms.

[65] Fig. 1 is schematic diagram of a system 100 in which one or more embodiments relating to the “Entity Interactions” concept may be implemented. The system 100 is an example implementation and other implementations (i.e., architectures) are possible within the scope of the disclosure.

[66] The system 100 comprises a service provider for OS 102 and a client ecosystem 104. The client may be a client of the service provider in some implementations, although in other implementations there may be no Interaction with the service provider. The client ecosystem 104 comprises compute infrastructure 106 (such as one or more processing nodes), an Application Programming Interface (API) 108 and a set of computing devices 110 (e.g., each computing device 110 associated with a user or member of a Community such as an organization). As depicted by Fig. 1, there are first set of Entities 112 (e.g., users or members that may be socially proven by other Entities associated with the community such as by being endorsed by other members associated with a Community) and a second set of Entities 114 (e.g., users or members that have not yet been socially proven by other Entities associated with the community). As discussed previously, a Community may be associated with one or more Entities, which may include controlling and / or controlled Entities. Other types of Entities may be associated with the Community such as controlled Entities. The API 108 is accessible to the set of computing devices 110 and the compute infrastructure 106, and facilitates the implementation of one or more embodiments described herein by the computing devices 110 and / or the compute infrastructure 106.

[67] Fig. 2 is a schematic diagram depicting an implementation of a key hierarchy that may be used in one or more embodiments relating to the “Entity Interactions” concept as described herein.

[68] Each Entity (e.g., a user or a project associated with a Community) has an associated master key (which may also be referred to herein as a Seed or master Seed). The Seed is generated based on a mnemonic and shares of the Seed. The Seed may be considered to be a spawnable key. The shares of the Seed are stored in trusted storage. Each share is stored in a separate storage such that no two shares are stored in the same logical memory. For example, the shares may be distributed throughout some compute infrastructure such as depicted by Fig. 1. An encryption service is enabled based on the master key, which is used to derive one or more keys deterministically based on the master key. Such keys may be used for different purposes. Each key may be socially proven (e.g., socially endorsed) such that if an Entity signs some data with such a key, a social-based proof mechanism exists to confirm that one or more other Entities associated with the Community trusts and / or verifies that it was indeed the Entity that signed the data, and that the Entity is still socially proven. The keys may be considered to be throwaway or single use or otherwise restricted use, meaning that the system can be confident that the same key cannot be used for a different purpose, which may enhance the security of the system.

[69] Figure 2 depicts one of many different possible purposes of the keys derived from the master key. In the depicted branch derived from the master key, an endorsement key is to facilitate for the purpose of generating a project or an Origin. In another example, a proof key (e.g., aggregate proof key) may be used to generate a community proof (e.g., for verifying a signature generated within the Community) or an issuance proof key. In another example, a key for use in blockchain operations may be derived. In another example, a key splitting scheme may be based on a key derived from the master key (e.g., to facilitate asset tracking or transfer). In each case, one or more revisions of the data, project, etc., may be signed using the key dedicated to the particular purpose. Thus, each key derived from the master key is intended for a specific purpose (e.g., a specific type of Interaction) associated with the Community. Security is maintained because no key is reused for signing data associated with different purposes. Instead, a key that has been deterministically derived according to the hierarchy for a specific purpose associated with the Community can be used for signing for only that specific purpose.

[70] Fig. 3 is a schematic diagram depicting certain Interactions in a Community according to one or more embodiments described herein. An Entity (e.g., a user) in or wishing to join a Community may have access to a master key, which is used to derive a proof key. One or more Community Entities (e.g., other users, which may be referred to herein as ‘endorsers’) may sign and / or countersign a message comprising the proof key, to indicate they endorse the Entity (user). The output is an aggregated signature, indicating Endorsement of the Entity (user). Thus, an Origin (associated with the user) may join the Community since the aggregation of the signatures provides Community-verifiable proof that the Entity (user) can be associated with the Community and is approved. When more than one Community Entity endorses the proof, this may generate a revision to the community proof. Similar, a revocation of Endorsement by one or more Entities may cause the community proof to be revised (e.g., from vl, to v2, etc.). In some cases, a third party Entity may use an endorsement key derived from their master key in order to (e.g., further) endorse the Entity (user).

[71] The OS includes several concepts that can be considered to be under the heading of ‘Interactions’. Interactions may include concepts such as endorsements, collaboration, and authentication, as discussed below. Thus, any reference to such concepts may be considered to generally refer to a type of Interaction. The concepts described below are illustrative of possible functionality enabled by the subject matter described herein, and are not limiting to the scope of the subject matter of the disclosure. Any one or more of these concepts may form part of, be combined in part or in whole with, or used in conjunction with any of the aspects or embodiments described herein. Endorsements

[72] Under the endorsement concept, a method may be implemented for enabling endorsements and assertions against known or unknown Entities.

[73] As already noted, an Entity is a term that could be used to describe a comprehensive system that includes everything within the universe, including living organisms, inanimate objects, digital avatars, artificial intelligence or any being.

[74] A request can be received by or sent to any Entity.

[75] Either the initiator / requester Entity or receiver Entity can be known or unknown to each other. It shall be understood that any Community may be associated with two or more Entities. Therefore, any reference herein to scenarios involving two Entities shall be understood to be non-limiting and can be extended to scenarios involving more than two Entities.

[76] The request can be made to endorse an Entity as anything that the requester Entity decides to be appropriate. The receiver Entity can make the decision as to whether to accept the request and sign the endorsement, creating a 2-way confirmation signature on the endorsement.

[77] Any Entity can decide to revoke the endorsement at any point in the future and the endorsement will be revoked at the discretion of one party (Entity) at the point of signature revocation.

[78] The following examples demonstrate how the system may be implemented and applied in different contexts. Collaboration

[79] An OS Collaboration is an example of a project management tool for WebX.O, amongst many other possible purposes. Such a collaboration may be used to organize and streamline the creation of a digital asset between multiple collaborators (i.e., Entities associated with a Community). This can include but is not limited to contract agreements, creating communities, minting digital NFTs, assigning physical items and much more. Collaboration may be considered to be an element of the OS process for managing projects.

[80] In OS, each project is composed of a number (e.g., two or more) of collaborators who are assigned a number of signatures to contribute to the smart contract metadata. Signatures can be assigned to individual members or groups to ensure that everyone involved has clear expectations and access to the same signature requirements of SFTs or NFTs.

[81] Some projects may require people outside of a network of collaborators. Guests can be invited to join individual projects as additional stakeholders without giving them full access to an entire portfolio. Authentication

[82] The OS Handle Endorsements and Collaboration concepts can enable monitor tracing of any Entity such as represented by a record that is stored in an appropriate location such as on-chain, off-chain, etc. Each OS Handle can be linked to any crypto wallet.

[83] The described technology can split the Seed of a Hierarchical Deterministic (HD) wallets. This means that any project collaboration can have one ore more keys issued to the various Entities involved both on a public and private level. This approach may enable multiple (e.g., two or more) Entities to assert authority of any physical asset that a public key and a payload is assigned to. Such a payload may comprise data indicative of one or more of: an identity of an Entity associated with a Community, an identity of the Community, information about the physical asset such as tracking and / or status information (e.g., sender address, recipient address, proof of when and / or where the physical asset has been scanned, or any other useful information for tracking), and / or any other useful information such as a link (e.g., a uniform resource locator) to the public key and / or a link to otherwise facilitate verification of and / or update a status of the physical asset. Any other appropriate information may be included in the payload.

[84] It is also possible to use one or more Radio Frequency Identification (RFID) tags to assign parts of threshold public keys and payloads (as described above) to individual parts of any physical item. This means item tampering is completely identifiable and may ensure the traceability of any asset along any supply chain.

[85] An example of the application of this technology to tracking the bottles of wine through the supply chain.

[86] Cryptographic keys may be split at the Origin associated with the winery. Associated private keys owned by the project collaboration owners may be shared with key stakeholders (e.g., the Winemaker and Winery).

[87] A physical cryptographic key (e.g., a public key) and a payload may be assigned to one or more RFID tags and attached to the physical item (e.g., embedded on seal of the bottle of wine, or otherwise physically implemented and attached).

[88] RFID tags can be scanned at any point and if the seal is broken the key is automatically destroyed, thereby indicating to the relevant stakeholder(s) that the bottle has been compromised. Additional Explanation

[89] Master keys (more accurately master Seed) may be generated from a mnemonic (either user supplied or generated for the user) and split into multiple shares using a technique such as Shamir’s Shared Secrets. Each share of the Seed is kept separately and encrypted with a different key e.g., a community storage key.

[90] The mnemonic, i.e., a Seed Phrase also known as a Mnemonic Phrase, is a series of words generated by an Origin Handle during its setup. This phrase serves as a backup mechanism for an Origin Handle in the same way as a cryptocurrency wallet's private keys, enabling the owner to recover their Origin Handles in the same was a user can recover their cryptocurrency holdings in case the wallet is lost, damaged, or otherwise inaccessible. The seed phrase is derived from a cryptographic algorithm based on a predetermined word list. The security and confidentiality of the seed phrase are paramount, as anyone with access to it can potentially gain control over the wallet's funds. For this reason, users are advised to store their seed phrase in a secure and private manner, avoiding digital storage methods that could be compromised. The seed phrase is a highly relevant component of wallet security within the blockchain ecosystem, offering a user-friendly and secure method of key management and recovery.

[91] This master Seed is used to deterministically derive private / public keys for different scenarios where each one of the keys is used contextually. For example, each Origin revision gets a proving key via a derivation path. When endorsing a project, a new key pair is issued for the project and the proving key is used to prove the issuance of this key to be valid with the context of the project (a commitment is made from details about the project). See hierarchy of Fig. 3 for more details about key derivation.

[92] Communities may act as a certificate authority where each Community has a set of community endorsers made up from a set of Origins. These Origins combine together to create a Boneh-Lynn-Shacham (BLS) signature to act as an initial proving signature for an Origin joining a Community or a community endorsement.

[93] Public keys may be shared with the item or Origin that has been endorsed so the signature can be verified. The Origin related to public key is also within the signature metadata which can then be used to check the key’s issuance proof against the Origin issuance key.

[94] Fully private data would hopefully not be on the system to begin with as one would try to use zero knowledge proofs where appropriate. That said, a user may want some endorsements to be private or only available to certain other parties. These hidden assertions do not appear when data about that particular Handle is requested, and such data requires a proof of access to be able to be retrieved. Thus, the presentation of the Origin can be different to parties who have been given different levels of access (e.g., a different status within the Community). Private / Hidden endorsements may be encrypted and may require proof of access to unlock them. Endorsement

[95] ‘Endorsement’ refers to a formal acknowledgment, approval, or support of an Asset, Interaction, or Entity within the ecosystem. This acknowledgment is typically made through a digital signature or a similar cryptographic mechanism that verifies the endorser's identity and their authority to provide such endorsement. An endorsement can serve multiple purposes, such as:

[96] Verifying the authenticity and integrity of a digital asset or transaction.

[97] Assertions and statements about an Entity, aspects of the entity or Interaction between Entities.

[98] Confirming the credibility or trustworthiness of entities within the Community, including individuals, organizations, or applications.

[99] Authorizing or validating a transaction, agreement, or interaction, thereby facilitating trust among parties involved.

[100] Endorsements within this context are highly relevant for maintaining a secure, trustworthy, and efficient environment, where trust is often derived from the digital reputation and the authenticated support of community members or systems. By leveraging blockchain technology and encryption, endorsements are made immutable and tamper-evident, ensuring that they reliably reflect the support or approval of the endorsing party at the time of endorsement. This mechanism supports the overarching goals of the Community to foster a trusted ecosystem for exchanges, collaborations, and transactions.

[101] An example method for endorsement may comprise following steps:

[102] A request is made to endorse an Entity with an assertion.

[103] A request to endorse may be a commencement of an approval Workflow (discussed in more detail below).

[104] A determination is made by an Entity associated with the Community whether to accept the request.

[105] Each user (Entity) approving the Endorsement needs to authorize via one of the associated authentication methods described herein.

[106] This approval process may be performed via retrieving a message from the server (message may be a commitment comprising a nonce and approval information).

[107] A signature is generated for the commitment / message.

[108] The message is submitted back to the Application Programming Interface (API).

[109] In the UI, this process can be performed via one button. [HO] Once all relevant parties (Entities) have signed their commitment / message then the platform may request the Community key servers to produce the actual signatures and proofs that are applied to the endorsed Entities. [Ill] A request for Endorsement (or a request to endorse another Entity) is part of an approval flow that requires both Entities to sign a message. This signature is distinct from the signatures and proofs generated from the Origin itself and are signatures derived from an access method configured on the account. These methods may be used to control and authorize actions on the platform.

[112] These methods may include or facilitate:

[113] A Web3 based wallet that has been associated with the Origin Handle (such as a metamask wallet). This wallet could be associated with a key generated from the Origin itself and imported into a 3rd party wallet or eventually the Origin wallet.

[114] An MFA process, such as a password login + Short Message / Messaging Service SMS code, which is used to reconstruct a signature via key derivation function (e.g., based on or similar to PBKDF2).

[115] An issued API key and a key derivation function.

[116] One or more of these methods may be used as authorizations which then allow the Origin Handle to be unlocked and used for key issuances / proofs / Endorsements etc. Revocation

[117] There may be several methods for checking revocation, examples of which are discussed below.

[118] When an Origin Endorsement is revoked, a new revision of the Endorsement is issued, and the metadata for the Origin for this reflects that when requested from the API.

[119] When a project Endorsement is revoked, then similarly the API can reflect this. If the Entity produced has updatable metadata (such as an NFT contract which allows this), then that item will be updated too.

[120] If the item has a physical representation of the Endorsements (such as a Quick Response (QR) code) then this may be submitted to a verifications API to see if these Endorsements are still valid. Workflow

[121] As used herein, a 'Workflow' in this context refers to the sequence of processes through which an interaction from an Entity is managed, using an Origin Handle for identification and authentication. A definition is provided below:

[122] Entity Recognition: The Workflow begins when an Entity initiates an Interaction. This Entity is recognized based on its unique Origin Handle.

[123] Handle Validation: The Origin Handle associated with the Entity is validated to confirm the identity of the Entity and ascertain the legitimacy of the Interaction. This involves crosschecking the Handle using cryptographic techniques.

[124] Interaction Creation: The Entity Endorses one or more participants to Interact on a set of Assertions attached to an Endorsement. The specific details of the Interaction initiated by the Entities are assigned to the Endorsement, pending signature.

[125] Interaction Processing: The recorded Interaction is then processed according to predefined procedures or algorithms. This involves routing the Interaction to the appropriate parties, triggering certain actions and performing computations.

[126] Signature Application: To ensure the integrity and authenticity of the Interaction, a digital signature is applied. This signature, which is linked to the Entity's Origin Handle, verifies that the Interaction has not been altered and that it originates from the authenticated entity.

[127] Response Generation: After the Interaction has been processed and signed, the Workflow generates a response. This response could be a confirmation message, the result of a computation, or any other appropriate output.

[128] Workflow Documentation: Finally, every step of the workflow, from initial recognition of the entity to the generation of the response, is documented. This record serves as an audit trail and aids in creating further Workflows, allowing accountability, troubleshooting, auditing and analysis.

[129] This Workflow may ensure that Interactions from Entities, identified by their Origin Handles, are handled securely, efficiently, and transparently. The Workflow may provide a structured approach to managing Interactions via the associated assertions and Endorsements, ensuring that each one is authenticated, processed correctly, and properly documented. The Workflow can then be branched into sub-branches or paths for Alias Workflows.

[130] When interacting with a workflow or community on one or a set of interactions the Entity origin can choose to issue a contextually scoped key for that interaction. In this scenario, this key will only be accepted on signatures that relate to the context and scope whether it be a workflow or community, and if that key is used to sign any other endorsement on the platform outside of this scope it will be rejected. When issuing the key, the originating origin produces a "key proof' which signs a commitment hash on this key with a top level revision key. This proof is provided with the signatures on any endorsements made with the contextually scoped key so consumers can see this key was originally genuinely produced by the source entity. This can be useful for scenarios where deferred or delegated signing may be required in a potentially semi-trusted environment. If a bad actor were to intercept this signing process and steal this contextual key, then he has only compromised this process and not the origins themselves. This key can then be revoked and the process invalidated. Thus, as used herein, where a key is stated as being derived from or based on the Seed, this could also include a key as described above, which can be considered to be a ‘contextual key’. Thus, depending on the context, a key can be generated by an Entity and then signed with the commitment hash on this key. In case this key is compromised, this contextual key may be considered to provide a form of firewall that reduces the risk of the Origin being compromised.

[131] Due to the flexible nature of the hierarchical derivation paths along many different types of signature such as secp256kl or bls 12-381 signatures do not always have to be applied by trusted nodes as with the correct choice of type of signature. Then the process of signing an endorsement could be distributed between many nodes using MPC signing techniques (or another type of distributed signing) preventing any one terminal / operator having access to a root key. Combined with contextually scoped keys this may create an environment where signatures can be applied on the behalf of entities with little risk to their secret keys being exposed. Collaboration

[132] Each collaborator (Entity) may be assigned its own private key (e.g., derived from the Seed). The mechanism allows each user (Entity) to have their own key, and a customer may set their own rules about Interaction with a central repository.

[133] An Entity may be predefined either as a project (e.g., which may refer to a Smart Contract Physical Product; Virtual Product, etc.), or a collaborator (e.g., user).

[134] OS may revolve around signing metadata and commitments rather than explicitly signing files, NFTs, or other controlled data. This could be files or metadata for NFTs, fingerprinting for video or images or whatever commitment third parties or users are generating. These do not need to be stored by a service provider. It is possible to accept these metadata blobs to verification API’s. These could be stored in whatever manner these users or third party should so wish. It is possible to provide a facility to host these files, fingerprints, metadata, or other items the third party has chosen to endorse and sign, but this is not a requirement.

[135] Access to the project itself (rather than the end produced asset) to collaborate or endorse is an approval Workflow that can be considered to be similar to the Origin Endorsement process laid out above where a ‘join project proposal’ is put forth to a collaborator and when both parties sign then the user joins the project. Once joined, the collaborators can put forth ‘request for allocation’ proposals. For example, an Entity may want to sign five items, and once all collaborators have approved the allocation, then the project can use one signature each from each Origin Handle to prove and endorse those five items.

[136] The following process may be followed.

[137] Setup phase:

[138] Step 1 : Owner Name; Title / Description / Avatar Image; Public / Privacy = Tick / Untick Toggle.

[139] Select Asset Type: Contract; NFT; Semi-Fungible Token (SFT); Metadata; Asset (if selected has the option for multiple).

[140] As used herein, the term CTA' refers to ‘Create Project’.

[141] Step 2: NFT; Carry over info from above.

[142] Add Collaborators &Endorsement for each role in the project (for each collaborator).

[143] Add Assets either as 1 item (SFT / Metadata / Asset) or a list of items (NFT / Assets) dependent on the initial project setup.

[144] Each Asset has metadata associated (Traits and Properties).

[145] CTA = Sign and Mint (greyed out Call to Action - CTA until everyone has joined the project). Authentication

[146] There may be multiple methods for key or secret splitting in use (such as Shamir’s shared secrets for private key storage) but in the ‘wine’ example, the keys are a set of threshold keys. It is possible to have two methods for threshold keys within the platform used for threshold proofs e.g., Schnorr and Boneh-Lynn-Shacham (BLS). In the case of using both methods, it is possible to have a signature that is only verifiable if an Entity has access to both public keys (e.g., a 2-of-2 threshold). If one key is destroyed in the seal and unreadable then the signature can longer be verified. How Data may be Stored

[147] In some cases, the data is decentralized. If an Origin Handle agrees to join the Community as a member (Entity), the Entity needs to share certain proof with the Community owner. Certain aspects of the data may stay with the owners of that Community; however, this is expected to be clear to the Origin User joining. For example, such information may be displayed on the Community page by the owner prior to any Origin users (Entities) joining.

[148] In some cases, public data may be stored but unencrypted.

[149] In some cases, private data is not stored by a service provider. Such data may be encrypted in transit and at rest, and may only be available on request by the owner and verified partners (i.e., Entities associated with the Community associated with the owner) who the owner can nominate accordingly. Such a concept may be referred to as a 'Grant' with a key to decrypt the data.

[150] This data may be stored on various nodes and may only be accessible to be decrypted once a designated user has been given a Grant. It is unlikely to be possible for a normal user without the Grant to access or request the information. That is, if there is no key for another Entity, there can be no request by that other Entity to access the information.

[151] Users can combine one or more of the following concepts to secure the data: Access tokens; Decryption key; Zero-knowledge proof.

[152] With one or more of the above concepts, users (Entities) can then unlock and gain access to the private data.

[153] With regards to data such as Personally Identifiable Information (PII), Know Your Customer (KYC), Anti Money Laundering (AML), etc., a service provider may not be expected to store this type of data. It is possible to prove the data and public data that is distributed around nodes to be retrieved by authorized parties (Entities) via Grants.

[154] A requester may receive such information once the data is provided by the point of authority of that data (e.g., the Community). This approach is changeable dependent on the use case. An example scenario is given below.

[155] Step 1: A requester requests data.

[156] Step 2: An Origin Handle approves request based on the requester criteria.

[157] Step 3: The requester accesses data and pulls the information required at that point in time.

[158] Step 4: Complete Transaction. The data is then no longer shared, so that if access to the data is required again, the same process as indicated above needs to be repeated.

[159] As above, personal information may be a hashed proof, only accessible and decrypted by a Grant from a Community or designated Origin Handle.

[160] A Commitment may be made from hashes of unique identifiers. This Commitment may be associated to the Origin being endorsed, the endorser Origin, signature and key proof. This creates a commitment chain. A purpose of a commitment chain is to enable secure and trustless transactions (i.e., a type of Interaction) between participants in a decentralized network, without the need for every transaction to be recorded on the underlying blockchain. This then links out to the Origin role and assertion(s) information for the Endorsement to be kept on distributed nodes securely. Further Explanation of Assertions, Endorsements, and Revisions

[161] Fig. 4 is a schematic depicting a system 400 for implementing assertions and endorsements according to one or more embodiments described herein.

[162] An Assertion may comprise one or more statements, potentially including one or more data entities, indicative of certain information of interest. In an example, the Assertion comprises two data entities, each data entity being in the form of a triplet (e.g., an RDF triple). In this case, the data entity comprises a subject, predicate, and object. Other types of data entities could be used depending on the implementation. The data entity format may allow for semantic querying of the content of the data entity. As depicted, the content could be represented by a character string which be suitable for querying and may or may not be human readable, though will be machine readable. In an example, the subject can be represented by ‘@example’, the predicate can be represented by ‘workedwith’ or ‘managedby’, and the object can be represented ‘@participant 1’ or ‘@participant2’. These examples are not to be construed literally; instead, they represent functional content of the data entity that can be used for the purpose of an Assertion as described herein.

[163] In accordance with the system 400, an Assertion can be transformed into an Assertion Commitment, which is a deterministic projection of the Assertion(s) and statements (e.g., in the form of a hash).

[164] Such a hash can be endorsed by one or more participants (i.e., Entities) associated with a Community. A participant does not see or access the content of the data entity in the Assertion, unless that is needed in some implementations. An Endorsement can be considered to represent a proof that a participant signed / proved the Assertion Commitment (i.e., hash). It is noted that this system 400 does not necessarily require significant human input; rather the system 400 may ensure that any Assertion has the opportunity to be proven by participants associated with the Community (e.g., providing a participant is online, the system 400 can automatically collect their Endorsement, although in some cases the system 400 could require a participant to provide their input). In the depicted case, Endorsements 1 to 3 can be generated based on the hash of the Assertion Commitment, though any appropriate number of Endorsements may be generated. One or more Endorsements and the Assertion Commitment are combined to form a new ‘Integrity’ Hash which forms part of the integrity when combined with the previous integrity hash, indicative of the Assertion being endorsed by one or more participants. The Integrity Hash represents a proof of integrity of the Assertion because it has been signed by (i.e., Endorsed by) one or more participants associated with the Community. Thus, the Hash represents a form of signature that can be used to prove which participants endorsed the Assertion Commitment.

[165] A previous Integrity Hash may have been generated based on a previous Assertion (represented by the ‘Previous Revision Integrity’). This is referred to as a ‘previous Revision’ because it represents a state at a previous time. Again, the previous Revision represents a form of signature proving which participants Endorsed the previous Assertion Commitment.

[166] In this implementation, the new Integrity Hash is hashed together with the previous Integrity Hash.

[167] The new Integrity Hash can then by used for the purpose of self endorsement or in connection with one or more Community Endorsements for the purpose of signing / proving any new Revision Integrities.

[168] It will be apparent that above implementation generates a chain of hashes, and the link between the hashes will be cryptographically provable in manner analogous to blockchain (though it should be understood that the implementation of the system 400 may be on-chain or off-chain). Further Explanation of Entity Interactions Concept

[169] Certain techniques described herein and / or certain aspects or embodiments may provide or facilitate one or more of the following technical advantage(s) that relate to the “Entity Interactions” concept.

[170] The OS may enable one or more Entities (e.g., members of Communities) to interact (e.g., create, collaborate, and / or trade assets) with one or more other Entities risk-free or at least at reduced risk. OS involves the use of one or more stages, including a unique verification, enforcement and approval process. This reduces or eliminates all known risks and potential future risks, associated with collaboration, authentication, sharing and insuring assets. Accordingly, the OS may enable individuals (Entities) and associated Communities to become a point of authority and create decentralized social proof. Enabling individuals and Communities to collaborate provides Social Proof, allowing them the ability to become a point of authority within their Community. The more points of Social Proof based authorities creates, the more decentralized the solution becomes, reducing or removing the risks within Digital Realms.

[171] A discussion on the provable permissions concept, introduced previously, is now provided. As already noted, certain embodiments that relate to the “Entity Interactions” concept may be applicable to and / or represent embodiments of the provable permissions concept. PROVABLE PERMISSIONS Explanation of Permissions

[172] Fig. 5 is a schematic diagram of an example permission management system 500. Other arrangements are possible and there may be more or fewer nodes than those depicted. A block may refer to a computing node or it may refer to a data item, depending on the context. Further, the connections between those computing nodes may vary depending on the configuration. Thus, the depicted arrangement is a relatively simple arrangement intended to convey the basic functionality of a permission management system. It will be appreciated that different levels of complexity and infrastructure arrangements are possible within any permission management system.

[173] The permission management system 500 indicates how a user computing device 502 interacts with one or more APIs 504 that are used to facilitate user access to one or more resources 506 (e.g., computing resources for the provision of a service to the user). Each API interacts with one or more access control systems 508 to facilitate such user access. An admin computing device 510 provides permissions (e.g., for specifying user access to the one or more resources 506) to the one or more access control systems 508, which are then used by the one or more resources 506 to allow the user to access the resource 506. Such permissions are based on the permission level for the user specified by the admin. This permission level may depend on various factors such as the use case, the role of the user, what kind of permission to access the resource does the resource wish to grant to the user, etc.

[174] Examples of access control systems 508 may be based on services such as OpenFGA™, OPL (Ory), and Amazon Web Services™ (AWS™) Identity and Access Management (IAM). Other types of access control systems are available.

[175] In an example, a permission may take the form of a data structure that defines a user’s permission to access a resource in accordance with what the requested permission level. For example, in Relationship-Based Access Control (ReBAC), such a data structure may be considered to specify one or more relationships between a user and a resource in order to define how the user is permitted to interact with the resource. Such data structures may be distributed as needed in order to facilitate such access. Similarly, such permissions can be revoked, if needed. A version of ReBAC was introduced by Google™ in a system known as ‘Zanzibar’ which is described in Peng et al., “Zanzibar: Google’s Consistent, Global Authorization System”, Proc. Of 2019 USENIX Annual Technical Conference (USENIX ATC ’19) and available at https: / / research.google / pubs / zanzibar-googles-consistent-global-authorizationsystem / , the content of which is incorporated by reference in its entirety. Zanzibar / ReBAC is also compatible with other access control schemes such as Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), and Policy-Based Access Control (PBAC).

[176] In Zanzibar and other access control schemes, relation tuples are examples of data structures that allow admin to facilitate and manage access control between users and resources. A relation tuple may define an object-user relationship using one or more indicators (e.g., byte indicators) such as an identity of a digital object (e.g., a resource), an identity of a user (e.g., within a set of users), and a relation (e.g., the status of the user that can be indicative of the permission level associated with the user). ReBAC schemes may allow one or more users to be added, removed or otherwise edited in any appropriate way with respect to a set of users associated with the digital object. When changes need to be made, the relation tuples can be edited and deployed readily to facilitate rapid access to resources at large scale (e.g., where there are large numbers of users with multiple possible ways to access multiple resources).

[177] The admin may define the permission initially. The admin needs to be a trusted entity since they have a lot of control over access to the resource by virtue of their ability to provide and edit permissions. Similarly, where a permission is accessible to any other entity such as if the permission is distributed to the resource or elsewhere in a network, such an entity may also have a lot of control over access to the resource.

[178] A malicious entity such as a hacker (such as an external hacker or an internal hacker authorized to access the permissions) could attempt to produce, revoke or edit such permissions, thereby facilitating unauthorized access to a resource or otherwise restricting access to the resource by authorized users. Similarly, an authorized admin could unintentionally or incorrectly produce, revoke or edit such permissions. Such changes would be very difficult to detect because the permissions themselves are inherently trusted.

[179] As such, there are one or more issues with permission schemes such as based on ReBAC. There may also be issues with permissions schemes based on different types of access control schemes.

[180] One or more techniques described herein may address one or more of these issues to improve the cyber security posture associated with permissions used in association with one or more access control schemes. Further Comments on Permissions

[181] As noted below, there is an inherent insecurity of permissions systems backed by simple rows within a database.

[182] Relying on a central database containing all the access control and grants, and relying on the security of the infrastructure rather than the security of the data itself is fundamentally flawed if the security boundaries are breached somehow. Any breach, whether by hacker or nefarious employee is free to manipulate such access control and grants as they should wish, directly at the database level, with no ramifications and to devastating effect. For cloud providers this could mean customer systems being manipulated without any way for them to stop it or even know relying on trust the cloud provider will not allow a breach of any kind.

[183] This can be broken down into these critical points:

[184] Manipulation Risk: Traditional systems rely on centralized databases, which are vulnerable to an unauthorized or nefarious party accessing and manipulating permissions at the source as there is no penalty or check for changing the data directly in the table where the permissions are stored. This can lead to altered or falsified permissions once the security around the database has been breached.

[185] Single Point of Failure: Centralized providers represent a single point of failure, making them susceptible to downtime, attacks, and breaches. By inherently having data that requires how it is kept securing it rather than proving its own integrity mandates a centralized “walled garden” to protect it. It also requires the provider’s API to be constantly available to provide permissions and verification at all times as the consumer has to take the provider’s guarantee about the access control grants and rules.

[186] Lack of Comprehensive Trust and Transparency: At any point it is not possible to interrogate if a permission has been manipulated and if so by what manner. It is possible to check logs provided by the APIs or user interfaces (Uis) of said provider but if a set of permissions was manipulated via a side-door or side-channel, then the validity of such data is unproven, and often this manipulation is only detected after the damage has been done.

[187] Existing technologies have limitations and are described below.

[188] Centralized Databases: Examples include: Traditional relational databases (eg., MySQL, PostgreSQL). Limitations include: Vulnerable to manipulation, downtime, and breaches; lack of transparency and contextual trust.

[189] Blockchain-Based Systems: Examples include: Decentralized ledgers like Ethereum, Hyperledger, etc. Limitations include: Often complex and resource-intensive; while they provide immutability, they may still struggle with scalability and privacy concerns.

[190] Verifiable Credential Frameworks: Examples include: Solutions based on technologies like World Wide Web Consortium™ (W3C™) Verifiable Credentials. Limitations include: Only designed really for proving of qualities of the entity asking for authorization but not about proving the authorization rules, who set them, when and why. The scope of verifiable credentials does not extend into the credentials of the target platform. Such that in themselves they may provide visibility, and partial validation but lack comprehensive contextual information needed to fully establish trust and fail to establish a full chain of trust within themselves for not just the user but the system which executes on the users’ permissions, of which if the permissions were manipulated upstream the system acts blindly to this fact. As such they can only provide claims about an individual, but the rules under which these are to be interpreted and executed are themselves unverifiable, cannot be reasoned against or rationalized, are not transparent or distributable.

[191] Thus, all current systems rely heavily on centralized databases, which are inherently insecure due to their susceptibility to unauthorized access and manipulation. These databases allow for rows of data to be accessed, edited, or amended, thereby compromising the integrity and truthfulness of the information stored.

[192] Furthermore, existing solutions like verifiable credentials offer visibility but fall short of providing true trust by themselves. They do not adequately address critical questions such as who performed an action, why it was performed, when it occurred, what specific data was involved, and how the action was executed and under what assumptions and auspices this credential is being issued. There is also no association between a set of verifiable credentials and the permission rules of a platform and no proof of what having a particular claim should allow one to do with said credentials, and if a permission rule was created, who created and granted this rule. Once a hacker has a valid set of credentials for access, regardless of the claims provided by a third party (or even without a valid set if they directly compromise the servers), they can change the rules of a platform by changing the permission sets within the target platform (for example granting compromised credentials effective admin access by rewiring the permissions ignoring the claims provided by the third party). As these rules are not checked for authenticity at any point, and systems tend to issue internal tokens and claim sets for communication between internal services rather than sending the actual verifiable credentials around with every request, verifiable credentials effectively provide authentication as the authorization (claims and roles) and the rights afforded by those claims is not enforceable, verifiable or provable by the system they are presented to. Implementations of Provable Permissions

[193] Fig. 6 is a schematic diagram of a permission management system 600 according to one or more techniques provided by this disclosure. Other arrangements are possible and there may be more or fewer nodes than those depicted. A block may refer to a computing node or it may refer to a data item, depending on the context. Further, the connections between those computing nodes may vary depending on the configuration. Thus, the depicted arrangement is a relatively simple arrangement intended to convey the basic functionality of a permission management system. It will be appreciated that different levels of complexity and infrastructure arrangements are possible within any permission management system.

[194] The permission management system 600 of Fig. 6 is similar to the permission management system 500 of Fig. 5 with certain differences described below. Reference numerals for like or similar features are incremented by 100. An admin computing device 610 is still able to manage permissions via one or more access control schemes 608. However, in contrast to the previous example, a translation layer 612 is included in the permission management system 500. In basic terms, the translation layer 612 modifies a permission produced in accordance with the access control system 608 to form an Assertion 614. Each permission (e.g., for each user) is translated by the translation layer 612 to form an Assertion 614. Thus, there may be multiple Assertions 614, each one representing the permission level associated with a particular user for a particular purpose.

[195] An Assertion 614 represents a cryptographically provable permission indicative of one or both the provenance and the integrity (also referred to herein as provenance ‘and / or’ integrity) of the underlying data (i.e., the permission data). In the case that the permission comprises a tuple, the translation layer 612 defines how to convert an existing tuple into an Assertion 614.

[196] In some cases, to produce an Assertion 614, an admin may use the translation layer 612 (which can be implemented in any appropriate way e.g., via an API or otherwise implemented by the admin computing device 610 itself) to produce the Assertion. To produce the Assertion, the permission (e.g., tuple) is mapped in such a way that one or more data elements of the permission can form the Assertion 614. An example of such a mapping is given below.

[197] The translation layer 612 may provide a cryptographic function to append additional data such as a digital signature (e.g., in the form of a digest or any other appropriate data) associated with the admin to the permission. Thus, the additional data (e.g., digital signature) can be used (in a verification stage, described below) to prove that the admin produced the permission.

[198] Although the terminology refers to an Assertion (as described in the section on Entity Interactions), it shall be appreciated that this does not limit the permission scheme functionality based on the Entity Interactions system described previously. In some cases, a digital signature (that is not based upon the Entity Interactions system) applied to the permission may be used to indicate the provenance and / or integrity of the permission. In some cases, a digital signature (that is based on an Interaction key derived under the Entity Interactions system) applied to the permission may be used to indicate the provenance and / or integrity of the permission.

[199] An Assertion 614 thus represents a permission but includes additional data that can be used to indicate the provenance and / or integrity of the permission. An Assertion 614 can then be used to facilitate access to a Resource 606. An Assertion 614 has additional functionality and is also backwards compatible with existing permission management systems such as represented by Fig. 5. The backwards compatibility is facilitated since the permission itself complies with the rules specified by the access control system 608. However, in view of the security concerns that arise from the use of permissions, only trusted entities (e.g., admin) can have access to the permissions to reduce security risks. Therefore, certain procedures may be put in place to manage the handling of the permissions. This limits the use cases of permissions.

[200] The nature of the Assertion 614 is such that it is possible to use permissions in more scenarios, including where non-trusted entities could attempt to access a particular Resource 606. As depicted in Fig. 6, a user computing device 602 can directly or indirectly access one or more Resources 606 (see block 618). The Assertion 614 facilitates access to the Resource 606 in the same way that a permission already facilitates access. The direct or indirect access depends on the configuration. In some cases, the configuration may be such that the access control system 608 (e.g., via an API) is needed to facilitate access to the Resource 606. In some cases, the configuration may be such that the access control system 608 is not needed at all times such as in an offline scenario described below. In either case, the Assertion 614 can be used to emulate a public key infrastructure (PKI) system 620 that involves issuing certificates (or another type of cryptographic infrastructure) to facilitate verification of the Assertion 614 at block 622. Verification of permissions is described in more detail below.

[201] Permissions are typically used in online scenarios where devices are connected to each other via a network connection. If there is a problem with the access control system 608 and / or the API, or if the permission is otherwise inaccessible, a Resource 606 cannot allow user access. This means that when the internet is down (such as if there is a cyber incident or if a software update goes awry), it may not be possible to gain access to a Resource 606.

[202] Since the Assertion 614 has a higher level of integrity (in view of the additional data appended to the permission) than an existing permission, there may be circumstances where the Assertion 614 can be deployed in an offline scenario. For example, a Resource 606 can hold the Assertion 614 and use local offline verification (using locally stored certificates associated with the Assertion 614) to check whether a user can access the Resource 606. Various rules can be put in place to control the access such as a period of time that the certificate is valid, etc. Certificates can be revoked and this may not be apparent until connection is made to the access control system 608. Similarly, even when the configuration is such that there needs to be an always-on online connection to facilitate access to a Resource 606, the additional verification functionality provided by the Assertion 614 via the public key infrastructure 620.

[203] A higher degree of trust can be instilled by using endorsements (as described previously). One or more Endorser computing devices 616 may endorse the Assertion 614. Each additional Endorser increases the degree of trust. This approach of endorsing permissions by a plurality of Entities (including the producer of the Assertion 614 and one or more Endorsers) represents a form of social proof that can increase trust in the Assertion 614. In this way, each involved Entity can check that the permission is correct and / or corresponds to their expectation. If a potential Endorser does not approve of an Assertion 614 and if a verification stage detects that the Assertion 614 does not meet a condition, then the verification stage can make it impossible for the Assertion 614 to be used to facilitate access to a Resource 606

[204] Rules can be put in place to specify one or more conditions that need to be satisfied for the verification stage in order to access a Resource 606. For example, an Assertion 614 may need to have been endorsed by a threshold number of Endorsers and one or more of the Entities involved in the production of an endorsed Assertion 614 may need to be authorized at a specified level. There is a high degree of flexibility and so the verification stage can implement any rules that are considered appropriate for the scenario.

[205] As such, an Assertion 614 represents a provable permission to indicate the provenance and / or integrity of the permission. The provenance may refer to who produced the permission (i.e., the origin of the permission, which can include the identity of the producer of the permission and data such as the time of production) and who else was involved in the endorsement (if endorsement is needed). The integrity may refer to whether the permission has been maintained in its original form since production of the permission i.e., the permission has not been modified by any unauthorized entity since its production. Based on one or more certificates (e.g., Secure Sockets Layer (SSL) certificates) issued in connection with the one or more Entities involved in the production of the Assertion 614, it is possible to verify the provenance and / or integrity and approve or deny access to a Resource 606 depending on whether or not the conditions have been satisfied. In other words, a level of auditability is possible since the Assertion 614 includes data that is cryptographically verifiable. Thus, various techniques described herein can be referred to as “provable permissions”, which may be considered to provide highly secure and verifiable access control backed by cryptographically provable and un-manipulatable signatures.

[206] In other similar words, various techniques described herein address one or more challenges by embedding data into the permission set and syncing it locally, thereby enabling robust access control without necessarily relying on a centralized database and the security surrounding the database. This approach may provide enhanced security, transparency, and trust in the data itself by proving provenance and / or integrity. In some cases, this approach involves providing digital signatures in the form of endorsements and creating a means to verify and log permissions in a distributed manner, thereby mitigating the risk of data manipulation and providing a comprehensive view of all access-related activities.

[207] It shall be appreciated that a permission scheme as referred to herein is distinct from a verification scheme based on user credentials since the permission scheme is intended to be defined by an entity other than the user such as an admin, whereas user credentials are defined by the end user. It could also be said that permissions are concerned with defining a level of access for one or more users to access resources, whereas user credentials are concerned with a secure way to allow a certain user to access a resource. In some cases, a permission scheme may be considered to be a server side solution (e.g., focused on being implemented at one or more computing nodes associated with one or more service providers), whereas user credentials may be considered to be a client side solution (e.g., focused on being implemented at a client device such as a user equipment). Additional Functionalities of Provable Permissions

[208] The following discussion refers to some additional functionalities of provable permissions according to one or more embodiments.

[209] Provable permissions as introduced herein may be considered to represent a breakthrough in secure access management through its innovative and flexible permissioning system (which can be used in an offline scenario, as well as in an online scenario). Unlike traditional verifiable credentials that prioritize visibility over true trust, techniques described herein may ensure genuine authorization by integrating advanced digital signatures and multi entity endorsements for not just claims and roles but also extending all the way to permission sets and rules.

[210] Provable permissions may include one or more of the following features and functionality in one or more embodiments.

[211] Secure Access Requests: Entities may transmit digitally signed messages to request access to services or resources, which are verified using public keys that confirm multi-entity endorsements.

[212] Robust Verification: The authorizing entity may verify these requests against endorsed public keys, ensuring that only genuinely authorized entities gain access.

[213] Transparent Access Rights: Clear indications of access rights may be transmitted back to the requesting entity, allowing secure and authenticated service access based on verified permissions.

[214] Full Chain of trust: As a full chain of trust can be provided for the entirety of a set of permissions / credentials with more advanced proofs, there is less (or no) need for a verifying party if the target platform is able to trust the issuers credentials.

[215] Provable Access Rules: Ability to prove how one’s access rights will be honored within a platform or ecosystem and who endorsed this access rule and why, when, what, where and how.

[216] There may be one or more technical benefits associated with one or more techniques described herein, as discussed below.

[217] True (or improved) Trust: Unlike verifiable credentials, which merely provide limited visibility and verifiability, techniques described herein may establish genuine trust through rigorous verification processes and a transparent web of trust, extending not just to the claimed credentials of the accessing party but also to the rules of engagement and usage of the processing party. By offering a direct translation layer between the implementation of provable assertions and common permissioning systems based on Relationship Based Access Control (ReBAC), the disclosed techniques may allow for tangible and easy way for developers embed provable permissions into their own implementations.

[218] Comprehensive Detail: The disclosed techniques may ensure transparency around who is accessing what service, why they need it, when the request was made, what resource is being accessed, and how the process is managed.

[219] Thus, the disclosed permissioning system may represent a significant advancement in secure access technology, offering unparalleled trust and security in digital interactions.

[220] In some cases, the permissions system may facilitate revoking access (e.g., in an offline context). However, it will be appreciated that the permissioning system can also operate in an online context.

[221] When a device's access needs to be revoked, the process may work as described in the following embodiment:

[222] When the permissioning system is online:

[223] A certificate list may be available. That is, when online, the system maintains a list of certificates.

[224] A revocation check may be performed. The system may first check a revocation list for any revocations applicable to the user (e g., Person A).

[225] If there are revocations, they may be synced and implemented immediately.

[226] New certificate issuance: As part of a syncing process, the new certificate may be issued and checked against the revocation list.

[227] Offline Access is now described.

[228] Upon a user attempting access, the system may: check the presented password and certificates, confirm whether Person A is associated with revoked access, and deny Person A or any password issued from Person A to Person B / C / D etc. access if the revocation is verified.

[229] Thus, revocations may first be checked and synced when the device is online, ensuring that any access changes are immediately reflected and enforced even when offline.

[230] It shall be appreciated that techniques that relate to Entity Interactions may be combined with or otherwise used in conjunction with Provable Permissions (for example, Endorsements may be used as part of a social proof mechanism). However, it shall be appreciated that Provable Permissions techniques do not rely on Entity Interactions techniques and Provable Permissions techniques can be implemented independently of Entity Interactions techniques. Mapping Permissions to Assertions

[231] Fig. 7 depicts a representation of example data structures 700, 702 based on ReBAC such as may be used by the example permission management system 500 of Fig. 5. The data structure 700 is a table representative of a tuple that includes indications of certain information as included in the table. The tuple is a form of permission that defines user access. In other words, the tuple defines the rules that specify what level of access a user has to a resource. The data structure 702 is a table representative of an authorization model that includes indications of certain information as included in the table. The type_definition is also effectively a tuple for each type, and can include a schema inside of it similar to the tuple data structure. Each field of each table can be in the form of a JSON field. It is the combination of the tuple 700 and authorization model 702 that defines what a user can and cannot do with respect to a resource. The data structures 700, 702 represent an example of how a scheme such as OpenFGA store permissions in their database. The combination of the data structures 700, 702 is interpreted based on a rule engine to specify the permissions. This is analogous to set intersection where, for example, certain users within one set have certain levels of permission and other users within another set have different levels of permission. However, all users can access the relevant resource, but with their individual permission level being indicated by their tuple 700, in the context of the authorization model 702.

[232] As indicated already, there is a risk that such data structures can be modified and create a scenario where unauthorized entities can access a resource. This is because neither data structure has any integrity protections or proofs. An attacker could insert a new row, change a user id (u|id), etc., and this would not be readily detected. As such, there is no auditability of the permissions such as represented by the combination of the tuple 700 and the authorization model 702. Provable permissions as described herein may reduce the risk of the data structures being compromised, or at least provide a mechanism to allow a verifier to determine whether or not the data structures have been compromised.

[233] Fig. 8 depicts a representation of example data structures 800, 802 according to one or more techniques provided by this disclosure. The data structures 800, 802 respectively correspond to the tuple 700 and authorization model 702 depicted by Fig. 7. In this case, the tuple 800 is modified by adding a digital signature into the data structure itself. Thus, in some cases, a commitment (e.g., hash) can be created from one or more properties (e.g., data from a table field) of the data structure. Thus, as long as properties of the data structure remain unchanged, this can be proven based on the commitment hash. If any of the properties are changed, then a verifier would find that a hash generated from these properties would not match the commitment hash. Thus, the commitment hash represents a form of integrity and / or provenance to allow a verifier to determine whether or not the data structures have been compromised. As part of the schema, digital signatures may also be embedded into each user set role within the scheme.

[234] In some embodiments, a data structure such as one or both of the tuple 700 and authorization model 702 depicted by Fig. 7 may be modified by using the translation layer 612 to create an Assertion 614, which may also be endorsed by one or more Endorsers to further protect the integrity of the Assertion 614. This approach may provide more information (as compared to the approach based on the data structures 800, 802) about the provenance and / or integrity of the permission (e.g., by allowing a verifier to determine which Entities were involved in the production and distribution of the permission in the case of the provenance, and / or allowing the verifier to determine whether or not permission has been modified in the case of the integrity). This approach is described in more detail below.

[235] Fig. 9 is a schematic diagram of an approach for producing an Assertion 914 based on a tuple 900 according to one or more techniques provided by this disclosure. Reference is made to the previous figures and associated description in the following. The tuple 900 has the same structure as the tuple 700. However, when producing the Assertion 914, certain fields of the table are mapped to the Assertion 914. In this case, the subject (handle) of the Assertion 914 is mapped to the fields “object” and “objectjd”, the predicate of the Assertion 914 is mapped to the field “relation”, and the object (handle) of the Assertion is mapped to the fields “user” and “usertype”. The subject-predicate-object mapping forms the basis of the Assertion 914.

[236] In some cases that relate to Entity Interactions, a Community (handle) is mapped to the field “store”. Other variations and mappings are possible. Thus, the Assertion 914 represents part of the tuple 900. In some cases, a link is made between a Community (comprising one or more Endorsers 916a) and the tuple 900. The one or more Endorsers 916a use their respective computing devices to sign the Assertion 914 with their key (derived from an Interaction key associated with the Community). In some cases, an Endorser 916a can edit the permission, and then this edited version of the permission can be endorsed by one or more other Endorsers 916a. Thus, the Endorsement 916b represents a provable permission. The digital signatures generated by the involved Entities allow the provenance and / or integrity of the Assertion 914 to be checked and verified in accordance with the configuration of the setup.

[237] As depicted, the Endorsement 916b can be used in various ways. In some cases, the Endorsement 916b is kept by the user or a third party. In some cases, the Endorsement 916b is stored on a public event chain or a blockchain. In some cases, the Endorsement 916b is kept by the provider and stored in their database (e.g., by the access control system itself). Thus, in some cases, permissions do not necessarily need to be held by the provider. These permissions can be distributed and used in accordance with the configuration of the setup.

[238] In some cases, a completely blind system can be created where it is unknown what permissions a user has until they turn up and present their endorsements as the rules. It is then possible for the system to work out what that user can or cannot do with respect to the resource they are trying to access. In a scenario where a high degree of confidentiality or secrecy is needed, access to a document may be provided without any other entity knowing that a particular user has access to the document.

[239] In some cases, a similar mapping could be made for verifiable credentials and / or a blockchain. Verifiable credentials are designed to be kept by the user (i.e., for the purpose of Self-Sovereign Identity (SSI)) and only support one “issuer” instead of multiple endorsers.

[240] As such, it is very difficult to manipulate the permissions since they feature protections (i.e., proof data) that allow verification of the provenance and / or integrity of the permission so that it is known who produced and edited the permission and / or whether or not the permission has been modified.

[241] Whilst it is feasible to apply a procedure that looks at what happened to a permission, by using the Assertion 914 based approach, it is known who produced the permission in the first place. That is, the Assertion 914 itself represents the origin of the permission, and that fact is cryptographically provable. Any editing of the permission by any other Entity can be made providing that Entity is authorized to do so. They can then endorse the edited Assertion 914. Rules can be specified to determine which and how many Entities should be involved in the production and / or editing of a permission. If the Assertion 914 does not include the cryptographic data proving that the rules have been followed, a verifier can stop a user from accessing a resource based on the Assertion 914. Prior techniques do not have these capabilities.

[242] As such, the permissioning system according to certain techniques described herein is more robust, secure and / or private than existing permissioning systems. Further functionality is also enabled by certain techniques described herein such as offline permissioning.

[243] Fig. 10 is a sequence diagram 1000 depicting a flow of data between various entities in a permission system according to one or more techniques provided by this disclosure. The depicted sequence is exemplary and refers to multiple embodiments. Various Entities (referred to as nodes) are depicted in the sequence diagram 1000. Not all of these Entities may be needed and / or one or more of the Entities may be combined in terms of their functionality, if appropriate. Each Entity is given a name, but this name is non-limiting in terms of the functionality since the name is intended to help distinguish between the different Entities. Each Entity can be instead referred to as a first, second, third, and so on, Entity.

[244] Node I is a node (referred to herein as an Asserting Entity) in which permission data (e.g., a tuple) is created, edited or otherwise ‘produced’ by an Entity (e.g., an IT admin) in a such a way to protect the integrity of the permission data for accessing a Resource (e.g., data / database, any computing device such as implemented in a drone, a service, an AI, etc.). A Resource (as discussed in more detail below) is anything computer implemented and a user (such as at the Client Entity) wishes to access processing resources and / or memory resources.

[245] In some cases, an Assertion (e.g., see the digital signature of Fig. 8) can be a signature created by the Entity based on the properties of the permission data itself.

[246] In some cases, an Assertion (e.g., see Fig. 9) is based on a mapping of a tuple to an Assertion. In some cases, such an Assertion can be endorsed by one or more Endorsing Entities (e.g., of a Community specified by the Entity Interactions system).

[247] Node II is a node (referred to herein as an Endorsing Entity) where an Entity (e.g., an existing IT admin) in a Community endorses the produced permission data.

[248] Node III is a node (referred to herein as a Requesting Entity) where an Entity (any interested node) requests another Entity (a handling / verifying node) to verify the integrity of the permission data (and then receives a response to that request).

[249] Node IV is a node (referred to herein as a Verifying Entity) that receives such a request to verify the integrity and then issues a response based on the verification (which could be performed by the device itself, or yet another node). This node can revoke access to a Resource.

[250] Node Visa node (referred to herein as an access control node e.g., corresponding to an access control system such as depicted in Fig. 6) in a network that receives permission data whose integrity and / or provenance is verifiable. The verifiable permission data is accessible (locally or remotely) to that node and the node processes any requests that seek access to a Resource depending on the permission. In some cases, the node can then provide access to the Resource by granting access to an external Resource (e.g., with an access token). In some cases, the node can then provide access to the Resource by granting access to itself (e.g., where the access control node itself provides the ‘Resource’). This is relevant to the drone use case described below.

[251] Node VI is a node (referred to herein as a Client Entity (e.g., a service user)) that makes a request to access a Resource. In the depicted Options Al / Bl (i.e., the signature-based approach), a node that controls or represents a Resource that receives control instructions from an Entity (such as a service user) seeks verification and then the node processes those instructions depending on the Entity’s (verifiable) permission level.

[252] Under the depicted Options A2 / B2 (i.e., the self-verification approach), Node VII is a node (referred to herein as a Controlling Entity or Resource, depending on context) that controls or represents a Resource is interacted with by a user who provides control instructions (indicative of the user’s origin) that are processed by the Resource depending on the permission data saved at the Resource. This is particularly relevant to the drone use case.

[253] Reference is now made to the functionality of each of the nodes in the following flowcharts. An Entity / node is a computing device implemented by the specified Entity. Continued reference may be made to Fig. 10 in the following discussion.

[254] Fig. 11 is a flowchart of a method 1100 according to a technique of this disclosure. In an example, the method 1100 is implemented by Node I in Fig. 10 (see block 1004). Reference should be made to the previous discussion, embodiments and techniques associated with the nodes in Fig. 10.

[255] The method 1100 is a computer-implemented method performed by an Asserting Entity (e.g., an admin as described in Figs. 6 or 8, or any other appropriate user). The method 1100 comprises, at block 1102, producing permission data for controlling access by a Client Entity to a Resource based on an access right associated with the Client Entity. The permission data comprises proof data indicative of one or both of a provenance and an integrity of the permission data.

[256] Permission data can refer to a permission such as a tuple or any other data structure for use in permissioning, as already described. The permission data is for use in controlling access by a Client Entity to a Resource in accordance with what is indicated by the permission data (e.g., see the discussion in relation to Figs. 7-8). Thus, the level of access for a user is indicated by the permission data.

[257] The proof data can be anything to indicate what happened to the permission data, and when. Further details are provided in the following discussion. Generating the proof data may be part of producing the permission data. For example, the Assertion 914 may include proof data such as a digital signature. The proof data may be produced at the same time or in conjunction with production of the permission data itself.

[258] The production of the permission data may be based on a translation of an access right (e.g., see the translation layer 612 of Fig. 6 and block 1006 of Fig. 10) associated with a Client Entity to produce an Assertion (an example of permission data). The proof data included with the Assertion and (in some cases) one or more Endorsements is indicative of one or both of the provenance and the integrity of the permission data.

[259] As depicted by Fig. 10, the Asserting Entity may be informed (at block 1002) about the Client Entity’s access right by the Client Entity. This informing may include a request by the Client Entity for a certain level of access to be granted. Other / dififerent nodes may be involved as part of producing the permission data based on one of these nodes requesting that the Client Entity be issued permission data so that the Client Entity can access the Resource.

[260] Some embodiments relating to the method 1100 are now described. One or more of these embodiments may be combined with each other or otherwise modified by each other or based on any other embodiments and techniques described herein. Some of these embodiments are applicable to other methods and techniques described herein.

[261] In some embodiments, the permission data is configured to facilitate Relationship Based Access Control (ReBAC).

[262] In some embodiments, the provenance of the permission data is indicative of one or more of: an origin of the permission data; a reason for producing the permission data; evidence to support the access right; a record of an Interaction with the permission data after production of the permission data.

[263] In some cases, the Asserting Entity may be associated with the origin of the permission data because the Asserting Entity is the entity that produced the permission data at the particular time. The origin of the permission data may indicate an identity of the Asserting Entity, a time of production of the permission data, a location where the permission data was produced, etc. Any of this information could be represented in any appropriate way such as using natural language or via an indicator such as a number or character that can be looked up e.g., in the form of metadata appended to the permission data.

[264] In some cases, the record of the Interaction (which can refer to more than one Interaction) with the permission data can include one or more of: a record of where the permission data has been located after being produced; a record of an identity of any computing node that one or more of: stored and processed the permission data; a record of any modifications to the permission data; and a timestamp associated with each Interaction with the permission data.

[265] In some embodiments, the proof data comprises a digital signature.

[266] In some cases, A digital signature could be a hash such as a Commitment hash. In other words, the digital signature is representative of a Commitment based on an Assertion (covered below).

[267] In some embodiments, the method 1100 further comprises generating the digital signature using a key indicative of an origin of the Asserting Entity.

[268] In this context, the origin of the Asserting Entity means that the key (e.g., private key) can be used so that, when needed, the provenance and / or integrity of the digital signature can be checked by a verifier (e.g., using the associated public key accessed from a certificate authority or using some other appropriate mechanism).

[269] In some embodiments, the key comprises an Interaction Key associated with a Community. This is in the context of Entity Interactions.

[270] In some embodiments, the produced permission data represents a cryptographically provable Assertion made by the Asserting Entity that the permission data was produced by the Asserting Entity.

[271] In some embodiments, the permission data is based on a data access structure indicative of the access right.

[272] In some cases, a data access structure may comprise a tuple or other appropriate data structure. A data access structure such as a tuple defines a relation between the Client Entity and at least one other Entity to facilitate access to the Resource.

[273] In some embodiments, the permission data is indicative of a mapping between the data access structure and the proof data.

[274] In some embodiments, the permission data represents an Assertion made by the Asserting Entity. The Assertion may be translated from the data access structure based on at least part of the proof data.

[275] In some cases, an Assertion may be made by more than one Asserting Entity (or indeed any other type of Entity).

[276] In some embodiments, the proof data is based on at least part of content of the data access structure. This functionality refers to the technique such as depicted by Fig. 8.

[277] In some embodiments, a plurality of computing nodes are used to produce the permission data.

[278] In some cases, the plurality of computing nodes may be involved in producing the permission data in response to a requirement that the more than one computing node needs to make the Assertion. This may improve the trustability of the permission data. The term “computing node” is intended to be non-limiting and can include the Asserting Entity and any other type of Entity.

[279] In some embodiments, the data further comprises a digital signature applied to the permission data by an Endorsing Entity.

[280] In some embodiments, the Endorsing Entity is associated with a Community. The digital signature applied by the Endorsing Entity is based on a key associated with the Community. In some cases, the digital signature represents an “Endorsement” made by the Endorsing Entity.

[281] In some embodiments, the method 1100 further comprises: receiving an indication of the access right associated with the Client Entity; and producing the permission data based on the indication. The indication may be received from the Client Entity (as depicted by Fig., 10) or from any other appropriate entity. In some cases, the indication can be an instruction to do something to a data access structure such as editing the data access structure.

[282] In some embodiments, the method 1100 further comprises producing the permission data based on the indication comprises mapping the indication to an Assertion made by the Asserting Entity that represents the proof data. Such a mapping may be performed by the translation layer 612.

[283] In some embodiments, the Resource comprises one of more of: a memory resource; a processing resource; a computing device; hardware; firmware; software; an artificial intelligence (AI) model; an AI agent; and a drone. The memory resource may store information of interest. The processing resource may enable a client to run some software. Many other functions are possible.

[284] Fig. 12 is a flowchart of a method 1200 according to a technique of this disclosure. In an example, the method 1200 is implemented by Node II in Fig. 10. Reference should be made to the previous discussion, embodiments and techniques associated with the nodes in Fig. 10.

[285] The method 1200 is a computer-implemented method performed by an Endorsing Entity. The method 1200 comprises, at block 1202, endorsing permission data for controlling access by a Client Entity to a Resource based on an access right associated with the Client Entity. The permission data comprises proof data indicative of one or both of a provenance and an integrity of the permission data.

[286] As depicted by block 1008 of Fig. 10, method 1200 is relevant to Option A2, which involves endorsing permission data received from the Asserting Entity. Optionally, the endorsed permission data can be sent to one or more Endorsing Entities (not depicted by Fig. 10) for consecutive endorsement by each of the one or more Endorsing Entities. The Endorsed Assertion can then be send to the Verifying Entity or the Controlling Entity / Resource. However, this is exemplary and other nodes may be sent such data.

[287] Some embodiments relating to the method 1200 are now described. One or more of these embodiments may be combined with each other or otherwise modified by each other or based on any other embodiments and techniques described herein. Some of these embodiments are applicable to other methods and techniques described herein.

[288] In some embodiments, endorsing the permission data comprises applying a digital signature to the permission data.

[289] In some embodiments, the Endorsing Entity is associated with a Community. The digital signature applied by the Endorsing Entity may be based on a key associated with the Community.

[290] In some embodiments, the endorsed permission data represents a cryptographically provable endorsement of an Assertion made by an Asserting Entity that the permission data was produced by the Asserting Entity and endorsed by the Endorsing Entity.

[291] In some embodiments, the method 1200 further comprises: receiving the permission data from an Asserting Entity that produced the permission data comprising the proof data; and endorsing the permission data by generating additional proof data for the permission data that is further indicative of one or both of the provenance and the integrity of the permission data. In some cases, this includes that there may be multiple Endorsing Entities.

[292] In some embodiments, the additional proof data is generated using a key indicative of the origin of the Endorsing Entity.

[293] In some embodiments, the method 1200 further comprises transmitting the endorsed permission data.

[294] In some cases, the transmitted endorsed permission data may be used by any entity that might need it, for example, another Endorsing Entity (for that Endorsing Entity to endorse the endorsed permission data), a Verifying Entity, an Access Control Entity, a Controlling Entity, Resource, etc., depending on the configuration of the system.

[295] Fig. 13 is a flowchart of a method 1300 according to a technique of this disclosure. In an example, the method 1300 is implemented by Node III in Fig. 10. Reference should be made to the previous discussion, embodiments and techniques associated with the nodes in Fig. 10.

[296] The method 1300 is a computer-implemented method performed by a Requesting Entity. The method 1300 comprises, at block 1302, sending a request to a Verifying Entity to verify one or both of a provenance and an integrity of permission data for controlling access to a Resource. See blocks 1010 and 1012 of Fig. 10. The permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data.

[297] The method 1300 further comprises, at block 1304, receiving, from the Verifying Entity, an indication of whether the proof data proves one or both of the provenance and the integrity of the permission data. See block 1014 of Fig. 10.

[298] Some embodiments relating to the method 1300 are now described. One or more of these embodiments may be combined with each other or otherwise modified by each other or based on any other embodiments and techniques described herein. Some of these embodiments are applicable to other methods and techniques described herein.

[299] In some embodiments, the proof data comprises a digital signature, and wherein verification of one or both of the provenance and the integrity of the permission data is based on a signature check.

[300] In some cases, a signature check can include checking that the digital signature matches an expectation based on a certificate from a trusted Entity such as a certificate authority. The expectation may be based on an Asserting Entity’s public key being used to confirm that the Asserting Entity’s associated private key was indeed used to generate the signature (as per any appropriate signature verification system). Similarly, the expectation may be based on any other Entity that is involved such as an Endorsing Entity that endorsed the permission data with their own digital signature. A signature check can also include a check that the certificate issued in connection with the Asserting Entity’s data is still valid and up to date and / or whether the certificate has been revoked. The verification can also include checking for any metadata (e.g., held by the trusted Entity) indicative of any other conditions that need to be satisfied in order for the verification to be allowed, for example, a minimum or threshold number of Assertions and / or Endorsements needed.

[301] In some embodiments, the request further comprises a request to verify one or both of a provenance and an integrity of additional proof data included in the permission data, wherein the additional proof data is indicative of an origin of another Entity that produced the additional proof data to further indicate one or both of the provenance and the integrity of the permission data.

[302] In some embodiments, the method 1300 further comprises receiving, from the Verifying Entity, an indication of whether the additional proof data proves one or both of the provenance and the integrity of the permission data.

[303] In some embodiments, the additional proof data comprises a digital signature, and wherein verification of one or both of the provenance and the integrity of the permission data is based on a signature check.

[304] In some embodiments, the method 1300 further comprises receiving a request from a Client Entity to access the Resource. See block 1016 of Fig. 10. Block 1016 depicts option Bl in which the Client Entity seeks to interact with a (remote) resource (at block 1018) and has requested access (at block 1020) to the Resource by sending the request to the Access Control Entity, which in turn informs the Requesting Entity of the request at the block 1016. The permission data may be indicative of an access right of the Client Entity associated with the Resource.

[305] In some embodiments, in response to verifying one or both of the provenance and the integrity of the permission data, the method 1300 further comprises indicating that access to the Resource is to be granted in accordance an access right indicated by the permission data. See block 1020, in which the Requesting Entity informs the Access Control Entity as to whether the provenance and / or integrity is verified, and thereby indicating that access to the Resource is to be granted by the Access Control Entity.

[306] In some embodiments, in response to not verifying one or both of the provenance and the integrity of the permission data, the method further comprises: indicating that access to a Resource is not to be granted.

[307] Fig. 14 is a flowchart of a method 1400 according to a technique of this disclosure. In an example, the method 1400 is implemented by Node IV in Fig. 10. Reference should be made to the previous discussion, embodiments and techniques associated with the nodes in Fig. 10.

[308] The method 1400 is a computer-implemented method performed by a Verifying Entity.

[309] The method 1400 comprises, at block 1402, receiving a request from a Requesting Entity to verify one or both of a provenance and an integrity of permission data for controlling access to a Resource, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data. See blocks 1010 and 1012 of Fig. 10.

[310] The method 1400 further comprises, at block 1404, sending, to the Requesting Entity, an indication of whether the proof data proves one or both of the provenance and the integrity of the permission data. See block 1014 of Fig. 10.

[311] The Verifying Entity may be considered to mirror the functionality of the Requesting Entity. The Verifying Entity can allow, prevent or revoke access to a Resource.

[312] Some embodiments relating to the method 1400 are now described. One or more of these embodiments may be combined with each other or otherwise modified by each other or based on any other embodiments and techniques described herein. Some of these embodiments are applicable to other methods and techniques described herein.

[313] In some embodiments, the method 1400 further comprises verifying the proof data by checking information stored in a database accessible to the Verifying Entity whether the proof data corresponds to an expectation for the proof data. As described above, this can involve a signature check.

[314] In some embodiments, the method 1400 further comprises verifying the proof data by causing another Entity (e.g., in scenarios where the Verifying Entity itself does not have all of the needed information) to check information stored in a database accessible to the other Entity whether the proof data corresponds to an expectation for the proof data. The method 1400 may further comprise receiving from the other Entity an indication of whether the proof data proves one or both of the provenance and the integrity of the permission data.

[315] In some embodiments, the proof data comprises a digital signature.

[316] In some embodiments, the information is indicative of an associated public key.

[317] In some embodiments, the method 1400 further comprises determining whether the permission data is associated with a timeframe during which the permission data applies. In response to determining that a current time is within the timeframe, the method 1400 comprises sending an indication that the permission data is applicable.

[318] In some embodiments, the method 1400 further comprises determining whether the permission data is associated with a timeframe during which the permission data applies. In response to determining that a current time is outside the timeframe, the method 1400 comprises sending an indication that the permission data no longer applies. This approach may allow or prevent further access to the Resource. Such an indication can be sent to any other entity. Any appropriate Entity could perform this action.

[319] In some embodiments, the method 1400 further comprises determining whether a revocation is applicable to the permission data. In response to determining that the revocation is applicable, the method 1400 comprises sending an indication that the permission data no longer applies. This approach may prevent further access to the Resource. Such an indication can be sent to any other entity. Any appropriate Entity could perform this action.

[320] In some embodiments, the method 1400 further comprises accessing a certificate list indicative of a Client Entity that has permission to interact with the Resource in accordance with an access right associated with the Client Entity to determine whether or not to allow the request.

[321] The certificate list may be indicative of a plurality of Client Entities that have permission to interact with the Resource in accordance with the assess right associated with each respective Client Entity. If the proof data is indicative of a Client Entity that is within the plurality of Client Entities, then the request can be allowed.

[322] In some embodiments, the method 1400 further comprises causing a certificate associated with the Client Entity to be revoked in response to determining that the permission data no longer applies to the Client Entity. This could be because the certificate is out of date or some other condition is no longer satisfied, or because the Verifying Entity has been informed by some other entity that the Client Entity can no longer interact with the Resource.

[323] In some embodiments, the Verifying Entity may store or distribute permission data to another entity (e.g., the Requesting Entity, the Access Control Entity and / or the Controlling Entity / Resource). See block 1022 of Fig. 10. This can be part of option A (e.g., the signaturebased approach using the Verifying Entity) or option B (e.g., the self-verification approach).

[324] Fig. 15 is a flowchart of a method 1500 according to a technique of this disclosure. In an example, the method 1500 is implemented by Node V in Fig. 10. Reference should be made to the previous discussion, embodiments and techniques associated with the nodes in Fig. 10.

[325] The method 1500 is a computer-implemented method performed by an Access Control Entity.

[326] The method 1500 comprises, at block 1502, receiving a request from a Client Entity to access a Resource. See block 1020 of Fig. 10.

[327] The method 1500 further comprises, at block 1504, determining an access right associated with Client Entity based on permission data in response to one or both of a provenance and an integrity of the permission data being verified. The permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data. See block 1024 of Fig. 10.

[328] The method 1500 further comprises, at block 1506, determining whether to authorize access to the Resource based on the access right. See blocks 1026 of Fig. 10, which depict that the indication is sent to the Client Entity and the Controlling Entity / Resource, though whether one or both of the blocks 1026 are sent may depend on the particular configuration of the access control system.

[329] Some embodiments relating to the method 1500 are now described. One or more of these embodiments may be combined with each other or otherwise modified by each other or based on any other embodiments and techniques described herein. Some of these embodiments are applicable to other methods and techniques described herein.

[330] In some embodiments, the method 1500 further comprises verifying the integrity of the permission data accessible to the Access Control Entity, and in response, determining whether to authorize access to the Resource based on the access right.

[331] In some embodiments, the method 1500 further comprises sending a request to a Verification Entity to verify one or both of the provenance and the integrity of the permission data. The method 1500 may further comprise receiving an indication from the Verification Entity that one or both of the provenance and the integrity of the permission data has been verified, and in response, determining whether to authorize access to the Resource based on the access right.

[332] In some embodiments, the method 1500 further comprises, in response to one or both of the provenance and the integrity of the permission data being verified, authorizing access to the Resource based on the access right by generating a token indicative of the Client Entity being authorized to access the Resource. The token may be configured to allow the Client Entity to access the Resource. This may trigger information to be logged that the Client Entity was granted access to the Resource. The token is an example of the indication sent in blocks 1026.

[333] In some cases, the token may be attached to conditions such as a timeframe, allowable actions, etc., and be used to set up a communication channel that allows the Client Entity and the Resource to communicate with each other in accordance with those conditions.

[334] In some embodiments, the Resource is provided by the Access Control Entity, and wherein to authorize access to the Resource based on the access right, the method 1500 may further comprise authorizing access to the Resource provided by the Access Control Entity. This may trigger information to be logged that the Client Entity was granted access to the Resource.

[335] In some embodiments, in response to one or both of the provenance and the integrity of the permission data not being verified, the method 1500 may further comprise restricting access to the Resource.

[336] In some embodiments, the Access Control Entity comprises one or more of a user equipment; a server; a public event chain; a blockchain node; a drone; and a service configured to provide access to the Resource.

[337] Thus, the permission data may be distributed to be held locally by whatever device / Resource a user wishes to access, or it may be held remotely (e.g., in a database) and may be queried on demand when a user wishes to access the Resource.

[338] Fig. 16 is a flowchart of a method 1600 according to a technique of this disclosure. In an example, the method 1600 is implemented by Node VI in Fig. 10. Reference should be made to the previous discussion, embodiments and techniques associated with the nodes in Fig. 10.

[339] The method 1600 is a computer-implemented method performed by a Client Entity.

[340] The method 1600 comprises, at block 1602, sending a request to an Access Control Entity to access a Resource. See block 1020 of Fig. 10.

[341] The method 1600 further comprises, at block 1604, receiving an indication that the Access Control Entity has determined an access right associated with the Client Entity based on permission data in response to one or both of a provenance and an integrity of the permission data being verified. See block 1026 of Fig. 10. The permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data.

[342] In some cases, the Resource comprises the Access Control Entity.

[343] Some embodiments relating to the method 1600 are now described. One or more of these embodiments may be combined with each other or otherwise modified by each other or based on any other embodiments and techniques described herein. Some of these embodiments are applicable to other methods and techniques described herein.

[344] In some embodiments, the indication is to authorize access to the Resource based on the access right.

[345] In some embodiments, the method 1600 further comprises sending the permission data to the Access Control Entity. The permission data may comprise the proof data. Such permission data may be part of the request at block 1020.

[346] In some embodiments, the request further comprises information configured to facilitate access to the Resource in accordance with a Relationship Based Access Control (ReBAC).

[347] In some embodiments, the method 1600 further comprises sending a control instruction to cause the Resource to perform an action. See block 1028 of Fig. 10. The control instruction may cause the Controlling Entity / Resource to cause an action based on the control instruction (see block 1030 of Fig. 10).

[348] In some embodiments, the method 1600 further comprises comprising receiving a response as a result of the Resource performing the action. See block 1032 of Fig. 10, which depicts the response (if any response is needed) being sent by the Controlling Entity / Resource (e.g., in response to the action being performed).

[349] Causing the Resource to perform an action (such as store or process some information) may correspond to an Interaction, and the response may be produced by the Resource when it performs that action.

[350] Fig. 17 is a flowchart of a method 1700 according to a technique of this disclosure. In an example, the method 1700 is implemented by Node VII in Fig. 10. Reference should be made to the previous discussion, embodiments and techniques associated with the nodes in Fig. 10.

[351] The method 1700 is a computer-implemented method performed by a Controlling Entity.

[352] The method 1700 comprises, at block 1702, receiving a control instruction from a Client Entity authorized to access a Resource associated with the Controlling Entity in response to a verification of one or both of a provenance and an integrity of permission data associated with the Client Entity. See block 1028 of Fig. 10. The permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data.

[353] The method 1700 further comprises, at block 1704, causing the Resource to perform an action based on the control instruction. See block 1030 of Fig. 10.

[354] In some cases, ‘causing’ may refer to forwarding the control instruction to the Resource or otherwise interpreting the control instruction and then instructing the Resource accordingly. In some cases, ‘causing’ may refer to instructing the Controlling Entity itself (where it represents the Resource) to perform the action.

[355] Some embodiments relating to the method 1700 are now described. One or more of these embodiments may be combined with each other or otherwise modified by each other or based on any other embodiments and techniques described herein. Some of these embodiments are applicable to other methods and techniques described herein.

[356] In some embodiments, the action comprises one or more of: information indicated by the control instruction being stored in a memory resource accessible to the Resource; and information indicated by the control instruction being processed by a processing resource accessible to the Resource.

[357] In some embodiments, the method 1700 further comprises sending a response to the Client Entity based on the action performed by the Resource. See block 1032 of Fig. 10.

[358] In some embodiments, the response comprises one or more of: a confirmation that information has been stored in a memory resource accessible to the Resource; a confirmation that information has been processed by a processing resource accessible to the Resource; and a processing result associated with the information has been processed by a processing resource accessible to the Resource.

[359] In some embodiments, the control instruction is indicative of an origin of the Client Entity.

[360] The control instruction may therefore allow the Client Entity to interact with the Resource because it contains the information indicative of the origin of the Client Entity (proving that the Client Entity is who they say they are). For example, the control instruction may comprise an access token that allows the Client Entity to interact with the Resource. The access token is indicative of the origin of the Client Entity because the access token would only be issued if the origin (e.g., identity) of the Client Entity had been verified by the Access Control Entity.

[361] Fig. 18 is a flowchart of a method 1800 according to a technique of this disclosure. In an example, the method 1800 is implemented by Node VII in Fig. 10. Reference should be made to the previous discussion, embodiments and techniques associated with the nodes in Fig. 10. As compared with Fig, 17, Fig. 18 refers to a node that controls or represents a Resource that a user provides control instructions (indicative of the user’s origin) to that are processed by the node depending on the permission data saved at the Resource. This is relevant to the drone use case and certain other use cases described herein.

[362] The method 1800 is a computer-implemented method performed by a Controlling Entity.

[363] The method 1800 comprises, at block 1802, receiving a control instruction to interact with a Resource associated with the Controlling Entity, wherein the control instruction is associated with permission data accessible to the Controlling Entity, wherein the permission data is indicative of an access right associated with the control instruction. The permission data comprises proof data indicative of one or both of a provenance and an integrity of the permission data. The permission data may have been saved by the Controlling Entity at block 1034 of Fig. 10 upon receipt from the Verifying Entity (see block 1022 of Fig. 10). In some cases, the permission data may be verified using the system described previously involving the Verifying Entity (i.e., Option A1 / A2 as described previously). In some cases (as now described), the permission data is self-verified by the Controlling Entity / Resource. A user may seek to interact with a (local) Resource such as a drone controlled by the Controlling Entity. Thus, a control instruction may be received by the Controlling Entity (e.g., from a user device coupled to the Controlling Entity). See block 1036 of Fig. 10

[364] The method 1800 further comprises, at block 1804, determining whether to grant access to the Resource based on verification that an origin of the control instruction is associated with the permission data and based on verification of one or both of the provenance and the integrity of the permission data. With reference to block 1036 of Fig. 10, the Controlling Entity may then decide whether to grant access to the Resource (based on whether or not the permission data and any rules or conditions that apply indicates that access can be granted to the user device).

[365] The method 1800 further comprises, at block 1806, causing the Resource to perform an action in accordance with the control instruction based on access being granted. See block 1030 ofFig. 10.

[366] In some cases, the access right is associated with a user, Client Entity, Client device, or the like.

[367] Some embodiments relating to the method 1800 are now described. One or more of these embodiments may be combined with each other or otherwise modified by each other or based on any other embodiments and techniques described herein. Some of these embodiments are applicable to other methods and techniques described herein.

[368] In some embodiments, the control instruction is issued by one or more of: a Client Entity; a user; and a computing device communicatively coupled to the Controlling Entity.

[369] In some embodiments, the method 1800 further comprises determining whether to grant access to the Resource further based on a certificate accessible to the Controlling Entity, wherein the certificate is indicative of one or both of the provenance and the integrity of the permission data. The certificate may be further indicative of the access right associated with the control instruction.

[370] In some embodiments, the certificate is accessible from a remote entity (e.g., a user device). For example, the certified may be kept up-to-date if the Controlling Entity is connected to a node that is informed when there has been an update to the permissions.

[371] In some embodiments, the certificate is stored in a memory of the Controlling Entity.

[372] In some embodiments, the certificate is indicative of a validity of one or more of: the permission data; and the access right. This may be useful if the Controlling Entity is not connected to the network. For example, the certificate may be saved on the device and may indicate conditions that are attached to the certificate such as a timeframe during which an authorized user can access the Resource, which users can access the Resource, what those user(s) are able to do with the Resource, any records that need to be kept, etc.

[373] In some embodiments, the Resource comprises one of more of: a memory resource; a processing resource; a computing device; hardware; firmware; software; an artificial intelligence (AI) model; an AI agent; and a drone.

[374] In some embodiments, the Resource comprises the Controlling Entity.

[375] In some embodiments, the Resource is communicatively coupled to the Controlling Entity.

[376] In aspects of the disclosure, a computing device or computing node is configured to implement one or more of the techniques, aspects, or embodiments described herein.

[377] In some cases, the computing device or computing node comprises: a memory; and a processor coupled to the memory. The processor is configured to implement any one of techniques, aspects, or embodiments described herein.

[378] In aspects of the disclosure, an apparatus is provided. The apparatus comprises means (such as one or more processors) for performing any one of techniques, aspects, or embodiments described herein.

[379] In aspects of the disclosure, a non-transitory machine-readable medium stores instructions which, when implemented by a processor, cause the processor to implement any one of the techniques, aspects, or embodiments described herein.

[380] In aspects of the disclosure, a computer-readable (storage) medium stores instructions which, when implemented by a processor, cause the processor to implement any one of the techniques, aspects, or embodiments described herein.

[381] Any reference to ‘a’ processor includes ‘one or more’ processors. Similarly, any reference to ‘a’ memory includes ‘one or more’ memories.

[382] Fig. 19 is a schematic drawing of a computer-readable medium 1900 (e.g., a computer-readable storage medium and / or a non-transitory machine-readable medium) for implementing various techniques and embodiments described herein. As used herein, the term “non-transitory” does not encompass transitory propagating signals. The computer-readable medium 1900 stores instructions 1902 readable and executable by a processor 1904 to implement the method of any of the techniques, aspects, or embodiments described herein. The computer-readable medium 1900 and / or the processor 1904 may be implemented by any relevant computing device of the architecture or system described herein.

[383] Fig. 20 is a schematic drawing of apparatus 2000 for implementing various techniques and embodiments described herein. The apparatus 2000 may be implemented by any relevant computing device of the architecture or system described herein.

[384] The apparatus 2000 comprises a processor 2002. In some cases, the processor 2002 is configured to communicate with an interface 2004. The interface 2004 may be any interface (wireless or wired) implementing a communications protocol to facilitate exchange of data (e.g., data related to implementing a functionality described herein) with other devices such as another part of the architecture or system described herein.

[385] The apparatus 2000 further comprises a memory 2006 (e.g., non-transitory or otherwise) storing instructions 2008 readable and executable by the processor 2002 to implement various embodiments described herein.

[386] Any of the models described herein may be implemented by the processing circuitry for implementing the methods described herein. Thus, certain blocks of the methods may involve use of such models in order to provide the stated functionality. The models may be (machine learning / artificial intelligence) ML / AI-based or non-ML / AI-based.

[387] Fig. 21 is a schematic diagram of a system 2100 implementing one or more techniques relating to provable permissions and depicts various scenarios that may play out.

[388] The system 2100 includes a provable permissions infrastructure 2102 that implements functionality corresponding to any of the provable permissions techniques and embodiments described herein. With reference to the discussion of the previous figures, a user computing device 2104, admin computing device 2106 and one or more endorser computing devices 2108 interact with the provable permissions infrastructure 2102 for the purpose of accessing and / or controlling one or more resources, as depicted, e.g., via network infrastructure 2110. Network infrastructure 2110 can include wireless and / or wired communications technologies e.g., involving cellular networks (e.g., 3G, 4G, 5G, 6G, and so on, technologies), satellite networks, and any other means of communication. The network infrastructure 2110 may provide communication links with any of the depicted Resources via any appropriate communications protocol. Example of Resources include, as depicted, a database 2112, a server 2114, an AI agent 2116 (e.g., that independently operates according to its training to perform its designated function such as collecting data, processing data), a vehicle 2118 (such as a car or lorry but could include any form of land-based transportation means), a sea vessel 2120 (such as a ship, boat or submarine but could include any form of water-based transportation means), airborne transport 2122 (such as an airplane, helicopter or rocket but could include any form of air / space based transportation means), a satellite 2124 (communicatively coupled to the network infrastructure 2110), and drones 2126a, 2126b, 2126c. Although the drones 2126a, 2126b, 2126c are depicted as unmanned aerial vehicles, it shall be appreciated that any type of drone is envisaged including land-based drones, sea-based drones, air-based drones, space-based drones. A drone may or may not be manned (e.g., if manned it could be controlled remotely or by on-board computers). Also depicted is a representation of a malicious entity 2128 capable of transmitting a signal to cause interference or otherwise hack communications or devices themselves. Each of the depicted devices in Fig. 21 is a computing device that includes processing and / or memory resources, and may also include an interface for communicating (via any appropriate wireless or wired communication protocol) with other computing devices. It shall be appreciated that any type of device with computing and / or networking capabilities may benefit from implementing techniques that relate to provable permissions. Any of the example scenarios described herein are exemplary and the relevant techniques are applicable in many other scenarios.

[389] The provable permissions infrastructure 2102 may ensure that a user can access a Resource in accordance with their permission level. If an entity modifies a permission, this modification can be detected so that improper access can be denied, thereby enhancing security. Thus, any of the computing devices depicted by Fig. 21 (e.g., the network infrastructure 2110, database 2112, server 2114, AI agent 2116, vehicle 2118, sea vessel 2120, airborne transport 2122, satellite 2124, drone 2126, etc.) can be protected from malicious or unintentional modification of permissions that might lead to unexpected or undesirable functionality.

[390] As an example, if a permission for the AI agent 2116 could be modified by a malicious entity, then the AI agent 2116 may be instructed to perform functionality that is unexpected such as sending data to the malicious entity. If the AI agent is trusted to perform data collection, data analysis, etc., and that data is confidential, then modifying the permission could lead to unauthorized data leakage. However, by implementing the provable permissions infrastructure 2102, any modified permissions can be verified to either allow or deny access to modify the functionality of the AI agent 2116.

[391] In another example, suppose drones 2126a, 2126b, 2126c are autonomous or semi-autonomous and can operate independently of a controller (e.g., in case of interference in a control signal such as from a global navigation satellite system (GNSS) or a host or other controller). The drones 2126a, 2126b, 2126c could hold certificates indicative of permissions associated with the functionality of the drone 2126a, 2126b, 2126c. These certificates may be updated if there is an online connection. However, they may also be stored for offline use (e.g., for offline permissioning). In this manner, if the drone 2126a, 2126b, 2126c cannot remotely check the permission e.g., using a Verifying Entity, then they can implement rules to allow or prevent certain functionality of the drone 2126a, 2126b, 2126c from being implemented. In an example scenario, suppose drone 2126b has permission to control drone 2126a. If a remote connection is dropped or if drone 2126b is lost, another drone 2126c may have permission to control drone 2126a instead. If a malicious entity tried to take control of drone 2126a, the malicious entity would not have the necessary permission and could not control drone 2126a. The certificates could be stored in protected storage such as a trusted platform module (TPM) or hardware security module (HSM) that has a specified level of security such as the ability to destroy stored data, keys, etc., to render the device’s functionality null if the storage is compromised.

[392] There are multiple scenarios involving any combination or configuration of one or more of the Resources that have been envisaged. The provable permissions approach may enhance the security and have utility in many use cases. This includes cases where offline permissioning provides a powerful approach to provide security still enable the functionality of Resources to be utilized. This may provide more confidence to allow Resources such as drones and other assets to be deployed in a wide range of scenarios, including where the Resources are at increased risk of being targeted by a malicious entity. The provable permissions approach can therefore be considered to be a highly flexible and secure approach to control access to Resources and provides for many creative use cases in many scenarios.

[393] Some case studies based on one or more techniques and embodiments described herein are now described. Case Study 1

[394] The provable permissions approach includes certain components such as the Assertion to establish the validity of the permission and cryptographic signature(s) to ensure integrity and authenticity. Optional components include metadata to provide context information associated with any permission and components of the techniques that related to Entity Interactions.

[395] Some techniques that may be used includes the following:

[396] Data Embedding: Embeds data into a permission set and syncs locally to one or more designated devices.

[397] Single Check: Assertion check across all servers for changes, providing instant answers to validation.

[398] Offline Usage: Allows continued / uninterrupted use of the permissioning system even if some systems go offline, unlike traditional password-reliant servers.

[399] Various technical benefits may include one or more of the following: Speed: Local sync ensures fast responses. Zero Knowledge: No prior user knowledge required. Logging: All access and permissions are logged. Distributed Topology: Enables a decentralized approach. Topology Push: Prioritizes essential data in the network. Independence from Central Systems: Not reliant on constant central verification. DDoS Protection: Eliminates the risk of DDoS attacks. Trust Management: Enhances trust while reducing dependency on centralized systems. Client-Side Permissions: Permissions are pushed to user devices. No List Maintenance: Devices receive permissions directly. Private Membership: Maintains privacy without centralized data dependency.

[400] One or more techniques described herein may be utilized in order to provide the following use cases.

[401] A first technique is Adaptive Risk-Based Authentication (ARBA). Adaptive Risk-Based Authentication (ARBA) dynamically adjusts the level of authentication required based on real-time risk assessments. This approach continuously evaluates various factors and adapts security measures accordingly.

[402] ARBA may have one or more of the following features:

[403] Real-Time Risk Scoring: Continuously assesses the risk level based on user behavior, context, device characteristics, and network conditions.

[404] Dynamic Authentication Flows: Adjusts authentication requirements on-the-tly, requiring stronger verification for higher-risk scenarios and streamlined processes for lower-risk situations.

[405] Machine Learning Models: Utilizes AI and machine learning to analyze patterns and predict potential threats.

[406] Example: A user accessing their email from a new device in a different location might go through additional authentication steps compared to accessing it from their usual device and location.

[407] A second technique is Zero Trust Security (ZTS). Zero Trust Security (ZTS) is a comprehensive security model that operates under the principle "never trust, always verify." It requires continuous verification of every request, regardless of its origin.

[408] ZTS may have one or more of the following features:

[409] Micro-Segmentation: Divides the network into smaller segments to limit lateral movement of attackers.

[410] Continuous Verification: Every access request is subject to stringent verification processes.

[411] Least Privilege Access: Grants users the minimum level of access necessary to perform their duties, reducing the attack surface.

[412] Example: A corporate network where every individual request to access a resource, internal or external, is authenticated and authorized dynamically.

[413] A third technique is Behavioral and Cognitive Authentication. This paradigm leverages advanced behavioral and cognitive biometrics to authenticate users based on their unique interaction patterns and cognitive responses.

[414] Behavioral and Cognitive Authentication may have one or more of the following features:

[415] Behavioral Biometrics: Monitors and analyzes user interactions such as typing rhythm, mouse movements, and touchscreen gestures.

[416] Cognitive Biometrics: Assesses cognitive responses and decision-making patterns, which are harder to mimic than physical biometrics.

[417] Anomaly Detection: Identifies deviations from established behavior patterns to detect potential intrusions.

[418] Example: An online banking system that continuously verifies the user’s identity based on how they interact with the interface, including keystroke dynamics and navigation habits.

[419] A fourth technique is Decentralized Identity and Verifiable Credentials. Decentralized Identity (DID) systems and Verifiable Credentials (VC) enable users to control their own identity data and share it securely with services without relying on central authorities.

[420] DID and VC may have one or more of the following features:

[421] User-Centric Control: Users manage their own identities using secure wallets and choose what information to share.

[422] Interoperability: Credentials can be verified across different platforms and services.

[423] Privacy and Security: Ensures privacy by minimizing data exposure and securing information via cryptographic proofs.

[424] Example: A digital wallet that allows users to store and present verifiable credentials, such as digital diplomas or government IDs, to various services as needed, without the need for centralized databases.

[425] A fifth technique is Context-Aware Authentication (CAA). Context-Aware Authentication (CAA) enhances security by considering the broader context in which authentication attempts occur. This includes environmental factors, user behavior, and historical data.

[426] CAA may have one or more of the following features:

[427] Environmental Context: Considers factors like location, time of day, and device status.

[428] Historical Data: Uses past behavior and access patterns to inform current authentication decisions.

[429] Comprehensive Analysis: Integrates multiple data sources for a holistic view of the authentication context.

[430] Example: A workplace access system that grants entry based on not only biometric data but also the time of day, known working hours, and whether the user's smartphone is within a certain proximity.

[431] The following is another example explanation of how provable permissions may be implemented:

[432] An entity may be allowed to enable a new permission set to a new role, Person A can do x, y and z and he has been assigned by Person B - Person A does not need to be on the database or cloud service, they just require the combination of assertions, meta and signatures assigned to the asset with depth of information rather than read access. This allows endless provisions embedded into the asset such as who, why, when, what, how etc. These may all be cryptographically signed so they are unhackable and remotely secure in a decentralized manner. Existing relationship based permissioning systems do not facilitate such functionality. Case Study 2

[433] There has been a recognition that endorsements and assertions represents a powerful concept. Endorsements and assertions have an implicit permissive nature that has not yet been disclosed or exploited. For example, this permissive native allows an approach of “if I have this type of endorsement, it can allow me to X,Y and Z with this entity”. The use of triplets for assertions has facilitated one or more techniques described herein. Triplets are compatible with provable structured statements that could be interpreted easily by a consuming entity automatically, such as a 3rd party platform or API. Such provable structured statements have utility as a permissive authority in many contexts. This may form the basis of “delegate signing” for example.

[434] Based on the similarity between “relationships” in existing permission systems and the relationships formed via endorsements, assertions and statements, it is possible to leverage cryptographic techniques to improve the existing permissioning systems. This can involve the use of tuples (which may be considered to be analogous with statements on assertions) such as used in ReBAC

[435] Based on the openFGA definition language, relations can be backed by assertions and statements instead of just rows in a database such as indicated by the following paragraphs (though >indicates a split between rows):

[436] type user

[437] type folder >relations >define owner: [user]

[438] type document >relations >define parent: [folder] >define viewer: viewer from parent

[439] On the basis of the above context, relation based permission systems (that merely describe database rows) are now backed by entities / assertions with signatures and such.

[440] This provides PROVABLE access control, in contrast to existing access control systems. Disclosed techniques may maintain the flexibility benefits of existing access control systems but with additional technical benefits such as being able to provide extra statements on WHY an access is granted, WHO gave access and was it approved, When, and Other information such as metadata.

[441] In some cases, conditional statements that could be used to revoke said permissions in the future may be implemented.

[442] Because the signatures are trusted, it is not necessary to check back with the authority (as is the case with existing permissioning systems). Checking with the authority is a significant slow down to granting access. In disclosed techniques, if a Resource has cached the public keys indicative of the origin, it is possible trust to these statements and the user’s assertion of access verbatim without checking with a central platform. Not only is this approach faster but also may allow access to be granted in isolated conditions such as air-gapped security or offline / isolated conditions.

[443] As a whole, using the techniques described herein, there is now a whole new, compelling, and potentially massive game changer in the tech world of system permissions.

[444] To make the point very clear, nearly all permissions are essentially insecure, including all of those used by all major cloud providers and vendors, because any bad actor can grant permission if they can gain access to their infrastructure. The disclosed techniques may prove the right person created that permission in the first place and a bad actor would need the private keys to be able to grant themselves access. This means not only hacking the database but also the keys and all other factors that form the basis of the assertion. If one uses more than one key (multiple endorsements) to secure permissions, the hacker would need ALL keys to do this. As such, the disclosed techniques represent a major advance in permissioning systems. Case Study 3

[445] Decentralized Verifiable Permissions for Drone Verification and Military Communication:

[446] In modern military operations, the use of Unmanned Aerial Vehicles (UAVs), or drones, has become increasingly prevalent. These drones often operate in environments where they might lose connectivity, making it essential to have robust mechanisms for verifying their information and ensuring secure communication. Traditional centralized systems can be vulnerable to attacks and downtime, which is unacceptable in critical military applications.

[447] Challenge: A military operation found a drone in an offline state after it had completed a mission. The challenge was to verify the drone's information, including its mission data, origin, and integrity, without relying on a central database. Additionally, there was a need for a decentralized communication system that allows nodes (such as various military units and devices) to communicate securely and verify permissions autonomously using cryptographic keys to ensure they are unhackable.

[448] A possible solution involves Decentralized Verifiable Permissions (DVP) (i.e., based on provable permissions techniques as disclosed herein). Decentralized Verifiable Permissions (DVP) provide a solution that ensures each node in the network can verify the authenticity and permissions of other nodes independently. This approach leverages the disclosed techniques and cryptographic signatures to create a distributed and tamper-proof record of permissions and activities.

[449] An example implementation involves drone verification in an offline state which includes embedded certificates. For example, each drone is equipped with one or more certificates that include information such as mission details, origin data, assertions, meta data and cryptographic signatures.

[450] Local Verification: When the drone is found offline, a local device (e.g., a military laptop) accesses the drone's certificates.

[451] Revocation Check: The local device checks for any revocations stored in its local cache. If the drone's permissions have been revoked, this information is available locally.

[452] Cryptographic Validation: The certificates are validated using public keys, ensuring that the information has not been tampered with.

[453] An example implementation involves a node-based communication environment as follows:

[454] Distributed Ledger: Each node in the military network has access to a distributed certificates ledger of assertions that records all permission-related events.

[455] Inter-Node Communication: Nodes communicate using encrypted channels and verify each other's permissions through the ledger.

[456] Dynamic Updates: When a node issues a new permission or revocation, it broadcasts this event to the network. Other nodes update their local ledgers accordingly.

[457] Resilience and Redundancy: The decentralized nature ensures that if one node goes offline, others can still function independently, maintaining operational integrity.

[458] One or more of the following benefits may be realized:

[459] Enhanced Security: DVP eliminates the single point of failure associated with centralized systems. Each node can independently verify permissions, reducing vulnerability to attacks.

[460] Offline Verification: Military personnel can verify the information of a drone or any other device even when it is offline, ensuring continuous operational capability.

[461] Tamper-Proof Records: The use of cryptographic signatures and distributed ledgers ensures that all permission records are immutable and verifiable, preventing unauthorized alterations.

[462] Operational Continuity: In a node-based environment, the loss of connectivity for one node does not affect the overall network's ability to function and verify permissions.

[463] Scalability: The system can easily scale to include more nodes and devices, as each operates independently while maintaining synchronization through the distributed ledger.

[464] Summary: The implementation of Decentralized Verifiable Permissions in military operations offers a robust, secure, and scalable solution for verifying drone information and ensuring secure node-based communications. By leveraging disclosed techniques and cryptographic methods, the military (or indeed any drone operator) can maintain operational integrity, enhance security, and ensure continuous verification capabilities, even in disconnected environments. This approach not only addresses the immediate challenges of verifying offline drones but also paves the way for more resilient and autonomous military and non-military communication networks.

[465] Although this case study refers to a military context, these techniques are also relevant to civilian contexts. Case Study 4

[466] Decentralized Verifiable Permissions for Global Data Storage Security:

[467] In an increasingly digital world, securing data storage across a global network presents significant challenges. Traditional centralized data storage systems are vulnerable to cyberattacks, unauthorized access, and data manipulation. The need for a more secure, resilient, and tamper-proof solution has become paramount, particularly for industries handling sensitive information such as finance, healthcare, and government.

[468] Challenge: Organizations worldwide face the persistent threat of data breaches and unauthorized access. Centralized systems create single points of failure, making them attractive targets for hackers. The challenge is to develop a system that ensures data integrity, availability, and security across a global scale while being resistant to hacking attempts.

[469] A possible solution involves Decentralized Verifiable Permissions (DVP) (i.e., based on provable permissions techniques as disclosed herein). Decentralized Verifiable Permissions (DVP) provide a robust framework for securing global data storage by leveraging event chain technology and cryptographic techniques. This system distributes data across multiple nodes, each with independent verification capabilities, ensuring that data remains secure, verifiable, and unhackable.

[470] An example implements distributed data storage functionality as follows:

[471] Data Sharding: Data is broken into smaller pieces (shards) and distributed across various nodes worldwide. Each node stores a fragment of the data, making it difficult for hackers to access complete sets of information.

[472] Redundancy: Multiple copies of each shard are stored on different nodes to ensure data availability and resilience.

[473] Permission verification includes cryptographic authentication: Each data access request is authenticated using cryptographic signatures. Only authorized users with valid permissions can access and modify data shards.

[474] Event Chain Ledger: All permission-related events, such as data access, modifications, and revocations, are recorded on an eventchain ledger. This creates an immutable, transparent, and tamper-proof record.

[475] Secure data access includes decentralized validation: Nodes in the network independently verify access permissions before granting access to data shards. This reduces the risk of unauthorized access and ensures data integrity.

[476] Zero Trust Architecture: The DVP model operates on a zero-trust principle, meaning that every access request is verified without assuming any inherent trust.

[477] Hacking Resistance based on the distributed nature: Since data is distributed across numerous nodes, compromising one node does not grant access to complete datasets. This significantly reduces the attack surface.

[478] Immutability: The use of DVP eventchain ensures that once data and permissions are recorded, they cannot be altered or deleted retroactively, preventing tampering.

[479] One or more of the following benefits may be realized:

[480] Enhanced Security: The distributed and decentralized nature of DVP makes it extremely difficult for hackers to compromise data. Even if one node is attacked, the overall system remains secure.

[481] Data Integrity: Cryptographic authentication and eventchain ledger ensure that all data access and modifications are verified and recorded, maintaining data integrity and traceability.

[482] Resilience and Availability: Redundant storage across multiple nodes guarantees data availability even if some nodes go offline or are compromised.

[483] Scalability: The DVP framework can easily scale to accommodate increasing amounts of data and additional nodes, adapting to growing storage needs without sacrificing security.

[484] Transparency and Trust: Immutable records on the eventchain provide transparency and build trust among stakeholders, as all actions related to data access and permissions are publicly verifiable.

[485] Summary: Decentralized Verifiable Permissions offer a groundbreaking solution for securing global data storage. By distributing data across multiple nodes and leveraging an eventchain for permission management, DVP may ensure data remains secure, verifiable, and resistant to hacking attempts. This approach addresses the vulnerabilities of centralized systems, providing enhanced security, resilience, and scalability. Organizations adopting DVP can confidently protect their sensitive information, ensuring data integrity and availability in an increasingly interconnected world. Case Study 5 I486] Securing and Controlling AI Entities &Agents with Decentralized Verifiable Permissions:

[487] As artificial intelligence (AI) continues to evolve, AI entities or agents are increasingly being deployed in various sectors, from finance and healthcare to autonomous vehicles and smart cities. However, the rise of AI also brings significant security challenges, including unauthorized access, data manipulation, and control issues. Ensuring that AI entities operate securely and effectively, while preventing unauthorized usage and interference, is crucial for their reliable deployment.

[488] Challenge: An example challenge lies in securely managing and controlling AI entities, ensuring that only authorized individuals and systems can interact with these AI agents. Centralized control systems are susceptible to hacks, single points of failure, and unauthorized access, which can lead to severe consequences, such as data breaches, AI malfunction, or misuse.

[489] Solution: A possible solution involves Decentralized Verifiable Permissions (DVP) (i.e., based on provable permissions techniques as disclosed herein). Decentralized Verifiable Permissions (DVP) offer a robust solution for securing AI entities by leveraging eventchain technology and cryptographic methods. DVP may ensure that access controls and permissions for AI interactions are distributed, verifiable, and tamper-proof, providing a higher level of security and reliability.

[490] An example implements permission management as follows:

[491] Cryptographic Signatures: Each AI entity is assigned cryptographic keys. Interactions with the AI require signed requests, ensuring that only authorized users with valid permissions can control or access the AI.

[492] Eventchain Ledger: Permissions and access events are recorded on an eventchain ledger, creating a transparent and immutable record of all interactions.

[493] Decentralized Control: Distributed Access Control: Control mechanisms for AI entities are distributed across multiple nodes, reducing the risk of unauthorized access and single points of failure.

[494] Consensus Mechanisms: Changes to AI control parameters or permissions require consensus from multiple nodes, ensuring that no single entity can unilaterally alter AI behavior.

[495] Secure Interactions can be based on a Zero Trust Architecture: Every interaction with an AI entity is verified independently. This prevents unauthorized access and ensures the integrity of commands and data.

[496] Multi-Factor Authentication: Additional layers of security, such as multi-factor authentication, are used to further verify the identity of entities interacting with the AI.

[497] Tamper-Proof Records are based on immutability - All permission grants, revocations, and access logs are immutable, preventing any retroactive changes or deletions. This ensures a reliable audit trail.

[498] One or more of the following benefits may be realized:

[499] Enhanced Security: DVP provides a decentralized and tamper-proof framework, making it extremely difficult for unauthorized parties to gain access to or control AI entities.

[500] Operational Integrity: Cryptographic verification and consensus mechanisms ensure that AI entities operate according to authorized parameters, maintaining operational integrity.

[501] Resilience Against Attacks: The distributed nature of DVP reduces the risk of centralized attacks and single points of failure, enhancing the overall resilience of AI systems.

[502] Scalability: The DVP framework can scale with the growing number of AI entities and control nodes, supporting extensive deployments without compromising security.

[503] Transparency and Accountability: Immutable eventchain records provide transparency and accountability for all AI interactions, building trust among stakeholders and enabling thorough audits.

[504] Use Case Example: Autonomous Vehicle Fleet Management:

[505] An organization deploying a fleet of autonomous vehicles can use DVP to secure and control each vehicle. Here is an example of how this may be achieved:

[506] Vehicle Authentication: Each vehicle is equipped with cryptographic keys. Only authorized personnel can interact with the vehicles using signed requests.

[507] Access Control: Permissions for vehicle operations (e g., route updates, maintenance commands) are managed through an eventchain ledger, ensuring tamper-proof records.

[508] Decentralized Updates: Software updates and parameter changes are distributed across multiple nodes. Consensus from these nodes is required to implement any critical updates, preventing unilateral control.

[509] Incident Response: In case of a security incident, revocations can be immediately propagated through the network, ensuring that compromised vehicles are quickly isolated and secured.

[510] Summary: Decentralized Verifiable Permissions provide a powerful framework for securing and controlling AI entities or agents. By leveraging eventchain technology and cryptographic methods, DVP ensures that AI systems are protected from unauthorized access, manipulation, and control. This approach may enhance security, operational integrity, and resilience, making it ideal for deploying multiple AI in critical and sensitive applications. Organizations can confidently manage and scale their AI deployments, knowing that their systems are secure, accountable and scalable. Conclusion

[511] It will be recognized that techniques described herein may have many use cases beyond those that have been described. Any feature of the techniques and embodiments described herein may be combined with other disclosed features or used to modify a feature associated with another technique or embodiment. Any feature of the case studies and examples may be combined with other disclosed features or used to modify a feature associated with another case study, example, technique or embodiment. Thus, where a specific feature is described, it may be combined with any other feature disclosed herein to achieve one or more technical benefits that can be realized by implementing provable permissions.

[512] While the disclosure has been illustrated and described in detail in the drawings and foregoing description, such illustration and description are to be considered illustrative or exemplary and not restrictive; the invention is not limited to the disclosed embodiments.

[513] One or more features described in one embodiment may be combined with or replace features described in another embodiment.

[514] Embodiments in the present disclosure can be provided as methods, systems or as a combination of machine-readable instructions and processing circuitry. Such machine-readable instructions may be included on a non-transitory machine (for example, computer) readable storage medium (including but not limited to disc storage, CD-ROM, optical storage, flash storage, etc.) having computer readable program codes therein or thereon.

[515] The present disclosure is described with reference to flow charts and block diagrams of the method, devices, and systems according to embodiments of the present disclosure. Although the flow charts described above show a specific order of execution, the order of execution may differ from that which is depicted. Blocks described in relation to one flow chart may be combined with those of another flow chart. It shall be understood that each block in the flow charts and / or block diagrams, as well as combinations of the blocks in the flow charts and / or block diagrams can be realized by machine-readable instructions.

[516] The machine-readable instructions may, for example, be executed by a general-purpose computer, a special purpose computer, an embedded processor, or processors of other programmable data processing devices to realize the functions described in the description and diagrams. In particular, a processor or processing circuitry, or a module thereof, may execute the machine-readable instructions. Thus, functional modules of apparatus and other devices described herein may be implemented by a processor executing machine-readable instructions stored in a memory, or a processor operating in accordance with instructions embedded in logic circuitry. The term ‘processor’ is to be interpreted broadly to include a central processing unit (CPU), graphics processing unit (GPU), processing unit, ASIC, logic unit, programmable gate array, and / or any other type of processing apparatus. The methods and functional modules may all be performed by a single processor or divided amongst several processors.

[517] Such machine-readable instructions may also be stored in a computer readable storage that can guide the computer or other programmable data processing devices to operate in a specific mode.

[518] Such machine-readable instructions may also be loaded onto a computer or other programmable data processing devices, so that the computer or other programmable data processing devices perform a series of operations to produce computer-implemented processing, thus the instructions executed on the computer, or other programmable devices realize functions specified by block(s) in the flow charts and / or in the block diagrams.

[519] Further, the teachings herein may be implemented in the form of a computer program product, the computer program product being stored in a storage medium and comprising a plurality of instructions for making a computer device implement the methods recited in the embodiments of the present disclosure.

[520] Elements or steps described in relation to one embodiment may be combined with or replaced by elements or steps described in relation to another embodiment. Other variations to the disclosed embodiments can be understood and effected by those skilled in the art in practicing the disclosure, from a study of the drawings, the disclosure, and the appended embodiments. In the embodiments, the word “comprising” does not exclude other elements or steps, and the indefinite article “a” or “an” does not exclude a plurality. A single processor or other unit may fulfil the functions of several items recited in the embodiments. The mere fact that certain measures are recited in mutually different dependent embodiments does not indicate that a combination of these measures cannot be used to advantage. A computer program may be stored or distributed on a suitable medium, such as an optical storage medium or a solid-state medium supplied together with or as part of other hardware, but may also be distributed in other forms, such as via the Internet or other wired or wireless telecommunication systems. Any reference signs in the embodiments should not be construed as limiting the scope of the disclosure.

[521] The disclosure includes the following subject matter according to the following numbered clauses.

[522] Clause 1. A computer-implemented method performed by an Asserting Entity, comprising: producing permission data for controlling access by a Client Entity to a Resource based on an access right associated with the Client Entity, wherein the permission data comprises proof data indicative of one or both of a provenance and an integrity of the permission data.

[523] Clause 2. The method of clause 1, wherein the permission data is configured to facilitate Relationship Based Access Control (ReBAC).

[524] Clause 3. The method of any of clauses 1 to 2, wherein the provenance of the permission data is indicative of one or more of: an origin of the permission data; a reason for producing the permission data; evidence to support the access right; a record of an Interaction with the permission data after production of the permission data.

[525] Clause 4. The method of any of clauses 1 to 3, wherein the proof data comprises a digital signature.

[526] Clause 5. The method of clause 4, comprising generating the digital signature using a key indicative of an origin of the Asserting Entity.

[527] Clause 6. The method of clause 5, wherein the key comprises an Interaction Key associated with a Community.

[528] Clause 7. The method of any of clauses 1 to 6, wherein the produced permission data represents a cryptographically provable Assertion made by the Asserting Entity that the permission data was produced by the Asserting Entity.

[529] Clause 8. The method of any of clauses 1 to 7, wherein the permission data is based on a data access structure indicative of the access right.

[530] Clause 9. The method of clause 8, wherein the permission data is indicative of a mapping between the data access structure and the proof data.

[531] Clause 10. The method of any of clauses 8 to 9, wherein the permission data represents an Assertion made by the Asserting Entity, and wherein the Assertion is translated from the data access structure based on at least part of the proof data.

[532] Clause 11. The method of any of clauses 8 to 9, wherein the proof data is based on at least part of content of the data access structure.

[533] Clause 12. The method of any of clauses 1 to 11, wherein a plurality of computing nodes are used to produce the permission data.

[534] Clause 13. The method of any one of clauses 1 to 11, wherein the data further comprises a digital signature applied to the permission data by an Endorsing Entity.

[535] Clause 14. The method of clause 13, wherein the Endorsing Entity is associated with a Community, and wherein the digital signature applied by the Endorsing Entity is based on a key associated with the Community.

[536] Clause 15. The method of any of clauses 1 to 14, comprising: receiving an indication of the access right associated with the Client Entity; and producing the permission data based on the indication.

[537] Clause 16. The method of clause 15, wherein producing the permission data based on the indication comprises mapping the indication to an Assertion made by the Asserting Entity that represents the proof data.

[538] Clause 17. The method of any of clauses 1 to 16, wherein the Resource comprises one of more of a memory resource; a processing resource; a computing device; hardware; firmware; software; an artificial intelligence (AI) model; an AI agent; and a drone.

[539] Clause 18. A computer-implemented method performed by an Endorsing Entity, comprising: endorsing permission data for controlling access by a Client Entity to a Resource based on an access right associated with the Client Entity, wherein the permission data comprises proof data indicative of one or both of a provenance and an integrity of the permission data.

[540] Clause 19. The method of clause 18, wherein endorsing the permission data comprises applying a digital signature to the permission data.

[541] Clause 20. The method of clause 19, wherein the Endorsing Entity is associated with a Community, and wherein the digital signature applied by the Endorsing Entity is based on a key associated with the Community.

[542] Clause 21. The method of any of clauses 18 to 20, wherein the endorsed permission data represents a cryptographically provable endorsement of an Assertion made by an Asserting Entity that the permission data was produced by the Asserting Entity and endorsed by the Endorsing Entity.

[543] Clause 22. The method of any of clauses 18 to 21, comprising: receiving the permission data from an Asserting Entity that produced the permission data comprising the proof data; and endorsing the permission data by generating additional proof data for the permission data that is further indicative of one or both of the provenance and the integrity of the permission data.

[544] Clause 23. The method of clause 22, wherein the additional proof data is generated using a key indicative of the origin of the Endorsing Entity.

[545] Clause 24. The method of any of clauses 18 to 23, comprising transmitting the endorsed permission data.

[546] Clause 25. A computer-implemented method performed by a Requesting Entity, the method comprising: sending a request to a Verifying Entity to verify one or both of a provenance and an integrity of permission data for controlling access to a Resource, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data; and receiving, from the Verifying Entity, an indication of whether the proof data proves one or both of the provenance and the integrity of the permission data.

[547] Clause 26. The method of clause 25, wherein the proof data comprises a digital signature, and wherein verification of one or both of the provenance and the integrity of the permission data is based on a signature check.

[548] Clause 27. The method of any of clauses 25 to 26, wherein the request further comprises a request to verify one or both of a provenance and an integrity of additional proof data included in the permission data, wherein the additional proof data is indicative of an origin of another Entity that produced the additional proof data to further indicate one or both of the provenance and the integrity of the permission data, and wherein the method further comprises: receiving, from the Verifying Entity, an indication of whether the additional proof data proves one or both of the provenance and the integrity of the permission data.

[549] Clause 28. The method of clause 27, wherein the additional proof data comprises a digital signature, and wherein verification of one or both of the provenance and the integrity of the permission data is based on a signature check.

[550] Clause 29. The method of any one of clauses 25 to 28, further comprising receiving a request from a Client Entity to access the Resource, wherein the permission data is indicative of an access right of the Client Entity associated with the Resource.

[551] Clause 30. The method of any of clauses 25 to 29, wherein in response to verifying one or both of the provenance and the integrity of the permission data, the method further comprises: indicating that access to the Resource is to be granted in accordance an access right indicated by the permission data.

[552] Clause 31. The method of any of clauses 25 to 30, wherein in response to not verifying one or both of the provenance and the integrity of the permission data, the method further comprises: indicating that access to a Resource is not to be granted.

[553] Clause 32. A computer-implemented method performed by a Verifying Entity, the method comprising: receiving a request from a Requesting Entity to verify one or both of a provenance and an integrity of permission data for controlling access to a Resource, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data; and sending, to the Requesting Entity, an indication of whether the proof data proves one or both of the provenance and the integrity of the permission data.

[554] Clause 33. The method of clause 32, comprising verifying the proof data by checking information stored in a database accessible to the Verifying Entity whether the proof data corresponds to an expectation for the proof data.

[555] Clause 34. The method of clause 32, comprising verifying the proof data by causing another Entity to check information stored in a database accessible to the other Entity whether the proof data corresponds to an expectation for the proof data, the method further comprising receiving from the other Entity an indication of whether the proof data proves one or both of the provenance and the integrity of the permission data.

[556] Clause 35. The method of any of clauses 33 or 34, wherein proof data comprises a digital signature, and wherein the information is indicative of an associated public key.

[557] Clause 36. The method of any of clauses 32 to 35, comprising: determining whether the permission data is associated with a timeframe during which the permission data applies; and in response to determining that a current time is within the timeframe, sending an indication that the permission data is applicable.

[558] Clause 37. The method of any of clauses 32 to 35, comprising: determining whether the permission data is associated with a timeframe during which the permission data applies; and in response to determining that a current time is outside the timeframe, sending an indication that the permission data no longer applies.

[559] Clause 38. The method of any of clauses 32 to 37, comprising determining whether a revocation is applicable to the permission data, and in response to determining that the revocation is applicable, sending an indication that the permission data no longer applies.

[560] Clause 39. The method of any of clauses 32 to 38, comprising accessing a certificate list indicative of a Client Entity that has permission to interact with the Resource in accordance with an access right associated with the Client Entity to determine whether or not to allow the request.

[561] Clause 40. The method of clause 39, comprising causing a certificate associated with the Client Entity to be revoked in response to determining that the permission data no longer applies to the Client Entity.

[562] Clause 41. A computer-implemented method performed by an Access Control Entity, the method comprising: receiving a request from a Client Entity to access a Resource; determining an access right associated with Client Entity based on permission data in response to one or both of a provenance and an integrity of the permission data being verified, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data; and determining whether to authorize access to the Resource based on the access right.

[563] Clause 42. The method of clause 41, further comprising verifying the integrity of the permission data accessible to the Access Control Entity, and in response, determining whether to authorize access to the Resource based on the access right.

[564] Clause 43. The method of clause 41, further comprising: sending a request to a Verification Entity to verify one or both of the provenance and the integrity of the permission data; and receiving an indication from the Verification Entity that one or both of the provenance and the integrity of the permission data has been verified, and in response, determining whether to authorize access to the Resource based on the access right.

[565] Clause 44. The method of any of clauses 41 to 43, wherein, in response to one or both of the provenance and the integrity of the permission data being verified, the method further comprises authorizing access to the Resource based on the access right by generating a token indicative of the Client Entity being authorized to access the Resource, wherein the token is configured to allow the Client Entity to access the Resource.

[566] Clause 45. The method of any of clauses 41 to 44, wherein the Resource is provided by the Access Control Entity, and wherein to authorize access to the Resource based on the access right, the method further comprises authorizing access to the Resource provided by the Access Control Entity.

[567] Clause 46. The method of any of clauses 41 to 45, wherein, in response to one or both of the provenance and the integrity of the permission data not being verified, the method further comprises restricting access to the Resource.

[568] Clause 47. The method of any of clauses 41 to 46, wherein the Access Control Entity comprises one or more of: a user equipment; a server; a public event chain; a blockchain node; a drone; and a service configured to provide access to the Resource.

[569] Clause 48. A computer-implemented method performed by a Client Entity, the method comprising: sending a request to an Access Control Entity to access a Resource; and receiving an indication that the Access Control Entity has determined an access right associated with the Client Entity based on permission data in response to one or both of a provenance and an integrity of the permission data being verified, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data.

[570] Clause 49. The method of clause 48, wherein the indication is to authorize access to the Resource based on the access right.

[571] Clause 50. The method of any of clauses 48 to 49, further comprising sending the permission data to the Access Control Entity, wherein the permission data comprises the proof data.

[572] Clause 51. The method of any of clauses 48 to 50, wherein the request further comprises information configured to facilitate access to the Resource in accordance with a Relationship Based Access Control (ReBAC).

[573] Clause 52. The method of any of clauses 48 to 51, further comprising: sending a control instruction to cause the Resource to perform an action.

[574] Clause 53. The method of clause 52, further comprising receiving a response as a result of the Resource performing the action.

[575] Clause 54. A computer-implemented method performed by a Controlling Entity, the method comprising: receiving a control instruction from a Client Entity authorized to access a Resource associated with the Controlling Entity in response to a verification of one or both of a provenance and an integrity of permission data associated with the Client Entity, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data; and causing the Resource to perform an action based on the control instruction.

[576] Clause 55. The method of clause 54, wherein the action comprises one or more of: information indicated by the control instruction being stored in a memory resource accessible to the Resource; and information indicated by the control instruction being processed by a processing resource accessible to the Resource.

[577] Clause 56. The method of any of clauses 54 to 55, further comprising sending a response to the Client Entity based on the action performed by the Resource.

[578] Clause 57. The method of clause 56, wherein the response comprises one or more of: a confirmation that information has been stored in a memory resource accessible to the Resource; a confirmation that information has been processed by a processing resource accessible to the Resource; and a processing result associated with the information has been processed by a processing resource accessible to the Resource.

[579] Clause 58. The method of any of clauses 54 to 57, wherein the control instruction is indicative of an origin of the Client Entity.

[580] Clause 59. A computer-implemented method performed by a Controlling Entity, the method comprising: receiving a control instruction to interact with a Resource associated with the Controlling Entity, wherein the control instruction is associated with permission data accessible to the Controlling Entity, wherein the permission data is indicative of an access right associated with the control instruction, and wherein the permission data comprises proof data indicative of one or both of a provenance and an integrity of the permission data; determining whether to grant access to the Resource based on verification that an origin of the control instruction is associated with the permission data and based on verification of one or both of the provenance and the integrity of the permission data; and causing the Resource to perform an action in accordance with the control instruction based on access being granted.

[581] Clause 60. The method of clause 59, wherein the control instruction is issued by one or more of: a Client Entity; a user; and a computing device communicatively coupled to the Controlling Entity.

[582] Clause 61. The method of any of clauses 59 to 60, comprising determining whether to grant access to the Resource further based on a certificate accessible to the Controlling Entity, wherein the certificate is indicative of one or both of the provenance and the integrity of the permission data, and wherein the certificate is further indicative of the access right associated with the control instruction.

[583] Clause 62. The method of clause 61, wherein the certificate is accessible from a remote entity.

[584] Clause 63. The method of clause 61, wherein the certificate is stored in a memory of the Controlling Entity.

[585] Clause 64. The method of any of clauses 61 to 63, wherein the certificate is indicative of a validity of one or more of: the permission data; and the access right.

[586] Clause 65. The method of any of clauses 59 to 64, wherein the Resource comprises one of more of: a memory resource; a processing resource; a computing device; hardware; firmware; software; an artificial intelligence (AI) model; an AI agent; and a drone.

[587] Clause 66. The method of any of clauses 59 to 65, wherein the Resource comprises the Controlling Entity.

[588] Clause 67. The method of any of clauses 59 to 65, wherein the Resource is communicatively coupled to the Controlling Entity.

[589] Clause 68. A computer-implemented method (implemented by an authorizing entity), comprising: receiving a signed message indicative of a request by an Entity to access a service / resource; verifying whether the assertions on the message are signed by entities with permissions to grant access to the service / resource; transmitting an indication of access rights of the Entity in respect of the service / resource; authorizing access based on a fusion of relationship-based systems and assertions-based systems, leveraging technologies such as Zanzibar and Origin Technology, to create a decentralized verifiable permissions framework.

[590] Clause 69. A computer-implemented method (implemented by the requesting entity), comprising: transmitting a signed message to an authorizing entity, wherein the signed message is indicative of a request by the Entity to access a service / resource, and wherein the signed message is verifiable with a public key indicative of the Entity being endorsed by one or more other Entities to access the service / resource; receiving an indication from the authorizing entity indicative of access rights of the requesting Entity in respect of the service / resource; accessing the service based on access rights of the Entity in respect of the service / resource; incorporating a decentralized permission set that integrates relationshipbased authorizations and tuple-based assertions into an encrypted permission set assigned to each node.

[591] Clause 70. A computer-implemented method for authorizing the addition of provisions from a party that is unable to give direct access, comprising: receiving a signed message from an authorized entity indicating the provision of access rights; verifying the origin of the signed message to ensure it is from an entity with the correct origin to grant access to a new system; authorizing and signing the addition of the new provisions, thereby extending access rights to the requesting Entity based on validated endorsements and permissions from the originating entities.

[592] Clause 71. The method of clause 70, wherein the fusion of relationship-based systems and assertions-based systems within the context of Decentralized Verifiable Permissions ensures secure and verifiable access to resources and services.

[593] Clause 72. A computer-implemented method for managing group revocation, comprising: defining groups of entities and associated tuple-based assertions in a decentralized verifiable permissions framework; setting rules for a top-down approach to manage permissions within these groups; receiving a revocation message indicating that a group of entities' access permissions should be revoked; verifying the authenticity of the revocation message and ensuring it adheres to pre-defined rules; propagating the revocation across the network, ensuring that all nodes update their permissions accordingly to reflect the group revocation.

[594] Clause 73. A computer-implemented method (implemented by an authorizing entity), comprising: receiving a signed message indicative of a request by an Entity to access a service / resource; verifying whether the assertions on the message are signed by entities with permissions to grant access to the service / resource; and transmitting an indication of access rights of the Entity in respect of the service / resource.

[595] Clause 74. A computer-implemented method (implemented by the requesting entity), comprising: transmitting a signed message to an authorizing entity, wherein the signed message is indicative of a request by the Entity to access a service / resource, and wherein the signed message is verifiable with a public key indicative of the Entity being endorsed by one or more other Entities to access the service / resource; receiving an indication from the (authorizing entity) indicative of access rights of the requesting Entity in respect of the service / resource; and accessing the service based on access rights of the Entity in respect of the service / resource.

[596] Clause 75. A computer-implemented method used by a requesting entity, comprising: Transmitting a Signed Message (e.g., Transmitting a digitally signed message to an authorizing entity. The signed message indicates the entity's request to access a specific service or resource and can be verified using a public key. This public key demonstrates that the entity has been endorsed by one or more other entities to access the service or resource); Receiving Access Indication (e.g., Receiving an indication from the authorizing entity, which outlines the access rights granted to the requesting entity concerning the requested service or resource); and Accessing the Service (e.g., Accessing the service based on the granted access rights in respect of the requested service or resource).

[597] Clause 76. The method of clause 75, comprising ensuring that only properly endorsed entities gain entry.

[598] Clause 77. The method of clause 75 or 76, wherein the encrypted key securely stores all data related to who granted the permissions, why, when, what was permitted, and how the process was conducted, allowing for verification both online and offline.

[599] Clause 78. An apparatus configured to perform the method of any of clauses 1 to 17, 18 to 24, 25 to 31, 32 to 40, 41 to 47, 48 to 53, 54 to 58, 59 to 67, or 68 to 77.

[600] Clause 79. An apparatus comprising means for performing the method of any of clauses 1 to 17, 18 to 24, 25 to 31, 32 to 40, 41 to 47, 48 to 53, 54 to 58, 59 to 67, or 68 to 77.

[601] Clause 80. An apparatus, comprising: a memory; and a processor coupled to the memory and configured to perform the method of any of clauses 1 to 17, 18 to 24, 25 to 31, 32 to 40, 41 to 47, 48 to 53, 54 to 58, 59 to 67, or 68 to 77.

[602] Clause 81. A computer-readable medium storing instructions which, when implemented by a processor, cause the processor to perform the method of any of clauses 1 to 17, 18 to 24, 25 to 31, 32 to 40, 41 to 47, 48 to 53, 54 to 58, 59 to 67, or 68 to 77.

[603] Clause 82. A non-transitory machine-readable medium storing instructions which, when implemented by a processor, cause the processor to perform the method of any of clauses 1 to 17, 18 to 24, 25 to 31, 32 to 40, 41 to 47, 48 to 53, 54 to 58, 59 to 67, or 68 to 77. ABBREVIATIONS

[604] The following abbreviations are used in this disclosure. AI Artificial Intelligence AML Anti Money Laundering API Application Programming Interface AR Augmented Reality ATM Automated Teller Machine BLS Boneh^Lynn^Shacham BTC Bitcoin CX Customer Experience DAO Decentralized Autonomous Organizations DEFI Decentralized Finance ECIES Elliptic Curve Integrated Encryption Scheme GUI Graphical User Interface HD Hierarchical Deterministic ID Identifier or Identity (depending on context) JSON JavaScript Object Notation KDF Key Derivation Function KYC Know Your Customer LEI Legal Entity Identifier MFA Multi Factor Authentication ML Machine Learning NFT Non-Fungible Token OS Origin Standard P2P Peer-to-Peer PBKDF Password-Based Key Derivation Function (e g., 1 and 2) QR Quick Response RFID Radio Frequency Identification SC Smart Contract SDK Software Development Kit SFT Semi-Fungible Token SMS Short Message / Messaging Service UI User Interface UX User Experience VR Virtual Reality

Claims

1. A computer-implemented method performed by an Asserting Entity, comprising: producing permission data for controlling access by a Client Entity to a Resource based on an access right associated with the Client Entity, wherein the permission data comprises proof data indicative of one or both of a provenance and an integrity of the permission data.

2. The method of claim 1, wherein the permission data is configured to facilitate Relationship Based Access Control (ReBAC).

3. The method of any of claims 1 to 2, wherein the provenance of the permission data is indicative of one or more ofan origin of the permission data;a reason for producing the permission data;evidence to support the access right;a record of an Interaction with the permission data after production of the permission data.

4. The method of any of claims 1 to 3, wherein the proof data comprises a digital signature.

5. The method of claim 4, comprising generating the digital signature using a key indicative of an origin of the Asserting Entity.

6. The method of any of claims 1 to 6, wherein the permission data is based on a data access structure indicative of the access right, and wherein the permission data is indicative of a mapping between the data access structure and the proof data.

7. The method of claim 6, wherein the permission data represents an Assertion made by the Asserting Entity, and wherein the Assertion is translated from the data access structure based on at least part of the proof data.

8. The method of claim 6, wherein the proof data is based on at least part of content of thedata access structure.

9. The method of any of claims 1 to 8, wherein a plurality of computing nodes are used to produce the permission data.

10. The method of any one of claims 1 to 9, wherein the data further comprises a digital signature applied to the permission data by an Endorsing Entity.

11. The method of any of claims 1 to 10, comprising:receiving an indication of the access right associated with the Client Entity; and producing the permission data based on the indication.

12. The method of claim 11, wherein producing the permission data based on the indication comprises mapping the indication to an Assertion made by the Asserting Entity that represents the proof data.

13. A computer-implemented method performed by an Endorsing Entity, comprising: endorsing permission data for controlling access by a Client Entity to a Resource based on an access right associated with the Client Entity, wherein the permission data comprises proof data indicative of one or both of a provenance and an integrity of the permission data.

14. The method of claim 13, wherein endorsing the permission data comprises applying a digital signature to the permission data.

15. The method of claim 14, wherein the endorsed permission data represents a cryptographically provable endorsement of an Assertion made by an Asserting Entity that the permission data was produced by the Asserting Entity and endorsed by the Endorsing Entity.

16. The method of any of claims 13 to 15, comprising:receiving the permission data from an Asserting Entity that produced the permission data comprising the proof data; andendorsing the permission data by generating additional proof data for the permission data that is further indicative of one or both of the provenance and the integrity of the permission data.

17. The method of any of claims 13 to 16, comprising transmitting the endorsed permission data.

18. A computer-implemented method performed by a Requesting Entity, the method comprising:sending a request to a Verifying Entity to verify one or both of a provenance and an integrity of permission data for controlling access to a Resource, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data; andreceiving, from the Verifying Entity, an indication of whether the proof data proves one or both of the provenance and the integrity of the permission data.

19. The method of claim 18, wherein the proof data comprises a digital signature, and wherein verification of one or both of the provenance and the integrity of the permission data is based on a signature check.

20. The method of any of claims 18 to 19, wherein the request further comprises a request to verify one or both of a provenance and an integrity of additional proof data included in the permission data, wherein the additional proof data is indicative of an origin of another Entity that produced the additional proof data to further indicate one or both of the provenance and the integrity of the permission data, and wherein the method further comprises:receiving, from the Verifying Entity, an indication of whether the additional proof data proves one or both of the provenance and the integrity of the permission data.

21. The method of any one of claims 18 to 20, further comprising receiving a request from a Client Entity to access the Resource, wherein the permission data is indicative of an access right of the Client Entity associated with the Resource.

22. The method of any of claims 18 to 21, wherein in response to verifying one or both of the provenance and the integrity of the permission data, the method further comprises:indicating that access to the Resource is to be granted in accordance an access right indicated by the permission data, or wherein in response to not verifying one or both of theprovenance and the integrity of the permission data, the method further comprises: indicating that access to a Resource is not to be granted.

23. A computer-implemented method performed by a Verifying Entity, the method comprising:receiving a request from a Requesting Entity to verify one or both of a provenance and an integrity of permission data for controlling access to a Resource, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data; andsending, to the Requesting Entity, an indication of whether the proof data proves one or both of the provenance and the integrity of the permission data.

24. The method of claim 23, comprising verifying the proof data by checking information stored in a database accessible to the Verifying Entity whether the proof data corresponds to an expectation for the proof data.

25. The method of claim 24, comprising verifying the proof data by causing another Entity to check information stored in a database accessible to the other Entity whether the proof data corresponds to an expectation for the proof data, the method further comprising receiving from the other Entity an indication of whether the proof data proves one or both of the provenance and the integrity of the permission data.

26. The method of any of claims 23 to 25, comprising:determining whether the permission data is associated with a timeframe during which the permission data applies; andin response to determining that a current time is within the timeframe, sending an indication that the permission data is applicable; orin response to determining that a current time is outside the timeframe, sending an indication that the permission data no longer applies.

27. The method of any of claims 23 to 26, comprising determining whether a revocation is applicable to the permission data, and in response to determining that the revocation is applicable, sending an indication that the permission data no longer applies.

28. The method of any of claims 23 to 27, comprising accessing a certificate list indicative of a Client Entity that has permission to interact with the Resource in accordance with an access right associated with the Client Entity to determine whether or not to allow the request.

29. The method of claim 28, comprising causing a certificate associated with the Client Entity to be revoked in response to determining that the permission data no longer applies to the Client Entity.

30. A computer-implemented method performed by an Access Control Entity, the method comprising:receiving a request from a Client Entity to access a Resource;determining an access right associated with Client Entity based on permission data in response to one or both of a provenance and an integrity of the permission data being verified, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data; anddetermining whether to authorize access to the Resource based on the access right.

31. The method of claim 30, further comprising verifying the integrity of the permission data accessible to the Access Control Entity, and in response, determining whether to authorize access to the Resource based on the access right.

32. The method of claim 30, further comprising:sending a request to a Verification Entity to verify one or both of the provenance and the integrity of the permission data; andreceiving an indication from the Verification Entity that one or both of the provenance and the integrity of the permission data has been verified, and in response, determining whether to authorize access to the Resource based on the access right.

33. The method of any of claims 30 to 32, wherein, in response to one or both of the provenance and the integrity of the permission data being verified, the method further comprises authorizing access to the Resource based on the access right by generating a token indicative of the Client Entity being authorized to access the Resource, wherein the token isconfigured to allow the Client Entity to access the Resource.

34. The method of any of claims 30 to 33, wherein, in response to one or both of the provenance and the integrity of the permission data not being verified, the method further comprises restricting access to the Resource.

35. The method of any of claims 30 to 34, wherein the Access Control Entity comprises one or more of:a user equipment;a server;a public event chain;a blockchain node;a drone; anda service configured to provide access to the Resource.

36. A computer-implemented method performed by a Client Entity, the method comprising:sending a request to an Access Control Entity to access a Resource; andreceiving an indication that the Access Control Entity has determined an access right associated with the Client Entity based on permission data in response to one or both of a provenance and an integrity of the permission data being verified, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data.

37. The method of claim 36, further comprising sending the permission data to the Access Control Entity, wherein the permission data comprises the proof data.

38. The method of any of claims 36 to 37, further comprising:sending a control instruction to cause the Resource to perform an action39. A computer-implemented method performed by a Controlling Entity, the method comprising:receiving a control instruction from a Client Entity authorized to access a Resourceassociated with the Controlling Entity in response to a verification of one or both of a provenance and an integrity of permission data associated with the Client Entity, wherein the permission data comprises proof data indicative of one or both of the provenance and the integrity of the permission data; andcausing the Resource to perform an action based on the control instruction.

40. The method of claim 39, wherein the action comprises one or more of:information indicated by the control instruction being stored in a memory resource accessible to the Resource; andinformation indicated by the control instruction being processed by a processing resource accessible to the Resource.

41. The method of any of claims 39 to 40, further comprising sending a response to the Client Entity based on the action performed by the Resource.

42. The method of any of claims 39 to 41, wherein the control instruction is indicative of an origin of the Client Entity.

43. A computer-implemented method performed by a Controlling Entity, the method comprising:receiving a control instruction to interact with a Resource associated with the Controlling Entity, wherein the control instruction is associated with permission data accessible to the Controlling Entity, wherein the permission data is indicative of an access right associated with the control instruction, and wherein the permission data comprises proof data indicative of one or both of a provenance and an integrity of the permission data;determining whether to grant access to the Resource based on verification that an origin of the control instruction is associated with the permission data and based on verification of one or both of the provenance and the integrity of the permission data; andcausing the Resource to perform an action in accordance with the control instruction based on access being granted.

44. The method of claim 43, comprising determining whether to grant access to the Resource further based on a certificate accessible to the Controlling Entity, wherein thecertificate is indicative of one or both of the provenance and the integrity of the permission data, and wherein the certificate is further indicative of the access right associated with the control instruction.

45. The method of claim 44, wherein the certificate is stored in a memory of the Controlling Entity, wherein the certificate is indicative of a validity of one or more of: the permission data; and the access right.

46. The method of any of claims 43 to 45, wherein the Resource comprises one of more of: a memory resource;a processing resource;a computing device;hardware;firmware;software;an artificial intelligence (AI) model;an AI agent; and a drone.

47. An apparatus, comprising:a memory; anda processor coupled to the memory and configured to perform the method of any of claims 1 to 12, 13 to 17, 18 to 22, 23 to 29, 30 to 35, 36 to 38, 39 to 42, or 43 to 46.

Images