Method and system for permission management - Patents.com

Abstract

The present disclosure proposes a method, a device, a system, and a computer program for creating a permit. More specifically, the method includes the steps of receiving a request including a first permit identifier, where the first permit identifier identifies a first permit, and obtaining first permit data based on the first permit identifier, where the first permit data includes data indicative of at least one permission, where the at least one permission provides an indication of one or more actions that the holder of the first permit may take and / or what the holder of the first permit is authorized to do, where the request is a request for creating a further permit, where the request includes data indicative of the further permit.

Description

[Technical field]

[0001] The present disclosure relates to providing permits and authorization systems. More particularly, the present disclosure provides flexible permits that allow pseudo-anonymous association of identities with permits, flexible permission definition, revocation, and addition, and improved security. [Background technology]

[0002] A permit is something that allows you to do something, something that you possess and often carry around. There are many different permits, with different levels of permissibility associated with them. For example, if a person has a driver's license, it means that they have permission to drive. Different driver's licenses may have different restrictions. For example, a learner's license may only allow you to drive during certain times, only in certain types of vehicles, or only if accompanied by another fully authorized driver. Other licenses include a fishing license, which allows you to fish, but may also impose restrictions on the type, size, and / or number of fish that can be caught over a period of time.

[0003] It can be seen that a permit preferably includes two components: the permit (optionally with additional restrictions associated with it) and the person who is permitted to do the things listed in the permit.

[0004] Permits can require a great deal of trust between the holder and the verifier: in particular, the verifier must trust that the physical holder of the permit is who they claim to be, that the permit has not been forged in any way and that it came from a trusted source, and that what the permit allows the holder to do is correct.

[0005] Thus, there is a need for improved, versatile, and / or secure permit systems, or at least to provide a useful alternative. Summary of the Invention

[0006] In a first aspect, the present disclosure proposes a method, a device, a system and a computer program for creating a permit. More specifically, the method includes the steps of receiving a request including a first permit identifier, where the first permit identifier identifies the first permit, and obtaining first permit data based on the first permit identifier, where the first permit data includes data indicative of at least one permission, where the at least one permission provides an indication of one or more actions that the holder of the first permit may take and / or what the holder of the first permit is authorized to do, where the request is a request for creating a further permit, where the request includes data indicative of the further permit.

[0007] Certain specific components and embodiments of the disclosed method will now be described, by way of example only, with reference to the accompanying drawings, in which like reference numerals refer to like features and in which: [Brief description of the drawings]

[0008] [Figure 1] 1 illustrates an exemplary secure processing environment and several devices configured to interact therewith. [Diagram 2] 1 illustrates an exemplary hierarchical permit structure. [Figure 3A] 1 illustrates an exemplary hierarchical permit structure. [Figure 3B] 1 illustrates an exemplary hierarchical permit structure. [Figure 4A] 1 illustrates an exemplary method for generating new permits and / or additional extensions. [Figure 4B] 1 illustrates an exemplary method for generating new permits and / or additional extensions. [Diagram 5] 1 illustrates an exemplary method for revoking a permit and / or a permit extension. [Figure 6]FIG. 1 is a schematic diagram illustrating a computing environment in which various aspects and embodiments of the present disclosure can be implemented. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0009] Provided herein are methods, devices, systems, and computer programs for creating, revoking, extending, validating, or otherwise interacting with permits, including permissions. A permit preferably provides both an identification (or information that can be used in the process of identifying the holder of the permit) and a description of what the holder is authorized to do and / or what actions the holder can take. More preferably, interactions with permits and / or children of permits are performed via requests.

[0010] In a first aspect, the present disclosure proposes a method, a device, a system and a computer program for creating a permit. More specifically, the method includes the steps of receiving a request including a first permit identifier, where the first permit identifier identifies the first permit, and obtaining first permit data based on the first permit identifier, where the first permit data includes data indicative of at least one permission, where the at least one permission provides an indication of one or more actions that the holder of the first permit may take and / or what the holder of the first permit is authorized to do, where the request is a request for creating a further permit, where the request includes data indicative of the further permit.

[0011] Advantageously, the creation of child permits allows for a hierarchical structure within the permit system, which allows for efficient revocation methods as described below. Furthermore, a secure and flexible method of permit creation is provided, allowing permit holders to build child permits using the content of a request.

[0012] In one embodiment, the method further comprises the steps of validating the first permit, creating a further permit based on data indicative of the further permit, and recording a reference to the further permit in the first permit data such that the further permit is recorded as a child of the first permit. Advantageously, the use of a reference to the child permit further enables traversal of a hierarchical permit structure and all the advantages associated therewith.

[0013] In one embodiment, verifying the first permit data includes determining whether the first permit has been revoked. In one embodiment, determining whether the first permit has been revoked includes checking a revoked field in the first permit data. Advantageously, revocation allows remaining checks associated with permit creation to be skipped (as a revoked permit cannot create new child permits), thereby improving processing efficiency. Furthermore, storing the revoked field in the permit data itself allows the permit itself to report whether it has been revoked, without relying on further resources (such as a revocation list) or third parties that may be unreliable and / or require extra resources for interaction and storage of results, thus providing efficiency.

[0014] In one embodiment, determining whether the first permit is revoked includes comparing the first time stored in the revoked field with a current time. Preferably, if the first time is in the past compared to the current time, the first permit is considered revoked. Preferably, if the first permit is considered revoked, no further permits are created and / or processing of requests stops. Using a timestamp in the revoked field adds flexibility and additional security to the system as to when a permit is considered revoked.

[0015] In one embodiment, the method includes verifying that the first permit can create child permits. In one embodiment, verifying that the first permit can create child permits includes any one or more of verifying that a maximum number of child permits associated with the first permit has not been exceeded and / or verifying that a maximum depth of child permits associated with the first permit has not been exceeded. Storing data indicating whether a permit can create children in the parent permit itself eliminates the need to manage or reference a separate resource, improving computational efficiency. Furthermore, these methods of restricting child creation result in a flexible, yet secure system, since the creator of the first permit can set child creation limits that must be adhered to during the lifetime of the first permit.

[0016] In one embodiment, the method further comprises verifying data indicative of the further permit. In one embodiment, the request further comprises a signature, and verifying the data indicative of the further permit comprises verifying that the signature is valid and has been signed using the private key of the first permit holder. Advantageously, cryptographically secure verification of the signature improves the overall security of the system, limiting or completely prohibiting third parties from impersonating a permit holder.

[0017] In one embodiment, verifying the data indicative of the further permit comprises verifying that the validity range of the further permit is within the validity range of the first permit. Preferably, verifying that the validity range of the further permit is within the validity range of the first permit comprises determining that a start point of the validity range of the further permit is the same as or later than a start point of the first permit, and determining that an end point of the validity range of the further permit is the same as or earlier than an end point of the first permit. Advantageously, providing a validity range for the permit improves security as it reduces the time a third party may interact with the permit in the event of unauthorized access.

[0018] In one embodiment, verifying the data indicative of the further permit includes verifying that one or more permissions of the further permit are within the scope of permissions that the parent permit is authorized to create. In one embodiment, the one or more permissions of the further permit are included in the request. In one embodiment, verifying that any permissions of the further permit are within the scope of permissions that the parent permit may create includes determining one or more namespaces that the parent permit is authorized to create, determining one or more namespaces of the one or more permissions of the further permit, and determining that the one or more namespaces of the one or more permissions of the further permit are the same as or are prefixed by one or more namespaces that the parent permit is authorized to create. Advantageously, this provides a hierarchical aspect or dimension to the permissions, which also improves security, since, for example, a permission cannot be created that is not within the scope of the authorized permissions of an organization.

[0019] In one embodiment, creating the further permit comprises creating a further permit data instance based on the permit, the further permit data comprising a parent permit value set to the first permit identifier.

[0020] In one embodiment, the method further comprises the step of providing a further permit identifier to the sender of the request. In one embodiment, only the further permit identifier is provided to the sender of the request. Advantageously, the permit identifier is used to interact with the permit in a pseudo-anonymous manner, in that the identifier alone does not allow identification of a user associated with the permit.

[0021] In one embodiment, the data indicative of the at least one permission is an object including at least one name-value pair. In one embodiment, the name of the name-value pair is represented by a string and the value of the name-value pair is represented by a string and / or at least one further name-value pair. In one embodiment, the string is arbitrary and / or user generated. In one embodiment, the value is arbitrary and / or user generated. Advantageously, the use of name-value pairs, and in particular user generated name-value pairs, allows greater flexibility in the design of the security permission system and further enables a namespace feature as described below.

[0022] In one embodiment, the request is received via an API provided only to computing modules belonging to the secure computing environment. In one embodiment, the computing module implementing the method of any one or more of the preceding embodiments is part of the secure computing environment. Advantageously, if the request originates from the secure computing environment, the request can often be presumed to be valid. By presuming the request is valid, processing time can be saved because other checks (such as signature verification, authorization, verification of the request itself, and other checks) can be skipped, thereby reducing the processing time and computing resources required to process the request.

[0023] In one embodiment, the first permit is part of a hierarchy of permits. In one embodiment, the first permit data includes data indicative of a parent permit. In one embodiment, the first permit data includes data indicative of a child permit. Advantageously, the hierarchical permit structure allows for alternative and improved management of permits. In one embodiment, the hierarchy is such that when a parent permit is revoked, its children are also revoked. Having parents and children preferably provides a hierarchical tree structure. Further advantageously, the hierarchical structure allows for parent and child relationships, which allows for the benefits described below with respect to namespaces, child creation restrictions, and cascading revocation.

[0024] In one embodiment, the first permit data includes at least one namespace, each namespace defining a portion of the permissions that children of the first permit may have. Advantageously, this provides a way of restricting what permits can do, such that if the child permit and / or parent permit are somehow compromised, the further permissions that the child permit may generate and / or receive with other permits are limited.

[0025] In one embodiment, the first permit data includes an indication as to whether further permits that are children of the first permit may be created. In one embodiment, the first permit data includes an indication as to the maximum depth of descendants the first permit may have. In one embodiment, the first permit data includes a maximum number of child permits the first permit may have. In one embodiment, the first permit data includes an array indicating the maximum number of descendant permits the first permit may have at different depths. Advantageously, limiting the number of children a permit may create (which may be zero), the depth of the children, and / or the number of children at different depths improves security, as these limitations allow a parent permit holder to limit what a potentially compromised and / or hostile first permit holder can do.

[0026] In one embodiment, the first permit data includes a validity range. In one embodiment, the first permit data includes a time indicating from when the permit is valid. In one embodiment, the first permit data includes a time indicating until when the permit is valid. Advantageously, providing a time value for from when or until when the permit is valid allows the parent permit holder greater flexibility in selecting when the permit is valid. Additionally, limiting the time the permit is valid increases the security of the system. Limiting the time the permit is valid limits the amount of time a hostile third party can interfere with the permit.

[0027] In one embodiment, the first permit identifier obliviates the identity of the holder of the first permit. In one embodiment, the first permit identifier is a pseudo-randomly generated string. Advantageously, allowing the user associated with the permit to not be identified by the permit identifier further improves security by making it much more difficult for a hostile third party with access to the identifier to identify, impersonate, approach, and / or otherwise interact with the associated user.

[0028] In one embodiment, the method further comprises the step of transmitting data indicative of a request for storage in the log or for inclusion in the blockchain. Preferably, the data indicative of the request is configured to provide an indication regarding the status of the permit. More preferably, the set of data indicative of previous interactions with the permit is configured to provide an indication regarding the current state of the permit.

[0029] Advantageously, by remembering all interactions with the permit, including its creation (especially any "send" interactions that modify the permit), the set of interactions can be used to reconstruct the permit. This reconstruction can be compared to the permit's current status to ensure that nothing has been tampered with regarding the permit, thereby further improving security and increasing the ability of third parties to rely on the permit's secure status. Using a blockchain to record interactions further improves security, as the blockchain provides additional security, providing publicness, verifiability and non-malleability of the interaction log.

[0030] More specifically, the system of the first aspect comprises a first computing module configured to generate a first request and a permit computing module configured to perform any one of the embodiments of the method of the first aspect. In one embodiment, the permit computing module belongs to a secure computing environment. In one embodiment, the first computing module is a further permit computing module, the further permit computing module belonging to the secure computing environment.

[0031] Advantageously, if the devices are all running within the same secure computing environment, this can act as a way to verify that the request originates from a secure source and can therefore be presumed to be valid (in many cases). By presuming the request is valid, processing time can be saved because other checks (such as signature verification, authorization, verification of the request itself, and other checks) can be skipped, thereby reducing the processing time and computing resources required to process the request.

[0032] In one embodiment, the first computing module is a user device, which advantageously allows other users to interact with the permit.

[0033] More specifically, the device of this aspect comprises a processor and a memory, the memory including executable instructions that, upon execution by the processor, cause the device to perform a computer-implemented method according to any one of the method embodiments of the first aspect.

[0034] According to a first aspect, a non-transitory computer readable storage medium comprising computer program code instructions executable by a computer for performing any of the method embodiments of the first aspect is also described.

[0035] In a second aspect, the present disclosure proposes a method, a device, a system, and a computer program for verifying a permit. More specifically, the method of the second aspect includes the steps of receiving a request including a first permit identifier, where the first permit identifier identifies a first permit, and obtaining first permit data based on the first permit identifier, where the first permit data includes data indicative of at least one permission, where the at least one permission provides an indication of one or more actions that the holder of the first permit may take and / or what the holder of the first permit is authorized to do, where the request is a request for verifying a representation associated with the at least one permission of the first permit, where the request includes data indicative of the representation.

[0036] Advantageously, receiving and processing the request in a process associated with the authorization allows a third party to interact with and verify the authorization, enabling secure, programmatic verification of a user's authorization. Further advantages are provided below next to each optional embodiment, as well as throughout the specification as each embodiment is described.

[0037] In one embodiment, the method further comprises determining whether the authorization includes matching permissions with the data indicative of further permissions. Preferably, the method further comprises returning the result of the determination of matching permissions to the sender. Advantageously, allowing third parties wishing to check different permissions of the authorization to reference specific permissions allows greater flexibility in the construction of the authorization, as well as greater flexibility in how the permissions are interacted with.

[0038] In one embodiment, the method further includes continuing to process the request based on a determination of whether the first permit has been revoked. Advantageously, revocation allows remaining permit checks to be skipped (as they are all considered invalid), thereby improving processing efficiency.

[0039] In one embodiment, determining whether the first permit has been revoked includes checking a revoked field in the first permit data. Advantageously, storing the revoked field in the permit data itself provides efficiency by allowing the permit itself to report whether it has been revoked, without relying on further resources (such as a revocation list) or third parties that may be unreliable and / or require extra resources for interaction and storage of results.

[0040] In one embodiment, determining whether the first permit has been revoked includes checking whether the first time stored in the revoked field is earlier than the current time. Using a timestamp in the revoked field adds flexibility to the system as to when a permit is considered revoked, thereby improving security by reducing the attack surface when permits may be subject to tampering.

[0041] In one embodiment, the representation includes data configured to query characteristics of the permissions associated with the first permit. In one embodiment, the method further includes evaluating the representation. In one embodiment, the method further includes returning a result of the evaluation of the representation to the sender of the request. Advantageously, by being able to evaluate the representation with and in relation to the permissions of the permit, creators and requesters of permits have the flexibility to adapt and extend how they interact with the permit and the types of functionality that can be stored in the permit.

[0042] In one embodiment, the method further includes determining whether the subset of permissions is valid. In one embodiment, the method further includes comparing the current time to a validity range associated with the subset of permissions.

[0043] In one embodiment, the request includes data for identifying the subset of permissions. In one embodiment, evaluating the expression includes identifying or accessing one or more permissions being queried based on the data to identify the subset of permissions.

[0044] In one embodiment, the method further comprises receiving a further request to verify the signature signed by the holder of the permit. In one embodiment, the further request comprises the signature and the message to which the signature has been applied. In one embodiment, the method comprises verifying the signature, the verification of the signature being based on the first permit data, the signature, and a public key of the first permit obtained from the data. In one embodiment, the result of the verification is provided to the sender of the further request. In one embodiment, the sender of the request and the further request is the same. Advantageously, by using cryptographically secure techniques to secure the "who" part of the permit aspect, the permit can improve the security of the overall method and use of the permit.

[0045] In one embodiment, the data indicative of the at least one permission is an object including at least one name-value pair. In one embodiment, the name of the name-value pair is represented by a string and the value of the name-value pair is represented by a string and / or at least one further name-value pair. In one embodiment, the string is arbitrary and / or user generated. In one embodiment, the value is arbitrary and / or user generated. Advantageously, the use of name-value pairs, and in particular user generated name-value pairs, allows greater flexibility in the design of the security permission system and further enables a namespace feature as described below.

[0046] In one embodiment, the request is received via an API provided only to a computing module belonging to the secure computing environment. In one embodiment, the computing module implementing the method of any one or more of the embodiments herein is part of the secure computing environment. Advantageously, if the request originates from the secure computing environment, the request can often be presumed to be valid. By presuming the request is valid, processing time can be saved because other checks (such as signature verification, authorization, verification of the request itself, and other checks) can be skipped, thereby reducing the processing time and computing resources required to process the request.

[0047] In one embodiment, the first permit is part of a hierarchy of permits. In one embodiment, the first permit data includes data indicative of a parent permit. In one embodiment, the first permit data includes data indicative of a child permit. Advantageously, the hierarchical permit structure allows for alternative and improved management of permits. In one embodiment, the hierarchy is such that when a parent permit is revoked, its children are also revoked. Having parents and children preferably provides a hierarchical tree structure. Further advantageously, the hierarchical structure allows for parent and child relationships, which allows for the benefits described below with respect to namespaces, child creation restrictions, and cascading revocation.

[0048] In one embodiment, the first permit data includes at least one namespace, each namespace defining a portion of the permissions that children of the first permit may have. Advantageously, this provides a way of restricting what permits can do, such that if the child permit and / or parent permit are somehow compromised, the further permissions that the child permit may generate and / or receive with other permits are limited.

[0049] In one embodiment, the first permit data includes an indication as to whether further permits that are children of the first permit may be created. In one embodiment, the first permit data includes an indication as to the maximum depth of descendants the first permit may have. In one embodiment, the first permit data includes a maximum number of child permits the first permit may have. In one embodiment, the first permit data includes an array indicating the maximum number of descendant permits the first permit may have at different depths. Advantageously, limiting the number of children a permit may create (which may be zero), the depth of the children, and / or the number of children at different depths improves security, as these limitations allow a parent permit holder to limit what a potentially compromised and / or hostile first permit holder can do.

[0050] In one embodiment, the first permit data includes a time indicating from when the permit is valid. In one embodiment, the first permit data includes a time indicating until when the permit is valid. Advantageously, providing a time value for from when or until when the permit is valid allows the parent permit holder greater flexibility in selecting when the permit is valid. Additionally, limiting the time the permit is valid increases the security of the system. Limiting the time the permit is valid limits the amount of time a hostile third party can interfere with the permit.

[0051] In one embodiment, the first permit identifier obscures the identity of the holder of the first permit. In one embodiment, the first permit identifier is a pseudo-randomly generated string. Advantageously, allowing the user associated with the permit to be unidentifiable by the permit identifier further improves security by making it much more difficult for a hostile third party with access to the identifier to identify, impersonate, approach, and / or otherwise interact with the associated user.

[0052] In one embodiment, the method further comprises the step of transmitting data indicative of a request for storage in the log or for inclusion in the blockchain. Preferably, the data indicative of the request is configured to provide an indication regarding the status of the permit. More preferably, the set of data indicative of previous interactions with the permit is configured to provide an indication regarding the current state of the permit.

[0053] Advantageously, by remembering all interactions with the permit, including its creation (especially any interactions that modify the permit), the set of interactions can be used to reconstruct the permit. This reconstruction can be compared to the permit's current state to ensure that nothing has been tampered with regarding the permit, thereby further improving security and increasing the ability for third parties to rely on the permit's secure status. Using a blockchain to record interactions further improves security, as the blockchain provides additional security, providing publicness, verifiability and non-malleability of the interaction log.

[0054] More specifically, the system of the second aspect comprises a first computing module configured to generate a first request and a permit computing module configured to perform any one of the embodiments of the method of the second aspect. In one embodiment, the permit computing module belongs to a secure computing environment. In one embodiment, the first computing module is a further permit computing module, the further permit computing module belonging to the secure computing environment.

[0055] Advantageously, if the devices are all running within the same secure computing environment, this can act as a way to verify that the request originates from a secure source and can therefore be presumed to be valid (in many cases). By presuming the request is valid, processing time can be saved because other checks (such as signature verification, authorization, verification of the request itself, and other checks) can be skipped, thereby reducing the processing time and computing resources required to process the request.

[0056] In one embodiment, the first computing module is a user device, which advantageously allows other users to interact with the permit.

[0057] More specifically, the device of the second aspect comprises a processor and a memory, the memory including executable instructions that, upon execution by the processor, cause the device to perform a computer-implemented method according to any one of the method embodiments of the second aspect.

[0058] According to a second aspect, a non-transitory computer readable storage medium comprising computer program code instructions executable by a computer for performing any of the method embodiments of the second aspect is also described.

[0059] In a third aspect, the present disclosure proposes a method, a device, a system, and a computer program for revoking at least a permission. More specifically, the method of the third aspect includes the steps of receiving a request including a first permission identifier, the first permission identifier identifying a first permission, and obtaining first permission data based on the first permission identifier, the first permission data including data indicative of at least one permission, the at least one permission providing an indication of one or more actions that the holder of the first permission may take and / or what the holder of the first permission is authorized to do. The request is a request for revoking at least a subset of the permissions of the first permission data, and the method further includes the step of revoking the subset of the permissions.

[0060] In one embodiment, revoking the subset of permissions is revoking all of the permissions. In one embodiment, revoking all of the permissions includes revoking the first permission. Advantageously, if all of the permissions of a permission (and the permission itself) need to be revoked, a computationally efficient method is presented since it is not necessary to repeatedly remove / revoke the set of permissions or individual permissions.

[0061] In one embodiment, the request further includes an indication of the subset of permissions to be revoked. In one embodiment, the indicator of the subset of permissions is a string. In one embodiment, the string is generated by the user. Advantageously, allowing a group of permissions to be represented by a string not only provides an efficient way to identify and specifically revoke them compared to listing each individual permission the user wishes to revoke, but also provides more fine-grained control compared to revoking the entire permit.

[0062] In one embodiment, revoking the subset of permissions of the first permit data includes setting a value in a revoked field in the first permit data. In one embodiment, the value is a time value. In one embodiment, the time value set in the revoked field is the current time or the time field in the request. In one embodiment, the first permit and / or the subset of permissions of the first permit are considered revoked based on the value in the revoked field. In one embodiment, the first permit and / or the subset of permissions of the first permit are considered revoked based on a comparison of the current time to the time value set in the revoked field. Using a timestamp in the revoked field adds flexibility to the system as to when a permit is considered revoked, which also improves security since it also reduces the attack surface when permits may be tampered with.

[0063] In one embodiment, the method includes determining the validity of the request, where determining the validity of the request includes verifying that the sender of the request is a process associated with the parent of the first permit or sent by the holder of the parent of the first permit. In one embodiment, if the sender of the request is neither the parent of the first permit nor the holder of the parent permit, the request is rejected. In one embodiment, determining that the sender of the request is a process associated with the parent of the first permit includes determining that the request is received from a computing module in the secure computing environment. In one embodiment, determining that the request is received from a computing module in the secure environment includes comparing a process identifier included in the received request with a further process identifier associated with the first permit. In one embodiment, verifying that the sender of the request is a process associated with the parent of the first permit or sent by the holder of the parent of the first permit includes verifying a cryptographic signature of the request. In one embodiment, verifying the cryptographic signature includes verifying that the signature was signed by the holder of the parent permit. Advantageously, invalid requests to revoke a permit or a subset of permits are rejected using cryptographic means or by ensuring that the request originates from a known secure process, thereby improving the security of the system.

[0064] In one embodiment, determining the validity of the request further comprises determining whether a permit identifier included in the request matches a parent permit identifier stored in the first permit data. Advantageously, by thus ensuring that only the parent permit can modify the child permit, security is further improved.

[0065] In one embodiment, the method further comprises the step of revoking all descendants of the first permit. In one embodiment, the step of revoking all descendants of the first permit comprises the steps of obtaining a list of child permits from the first permit data and sending a further revocation request to the child permit process so that the child permit revokes all its descendants. In one embodiment, the further revocation request is constructed such that, upon receipt, each descendant permit recursively performs the steps of this aspect until all descendants are revoked. Advantageously, this ensures that descendants of the parent permit are also revoked. This improves the overall security of the permit hierarchy and the system, and further provides an efficient way of revoking all child permits without the called party actually having knowledge of all child permit identifiers.

[0066] In one embodiment, the data indicative of the at least one permission is an object including at least one name-value pair. In one embodiment, the name of the name-value pair is represented by a string and the value of the name-value pair is represented by a string and / or at least one further name-value pair. In one embodiment, the string is arbitrary and / or user generated. In one embodiment, the value is arbitrary and / or user generated. Advantageously, the use of name-value pairs, and in particular user generated name-value pairs, allows greater flexibility in the design of the security permission system and further enables a namespace feature as described below.

[0067] In one embodiment, the request is received via an API provided only to a computing module belonging to the secure computing environment. In one embodiment, the computing module implementing the method of any one or more of the embodiments herein is part of the secure computing environment. Advantageously, if the request originates from the secure computing environment, the request can often be presumed to be valid. By presuming the request is valid, processing time can be saved because other checks (such as signature verification, authorization, verification of the request itself, and other checks) can be skipped, thereby reducing the processing time and computing resources required to process the request.

[0068] In one embodiment, the first permit is part of a hierarchy of permits. In one embodiment, the first permit data includes data indicative of a parent permit. In one embodiment, the first permit data includes data indicative of a child permit. Advantageously, the hierarchical permit structure allows for alternative and improved management of permits. In one embodiment, the hierarchy is such that when a parent permit is revoked, its children are also revoked. Having parents and children preferably provides a hierarchical tree structure. Further advantageously, the hierarchical structure allows for parent and child relationships, which allows for the benefits described below with respect to namespaces, child creation restrictions, and cascading revocation.

[0069] In one embodiment, the first permit data includes at least one namespace, each namespace defining a portion of the permissions that children of the first permit may have. Advantageously, this provides a way of restricting what permits can do, such that if the child permit and / or parent permit are somehow compromised, the further permissions that the child permit may generate and / or receive with other permits are limited.

[0070] In one embodiment, the first permit data includes an indication as to whether further permits that are children of the first permit may be created. In one embodiment, the first permit data includes an indication as to the maximum depth of descendants the first permit may have. In one embodiment, the first permit data includes a maximum number of child permits the first permit may have. In one embodiment, the first permit data includes an array indicating the maximum number of descendant permits the first permit may have at different depths. Advantageously, limiting the number of children a permit may create (which may be zero), the depth of the children, and / or the number of children at different depths improves security, as these limitations allow a parent permit holder to limit what a potentially compromised and / or hostile first permit holder can do.

[0071] In one embodiment, the first permit data includes a time indicating from when the permit is valid. In one embodiment, the first permit data includes a time indicating until when the permit is valid. Advantageously, providing a time value for from when or until when the permit is valid allows the parent permit holder greater flexibility in selecting when the permit is valid. Additionally, limiting the time the permit is valid increases the security of the system. Limiting the time the permit is valid limits the amount of time a hostile third party can interfere with the permit.

[0072] In one embodiment, the first permit identifier obscures the identity of the holder of the first permit. In one embodiment, the first permit identifier is a pseudo-randomly generated string. Advantageously, allowing the user associated with the permit to be unidentifiable by the permit identifier further improves security by making it much more difficult for a hostile third party with access to the identifier to identify, impersonate, approach, and / or otherwise interact with the associated user.

[0073] In one embodiment, the method further comprises the step of transmitting data indicative of a request for storage in the log or for inclusion in the blockchain. Preferably, the data indicative of the request is configured to provide an indication regarding the status of the permit. More preferably, the set of data indicative of previous interactions with the permit is configured to provide an indication regarding the current state of the permit.

[0074] Advantageously, by remembering all interactions with the permit, including its creation (especially any "send" interactions that modify the permit), the set of interactions can be used to reconstruct the permit. This reconstruction can be compared to the permit's current status to ensure that nothing has been tampered with regarding the permit, thereby further improving security and increasing the ability of third parties to rely on the permit's secure status. Using a blockchain to record interactions further improves security, as the blockchain provides additional security, providing publicness, verifiability and non-malleability of the interaction log.

[0075] More specifically, the system of the third aspect comprises a first computing module configured to generate a first request and a permit computing module configured to perform any one of the embodiments of the method of the third aspect. In one embodiment, the permit computing module belongs to a secure computing environment. In one embodiment, the first computing module is a further permit computing module, the further permit computing module belonging to the secure computing environment.

[0076] Advantageously, if the devices are all running within the same secure computing environment, this can act as a way to verify that the request originates from a secure source and can therefore be presumed to be valid (in many cases). By presuming the request is valid, processing time can be saved because other checks (such as signature verification, authorization, verification of the request itself, and other checks) can be skipped, thereby reducing the processing time and computing resources required to process the request.

[0077] In one embodiment, the first computing module is a user device, which advantageously allows other users to interact with the permit.

[0078] More particularly, the device of the third aspect comprises a processor and a memory, the memory including executable instructions that, upon execution by the processor, cause the device to perform a computer-implemented method according to any one of the method embodiments of the third aspect.

[0079] According to a third aspect, a non-transitory computer readable storage medium comprising computer program code instructions executable by a computer for performing any of the method embodiments of the third aspect is also described.

[0080] In a fourth aspect, the present disclosure proposes a method, a device, a system and a computer program for adding further permissions to a first permit. More specifically, the method of the fourth aspect includes the steps of receiving a request including a first permit identifier, where the first permit identifier identifies the first permit, and obtaining first permit data based on the first permit identifier, where the first permit data includes data indicative of at least one permission, where the at least one permission provides an indication of one or more actions that the holder of the first permit may take and / or what the holder of the first permit is authorized to do, where the request is for adding the set of further permissions to the first permit, where the request includes the set of further permissions.

[0081] In one embodiment, the method includes determining that the sender of the request is a computing module and / or a parent permit holder associated with a parent permit, the parent permit being a parent permit of the first permit. In one embodiment, if the sender of the request is neither a parent permit nor a parent permit holder, the request is not processed. In one embodiment, determining that the sender of the request is a computing or parent permit holder associated with the parent permit includes comparing a permit identifier included in the received request with a parent identifier included in the first permit data, and verifying based on the comparison that the sender of the request is a computing or parent permit holder associated with the parent permit. In one embodiment, determining that the sender of the request is a process associated with the first permit includes verifying a cryptographic signature of the request. In one embodiment, verifying the cryptographic signature includes verifying that the signature was signed by the parent permit holder. Advantageously, using cryptographic means or ensuring that the request originates from a known secure process, the security of the system is improved as invalid requests to revoke a permit or a subset of permissions are rejected.

[0082] In one embodiment, continuing to process the request based on a determination of whether the first permit has been revoked. In one embodiment, determining whether the first permit has been revoked includes checking a revoked field in the first permit data. In one embodiment, determining whether the first permit has been revoked includes checking whether a first time stored in the revoked field is earlier than a current time.

[0083] In one embodiment, the method further includes determining that adding the additional permission sets will not exceed the maximum number of permission sets and continuing to process the request based on the determination. In one embodiment, at least one permission includes data indicating the maximum number of permissions that may be associated with the permission. Advantageously, the permission has built-in customizable restrictions, thereby improving the security of the permission itself.

[0084] In one embodiment, the request includes a string to identify the set of further permissions. In one embodiment, the string is generated by a user. Advantageously, allowing a string to represent a group of permissions provides an efficient way to revoke them compared to listing each individual permission that the user wishes to revoke. Additionally, referencing groups of permissions by their identifiers provides efficiencies by eliminating the need to reference each permission individually or iterate over groups of permissions.

[0085] In one embodiment, the method further comprises adding a further set of permissions to the permit.

[0086] In one embodiment, the data indicative of the at least one permission is an object including at least one name-value pair. In one embodiment, the name of the name-value pair is represented by a string and the value of the name-value pair is represented by a string and / or at least one further name-value pair. In one embodiment, the string is arbitrary and / or user generated. In one embodiment, the value is arbitrary and / or user generated. Advantageously, the use of name-value pairs, and in particular user generated name-value pairs, allows greater flexibility in the design of the security permission system and further enables a namespace feature as described below.

[0087] In one embodiment, the request is received via an API provided only to a computing module belonging to the secure computing environment. In one embodiment, the computing module implementing the method of any one or more of the embodiments herein is part of the secure computing environment. Advantageously, if the request originates from the secure computing environment, the request can often be presumed to be valid. By presuming the request is valid, processing time can be saved because other checks (such as signature verification, authorization, verification of the request itself, and other checks) can be skipped, thereby reducing the processing time and computing resources required to process the request.

[0088] In one embodiment, the first permit is part of a hierarchy of permits. In one embodiment, the first permit data includes data indicative of a parent permit. In one embodiment, the first permit data includes data indicative of a child permit. Advantageously, the hierarchical permit structure allows for alternative and improved management of permits. In one embodiment, the hierarchy is such that when a parent permit is revoked, its children are also revoked. Having parents and children preferably provides a hierarchical tree structure. Further advantageously, the hierarchical structure allows for parent and child relationships, which allows for the benefits described below with respect to namespaces, child creation restrictions, and cascading revocation.

[0089] In one embodiment, the first permit data includes at least one namespace, each namespace defining a portion of the permissions that children of the first permit may have. Advantageously, this provides a way of restricting what permits can do, such that if the child permit and / or parent permit are somehow compromised, the further permissions that the child permit may generate and / or receive with other permits are limited.

[0090] In one embodiment, the first permit data includes an indication as to whether further permits that are children of the first permit may be created. In one embodiment, the first permit data includes an indication as to the maximum depth of descendants the first permit may have. In one embodiment, the first permit data includes a maximum number of child permits the first permit may have. In one embodiment, the first permit data includes an array indicating the maximum number of descendant permits the first permit may have at different depths. Advantageously, limiting the number of children a permit may create (which may be zero), the depth of the children, and / or the number of children at different depths improves security, as these limitations allow a parent permit holder to limit what a potentially compromised and / or hostile first permit holder can do.

[0091] In one embodiment, the first permit data includes a time indicating from when the permit is valid. In one embodiment, the first permit data includes a time indicating until when the permit is valid. Advantageously, providing a time value for from when or until when the permit is valid allows the parent permit holder greater flexibility in selecting when the permit is valid. Additionally, limiting the time the permit is valid increases the security of the system. Limiting the time the permit is valid limits the amount of time a hostile third party can interfere with the permit.

[0092] In one embodiment, the first permit identifier obscures the identity of the holder of the first permit. In one embodiment, the first permit identifier is a pseudo-randomly generated string. Advantageously, allowing the user associated with the permit to be unidentifiable by the permit identifier further improves security by making it much more difficult for a hostile third party with access to the identifier to identify, impersonate, approach, and / or otherwise interact with the associated user.

[0093] In one embodiment, the method further comprises the step of transmitting data indicative of a request for storage in the log or for inclusion in the blockchain. Preferably, the data indicative of the request is configured to provide an indication regarding the status of the permit. More preferably, the set of data indicative of previous interactions with the permit is configured to provide an indication regarding the current state of the permit.

[0094] Advantageously, by remembering all interactions with the permit, including its creation (especially any "send" interactions that may modify the permit), the set of interactions can be used to reconstruct the permit. This reconstruction can be compared to the permit's current status to ensure that nothing has been tampered with regarding the permit, thereby further improving security and the ability of third parties to rely on the permit's secure status. Using a blockchain to record interactions further improves security, as the blockchain provides additional security, providing publicness, verifiability and non-malleability of the interaction log.

[0095] More specifically, the system of the fourth aspect comprises a first computing module configured to generate a first request and a permit computing module configured to perform any one of the embodiments of the method of the fourth aspect. In one embodiment, the permit computing module belongs to a secure computing environment. In one embodiment, the first computing module is a further permit computing module, the further permit computing module belonging to the secure computing environment.

[0096] Advantageously, if the devices are all running within the same secure computing environment, this can act as a way to verify that the request originates from a secure source and can therefore be presumed to be valid (in many cases). By presuming the request is valid, processing time can be saved because other checks (such as signature verification, authorization, verification of the request itself, and other checks) can be skipped, thereby reducing the processing time and computing resources required to process the request.

[0097] In one embodiment, the first computing module is a user device, which advantageously allows other users to interact with the permit.

[0098] More particularly, the device of the fourth aspect comprises a processor and a memory, the memory including executable instructions that, upon execution by the processor, cause the device to perform a computer-implemented method according to any one of the method embodiments of the fourth aspect.

[0099] According to a fourth aspect, a non-transitory computer readable storage medium comprising computer program code instructions executable by a computer for performing any of the method embodiments of the fourth aspect is also described.

[0100] Those skilled in the art will appreciate that the above described aspects may be used in any combination with each other, for example the first and second aspects may be combined such that there is one way of checking permits and adding further permits.

[0101] Exemplary System Overview 1 shows an exemplary system 100 for implementing an authorization as described herein. The system comprises several computing modules 102, 104, 106 inside a secure processing environment 108. Outside the secure processing environment are several client devices 110, 112. The client devices 110, 112 are configured to interact with some of the computing modules 102, 104, 106 of the secure processing environment. Preferably, the computing modules 104, 106 have an associated address and can receive requests including the address. Optionally, the computing module 102 is a gateway module configured to receive requests from the client devices 110, 112 and forward them to the correct computing module 104, 106 according to the address stored in the request.

[0102] Preferably, the computing modules 102, 104, 106 are implemented as microservices running within a secure processing environment 108. Optionally, the secure processing environment is a single server or a single collection of servers in a computer network. Alternatively, the computing modules are implemented as part of a serverless system, which defines the secure processing environment. Exemplary serverless environments include AWS Lambda.

[0103] Preferably, the computing modules 102, 104 have an associated process identifier, which is the same for all processes associated with a permit within the secure processing environment 108, where the process identifier identifies a class of similar computing modules. Computing modules are also described herein as instances, which have "instance identifiers" of "instanceId". Optionally, the process identifier is stored in the permit data instance.

[0104] As described below under the heading "Interacting with Permits," each permit includes an associated computing module (although the reverse may also be considered true, with each computing module having an associated permit). Thus, when an action is performed on a permit, this preferably involves interacting with the computing module associated with the permit. Preferably, the interaction is performed by sending a request to the computing module associated with the relevant permit.

[0105] Optionally, within the secure processing environment 108 is a computing module manager 114. Preferably, this computing module manager 114 is configured to create new processes within the secure processing environment 108.

[0106] Permits and Permit Content A permit provides a way to identify a user and specify what the permit holder is authorized to do. The identification aspect is done using public key cryptography, and the "what the holder can do" is done using permissions as described herein.

[0107] In one embodiment, each permit has an associated permit data instance (also described as associated permit data or permit data). The permit data instance includes data about the permit itself and permissions indicating what the holder of the permit can do. Preferably, each permit includes at least one permission, and more preferably includes multiple permissions. The permissions are configured to determine what the holder of the permission is authorized to do. Preferably, the permissions are defined by name-value (also called key-value) pairs. Preferably, the name is a string. More preferably, the string is human readable and provides an indication of what the permission relates to. Preferably, the value is a string, number or a data structure, and the data structure is one or more name-value pairs. The permissions are preferably in a form as described in more detail below under the heading "Permissions". When referring to a permit including one or more permissions as used herein, this preferably refers to a permit data instance including name-value permissions. The permissions are preferably provided in sets or groups (called permissionSets in the examples described herein). Preferably, the group of permission(s) is part of each permit as an "extension", which is further described below under the heading "Extensions".

[0108] Each permit also contains data such that the identity of the permit holder can be verified. Preferably, the permit contains a public key associated with the permit holder. Verification of the permit holder's identity can be determined by the holder signing a message (or any data) with their private key, after which a party verifying the permit holder's identity can compare the signature and message against the public key associated with the permit holder. Preferably, the public key associated with the permit holder is stored in the associated permit data instance.

[0109] Preferably, each permit is identified by a permit identifier. Preferably, the permit identifier provides no indication as to the contents of the permit. Preferably, the permit identifier is a pseudo-randomly generated string.

[0110] In one embodiment, the system provides a method for verifying a user's signature against a permit, and therefore verifying whether the user is the holder of the permit. Preferably, the verification is performed according to the method described under the heading "Signature Verification".

[0111] Preferably, permits are part of a hierarchy. With reference to FIG. 2, a hierarchy 200 of permits is shown. Every permit (except the root 202) has a parent permit and, optionally, one or more child permits. Preferably, a child permit cannot have more than one parent. The resulting permit hierarchy is a tree. A parent permit can create child permits (subject to various restrictions imposed on the permit itself, which are described in more detail below, particularly under the heading "Adding a Child Permit"). Preferably, when a parent is revoked, its children are also revoked. More preferably, the process is recursive, such that all descendants of the parent permit are also revoked. This can be seen as a cascading revocation starting from the parent permit.

[0112] Preferably, the permit contains a set of rules that allow the permit holder to create child permits that contain permits within a given "domain" or "namespace" but that do not span other domains or namespaces. The use of these namespaces prevents separate organizations from interfering with other organizations using the permit system. The set of rules is described in the special permits described below.

[0113] Additionally, the set of rules allows for delegation of authority to child permissions, granting child permissions the right to create grandchildren within the domain or namespace, subject to optional depth and total number limitations. These limitations are recursive in that children preferably inherit the same or more restrictive delegations of authority from their parents.

[0114] The top-level root permit 202 has the ability to create a large or even unlimited number of child permits with little or no restrictions. With such broad capabilities, the private / public key pair used to create the root permit is preferably managed securely. Preferably, the private key associated with the root permit is kept offline on a secure device.

[0115] Creating a top-level root permit 202 (not an organizational level root permit 206, 208, 210) is a one-time process. The method is similar to creating a child permit, except that since there is no parent permit to reference, all checks regarding parent permissions, authentication, authorization, and other characteristic checks are skipped or otherwise ignored. In this embodiment, this is preferably done once and never again.

[0116] In the exemplary permit hierarchy 200 of FIG. 2, there are four different organizations using permits. nChain™ is the holder of the root permit, and Org ABC, Org PQR, and Org XYZ are all using permits that are children of nChain's permit. Those skilled in the art will appreciate that the specific companies are used only as examples. Furthermore, there may be any number of organizations in such a permit system. The exemplary hierarchy and organizations shown in FIG. 2 illustrate the flexibility of permit construction when using some of the present embodiments described herein.

[0117] Continuing with the example, Org ABC has an organization-level root permission 206. This is a root permission in that it is the root of permissions for Org ABC, and not the top-level root 202 for the entire tree. Org ABC has created at least two child permissions 212, 214. These child permissions are for different customers and / or end users.

[0118] Org XYZ has a root permit 210. Org XYZ has chosen to have a different hierarchical structure with permits for each country. XYZ UK permit 216 is shown along with at least two permits 218, 220 for members and / or end users.

[0119] In one embodiment, the holder of a root permit creates several child permits 204 with the same holder. These child permits are configured to be able to create further child permits 206, 208, 210 for other users of the system. This eliminates the need to use the top-level root permit 202 to create further permits every time a new user or organization desires a permit. Thus, the opportunities for attacks are reduced and the security of the root permit is improved.

[0120] Preferably, every permit contains a reference to its parent and one or more named permissions. At creation time, the parent provides data indicating the set of permissions and the public key (holderPubKey) associated with the permit holder. By default, permissions are stored under the extensions["default"] object, as seen in the example permit data instance below. Permit creation is described in more detail under the heading "Adding a Child Permit".

[0121] Preferably, the permit information is tracked in a data structure called a Permit Data Instance or Permit Data. The data structure includes at least some of the following elements shown in the table below. Preferably, all elements are required. Some of the values ​​for the elements can be set to null, zero, or zero length. More preferably, parent is required and is not null.

[0122] Optionally, the permit is valid from the current time to an end date and time. Preferably, the end date and time is set in the permit data instance under the "revoked" element. Once revoked, a permit cannot be reactivated. To temporarily deactivate a permit (or a subset of its permits), revoking and adding extensions can be used as described under the "Extensions" heading below. [Table 1]

[0123] Preferably, determining whether a permit has been revoked depends on the current time. Each permit includes a "revoked" element that contains a time. For a permit to be considered revoked, the current time must be after the revocation time stored in the permit. More preferably, and according to a further embodiment, a method is provided in which a permit is provided at some point in the future and returns whether it is valid at that time.

[0124] Preferably, maps of named permissions are referenced by their name in the extension map. The name "default" is used when storing the initial extension.

[0125] Alternatively, no extension map is used and only one set of permissions is associated with a permit.

[0126] Each extension contains several elements. Exemplary elements of an extension are shown in Table 2 below. Preferably, all of them are required. [Table 2]

[0127] An example permit data instance with all elements populated (but some set to null) is shown below in JSON format:

number

[0128] Those skilled in the art will appreciate that the above is an exemplary authorization and that certain features of this authorization data instance may be omitted, not used, or modified depending on the particular embodiment described herein. Those skilled in the art will further appreciate that JSON is provided herein as an example of representing the authorization. The authorization and its contents may be represented using other formats, such as XML, a binary encoding format, or any other suitable format.

[0129] Referring to Figure 3A, a simple example is shown (with the final top-level root permit omitted), where an organizational root permit 302 has at least two child permits 304, 306. The organization is the National Bureau of Waterways (NBW) which issues fishing permits 304, 306 (in this example restricted to anglers). Optionally, the NBW provides a mobile application which holds identifiers for holders' permits and private keys that allow permit holders to verify that they hold the permit. Each angler permit 304, 306 contains a permission called "org.nbw.angler.rights" and preferably has the following structure:

number

[0130] Optionally, there are other permissions associated with the individual's identity, such as a membership number and a username.

[0131] In use, a fishing inspector wanting to verify that a user (such as Fred Bass holding first child permit 304) is fishing with the correct type of equipment and catching the correct type of fish can use this permit to verify. The inspector can use the permit identifier (preferably obtained from Fred Bass' phone via a QR code). With this permit identifier, the inspector can query the permit instance itself to verify both the authorization (that Fred Bass is using a rod and is only fishing for carp, tench, or pike) and the identity (that Fred is in fact the permit holder and has not copied someone else's permit identifier).

[0132] permission Preferably, the permissions are namespaced. More preferably, the permissions are namespaced by restricting what the names in the name-value pairs can be. Preferably, the namespace uses a reverse DNS domain-like structure separated by "." (periods). Some examples of namespaces are given below:

number

[0133] Thus, these namespaces are constructed from left to right, with the leftmost prefixes being the least specific features and the rightmost suffixes being the most specific features.

[0134] Preferably, both the names and values ​​of these permission name-value pairs are customizable (as long as the names are within the allowable namespace of the parent permission). Preferably, both the names and values ​​can be any value. Preferably, both the names and values ​​are supplied by a user of the permission system; thus, the names and values ​​are user generated. Providing user generated and / or customizable names and values ​​makes the use cases for permissions very flexible, thereby enabling use in a large number of different applications.

[0135] Preferably, the namespace can only be long. This can also be understood as meaning that the permissions of a child permission can only be a subset of those granted according to the parent permission(s). Preferably, the namespace allows the permissions to be structured in a hierarchy (this is in addition to, and often coincident with, the permissions also being hierarchical).

[0136] Preferably, the permission hierarchy follows the same structure as the permissions, which can also be understood as each child permission containing permissions that are a subset (in terms of namespace) of the parent.

[0137] A set of special permissions, prefixed with the "$" namespace, provide information and / or restrictions about the permission itself. The "$" namespace provides restrictions on what permissions these permissions can add to child permissions. These restrictions can include: Enforcing one or more namespace prefixes for all permissions in the child; Delegating the right to create further permits to children, recursively to a given depth; Limits on the number of children and further descendants that can be created; and / or · Limits on the number of Extensions you can create (described below under the heading "Extensions").

[0138] Alternatively, the information stored in these special permits (i.e., permit restrictions and other information) is stored in the permit data instance rather than being stored in the special permit. Preferably, each restriction is stored as its own element in the permit data instance. Those skilled in the art will appreciate that these restrictions may be stored in any number of different locations associated with the permit.

[0139] Optionally, the "$" namespace is also used to define the scope of validity of the permit. [Table 3]

[0140] The special ($) namespace does not need to conform to the "$.children.namespace" rule as described above. Preferably, it is possible to create only a specific set of special permissions. More preferably, the set is the only special permissions that a permission can have.

[0141] Preferably, the $.valid.after and $.valid.before permissions use local time. Preferably, the permissions are optional and not required. Preferably, $.valid.after and $.valid.before define the validity period (also called the validity range) of the permit and / or extension. Preferably, if a parent has either $.valid.after and $.valid.after permissions set, any children created from it must convey the same or a narrower time window. Thus, it can be seen that the validity range of a child permit cannot exceed the validity range of its parent permit.

[0142] Since these special permissions refer to the permit as a whole, these special permissions are preferably stored only in the initial / default extension. Any special permissions stored in a different extension are ignored or rejected.

[0143] Referring to the previous example of FIG. 3A, the NBW root permit 302 includes at least the following permits:

number

[0144] These permissions indicate that the holder of the NBW root permission 302 can create as many child permissions as necessary, as long as the child permissions start with "org.nbw" and the children are only one level deep.

[0145] 3B, a further exemplary permit structure 320 is now shown. This structure is similar to that described with reference to FIG. 3A. The NBW root permit 302 has a "$.children.levels" permission equal to (or greater than) 2. In this example, the holder of the NBW permit 302 wants to enable the club to create permits for its own members. The NBW permit 302 creates a club permit BLFC 322 (Big Lake Fishing Club) which includes the following permissions:

number

[0146] These permissions allow the BLFC to create up to 50 permissions for its members, but only within the namespace "org.nbw.angler". Therefore, permissions such as "org.nbw.club.id" are not granted to any children, and therefore children cannot impersonate the club permission (e.g., if a child permission contains the permission "org.nbw.club.id", then the child can pose as the club itself and take any action associated with the club) or any other similar permission.

[0147] The BLFC permit 322 creates at least two child permits 324, 326. These child permits must have a permission prefixed with "org.nbw.angler".

[0148] Expansion Preferably, permissions are stored in "extensions". Preferably, an extension contains a set of permissions (called permissionSets), a revoke element, and a holderPubKey element. Extensions are stored in permission data instances in an extension map and referenced by name. Preferably, the name is generated by the user. Preferably, the name is human readable. Optionally, the initial extension and / or the default extension is labelled "default", where human readable is any encoding that is naturally readable by humans. Preferably, the encoding is ASCII or Unicode text.

[0149] An extension preferably provides a way to reference at least one group of permissions. More preferably, the permissions provide a human readable way to reference at least one group or set of permissions. As described above in Table 2, each extension includes several elements that contain a set of permissions.

[0150] An extension may also be described as containing, defining, or being a subset of the permissions of the permit to which the extension belongs.

[0151] Those skilled in the art will appreciate that the structure and format of the extensions and how they are stored need not be strictly adhered to. Alternative structures for extensions and / or collections of permissions may be possible. An alternative may be that the extensions do not have to be strictly stored in the extension map, but may be stored in a list or other suitable data structure. Alternatively, the extension objects described herein may have a different structure in that they only contain a list of permissions or a list of permission references, with the permissions themselves being stored elsewhere on the permit.

[0152] During the lifetime of a permit, extensions can be used to add and replace sets of permissions. Extensions may be added or revoked by parent permits. Preferably, all permissions added to a permit are signed by the holder of the parent permit.

[0153] Adding an extension to a license is described in more detail under the heading "Adding an Extension." Revoking an extension is described in more detail under the heading "Revoking an Extension."

[0154] In one embodiment, the extension allows a permit holder to associate different devices with a permit. For example, if the permit is for access to a particular resource (optionally a computing resource), a single permit holder may have an "iPhone" extension to manage the interaction of his iPhone and a "desktop" extension to manage the interaction of his desktop computer with the computing resource. As mentioned above, the extensions are revocable. Advantageously, if a user loses his iPhone, he can contact his permit provider (which controls the parent permit that created the permit for this user) and revoke the iPhone extension without affecting the user's interaction with other devices and services. It can thus be seen that the extension system offers improved flexibility and control with respect to providing / removing access to resources. This, combined with the lack of centralized management of permits and / or certificate revocation lists (CRLs, further described under the heading "Revoking Permits"), can conserve computing resources since distribution and maintenance of such lists is not required with respect to checking the permits in the relevant extensions.

[0155] Interacting with the permit As mentioned above, the authorization system described herein is preferably interacted with using requests. Preferably, the requests are HTTP requests. More preferably, the requests are sent to a REST endpoint. There are two REST endpoints that are of interest: … / send to request actions on the license, including creating and revoking children, and … / query to check permit validity and authorization.

[0156] Preferably, some interactions require that the request include a signature, so organizations wishing to interact with permits for creation, revocation, or other interactions will need to have a private / public key pair set up. Any request will also need to include the instance id of the permit of interest. The instance id and public key can be publicly viewable or knowable, but the private key must be kept secret.

[0157] Sending requests to these endpoints can also be described as "calling" the endpoints as they are presented as RESTful APIs. The sender of the request can therefore also be considered the "caller."

[0158] Preferably, any request sent to the "... / send" endpoint is logged. Preferably, the logging is done on the blockchain so that requests can be audited by a third party. Preferably, requests sent to the "... / query" endpoint are not logged.

[0159] Optionally, requests that would normally be sent to "... / query" can be sent to the "... / send" endpoint for logging. This option is useful when permit (or permit permissions) checking is important and needs to be verified afterwards. For example, if all permit holders are required to check their permit before entering a location, then it is likely necessary to log each time a permit is checked to ensure that the check actually occurred.

[0160] In one embodiment, the interactions described under the headings "Create Child Permit", "Revoke Permit", "Revoke Extension" and "Add Extension" are logged on the blockchain, or at least a subset of the interactions are logged on the blockchain. Preferably, all of these interactions are logged off-chain and a subset of the interactions are logged on the blockchain. Preferably, the interactions are recorded in sets of interactions, each set of interactions associated with a single permit. Each set of interactions also has an associated representation (with a transaction) on the blockchain. Thus, an auditor wishing to track interactions with a permit of interest can audit only the set of interest.

[0161] Preferably, each interaction logged on the blockchain includes an immutable reference to the previous interaction (optionally also stored on the blockchain). Preferably, this reference is a hash of the previous interaction. Preferably, every interaction includes a reference to the previous interaction, thus establishing an immutable chain of all interactions. Thus, an immutable log requires that only a subset of interactions are recorded on the blockchain. Optionally, only the first and last interactions are recorded on the blockchain.

[0162] Preferably, logging is done using an Event Stream for each permit. Optionally, there is a logging service that is interacted with via an API to provide the logging implementation. The Event Stream is described with reference to: · PCT / IB2021 / 051258, filed on February 15, 2021 by nChain Holdings Limited; PCT / IB2021 / 051260, filed on February 15, 2021 by nChain Holdings Limited; and · PCT / IB2021 / 051333 filed on February 17, 2021 by nChain Holdings Limited.

[0163] Preferably, all of the interactions described under the headings "Create a Child Permit", "Revoke a Permit", "Revoke an Extension", and "Add an Extension" are provided using the ... / send API endpoint.

[0164] Preferably, data indicative of any interactions with the permit is sent to an Event Stream using the Event Stream API. Preferably, the Event Stream API is a RESTful API. The current state of the permit can be verified by taking all interactions with the permit (including its creation) and replaying all the interaction steps again to recreate a "dummy permit" (this can also be described as a "dry run" in that no new permit is actually created). The final state of the "dummy permit" should have the same current state as the real permit. The same is true for verifying any intermediate states of the permit, if the intermediate states are known.

[0165] Thus, by logging interactions with the permit, we know that the state of the permit is logged, and therefore the current state or any previous state is auditable and verifiable. By submitting these state changes to the blockchain via an event stream, the permit becomes durably auditable and verifiable, providing high confidence in data integrity.

[0166] Some example requests to an endpoint may include the following features in the header:

number

[0167] where {AWS ID} is the id of the AWS(TM) endpoint and {instance ID} is the authorization identifier. Those skilled in the art will appreciate that other URLs and services may be used. For example, non-AWS URLs may be used. Those skilled in the art will appreciate that the requests provided herein are exemplary and may take different forms. The request is shown as including the URL to which the request is being sent. Optionally, the full URL is not provided as such, just the path is provided.

[0168] Optionally, the request header also includes an AWS API key.

[0169] Preferably, the body of the POST should be a JSON object containing a single property named for the message or interaction being sent. Preferably, authentication and authorization for the request is performed by signing the parameters with the sender's private key and putting the result in the signature property of the request, for example:

number

[0170] Note that the parts of the request being signed must be sent as a string representation of the request's contents, not the JSON object itself. This is to ensure that both the sender of the request and the receiver of the request use the same representation of the object (spacing, order, etc. are irrelevant) to compute the signature. Instead of stringifying, a canonical structure of the object may be used. This canonical structure is optionally defined according to RFC8785. The canonicalization scheme is one that is agreed upon by both the sender and receiver. The scheme may be agreed upon in advance, or the scheme is identified by the sender such that the receiver understands which scheme is being used.

[0171] Preferably, when canonicalization is used, the JSON objects in the request are not stringified and can be sent in any valid JSON form.

[0172] Preferably, a response to the above request is provided with result properties and an optional message, for example:

number

[0173] The exact content of the message (msg) depends on the context of the request and how it is processed.

[0174] Below are presented several different embodiments that describe different interaction permissions. Preferably, any number of these embodiments may be used with any number of different other embodiments. Those skilled in the art will understand that some embodiments may not be used in all possible systems. For example, extensions may not be used, and therefore interactions regarding creating or canceling extensions may not be used.

[0175] Creating a child license 4A and 4B, exemplary methods 400, 420 for creating a child permit are shown. The first method 400 is preferably performed by or on behalf of a user (such as an organization) that wishes to create a new child permit for a permit that it already holds. The second method 420 is preferably performed by a permit computing module, such as the computing module 104 of FIG. 1. Those skilled in the art will appreciate that some of the steps of each method may be performed by different parties, and strict adherence to which member performs which step is not required.

[0176] Preferably, the public key of the holder of the new permit to be created is known or obtained (402). Optionally, obtaining the new public key includes generating a new private / public key pair. Preferably, the generation of the private / public key pair is performed by the holder of the new permit such that the holder of the parent permit (and / or the sender of the request to create the new permit) does not gain knowledge of the new permit holder's private key. Thus, a new public key is received from the holder of the new permit.

[0177] A request to create a new permit is constructed (404), the request including a number of features describing the new permit. Preferably, the features describing the new permit include at least data indicating the permissions the new permit will have and the holder's public key of the new permit holder. Optionally, the features describing the new permit further include the validity range of the new permit.

[0178] Preferably, the features describing the new permit are signed using the private key of the parent permit. More preferably, the features are converted into a string (also known as "stringified") and / or converted into a canonical data structure, and the resulting string or data structure is signed. The request includes the signature.

[0179] Optionally, the feature describing the new permit is called "permitContents". As an example, the request has the following form:

number

[0180] The pre-stringified permitContents is optionally a JSON structure and has the following format:

number

[0181] As mentioned above, as an alternative to stringified permitContents (or any other stringified JSON used herein), a JSON canonicalization can be used, where the JSON structure of the request can be in its normal, non-stringified form.

[0182] As an alternative to JSON, the permitContents and / or the request may be in XML format. Returning to the fishing example of Figures 3A and 3B, in the particular example where NBW wants to create a fishing permit 304 for Fred Bass, the permissionContents for creating Fred's permit 304 would look like this:

number

[0183] The request is created and sent by the user (408) and received by the parent permit (422). As described above with reference to interacting with permits, the request includes an address (preferably in a header). Preferably, that address includes the permit identifier of the parent permit. Thus, the request is sent to and received at the computing module associated with the parent permit.

[0184] Referring to method 420 of Figure 4B, the steps involved in validating the new permit and the parent permit are shown. Preferably, at least these steps are performed by a computing module associated with the parent permit.

[0185] After receiving 422 the request, permit instance data (also referred to as permit data) is obtained 424. Preferably, the computing module already has this information stored in memory. Alternatively, the computing module obtains the permit instance data from a repository and / or database that contains other permit instance data.

[0186] As described below with reference to this method, as well as with reference to other embodiments involving checking and / or verification steps, several validity checks are performed to ensure that some features of the request and / or permit are correct. This description details a happy path where the received request and all data being checked is correct. However, if anything is found to be invalid or incorrect, the computing module skips to the last step 432 of the method (or the last step 518 of the revocation method 500) and creates and sends a response to the sender. This response is to indicate that the request has failed, and optionally includes the reason for the failure of the request.

[0187] Some validation is performed on the parent permit itself as to whether the permit instance data allows the parent permit to create child permits 426. Preferably, the validation of the parent permit includes checking whether the parent permit has been revoked (as a revoked permit cannot create children and all its children are considered revoked).

[0188] Preferably, validating the parent permission includes checking its own permission as to whether it can create children. Preferably, this includes ensuring that the number of hierarchical levels that the parent permission can create under itself is greater than or equal to 1. With reference to the permission data instance embodiment described above, this means checking that the "$.children.levels" permission is greater than or equal to 1. If the levels value is not set, which is the same as being equal to zero, the parent permission cannot create children.

[0189] Preferably, checking the permission itself as to whether it can create children includes checking that the maximum number of children has not been exceeded. With reference to the permit data instance embodiment described above, this means ensuring that "$.children.max" is either not set (meaning there is no limit), or is set to a number greater than the number of children the permit already has, or is set to an array (the first number in the array is greater than the number of children the permit already has).

[0190] The request and its contents are then verified 428. Preferably, by verifying the signature of the request, the permit computing module ensures that the request is signed by the holder of the permit (or at least by someone who holds a private key associated with the public key of the parent permit). Preferably, this signature verification is performed using a public key stored in the data instance of the permit.

[0191] Optionally, if a validity range is stored in the request for the new permit, a validation step is performed to ensure that the validity range of the new permit does not exceed that of the parent permit.

[0192] Preferably, the permissions of the new permit are verified to be within the range of permissions that the parent is authorized to provide. With reference to the permit data instance embodiment described above, this means ensuring that the permissions being added to the new permit are within the namespace as outlined in the parent's "$.children.namespace". For example, when creating a new permit with the permission "org.nbw.angler.rights", validation may include ensuring that the parent permit contains a namespace with "org.nbw.angler" (or a broader namespace such as "org.nbw" or "org").

[0193] In addition to the above, the namespace of the permit that the child is allowed to create is also verified to be the same or in the same scope as the parent permit. For example, if the parent namespace is [“org.nbw,angler”, “org.nbw.club”], then the child permit cannot have the namespace [“org.nbw”] as it is broader than the parent namespace.

[0194] Preferably, any one or more of the following further checks are performed: (A) the total levels that a parent and / or child may have; (B) the maximum number of children that a parent or child may have; and (C) The child's validity has the same or a narrower scope compared to the parent.

[0195] Note that all of these checks are to ensure that the child permit does not contain broader or more numerous features than the parent permit.

[0196] Regarding (A) above, if the child contains $.children.levels, it must be smaller than the parent. Regarding (B) above, if the child contains $.children.max, it must fit within the envelope of the parent's array (if there is one) except for the first element. Note that if the parent has no levels, it means there is no limit. Regarding (C) above, $.valid.{before,after} must be at least as narrow as the parent.

[0197] A new permit is then created (430). Preferably, when used in combination with the embodiment described with reference to Figure 1, this step includes sending a further request to the computing module manager 114. The computing module manager 114 creates a new computing module for the new permit and the new permit identifier.

[0198] A new permit data instance is created for or with the new permit and the relevant new content of the permit is added to it. Exemplary content includes the new permit created in the second step 404 of the first method 400 and then verified by the parent permit module in the second method 420.

[0199] Optionally, the new permit checks that the process that created it (in this case the parent permit) is part of the same secure processing environment 108 .

[0200] Preferably, the new permit sets the parent permit as its parent, more preferably by storing the instance id of the parent permit as the "parent" element of the data instance of the new permit.

[0201] When a new permit process is created, the new permit returns its own permit identifier to the parent permit, which adds the child's permit identifier to its list of children. Preferably, this means adding the instance id of the new permit to the "children" array element of the parent's data instance.

[0202] Finally, a response to the sender of the request is generated and sent to the sender, the response including an indication that the new permit was successfully created (or not, if not), and an identifier for the new permit, which is preferably also provided to the owner of the new permit so that it can be referenced when necessary.

[0203] Those skilled in the art will appreciate that some of these steps may be considered optional depending on the usage context, especially the security context. For example, the parent permit may not need to perform many of the validation steps (such as verifying the signature or checking if the namespace is correct) if the request is received from a sender known to be configured to generate only valid requests.

[0204] Additionally, while steps are presented herein in a particular order, this is for ease of explanation only, and one of ordinary skill in the art will appreciate that some of these steps may occur in any order and / or simultaneously.

[0205] Revocation of license 5, a method 500 according to one embodiment for revoking a child permit is shown. Preferably, the method is performed by a parent permit, where the holder of the parent permit wishes to revoke a permit that is a child of the parent permit.

[0206] Preferably, a permit can only be revoked by the owner of the parent permit. Optionally, a permit can also be revoked by any ancestor.

[0207] Preferably, when a license is revoked, all of its descendants are also revoked.

[0208] Advantageously, by having a "revoked" field in each permit that is actively maintained by the system operator, the permit holder, and / or the holder of any parent permits, the need for a Certificate Revocation List (CRL) is eliminated. A CRL is a list of all digital certificates that have been revoked by their issuer. This allows permits to be used more time and resource efficient, since the user / validator does not need to retrieve the list, verify that it is up-to-date, and finally traverse a potentially large list of revoked permits each time the permit is used.

[0209] Preferably, revocation of a permit is irreversible. Temporary revocation of a subset of the permits of a permit can be done using revoking and adding extensions as described under the "Extensions" heading above.

[0210] Revoking a permit can be thought of as optionally revoking a subset of the child permits, where the subset is all of the permits. In other words, revoking a permit also revokes all of the permits, so that the permit no longer has permission to do anything. Revoking a smaller subset of permissions is preferably done by revoking extensions, as described below under the heading "Revoking Extensions."

[0211] A permit can preferably only send messages directly to computing modules associated with its child permits. To revoke all descendants, a permit must send revocation messages to all its children, and each child must do the same. Thus, the revocation process is recursive.

[0212] Preferably, the child permit verifies that the revocation message was sent by its parent. When used with the embodiment described with reference to FIG. 1, verifying that it is the parent computing module that revoked the parent includes checking that the caller's "instanceId" matches the parent's instanceId stored in the data instance of the child permit. Advantageously, since each permit computing module is part of the secure processing environment 108, this check is sufficient to determine that the caller has the appropriate authorization to perform the revocation. Optionally, further security is required if the call is from outside the secure processing environment and / or if an alternative system to that described in FIG. 1 is used. The revocation message also includes a cryptographic signature generated by signing parts of the message. The permit to be revoked can then be cryptographically verified that the sender of the message is the parent permit (and / or, optionally, the holder of the parent permit) by checking against the parent's public key and / or by using a further service that provides verification that the cryptographic signature matches the public key of a given instanceId. Optionally, this is done using the methods described under the heading "Verifying the Signature."

[0213] Before this method 500 is performed, the sender (owner of the parent permit) creates a request that includes a permit indicator for the permit to be revoked. Optionally, the request includes an indication as to when the child permit is to be considered revoked. Optionally, the request includes an indication as to the particular extension that is to be revoked. Revoking extensions is described in more detail under the heading "Revoking Extensions."

[0214] Preferably, when an extension is provided, the descendants of the child license are not revoked.

[0215] Preferably, the request has a body following the following format:

number

[0216] Preferably, a similar process is used here as with the child license creation request of creating a JSON object, stringifying it (or using canonicalization during the signing and verifying steps), and then signing the data.

[0217] Preferably, the revokeContents element includes a license identifier, and optionally a revocation time and the extensions to be revoked. An exemplary format of revokeContents is as follows:

number

[0218] The caller sends a request to the parent of the permit that they wish to revoke.

[0219] Upon receiving the request, the parent permit verifies that it has not itself been revoked, 504. If the parent has been revoked, then all its children have already been revoked and processing time can be saved by not performing further steps of the method.

[0220] Preferably, there is a check that the sender of the revoked child permit is the holder of the parent permit (506). Preferably, this is done by verifying that the request was signed by the permit holder (or at least by someone who holds a private key associated with the parent permit's public key and thus presumably has the permit holder's permissions). Preferably, this signature verification is done using a public key stored in the permit data instance.

[0221] Preferably, there is a check that the provided child license identifier is in fact a child of the parent license 508. As noted above, only a parent can revoke its children.

[0222] Once these checks are complete, the parent permit generates and sends a further revocation request to the child permit, optionally including the time to revoke the child permit, and optionally including the extensions to be revoked.

[0223] Preferably, the child permit checks that the sender of the further revocation request is from the parent permit. This can be done in a number of ways, including verifying that the address at which the request was received is an internal-only address that can only be used by computing modules in the secure processing environment, or verifying that a cryptographic signature associated with or attached to the further revocation request was correctly signed by the parent permit. Those skilled in the art will appreciate that other methods of identifying the function caller are possible.

[0224] Preferably, the child permit is checked to see if it has been revoked. Preferably, this check is done by the child permit itself, but the parent permit may also perform this check. If the child permit has already been revoked, no further action is required.

[0225] Preferably, the child is revoked 514. More preferably, the child permit is revoked by adding data to a data instance of the child permit indicating that the child is revoked. More preferably, the data is a time value after which the permit is no longer considered valid.

[0226] If no time is provided in the revocation request, the current time is determined and the current time is stored against the "revoked" element of the child permit data instance.

[0227] Once these time values ​​are set, the permit will be considered revoked, or will be considered revoked when the time set in the revoked field has passed.

[0228] When a child permit is revoked, it then builds similar further revocation requests for each of its children (which are the grandchildren of the original parent permit). These further revocation requests cause each grandchild permit to take the same step of setting the same time in their "revoked" element, and trigger the revocation of their children, and so on. Thus, by using the same method recursively for different levels of children, the entire branch of permits starting from the original child permit is revoked. This ensures that when a permit is revoked, all of its children are also revoked.

[0229] The child permit responds to the parent permit that it has been revoked. Optionally, each permit waits until all of its children have been revoked and the parent permit receives a message indicating that all of the child's descendants have also been revoked.

[0230] The parent permit then generates and provides a response 518 to the sender of the original revocation request.

[0231] Those skilled in the art will appreciate that some of these steps may be considered optional depending on the usage context, especially the security context. For example, the parent permit may not need to perform many of the validation steps (such as verifying the signature or checking if the namespace is correct) if the request is received from a sender known to be configured to generate only valid requests.

[0232] Additionally, while steps are presented herein in a particular order, this is for ease of explanation only, as one of ordinary skill in the art will appreciate that some of these steps may occur in any order or simultaneously.

[0233] Undoing the extension As mentioned above, the method for revoking an extension is similar to the method for revoking a permit 500, so only the differences between the two methods will be described.

[0234] To revoke an extension rather than the permit itself, the request from the parent permit holder must include the name of the extension. An example request might contain a stringified version of the following object (where iPhone is the name of the extension to be revoked):

number

[0235] Another modification in the permit revocation method 500 is that instead of revoking the permit (514), only the extension is revoked. This is done by finding the extension data structure and adding data to a "revoked" field to indicate that the extension has been revoked. Preferably, time data is added to the revoked field. As with permit revocation, the time value is the value received in the revocation request (if present) or the current time (if no time value is present). Preferably, if a validity range is defined, the end of the validity period is set to the same time value.

[0236] Instead of revoking the children (514), only the extension is revoked (520).

[0237] As noted above, when only extensions are revoked, no further or child permits are revoked, and therefore no additional revocation messages are generated and sent (516) for child permits.

[0238] Adding an extension In one embodiment, a method is provided for adding extensions to a permit (preferably as described under the heading "Extensions"). Preferably, extensions can only be added by the permit's parent and / or the parent permit holder. A permit cannot add extensions to itself without confirmation from the parent permit, valid transmission from the parent permit, and / or valid transmission from the parent permit holder.

[0239] Preferably, the licensee of the license to be extended (optionally referred to as the child licensee in this exemplary embodiment) creates an additional public / private key pair for the new extension. Alternatively, the same public key as the default / initial extension is used.

[0240] Preferably, when adding an extension, a similar method is used to create a new child permit. In particular, the parent permit holder creates a similar permitContents structure that is stringified and signed. The resulting request body might look like this:

number

[0241] Note that the structure is the same, except that the "extend" name is used instead of "createChild". A pre-stringified extend object optionally has a JSON structure and has the following format:

number

[0242] Thus, the request preferably includes the child permit identifier, the extension name, the public key for the new extension, and the extension's permissions. Upon receiving the request, the parent permit performs the same or similar validation steps as creating a permit, including verifying that the parent is still valid (not revoked and within its validity range), verifying that the signature was correctly signed by the holder of the parent permit, verifying that the namespace of the permit does not exceed that of the parent permit, and that the validity range is within the validity range of the parent permit.

[0243] Preferably, any one or more of the following further checks are performed: (A) the total levels that a parent and / or child may have; (B) the maximum number of children that a parent or child may have; and (C) The child's validity has the same or a narrower scope compared to the parent.

[0244] Note that all of these checks are to ensure that the new extension does not contain broader or more features than the parent license.

[0245] Regarding (A) above, if the child contains $.children.levels, it must be smaller than the parent. Regarding (B) above, if the child contains $.children.max, it must fit within the envelope of the parent's array (if there is one) except for the first element. Note that if the parent has no levels, it means there is no limit. Regarding (C) above, $.valid.{before,after} must be at least as narrow as the parent. There is a further check that the child permit to be extended is actually a child of the parent. This is done by ensuring that the child permit identifier is in the list of children stored in the parent permit's data instance.

[0246] A further extension add request is then created and sent to the computing module associated with the child permit. Preferably, the child permit validates the received request in a manner similar to the embodiment describing revoking a permit or extension. Preferably, the child permit validates that the request was received from a parent permit. Preferably, the child validates that the request was received from within the secure computing environment. Preferably, the child validates that it is not currently revoked.

[0247] Preferably, there is a check that the maximum number of extensions is not exceeded by adding a new extension. Preferably, this is done by the child permit itself. Alternatively, this is done by the parent permit using the "Verify Permit" described below under the same heading.

[0248] Once the validation is complete, the new extension is added to the child license, preferably following the following statement:

number

[0249] The child returns an appropriate success / failure message to the parent, which returns an appropriate success / failure message to the original sender of the request.

[0250] Checking Permissions In one embodiment, a method is provided for verifying authorization. Preferably, the method is provided to any party as an API. More preferably, the method is provided via a "query" endpoint, as described above under the heading "Interacting with Authorizations."

[0251] A caller of the method preferably makes a request including a permission identifier and permission verification data. Optionally, the request includes an extension of the permission to be verified. Optionally, multiple permissions are verified.

[0252] A request is sent that includes the permissions to be verified.

[0253] Preferably, a check is made to determine if the permit has been revoked, and if so, the permit responds with an error or invalid message indicating that the permit and / or authorization is invalid.

[0254] Preferably, the permission checking data includes the name of the permission to be checked. More preferably, the permission checking data includes an expression. Preferably, the permission checking data includes an expression which, when evaluated, operates on a value associated with the permission name (the value of the name-value pair). Preferably, the expression is in the form of an expression language. Preferably, the expression language provides a permission lookup pattern which the permission implements, thereby validating the request against the appropriate permission(s).

[0255] Preferably, the expression language includes features that allow the permission to be queried on various features of the permission's name and value. Various features of the expression language and examples are provided below. Preferably, the representation is provided in JSON format.

[0256] The permit evaluates the expression against its own permit data instance, and therefore against the relevant permit(s), and then provides the result to the caller.

[0257] Although a particular expression language is described below, those skilled in the art will appreciate that other expression languages, such as regular expressions, may also be used.

[0258] Optionally, the request includes an indication of the language of the extension, so the caller has flexibility of expression in the language they wish to use.

[0259] Preferably, the expression is an object with a single property that defines the top-level operator. If it is a binary operator, then the operands are defined as values ​​of the operator property in an array of objects. These objects may be further binary operators, unary operators that take a single operand object, leaf terms that take a simple value, or just simple values. Exemplary expressions including the expressions "not", "eq", and "permission" are shown below:

number

[0260] In simple terms, this is an expression that checks whether the permission "com.acme.customer.type" is not equal to "wholesale".

[0261] Additionally, there are expressions for determining whether a permit (or extension) has a particular permission. Basic terms in the expression language include "permission" and "has". [Table 4]

[0262] Preferably, some comparison operators that can be used in the expressions are: equal to, not equal to, less than, less than or equal to, greater than, and greater than or equal to. [Table 5]

[0263] Preferably, the following query operators are for use in string matching: contains, starts with, matches, ends. [Table 6]

[0264] Preferably, several unary operators can be used in the expressions: not, minus, length. [Table 7] Note that "falsy" means false, 0, or the empty string.

[0265] Preferably, several Boolean operators can be used in the expressions: and, or. [Table 8] Note that "truthy" means true, a non-zero number, or a non-empty string.

[0266] Preferably, the following mathematical query operators can be used to construct the expressions: add, subtract, divide, modulus. [Table 9]

[0267] Preferably, the expression can be enhanced with set query operators: includes, in. [Table 10] Note that the two are nearly identical, they just differ in the order of their operands.

[0268] Below we provide some example expressions and their associated easy-to-understand explanations of what they check.

number

number

number

number

[0269] Obtaining permission In one embodiment, a method is provided for obtaining one or more permissions. Preferably, the method is provided to any party as an API. More preferably, the method is provided via a "query" endpoint, as described above under the heading "Interacting with Permissions."

[0270] The caller of the method preferably creates a request that includes at least the identifiers of the permits that he or she is interested in. The request is sent to the relevant permits.

[0271] If only one permission is of interest, the caller of the method preferably creates a request that includes the name of the permission in which it is interested.

[0272] Optionally, the request includes an extension, if one is provided, the particular extension of interest is used.

[0273] Upon receiving a request, the permit responds with the contents of the permissions if a specific permission is provided, or with the complete list of permissions if requested.

[0274] Optionally, no method is provided to obtain all the permissions associated with a permit (and / or permit extensions). By not providing such a method, the security of the system is improved since a third party cannot see everything the permit holder is authorized to do, which could leak sensitive information. This can also be described as only providing services or methods that require the caller to request specific permissions.

[0275] Validity Check In one embodiment, a method is provided that allows an external party to check if a given permit (and optionally its ancestors) has been valid for some time. Preferably, the method is provided to any party as an API. More preferably, the method is provided via a "query" endpoint, as described under the heading "Interacting with Permits" above.

[0276] The caller of the method preferably sends a request including the license identifier. Optionally, the request includes any one or more of the following: The time at which the validity is checked (if no time is provided, the current time is used), Ancestor identifiers (if any) to determine the number of ancestors whose validity should be checked; and / or · The extension whose validity should be checked.

[0277] Preferably, when an extension is provided, the ancestors are not checked.

[0278] Preferably, the ancestor identifier is one of the following: no, parent, grandparent, great-grandparent, root.

[0279] Preferably, the request is received by a computing module associated with the permit being checked.

[0280] When a request is received, the permit is checked to see that the provided time (which will be the current time if no specific time is provided) is within the permit validity range. The validity range is defined as being within the special permit "$.valid.before" and "$.valid.after" and "revoked" elements of the permit instance data structure. If an extension is provided in the request, the same fields are checked within the given extension, if present. If the extension does not exist, an error is returned.

[0281] If the request contains an ancestor identifier other than "no", a further validity request is generated and sent to the parent permits, which are identified according to the parent element stored in each permit's data instance. This request is constructed such that the appropriate levels of the permit tree are traversed. Since each permit only knows about the level above it, each parent sends further validity requests, traversing the relevant parts of the permit tree structure. The permit whose validity has been checked receives an indication from its parent as to the validity of all requested parent permits.

[0282] The permit responds with an indication as to the validity of the permit. The response also includes an indication as to the validity of any ancestors requested.

[0283] Verifying the signature In one embodiment, a method is provided for verifying that a message has been signed by the holder of a given permit. Preferably, the method is provided to any party as an API. More preferably, the method is provided via a "query" endpoint, as described above under the heading "Interacting with Permits."

[0284] The caller of the method preferably sends a request including the message to which the signature has been applied, the signature itself, and an identifier of the permit. Optionally, the identifier of the permit is included in a header and / or address of the request, and the signature and the message are provided in the body.

[0285] Optionally, an extension string is also provided. If an extension string is present in the request, the holderPubKey for the particular extension is used as opposed to the "default" extension.

[0286] The recipient of the request finds the appropriate holderPubKey and then verifies that the signature was signed by the holder of the associated private key (which should only be held by the holder of the permit). Finding the appropriate holderPubKey preferably requires obtaining the correct permit data instance and then the appropriate extension (if used, if not a "default" extension is used). Preferably the request is received at a permit computing module associated with the identifier (and thus the appropriate permit data instance), with an address including the permit identifier, as described under the heading "Interacting with Permits" above.

[0287] Preferably, verifying the signature involves hashing the message, decrypting the signature using the holderPubKey to be verified, and comparing the two. If they are the same, then the signature was generated using only the private key associated with the holderPubKey. More preferably, the signature, and thus the verification of the signature, uses ECDSA signatures and the ECDSA signature algorithm as described in RFC 6979.

[0288] The result of the verification is returned to the caller in the response. Preferably, the response is also signed to prove that the response originated only from the specified certificate computing module. More preferably, the signature is provided in the header of the response and the verification result is provided in the body.

[0289] session Optionally, in one embodiment, interactions with the permit, such as those listed under the heading "Interactions with Permits" above, occur after session authorization has occurred.

[0290] A licensee may request a session key / token by calling the ... / session endpoint (or ... / send or ... / query). An example session request header may include the following:

number

[0291] When such a request is made, the authorizer is called with the appropriate endpoint (e.g., session) provided to them. The authorizer should receive a request that contains the following signed command:

number

[0292] Preferably, the "instruction" object is stringified so that the signature is applied to a known data structure as described herein.

[0293] The timestamp is preferably within about one minute of the current time to prevent replay attacks, and the period is the desired length of the session in seconds. The permit verifies the signature (using appropriate extensions, if provided) and MAY set the session permit to any value less than or equal to the desired period.

[0294] If parent is present, the request is from a parent license holder rather than the license holder. In this case the signature must be checked against the parent's public key. Preferably this check is done using the "Verify Signature" method, as described above under the heading "Verifying Signature".

[0295] When parent is present in the request, any extensions are ignored.

[0296] Optionally, a successful response may look like this:

number

[0297] If the request is rejected, for example because of a bad signature, the response might be:

number

[0298] If the session period is less than the minimum or greater than the maximum (eg, 20 seconds to 1 week, as determined by the certificate configuration and / or the secure processing environment configuration), then no session key is created.

[0299] If the session period is within an acceptable range, a session key is created and returned in the response header.

[0300] If the request is correctly signed but the period is too short, the period may be increased up to a minimum value.

[0301] Safety features Optionally, in one embodiment, a further security endpoint is provided.

[0302] An attacker may wish to generate fake credentials to fool observers. One way to mitigate this attack is to inspect the headers of responses received from the credentials. All genuine credentials have the same well-known process identifier, as described in "Overview of an Exemplary System." This process identifier is provided in the header of each message.

[0303] If additional security is required, cryptographic evidence can also be provided in the response: the certificate's public key is thus available from the / security endpoint allowing verification of any responses signed by the certificate.

[0304] An exemplary request may include the following headers:

number

[0305] A response to such an API request optionally has the following form:

number

[0306] The public key therefore allows a third party to verify the signature using their own device.

[0307] Computing Module 6, an exemplary simplified block diagram of a computing device 2600 that may be used to implement at least one embodiment of the present disclosure is provided. In various embodiments, the computing device 2600 may be used to implement any of the systems or methods illustrated and described above. For example, the computing device 2600 may be configured to operate the secure computing environment 108 and host several computing modules 102, 104, 106. The computing device 2600 may be configured to be a permit-carrying device associated with a permit holder. The computing device 2600 may be configured to be a computing module 102, 104, 106 itself. Thus, the computing device 2600 may be a portable computing device, a personal computer, a server, a collection of servers, or any electronic computing device.

[0308] When the computing device 2600 provides or is part of a secure computing environment 108, it also provides a system and method for the computing modules 102, 104 operating therein to communicate with each other. Optionally, this is provided through its own internal DNS and routing system. Optionally, this is provided through IPC calls.

[0309] 6, the computing device 2600 may include one or more processors (collectively labeled 2602) with one or more levels of cache memory and a memory controller that may be configured to communicate with a storage subsystem 2606, including a main memory 2608 and persistent storage 2610. The main memory 2608 may include dynamic random access memory (DRAM) 2618 and read only memory (ROM) 2620, as shown. The storage subsystem 2606 and cache memory 2602 may be used for storage of information, such as details associated with transactions and blocks as described in this disclosure. The processor(s) 2602 may be utilized to provide the steps or functions of any embodiment as described in this disclosure.

[0310] The processor(s) 2602 may also be in communication with one or more user interface input devices 2612 , one or more user interface output devices 2614 , and a network interface subsystem 2616 .

[0311] The bus subsystem 2604 may provide a mechanism for allowing various components and subsystems of the computing device 2600 to communicate with each other as intended. Although the bus subsystem 2604 is shown generally as a single bus, alternative embodiments of the bus subsystem may utilize multiple buses.

[0312] The network interface subsystem 2616 may provide an interface to other computing devices and networks. The network interface subsystem 2616 may act as an interface for receiving data from other systems and transmitting data from the computing device 2600 to other systems. For example, the network interface subsystem 2616 may allow a data technician to connect the device to a network so that the data technician can transmit data to and receive data from the device even if the data technician is in a remote location, such as a data center.

[0313] The user interface input devices 2612 may include one or more user input devices, such as a keyboard, a pointing device, such as an integrated mouse, trackball, touchpad, or graphics tablet, a scanner, a barcode scanner, a touch screen integrated into a display, a voice recognition system, an audio input device, such as a microphone, and other types of input devices. In general, use of the term "input device" is intended to include all possible types of devices and mechanisms for inputting information into the computing device 2600.

[0314] The one or more user interface output devices 2614 may include a display subsystem, a printer, or a non-visual display such as an audio output device, or the like. The display subsystem may be a cathode ray tube (CRT), a flat panel device such as a liquid crystal display (LCD), a light emitting diode (LED) display, or a projection or other display device. In general, use of the term "output device" is intended to include all possible types of devices and mechanisms for outputting information from the computing device 2600. The one or more user interface output devices 2614 may be used, for example, to present a user interface to facilitate user interaction with applications executing the described processes and variations therein, when such interaction may be appropriate.

[0315] The storage subsystem 2606 may provide a computer-readable storage medium for storing basic programming and data configurations that may provide functionality of at least one embodiment of the present disclosure. Applications (programs, code modules, instructions), which when executed by one or more processors, may provide functionality of one or more embodiments of the present disclosure, may be stored in the storage subsystem 2606. These application modules or instructions may be executed by one or more processors 2602. The storage subsystem 2606 may additionally provide a repository for storing data used in accordance with the present disclosure. For example, the main memory 2608 and the cache memory 2602 may provide volatile storage for programs and data. The persistent storage 2610 may provide persistent (non-volatile) storage for programs and data and may include flash memory, one or more solid state drives, one or more magnetic hard disk drives, one or more floppy disk drives with associated removable media, one or more optical drives (e.g., CD-ROM or DVD or Blu-ray) drives with associated removable media, and other similar storage media. Such programs and data may include programs for performing the steps of one or more embodiments as described in this disclosure, as well as data associated with transactions and blocks as described in this disclosure.

[0316] The computing device 2600 may be of various types, including a portable computing device, a tablet computer, a workstation, or any other device described below. Additionally, the computing device 2600 may include another device that may be connected to the computing device 2600 via one or more ports (e.g., USB, headphone jack, lightning connector, etc.). The device that may be connected to the computing device 2600 may include multiple ports configured to accept fiber optic connectors. Thus, the device may be configured to convert optical signals into electrical signals that may be transmitted through ports that connect the device to the computing device 2600 for processing. Due to the ever-changing nature of computers and networks, the description of the computing device 2600 shown in FIG. 6 is intended only as a specific example to illustrate a preferred embodiment of the device. Many other configurations are possible having more or fewer components than the system shown in FIG. 6.

[0317] The various methods described above may be implemented by a computer program. The computer program may include computer code configured to instruct a computer to perform the functions of one or more of the various methods described above. The computer program and / or code for performing such methods may be provided to an apparatus such as a computer on one or more computer readable media, or more generally on a computer program product. The computer readable medium may be transitory or non-transitory. The one or more computer readable media may be, for example, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, or a propagation medium for data transmission, for example, for downloading code via the Internet. Alternatively, the one or more computer readable media may take the form of one or more physical computer readable media, such as a semiconductor or solid state memory, a magnetic tape, a removable computer diskette, a random access memory (RAM), a read-only memory (ROM), a rigid magnetic disk, and an optical disk such as a CD-ROM, a CD-R / W, or a DVD.

[0318] In one implementation, the modules, components, and other features described herein may be implemented as individual components or integrated into the functionality of a hardware component such as an ASIC, FPGA, DSP, or similar device.

[0319] In one implementation, the modules described herein may be implemented as computing processes, such as processes running on a monolithic server, microservices, lambda functions, etc. Access to the computing modules may be provided using APIs as described herein. These modules optionally include sub-modules configured to send and receive data to and from other computing modules and / or computing devices. Preferably, the modules comprise a memory for temporary and / or persistent storage of data. In particular, the memory is configured to persistently store (for later access) the permit data instance of the permit itself.

[0320] A "hardware component" or "hardware module" is a tangible (e.g., non-transient) physical component (e.g., a set of one or more processors) capable of performing specific operations and may be configured or arranged in a specific physical manner. A hardware component may include dedicated circuitry or logic that is permanently configured to perform specific operations. A hardware component may be or include a dedicated processor, such as a field programmable gate array (FPGA) or ASIC. A hardware component may also include programmable logic or circuitry that is temporarily configured by software to perform specific operations.

[0321] Thus, the phrase "hardware component" or "hardware module" should be understood to encompass a tangible entity that may be physically constructed, permanently configured (e.g., hardwired), or temporarily configured (e.g., programmed) to operate in a particular manner or to perform particular operations described herein.

[0322] In addition, the modules and components may be implemented as firmware or functional circuitry within a hardware device. Further, the modules and components may be implemented in any combination of hardware devices and software components, or solely in software (e.g., code stored or otherwise embodied in a machine-readable medium or transmission medium).

[0323] Unless otherwise indicated, and as will be apparent from the following description, descriptions utilizing terms such as "determining," "providing," "calculating," "computing," "identifying," "combining," "establishing," "sending," "receiving," "storing," "estimating," "checking," "obtaining," and the like throughout the description will be understood to refer to the actions and processes of processes, functions, microservices, computer systems, or similar electronic computing devices that manipulate and convert data represented as physical (electronic) quantities in the registers and memory of a computer system into other data similarly represented as physical quantities in the computer system memory or registers or other such information storage, transmission or display devices.

[0324] The term "comprising" as used in this specification and the claims means "consisting at least in part of." In interpreting each statement in this specification and the claims containing the term "comprising," there may be features present other than the feature or features preceded by the term. Related terms such as "comprise" and "comprises" should be interpreted in the same manner.

[0325] Reference to a range of numbers disclosed herein (e.g., 1-10) also encompasses reference to all rational numbers within that range (e.g., 1, 1.1, 2, 3, 3.9, 4, 5, 6, 6.5, 7, 8, 9, 10), and any range of rational numbers within that range (e.g., 2-8, 1.5-5.5, 3.1-4.7), and thus all subranges of every range explicitly disclosed herein are intended to be expressly disclosed hereby. These are merely examples of what is specifically intended, and all possible combinations of numerical values ​​from the lowest value to the highest value recited should be considered to be expressly set forth in this application as well.

[0326] As used herein, the term "and / or" means "and" or "or" or both.

[0327] As used herein, "(s)" following a noun refers to the plural and / or singular form of that noun.

[0328] The singular reference of an element does not exclude the plural reference of such elements and vice versa.

[0329] It should be understood that the above description is intended to be illustrative, not restrictive. Many other implementations will become apparent to those skilled in the art upon reading and understanding the above description. Although the present disclosure has been described with reference to certain exemplary implementations, it will be recognized that the present disclosure is not limited to the described implementations, but can be practiced with modification and alteration within the scope of the appended claims. Thus, the specification and drawings should be considered in an illustrative, rather than a restrictive, sense. The scope of the present disclosure should therefore be determined with reference to the appended claims, along with the full scope of equivalents to which such claims are entitled.

Claims

1. 1. A computer-implemented method for generating a permit, comprising: receiving a request including a first permit identifier, the first permit identifier identifying a first permit; obtaining first permit data based on the first permit identifier, the first permit data including data indicative of at least one permission, the at least one permission providing an indication of one or more actions that a holder of the first permit may take and / or what the holder of the first permit is authorized to do; Including, the request is a request to create a further permit, the request including data indicative of the further permit; method.

2. validating the first permit; generating said further permit based on said data indicative of said further permit; recording a reference to said further permit in said first permit data such that said further permit is recorded as a child of said first permit; The method of claim 1 further comprising:

3. The method of claim 2 , wherein the step of verifying the first permit data includes determining whether the first permit has been revoked.

4. 4. The method of claim 3, wherein determining whether the first permit has been revoked comprises checking a revoked field in the first permit data.

5. 5. The method of claim 4, wherein determining whether the first permit has been revoked comprises comparing the first time stored in the revoked field with a current time.

6. The method of claim 1 , further comprising the step of verifying that the first permit is capable of creating child permits.

7. The step of verifying that the first permit can create a child permit comprises: verifying that the maximum number of child permits associated with said first permit has not been exceeded; verifying that the maximum depth of child permits associated with said first permit has not been exceeded; 7. The method of claim 6, comprising any one or more of:

8. The method of claim 1 further comprising the step of verifying the data indicative of the further authorization.

9. The request further includes a signature, and the step of verifying the data indicative of the further authorization comprises: verifying that the signature is valid and was signed using the private key of the first licensee. The method of claim 8, comprising:

10. The step of verifying the data indicative of the further authorization comprises: verifying that the validity range of said further permit is within the validity range of said first permit. The method of claim 8, comprising:

11. The step of verifying the data indicative of the further authorization comprises: verifying that the one or more permissions of said further permit are within the range of permissions that the parent permit is permitted to create. The method of claim 8, comprising:

12. The method of claim 11 , wherein the one or more permissions of the further permit are included in the request.

13. the step of verifying that any permissions of the further permit are within the range of permissions that the parent permit can create, determining one or more namespaces that the parent permit is authorized to create; determining the one or more namespaces of the one or more permissions of the further permit; determining that the one or more namespaces of the one or more permissions of the further permit are the same as or are prefixed by the one or more namespaces that the parent permit is permitted to create; The method of claim 11.

14. said step of generating said further permit comprising: instantiating further permit data based on the permit, the further permit data including a parent permit value set to the first permit identifier. The method of claim 2.

15. The method of claim 1 , further comprising the step of providing a further permit identifier to the sender of the request.

16. The method of claim 15 , wherein only the further permit identifier is provided to the sender of the request.

17. The method of claim 1 , wherein the data indicative of the at least one permission is an object including at least one name-value pair.

18. 18. The method of claim 17, wherein the name of the name-value pair is represented by a string and the value of the name-value pair is represented by a string and / or at least one further name-value pair.

19. The method of claim 18 , wherein the string is arbitrary and / or generated by a user.

20. The method of claim 18 , wherein the value is arbitrary and / or generated by a user.

21. The method of claim 1 , wherein the request is received via an API that is provided only to computing modules that belong to a secure computing environment.

22. 22. The method of claim 21, wherein a computing module that performs the method of claim 1 is part of the secure computing environment.

23. The method of claim 1 , wherein the first permit is part of a hierarchy of permits.

24. 24. The method of claim 23, wherein the first permit data includes data indicative of a parent permit.

25. 24. The method of claim 23, wherein the first permit data includes data indicative of a child permit.

26. The method of claim 1 , wherein the first permit data includes an indication as to whether further permits that are children of the first permit may be created.

27. The method of claim 1 , wherein the first permit data includes at least one namespace, each namespace defining a subset of permissions that a child of the first permit may have.

28. The method of claim 1 , wherein the first license data includes an indication of a maximum depth of descendants that the first license can have.

29. The method of claim 1 , wherein the first permit data includes a maximum number of child permits that the first permit can have.

30. The method of claim 1 , wherein the first permit data comprises an array indicating a maximum number of descendant permits that the first permit can have at different depths.

31. The method of claim 1 , wherein the first permit data includes a time indicating from when the permit is valid.

32. The method of claim 1 , wherein the first permit data includes a time indicating until when the permit is valid.

33. The method of claim 1 , wherein the first permit identifier obscures the identity of the holder of the first permit.

34. The method of claim 1 , wherein the first license identifier is a pseudo-randomly generated string.

35. sending data indicative of said request for storage in a log. The method of claim 1 further comprising:

36. transmitting data indicative of said request for inclusion on a blockchain. The method of claim 1 further comprising:

37. 36. The method of claim 35, wherein the data indicative of the request is configured to provide an indication regarding the status of the permit.

38. 38. The method of claim 37, wherein the set of data indicative of previous interactions with the permit is configured to provide an indication of a current state of the permit.

39. 1. A system comprising: a first computing module configured to generate a first request; a certificate computing module configured to perform the method of any one of claims 1 to 38; A system comprising:

40. 40. The system of claim 39, wherein the authorization computing module resides in a secure computing environment.

41. 41. The system of claim 40, wherein the first computing module is a further authorised computing module, the further authorised computing module belonging to the secure computing environment.

42. 40. The system of claim 39, wherein the first computing module is a user device.

43. 39. A device comprising a processor and a memory, the memory including executable instructions that, upon execution by the processor, cause the device to perform the computer-implemented method of any one of claims 1 to 38.

44. 39. A non-transitory computer-readable storage medium comprising computer program code instructions executable by a computer to perform the method of any one of claims 1 to 38.

45. 39. A computer program comprising instructions which, when executed by a computer, cause the computer to carry out a method according to any one of claims 1 to 38.

Images