System and method of evaluating delegation of authority from delegator to delegate

Abstract

A method of evaluating delegation of authority from a delegator to a delegate in a distributed access control system for governing access to digital data resource. The method comprising steps of receiving a plurality of leaf policies, where each leaf policy specifies actions and rules associated with access control, each leaf policy requires authority verification. The method comprises receiving a plurality of DoAPs, each DoAP specifies characteristics that define policy identification, and each DoAP, except for root DoAP, requires authority verification. The method comprises checking for authority verification for each leaf policy and for each DoAP, generating plurality of recursive administration requests based on checking step until root DoAP reached and responding to each of plurality of recursive administration requests to ensure that each DoAP resolved, thereby evaluating delegation of authority in the distributed access control system, where the responding is carried out in reverse order, starting from root DoAP.

Description

SYSTEM AND METHOD OF EVALUATING DELEGATION OF AUTHORITY FROM DELEGATOR TO DELEGATETECHNICAL FIELD

[0001] The present disclosure relates generally to the field of distributed access control systems; and more specifically, to a system and method for evaluating a delegation of authority from a delegator to a delegate in a distributed access control environment.BACKGROUND

[0002] In modern digital environments, access and usage control systems play a significant role in safeguarding digital resources, managing authorization rights, and ensuring secure interactions among users, systems, and data. The access control systems rely on policy-driven frameworks to determine the conditions under which subjects, such as individuals, organizations, or software programs, are granted access to the digital resources. The eXtensible Access Control Markup Language (XACML) standard is a widely adopted solution, offering a modular architecture with components, such as the policy decision point (PDP) , policy enforcement point (PEP) , policy administration point (PAP) , and context handler, which together manage policy evaluation and enforcement. The supporting elements, like the obligation service and policy information point (PIP) provide additional functionality for handling mandatory actions and contextual data.

[0003] Despite their strengths, the current access control frameworks face challenges in distributed and dynamic environments. The significant limitation lies in the assumption that all policies and their issuers are inherently trustworthy. This becomes problematic in scenarios involving multiple authorities with varying credibility levels or environments requiring compliance with localized regulations. While the XACML administration and delegation profile introduces delegation mechanisms, it fails to evaluate the trustworthiness of policy issuers or the issuance process, leaving gaps in security and policy effectiveness.

[0004] The recent advancements, such as extendible usage control (UCON+) framework with Trust-Level Evaluation Engine (TLEE) , incorporates trust evaluations into authorization policies, enabling dynamic decision-making in response to change conditions. However, the conventional solutions focus primarily on policy logic and fail to address the trustworthiness of issuers or the integrity of delegation paths. Consequently, there exists a technical problem associated with existing access and usage control systems having an inadequate evaluation of policy issuer trustworthiness, insufficient validation of delegation chain integrity, and limited adaptability to dynamic and distributed environments, compromising their effectiveness in ensuring secure and reliable access control.

[0005] Therefore, in light of the foregoing discussion, there exists a need for a comprehensive framework capable of evaluating trust across the entire authorization process.SUMMARY

[0006] The present disclosure provides a system and method for evaluating a delegation of authority from a delegator to a delegate in a distributed access control environment. The present disclosure provides a solution to the existing problem associated with access and usage control systems having an inadequate evaluation of policy issuer trustworthiness, insufficient validation of delegation chain integrity, and limited adaptability to dynamic and distributed environments, compromising their effectiveness in ensuring secure and reliable access control. An aim of the present disclosure is to provide a solution that overcomes at least partially the problems encountered in the prior art and provides an improved access control framework capable of evaluating trust across the entire authorization process. The improved framework incorporates trust conditions, thresholds, and a Trust-Level Evaluation Engine (TLEE) to ensure secure and optimized policy enforcement. By embedding trust evaluations throughout the entire authorization process, the framework enhances security, scalability, and flexibility, offering compatibility with alternative implementations, such as Role-Based Access Control (RBAC) systems, and addressing the evolving demands of modern digital ecosystems.

[0007] The object of the present disclosure is achieved by the solutions provided in the enclosed independent claims. Advantageous implementations of the present disclosure are further defined in the dependent claims.

[0008] In one aspect, the present disclosure provides a method of evaluating a delegation of authority from a delegator to a delegate in a distributed access control system for governing access to a digital data resource, the distributed access control system is distributed across a plurality of geographical locations. The method comprises receiving a plurality of leaf policies, wherein each leaf policy specifies actions and rules associated with access control in the distributed access control system, wherein each leaf policy requires an authority verification. The method further comprises receiving a plurality of delegation of authority policies (DoAPs) , wherein each DoAP specifies characteristics that define a policy identification, and wherein each DoAP, except for a root DoAP, requires an authority verification. The method further comprises checking for an authority verification for each leaf policy and each DoAP and generating a plurality of recursive administration requests based on the checking step until the root DoAP is reached. The method further comprises responding to each of the plurality of recursive administration requests to ensure that each DoAP is resolved, thereby evaluating a delegation of authority in the distributed access control system, wherein the responding is carried out in a reverse order, starting from the root DoAP.

[0009] The disclosed method evaluates the delegation of authority within a distributed access control system by leveraging a recursive policy-based framework. The method begins by receiving multiple leaf policies and DoAPs, each specifying rules, actions, and authority verification requirements. The authority verification is conducted for all policies, generating recursive administration requests that traverse through hierarchical DoAPs until the root DoAP is reached. The method ensures comprehensive validation of authority delegations while maintaining the integrity of the distributed system. By responding to the recursive requests in reverse order, starting from the root DoAP, the method guarantees accurate resolution of delegation paths, enabling robust and scalable access control management across geographically distributed resources.

[0010] In an implementation form, trust assessment conditions are incorporated into the plurality of DoAPs.

[0011] The integration of trust assessment conditions into DoAPs results in a more robust and dynamic authorization framework and enables real-time evaluation of trustworthiness, allowing for adaptive responses to changing risk profiles. This leads to improved decision-making processes and a significant reduction in potential vulnerabilities associated with authority delegation.

[0012] In a further implementation form, trust assessment conditions include trust attributes representing a delegate’s trustworthiness.

[0013] The integration of trust attributes leads to improved accuracy in trust assessments, enabling more informed and secure interactions. This results in enhanced system performance, as it allows for improved delegation of tasks and responsibilities based on the assessed trustworthiness of the delegate.

[0014] In a further implementation form, a trustworthiness path is selected based on the trust assessment conditions.

[0015] By systematically selecting the trustworthiness path, the method reduces the likelihood of errors and enhances the robustness of the distributed access control system, leading to improved outcomes in applications that rely on trust assessments.

[0016] In a further implementation form, the trust assessment conditions are checked at the checking step.

[0017] By implementing the checking step, the overall integrity of the distributed access control system is maintained, ensuring that decisions are based on reliable assessments. The implementation of the checking step leads to improved accuracy in trust assessments, resulting in a more robust and secure system. It enhances the reliability of outcomes by filtering out potentially harmful or untrustworthy actions, thereby fostering a safer operational environment.

[0018] In a further implementation form, the trust assessment conditions are incorporated into the root DoAP.

[0019] The incorporation of trust assessment conditions into the root DoAP ensures that only trustworthy entities are allowed to participate, thereby reducing the risk of fraud and increasing user confidence. Additionally, said incorporation facilitates improved risk management by providing a clear assessment of trustworthiness, which can lead to improved operational outcomes.

[0020] In a further implementation form, the root DoAP includes trust assessment conditions for each of the plurality of DoAPs.

[0021] The incorporation of the trust assessment conditions into the root DoAP is required for establishing a reliable trust chain. This ensures that only DoAPs that meet predefined trust criteria are recognized, thereby enhancing the overall security and integrity of the policy framework.

[0022] In a further implementation form, an additional policy, designated as a trust configuration policy, specifies the trustworthiness conditions required to allow a leaf policy to be considered admissible.

[0023] The establishment of the trustworthiness conditions mitigates the risk of adopting policies that may be unreliable or harmful, thereby fostering a more secure and trustworthy environment for policy application. Additionally, the establishment of the trustworthiness conditions ensures that only policies that meet predefined trustworthiness standards are utilized, thereby reducing vulnerabilities and enhancing the system's resilience against potential threats.

[0024] In a further implementation form, a leaf policy is considered to be admissible when it passes: (i) the trustworthiness condition assessment of the leaf policy; and (ii) a delegation evaluation.

[0025] By requiring the leaf policy to pass both assessments, the method ensures that only policies originating from trusted entities and valid delegation paths are considered for enforcement. This comprehensive approach reinforces the security and reliability of the distributed access control system, providing robust safeguards against unauthorized or untrustworthy policies in distributed environments.

[0026] In a further implementation form, the trust configuration policy is evaluated concurrently with the checking step (c) .

[0027] By performing these evaluations simultaneously, the method can be used to quickly identify any discrepancies or invalid links in the trust chain, thereby preventing the enactment of policies that lack proper authority. Additionally, by ensuring that the trust configuration policy is validated in conjunction with the authority checks, the distributed access control system minimizes the risk of implementing ineffective or unauthorized policies.

[0028] In a further implementation form, the trust configuration policy is evaluated prior to the checking step (c) .

[0029] By evaluating the trust configuration policy before the checking step (c) , the disclosed method effectively eliminates policies that fail to meet trust requirements, reducing unnecessary processing during authority verification. This proactive approach streamlines the overall policy evaluation process, ensuring that resources are dedicated to assessing only those policies that align with both trust and delegation standards.

[0030] In a further implementation form, a trust assessment policy is embedded into each leaf policy.

[0031] By embedding the trust assessment policy into each leaf policy enhances security and reliability by ensuring that all decisions made at the leaf level are informed by a standardized trust evaluation that allows for real-time assessments and dynamic adjustments based on changing data inputs. This leads to an increased efficiency in policy enforcement and a reduction in vulnerabilities, ultimately resulting in a more robust and resilient system.

[0032] In another aspect, there is provided a system comprising means adapted for carrying out all the steps of the method.

[0033] The system achieves all the advantages and technical features of the method after execution of the method.

[0034] In a yet another aspect, there is provided a computer program comprising instructions for carrying out all the steps of the method, when said computer program is executed on a computer system.

[0035] Additional aspects, advantages, features and objects of the present disclosure would be made apparent from the drawings and the detailed description of the illustrative implementations construed in conjunction with the appended claims that follow.BRIEF DESCRIPTION OF THE DRAWINGS

[0036] The summary above, as well as the following detailed description of illustrative embodiments, is better understood when read in conjunction with the appended drawings. For the purpose of illustrating the present disclosure, exemplary constructions of the disclosure are shown in the drawings. However, the present disclosure is not limited to specific methods and instrumentalities disclosed herein. Moreover, those skilled in the art will understand that the drawings are not to scale. Wherever possible, like elements have been indicated by identical numbers.

[0037] Embodiments of the present disclosure will now be described, by way of example only, with reference to the following diagrams wherein:

[0038] FIG. 1 illustrates a system for evaluating a delegation of authority from a delegator to a delegate in a distributed access control environment for governing access to a digital data resource, in accordance with an embodiment of the present disclosure;

[0039] FIG. 2 is a flowchart of a method of evaluating a delegation of authority from a delegator to a delegate in a distributed access control system for governing access to a digital data resource, in accordance with an embodiment of the present disclosure;

[0040] FIG. 3 is a diagram that represents a hierarchical structure and components of a Delegation of Authority Policy (DoAP) framework, in accordance with an embodiment of the present disclosure;

[0041] FIG. 4 is a flowchart that depicts a series of operations performed to make a final decision for an authorization request that triggers a leaf policy, in accordance with an embodiment of the present disclosure;

[0042] FIGs. 5A and 5B collectively, is a flowchart depicting a series of operations performed during delegation evaluation, in accordance with an embodiment of the present disclosure;

[0043] FIG. 6 is a flowchart that depicts a series of operations for an administrative request generation for a leaf policy, in accordance with an embodiment of the present disclosure;

[0044] FIG. 7 is a flowchart that depicts a series of operations for an administrative request generation for a Delegation of Authority (DoA) policy, in accordance with an embodiment of the present disclosure;

[0045] FIG. 8 is a diagram that represents a hierarchical structure and components of a DoAP incorporating trust conditions, in accordance with an embodiment of the present disclosure;

[0046] FIGs. 9A and 9B, collectively is a flowchart that depicts a series of operations of delegation evaluation process incorporating trust threshold determination and delegation chain evaluation, in accordance with an embodiment of the present disclosure;

[0047] FIGs. 10A and 10B, collectively is a flowchart that depicts a series of operations of root-level evaluation of trust for delegation path, in accordance with an embodiment of the present disclosure;

[0048] FIG. 11 is a flowchart that depicts a series of operations of an independent trust assessment decoupled from delegation evaluation, in accordance with an embodiment of the present disclosure;

[0049] FIG. 12 is a flowchart that depicts a series of operations of embedding trust assessment in leaf policies and decoupling from delegation evaluation, in accordance with an embodiment of the present disclosure;

[0050] FIG. 13 is a diagram that illustrates an implementation of a Trust Level Evaluation Engine (TLEE) as a subordinate to Policy Decision Point (PDP) within a distributed access control system, in accordance with an embodiment of the present disclosure;

[0051] FIG. 14 is a diagram that illustrates an implementation of TLEE as an optional auxiliary function for attribute value retrieval within a distributed access control system, in accordance with an embodiment of the present disclosure;

[0052] FIG. 15 is a diagram that illustrates Policy Information Point (PIP) with a generic trust evaluator within a distributed access control system, in accordance with an embodiment of the present disclosure;

[0053] FIG. 16 illustrates an exemplary implementation scenario of authority delegation in a multi-administrative authority system, in accordance with an embodiment of the present disclosure; and

[0054] FIG. 17 illustrates an exemplary implementation scenario of data access through consent-based delegation of authority, in accordance with an embodiment of the present disclosure.

[0055] In the accompanying drawings, an underlined number is employed to represent an item over which the underlined number is positioned or an item to which the underlined number is adjacent. A non-underlined number relates to an item identified by a line linking the non-underlined number to the item. When a number is non-underlined and accompanied by an associated arrow, the non-underlined number is used to identify a general item at which the arrow is pointing.DETAILED DESCRIPTION OF EMBODIMENTS

[0056] The following detailed description illustrates embodiments of the present disclosure and ways in which they can be implemented. Although some modes of carrying out the present disclosure have been disclosed, those skilled in the art would recognize that other embodiments for carrying out or practicing the present disclosure are also possible.

[0057] FIG. 1 illustrates a system for evaluating a delegation of authority from a delegator to a delegate in a distributed access control environment for governing access to a digital data resource, in accordance with an embodiment of the present disclosure. Referring to FIG. 1, there is shown a system 100 configured to operate in a distributed access control environment. There is shown a plurality of leaf policies 102 and a plurality of Delegation of Authority Policies (DoAPs) 104 which are provided as inputs to a processor 106 for authority verification. There is further shown that the processor 106 comprises an authority verifier 108 and a recursive administration request generator 110. Furthermore, there is shown a delegation evaluator 112 configured to respond to each administrative request, a memory 114, and a network interface 116. There is further shown a delegator 118, a delegate 120 and a digital data resource 122. In another implementation scenario, the authority verifier 108 and the recursive administration request generator 110 may be independent units and operate independently of the processor 106.

[0058] The system 100 may be referred to as a comprehensive framework designed to manage and enforce access to digital resources (e.g., the digital data resource 122) in a decentralized or hierarchical environment. The system 100 may be configured to validate access permissions through a combination of granular policy enforcement and trust-based delegation mechanisms, enabling dynamic and context-aware decision-making. Consequently, the system 100 ensures robust, scalable, and secure access management for diverse applications, such as cloud computing, IoT ecosystems, and enterprise networks. The system 100 may also be referred to either as a distributed access control system or a usage and control access system or an access control system.

[0059] Additionally, the system 100 incorporates recursive administration mechanisms to evaluate and resolve DoAPs through an iterative trust verification process, ensuring the integrity of the delegation chain from root to leaf. This innovative approach allows the system 100 to adapt to complex, distributed environments by seamlessly managing hierarchical policies and enforcing authority verification at every level. The system 100 may also be referred to either as a distributed access control system, a usage and control access system, or an access control system.

[0060] The plurality of leaf policies 102 may be referred to as a collection of discrete, fine-grained rules or policies that define specific conditions, actions, or constraints for managing access to or usage of digital data resources within a distributed access control system. Each leaf policy in the plurality of leaf policies 102 operates at an operational level, addressing particular use cases or scenarios, such as granting or denying access based on user attributes, resource type, or environmental conditions. The leaf policy is typically the end-point in a hierarchical policy structure and is evaluated to make decisions regarding individual requests. Together, the plurality of leaf policies 102 forms the foundation for enforcing granular control within the broader policy framework.

[0061] The plurality of DoAPs 104 may be referred to as a set of policies that govern the transfer of decision-making authority from one entity (e.g., the delegator 118) to another entity (e.g., the delegate 120) within a hierarchical or the distributed access control system (i.e., the system 100) . The plurality of DoAPs 104 defines the conditions, scope, and constraints under which an authority can be delegated, ensuring that only authorized entities can issue or enforce specific policies. The plurality of DoAPs 104 ensures that the delegation process is structured, traceable, and aligned with the overarching system objectives.

[0062] The processor 106 may include suitable logic, circuitry, and / or interfaces that is configured to execute instructions stored in the memory 114. Examples of the processor 106 may include, but are not limited to an integrated circuit, a co-processor, a microprocessor, a microcontroller, a complex instruction set computing (CISC) processor, an application-specific integrated circuit (ASIC) processor, a reduced instruction set (RISC) processor, a very long instruction word (VLIW) processor, a central processing unit (CPU) , a state machine, a data processing unit, and other processors or circuits. Moreover, the processor 106 may refer to one or more individual processors, processing devices, and a processing unit that is part of a machine.

[0063] The authority verifier 108 may be referred to as a component configured to validate the legitimacy of entities or policies within a system's delegation and decision-making processes. The authority verifier 108 ensures that each entity or policy being evaluated has the requisite authority to perform its designated role, as defined by the delegation of authority policies. The authority verifier 108 operates by examining attributes, such as the issuer's credentials, trustworthiness, adherence to delegation conditions, and compliance with the system's trust thresholds. The authority verifier 108 may be either a hardware module or a software module or a combination thereof.

[0064] The recursive administration request generator 110 is a component designed to facilitate the dynamic evaluation of delegation chains by generating successive administrative requests as required. When a policy or action requires validation of authority, the recursive administration request generator 110 creates and dispatches administrative requests to evaluate the admissibility of policies or delegates within the chain of delegation. The recursive administration request generator 110 ensures that all delegation paths are thoroughly validated, maintaining the integrity and consistency of the system's authority framework. The recursive administration request generator 110 may be a hardware module or a software module or a combination thereof.

[0065] The delegation evaluator 112 is configured to assess the validity and admissibility of delegation paths within a hierarchical or distributed policy framework. The delegation evaluator 112 operates by evaluating delegation of authority policies to ensure that the conditions, constraints, and trust criteria associated with each delegation step are satisfied. The delegation evaluator 112 processes inputs, such as administrative requests, attributes of delegates, and delegation policies, verifying that each link in the delegation chain meets the specified requirements.

[0066] The memory 114 may include suitable logic, circuitry, and / or interfaces that is configured to store machine code and / or instructions executable by the processor 106. Examples of implementation of the memory 114 may include, but are not limited to, an Electrically Erasable Programmable Read-Only Memory (EEPROM) , Random Access Memory (RAM) , Read Only Memory (ROM) , Hard Disk Drive (HDD) , Flash memory, a Secure Digital (SD) card, Solid-State Drive (SSD) , a computer readable storage medium, and / or CPU cache memory. A computer readable storage medium for providing a non-transient memory may include, but is not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing.

[0067] The network interface 116 may include suitable logic, circuitry, and / or interfaces that is configured to enable the system 100 to be connected to a variety of entities operating in the distributed access control environment. The network interface 116 serves as the access gateway, mediating requests by ensuring authorization and enforcement policies are applied. Examples of the network interface 116 may include, but are not limited to, access points in security frameworks, application programming interfaces (APIs) within cloud-based systems, and gateway modules in distributed computing environments.

[0068] The delegator 118 refers to an entity (e.g., a user, system, or authority) configured to grant specific permissions or authority to another entity, known as the delegate 120, within a distributed access control system (i.e., the system 100) . The delegator 118 is configured to define the scope and conditions of this delegation through policies, such as the DoAPs, which specify the actions and rules governing access to the digital data resource 122. The delegator 118 is also responsible for ensuring that the delegate 120 meets predefined trust assessment conditions and adheres to the overarching security and integrity requirements of the system 100. This ensures that the delegation chain remains secure, trustworthy, and compliant with the access control framework.

[0069] The delegate 120 refers to an entity (e.g., a user, system, or subordinate authority) that receives permissions or authority from the delegator 118 within a distributed access control system (i.e., the system 100) . The delegate 120 operates under the constraints and rules defined by the DoAPs, which specify the actions the delegate 120 is authorized to perform and the conditions that the delegate 120 must satisfy. The trustworthiness of the delegate 120 is assessed based on trust attributes and trust assessment conditions outlined in the DoAPs to ensure compliance with the system’s security and integrity requirements. By adhering to these policies, the delegate 120 plays a significant role in enabling secure and dynamic access to digital resources while maintaining the integrity of the delegation chain.

[0070] The digital data resource 122 refers to any data, file, database, or digital asset that is governed by the distributed access control system (i.e., the system 100) . The digital data resource 122 is subjected to strict access and usage controls defined by policies, such as the leaf policies and the DoAPs, which ensure only authorized entities can access or manipulate the digital data resource 122. The digital data resource 122 serves as a focal point of the system's security framework, with access permissions dynamically evaluated through trust-based mechanisms and delegation validations. By safeguarding the digital data resource 122, the system 100 ensures data integrity, confidentiality, and compliance with organizational or regulatory standards in decentralized environments.

[0071] In operation, there is provided the system 100 of evaluating a delegation of authority from the delegator 118 to the delegate 120 in a distributed access control system for governing access to the digital data resource 122, where the distributed access control system is distributed across a plurality of geographical locations. The system 100 enables seamless evaluation of authority delegation in the distributed access control framework, ensuring secure and dynamic management of permissions across geographically dispersed locations. By leveraging the combination of granular policy enforcement and trust-based delegation mechanisms, the system 100 validates the integrity of the delegation chain from the root to the leaf level. This approach ensures that the delegator 118 can securely transfer specific permissions to the delegate 120 while maintaining control and accountability over access to the digital data resource 122. Additionally, the system 100 is designed to operate efficiently in decentralized environments, making it ideal for applications in cloud infrastructures, global enterprise networks, and distributed IoT ecosystems.

[0072] The system 100 comprising the processor 106 configured to receive the plurality of leaf policies 102, where each leaf policy specifies actions and rules associated with access control in the distributed access control system, where each leaf policy requires an authority verification. The leaf policies represent granular directives, detailing the conditions for granting or denying access to digital data resources. Each leaf policy undergoes an authority verification process to confirm its legitimacy, ensuring that a trusted and authorized entity issues it. The requirement for authority verification in each leaf policy adds an additional layer of trust and accountability, ensuring that only authenticated and authorized entities can execute actions defined by these policies. This capability enables the system 100 to provide robust, scalable, and secure access management for distributed and dynamic environments, such as cloud infrastructures and enterprise systems.

[0073] The processor 106 is further configured to receive the plurality of delegation of authority policies (DoAPs) 104, where each DoAP specifies characteristics that define a policy identification, and wherein each DoAP, except for a root DoAP, requires an authority verification. Each DoAP specifies characteristics that define its policy identification, such as issuer details, issuance date, and the scope of delegated authority. This identification ensures that each policy is uniquely recognized and appropriately evaluated. The authority verification process is applied to every DoAP, except for the root DoAP, which is inherently trusted as the origin of the delegation chain. By systematically verifying each DoAP, the system 100 maintains the integrity of the trust chain, enabling secure and reliable enforcement of access control policies across the distributed environment.

[0074] The processor 106 is further configured to check for an authority verification for each leaf policy and for each DoAP. The authority verifier 108 is configured to perform the authority verification for each leaf policy and for each DoAP. The verification process involves assessing whether the issuer of a policy or delegation possesses the required authority, ensuring compliance with predefined trustworthiness and authorization criteria. By systematically checking both the leaf policies and the DoAPs, the system 100 establishes a robust trust chain that validates the legitimacy of all policies and delegations.

[0075] The processor 106 is further configured to generate the plurality of recursive administration requests based on the checking step until the root DoAP is reached. The recursive administration request generator 110 is configured to generate the recursive administration request. Each recursive administration request is triggered when a DoAP requires authority verification, initiating a step-by-step process that traces back through the chain of delegations. The process continues until the root DoAP, the ultimate trusted authority, is identified and validated. By generating and resolving these requests iteratively, the system 100 ensures that each delegation in the chain is verified for trustworthiness and compliance.

[0076] The processor 106 is further configured to respond to each of the plurality of recursive administration requests to ensure that each DoAP is resolved, thereby evaluating a delegation of authority in the distributed access control system, where the responding is carried out in reverse order, starting from the root DoAP. The responding process is carried out in reverse order, starting from the root DoAP. By progressing backward through the chain, the system 100 ensures that the validity of each delegation is contingent on the confirmation of its preceding authority. This step-by-step resolution strengthens the trust framework, ensuring that all delegations align with the system’s predefined trust and authorization criteria, thereby maintaining secure and reliable access control across distributed environments.

[0077] In accordance with an embodiment, a trust assessment policy is embedded into each leaf policy. The trust assessment policy refers to a systematic framework that delineates the criteria and methodologies employed to evaluate the reliability and credibility of entities or information within a specified context. The trust assessment policy ensures that each leaf policy is not only evaluated for its functional role in access control but also, for the trustworthiness of the entity that issued the leaf policy. In distributed access control systems, especially those distributed across multiple geographical locations, trust levels can vary between different issuers. Without this embedded trust evaluation, a policy from an untrusted source could undermine the entire access control framework. By embedding the trust assessment policy directly into each leaf policy, the system 100 can dynamically evaluate the credibility of the policy issuer in parallel with its compliance with access control rules.

[0078] In accordance with an embodiment, the evaluation of the leaf policy takes place concurrently with the evaluation of the trust assessment policy. The concurrent evaluation of the leaf policy and the trust assessment policy enhances the efficiency and reliability of the access control process in distributed systems. This approach is required because it ensures that both the functional compliance of the leaf policy and the trustworthiness of its issuer (i.e., the issuer of the leaf policy) are assessed simultaneously, avoiding delays and inconsistencies that may arise from sequential evaluations. In the system 100, that is spanning multiple geographical locations, policies are issued by diverse entities, making trust assessment a significant factor for maintaining integrity of the system 100. By evaluating the trust assessment policy alongside the leaf policy, the system 100 can dynamically verify the authority and credibility of the issuer while also validating the specific access control rules defined in the leaf policy.

[0079] In accordance with an embodiment, the trust assessment conditions are incorporated into the plurality of DoAPs. The trust assessment conditions refer to the specific criteria and parameters utilized to evaluate the reliability and credibility of an entity or an organization within a trust verification framework. Incorporating the trust assessment conditions into the DoAPs allows for a dynamic evaluation of the trustworthiness of each delegate, ensuring that the delegation is granted only to the entities (e.g., the delegate 120) that meet predefined trust threshold values. These conditions may include attributes, such as the delegate's historical performance, compliance with organizational standards, or contextual factors like geographical or operational constraints. By embedding the trust conditions directly within the DoAPs, the system 100 ensures that trust evaluation is integrated into the policy application process.

[0080] In accordance with an embodiment, the trust assessment conditions include trust attributes representing a delegate’s trustworthiness. The trust attributes refer to the characteristics or properties that contribute to the assessment of trust in a given entity or system. The trust attributes serve as quantifiable indicators of trustworthiness, encompassing factors, such as the delegate’s historical compliance, role within the organization, security certifications, or performance metrics. The trust attributes allow the system 100 to dynamically evaluate whether the delegate 120 meets the required trust threshold values defined in the DoAPs. By incorporating the trust attributes, the system 100 establishes a data-driven and objective approach to assess trustworthiness, ensuring that only qualified and reliable delegates are entrusted with authority.

[0081] In accordance with an embodiment, a trustworthiness path is selected based on the trust assessment conditions. The trustworthiness path refers to a systematic sequence of evaluations and assessments that determine the reliability and credibility of an entity or data source within a specified context, facilitating informed decision-making processes. The trustworthiness path selection is required because, in the system 100 with multiple delegation paths, the trust levels of different entities and their issued policies can vary significantly. The trustworthiness path represents the plurality of DoAPs 104 connecting the root issuer to the leaf policy, ensuring that each entity along the path satisfies predefined trust assessment conditions. These conditions may include trust attributes, such as compliance with organizational standards, certification levels, or historical performance metrics. The system 100 prioritizes secure and credible delegations by evaluating all potential paths and selecting the most trustworthy one.

[0082] In accordance with an embodiment, trust assessment conditions are incorporated into the root DoAP. The incorporation of trust assessment conditions is required because the root DoAP serves as the origin of the delegation chain, setting the baseline standards for trust that must be adhered to by all subsequent entities and policies. By embedding the trust assessment conditions, such as minimum trust thresholds or criteria for evaluating attributes, like certification levels, issuer credibility, or operational compliance, the root DoAP ensures that the trust chain begins with a robust and secure foundation. These conditions provide a centralized mechanism to enforce trust evaluation, ensuring consistency across all delegation paths. By anchoring trust at the root level, the system 100 enhances the integrity of the access control framework, enabling secure and reliable delegation of authority in the distributed environment.

[0083] In accordance with an embodiment, the root DoAP includes trust assessment conditions for each of the plurality of DoAPs. The root DoAP is structured to encompass specific trust assessment conditions that are systematically applied to each DoAP within the hierarchy. This involves defining criteria that evaluate the reliability and integrity of each DoAP based on its characteristics and the environmental context. The assessment process includes verifying compliance with established rules and conditions and ensuring that each DoAP meets the required standards for trustworthiness before the DoAP can be considered valid within the chain. The trust assessment conditions ensure that only DoAPs that meet predefined trust criteria are recognized, thereby enhancing the overall security and integrity of the policy framework. Furthermore, the trust assessment conditions prevent the acceptance of unverified or potentially unreliable DoAPs. The implementation of trust assessment conditions leads to a robust validation mechanism that enhances the security of the policy evaluation process.

[0084] In accordance with an embodiment, the trust assessment conditions are checked at the checking step. During the checking step, the authority verifier 108 is configured to evaluate the predefined trust assessment conditions, such as trust attributes, threshold values, or contextual parameters, for each DoAP and leaf policy. If the trust assessment conditions are met, the policy is considered trustworthy and eligible for enforcement. The authority verifier 108 may be configured to utilize algorithms or decision trees to assess the trust assessment conditions effectively. The system 100 seamlessly integrates the trust assessment into the existing policy evaluation workflow by performing this evaluation at the verification step or later. This ensures that only policies and delegations that meet both functional and trust criteria contribute to the secure operation of the access control framework, enhancing the reliability and robustness of the access control framework across the distributed environment.

[0085] In accordance with an embodiment, an additional policy, designated as a trust configuration policy, specifies the trustworthiness conditions required to allow a leaf policy to be considered admissible. The trust configuration policy may be referred to as a set of predefined rules and parameters that govern the establishment and management of trust relationships within a system or network. The trust configuration policy serves as a centralized mechanism to define the trust conditions, such as minimum trust thresholds, issuer credentials, or compliance with organizational standards, that a leaf policy must meet to be accepted. By decoupling trust assessment from the operational logic of the leaf policies, the trust configuration policy provides a flexible and standardized method for enforcing trustworthiness across diverse environments. The authority verifier 108 may be configured to evaluate each leaf policy against the criteria outlined in the trust configuration policy, ensuring that only those issued by credible and authorized entities are admitted. This approach strengthens the integrity of the system 100 by embedding a robust trust evaluation layer, enabling secure and reliable policy enforcement across distributed and dynamic operational landscapes.

[0086] In accordance with an embodiment, a leaf policy is considered to be admissible when it passes: (i) the trustworthiness condition assessment of the leaf policy; and (ii) a delegation evaluation. The trustworthiness condition refers to a specific criterion or set of criteria utilized to assess the reliability and integrity of an entity or system within a trust framework. The delegation evaluation refers to the process of analyzing and determining the appropriateness and validity of authority or responsibilities assigned to an agent or representative within a given context. The trustworthiness condition assessment verifies that the leaf policy meets predefined criteria, such as issuer credentials, compliance with trust thresholds, or adherence to organizational standards. Concurrently, the delegation evaluation examines the hierarchical chain of authority to confirm that the delegation of authority, from the root to the policy issuer, complies with the trust and authorization requirements outlined in the DoAPs. By requiring the leaf policy to pass both assessments, the system 100 leads to a more robust policy management framework, reducing vulnerabilities and ensuring that only trustworthy and appropriately delegated policies become operational.

[0087] In accordance with an embodiment, the trust configuration policy is evaluated concurrently with the checking step. The concurrent evaluation allows the system 100 to assess both the trustworthiness conditions outlined in the trust configuration policy and the authority verification of leaf policies and DoAPs, simultaneously. The trust configuration policy specifies the trust thresholds and criteria that the leaf policy must meet to be considered admissible, such as issuer credibility, compliance levels, or other trust attributes. By evaluating this policy in parallel with the checking step, the systems 100 ensures that trustworthiness assessments are seamlessly integrated into the policy validation process. This streamlined approach reduces latency, prevents redundancies, and ensures that only policies meeting both authority verification and trust conditions are admitted. By performing the evaluations simultaneously, the system 100 can quickly identify any discrepancies or invalid links in the trust chain, thereby preventing the enactment of policies that lack proper authority.

[0088] In accordance with an embodiment, the trust configuration policy is evaluated prior to the checking step. The early evaluation is required to ensure that only leaf policies meeting the predefined trustworthiness conditions proceed to the subsequent authority verification process. By evaluating the trust configuration policy before the checking step, the system 100 effectively eliminates policies that fail to meet trust requirements, reducing unnecessary processing during authority verification. This proactive approach streamlines the overall policy evaluation process, ensuring that resources are dedicated to assessing only those policies that align with trust and delegation standards.

[0089] Thus, the system 100 offers significant advantages over conventional access control systems by incorporating dynamic trust evaluation and robust delegation chain verification mechanisms. Unlike traditional systems that often assume equal trustworthiness of all policies and issuers, the system 100 integrates trust assessment conditions directly into the DoAPs, ensuring that every delegation is evaluated for compliance and reliability. The system 100 manifests the ability to generate and resolve recursive administration requests iteratively, starting from the root DoAP, ensuring that the entire delegation chain is validated with precision. Furthermore, the scalability and adaptability of the system 100 allow the system 100 to operate seamlessly across geographically distributed environments, making it ideal for applications in cloud infrastructures, IoT ecosystems, and global enterprise networks. By embedding context-aware decision-making, granular policy enforcement, and continuous trust monitoring, the system 100 mitigates vulnerabilities inherent in conventional frameworks and ensures secure, efficient, and resilient access control.

[0090] FIG. 2 is a flowchart of a method of evaluating a delegation of authority from a delegator to a delegate in a distributed access control system for governing access to a digital data resource, in accordance with an embodiment of the present disclosure. FIG. 2 is described in conjunction with elements from FIG. 1. With reference to FIG. 2, there is shown a method 200 that includes steps 202 to 210. The processor 106 of the system 100 (of FIG. 1) is configured to execute the method 200.

[0091] The method 200 is provided for evaluating a delegation of authority from the delegator 118 to the delegate 120 in a distributed access control system for governing access to the digital data resource 122. The method 200 enables an efficient management of access to the digital data resource 122 by processing the plurality of leaf policies 102 and the plurality of DoAPs 104. Each leaf policy specifies actions and rules for access control, necessitating authority verification, while each DoAP, except for the root DoAP, similarly requires authority verification. The method 200 involves verifying authority for both the plurality of leaf policies 102 and the plurality of DoAPs 104, generating recursive administrative requests until the root DoAP is reached, and resolving each request in reverse order. The trust assessment conditions are integral to this framework, incorporated into DoAPs and root policies, to ensure reliability by evaluating attributes, like the trustworthiness of the delegate 120. Furthermore, an additional trust configuration policy may specify the conditions for admissibility of the plurality of leaf policies 102, evaluated either concurrently with or prior to authority verification steps, ensuring a robust, secure, and adaptable method for use in the access control system.

[0092] At step 202, the method 200 comprises receiving a plurality of leaf policies, each leaf policy specifies actions and rules associated with access control in the distributed access control system, where each leaf policy requires an authority verification. The method 200 operates by receiving the plurality of leaf policies 102, where each policy specifies actions and rules that govern access to digital resources. The plurality of leaf policies 102 are fundamental operational components, defining the conditions under which an access to the digital data resource 122 is granted or denied. Each leaf policy requires authority verification, which is used to ensure that the policy's issuer possesses the required authorization as determined by a hierarchical trust structure.

[0093] In accordance with an embodiment, a trust assessment policy is embedded into each leaf policy. The embedding of the trust assessment policy into each leaf policy ensures that access control decisions are not only based on predefined actions and rules but also dynamically evaluated for the trustworthiness of the entity attempting access. This integration allows the validation of prominent factors, such as compliance history, security credentials, and contextual attributes of the delegate 120, before granting permissions. As a result, the method 200 manifests an enhanced security by preventing untrusted entities from bypassing the access control framework, even if they meet other static policy conditions.

[0094] In accordance with an embodiment, the evaluation of the leaf policy takes place concurrently with the evaluation of the trust assessment policy. The concurrent evaluation of the leaf policy and the trust assessment policy ensures that both access control rules and trustworthiness conditions are verified simultaneously, leading to faster and more cohesive decision-making. This parallel processing eliminates delays caused by sequential evaluations while maintaining the integrity of the access control framework. By evaluating these policies together, the method 200 ensures that access is granted only when both the predefined rules and dynamic trust conditions are satisfied, thereby enhancing security and efficiency.

[0095] At step 204, the method 200 further comprises receiving the plurality of delegation of authority policies (DoAPs) 104, each DoAP specifies characteristics that define a policy identification, and where each DoAP, except for a root DoAP, requires an authority verification. Each DoAP specifies characteristics that define its identification, such as issuer details, issuance date, and scope of delegation, providing a clear framework for evaluating its applicability. Except for the root DoAP, which is inherently trusted as the origin of the delegation chain, every other DoAP requires authority verification to ensure that each DoAP has been issued by a trusted entity. This verification process involves tracing the trust chain back to the root DoAP, validating the delegation of authority at each step. The step 204 is executed to ensure that only DoAPs from credible and authorized entities are considered, creating a secure and reliable foundation for managing access control policies across the system 100.

[0096] In accordance with an embodiment, the trust assessment conditions are incorporated into the DoAPs. The integration of trust assessment conditions into DoAPs results in a more robust and dynamic authorization framework. Such integration enables real-time evaluation of trustworthiness, allowing for adaptive responses to changing risk profiles.

[0097] In accordance with an embodiment, the trust assessment conditions include trust attributes representing a delegate’s trustworthiness. The integration of trust attributes leads to improved accuracy in trust assessments, enabling more informed and secure interactions. This results in enhanced system performance, as it allows for better delegation of tasks and responsibilities based on the assessed trustworthiness of delegates.

[0098] In accordance with an embodiment, the trustworthiness path is selected based on the trust assessment conditions. The trustworthiness path involves analyzing various trust assessment conditions, such as historical performance, data integrity, and contextual relevance. The selection of the trustworthiness path based on trust assessment conditions ensures that the delegation chain adheres to the highest standards of security and reliability. This approach leads to the evaluation of multiple delegation paths and prioritizing those that meet the predefined trust thresholds for each entity and step in the chain. By doing so, the method 200 results in mitigation of risks associated with untrusted or less reliable paths, ensuring that only the most secure and compliant delegation route is utilized for access control decisions.

[0099] In accordance with an embodiment, trust assessment conditions are incorporated into the root DoAP. The incorporation of the trust assessment conditions into the root DoAP establishes a foundational layer of security by setting the ultimate standards for trustworthiness across the entire delegation chain. This ensures that all subsequent delegations are validated against criteria defined by the root authority, creating a consistent and reliable framework for trust evaluation. By embedding these conditions into the root DoAP, the method 200 manifests an enhanced ability to maintain compliance, integrity, and security throughout distributed and hierarchical access control environments.

[0100] In accordance with an embodiment, the root DoAP includes trust assessment conditions for each of the plurality of DoAPs. The inclusion of trust assessment conditions for each of the plurality of DoAPs within the root DoAP ensures that all delegations across the chain are evaluated against a unified and comprehensive set of trust criteria. This approach is used to enforce consistent standards of trustworthiness, regardless of the complexity or distribution of the access control framework. By defining these conditions at the root level, the method 200 guarantees that every DoAP in the chain aligns with the overarching security and compliance requirements, enhancing the integrity and reliability of the entire delegation process.

[0101] At step 206, the method 200 further comprises checking for an authority verification for each leaf policy and for each DoAP. The checking for authority verification for each leaf policy and each DoAP ensures that every policy and delegation in the access control system is issued and applied by an authorized and trusted entity. This step prevents unauthorized policies or delegations from compromising the system’s integrity, reinforcing the chain of trust throughout the framework. By systematically verifying authority at each level, the method 200 guarantees secure and compliant access to digital resources, even in complex distributed environments.

[0102] In accordance with an embodiment, the trust assessment conditions are checked at the checking step. The checking of the trust assessment conditions at the checking step (i.e., the step 206) ensures that the evaluation process not only validates authority but also assesses the trustworthiness of the entities involved in the delegation chain. This integration of trust conditions at the verification stage enhances the security of the system by ensuring that only trusted entities can issue or act upon policies. By virtue of embedding trust checks at this step, the method 200 strengthens its ability to prevent vulnerabilities and maintain compliance across distributed access control environments.

[0103] In accordance with an embodiment, an additional policy, designated as the trust configuration policy, specifies the trustworthiness conditions required to allow a leaf policy to be considered admissible. The additional policy, known as a trust configuration policy, is established to outline specific criteria that determine the trustworthiness of the leaf policy. This involves defining parameters such as validation metrics, compliance standards, and risk assessment thresholds that must be met for the leaf policy to be accepted. The process includes evaluating the leaf policy against these established criteria, ensuring that only the leaf policies that meet the trustworthiness conditions are considered valid.

[0104] In accordance with an embodiment, a leaf policy is considered to be admissible when it passes: (i) the trustworthiness condition assessment of the leaf policy; and (ii) a delegation evaluation. The leaf policy is considered admissible only when the leaf policy satisfies both the trustworthiness condition assessment and the delegation evaluation, ensuring a dual layer of validation for enhanced security. The trustworthiness assessment verifies that the entity issuing or acting on the policy meets predefined trust criteria, such as compliance history and credentials. Simultaneously, the delegation evaluation confirms that the policy is part of a valid and authorized chain of delegations, ensuring the policy's integrity and alignment with the system’s access control framework. Together, these checks guarantee that only secure, reliable, and compliant policies are deemed admissible.

[0105] In accordance with an embodiment, the trust configuration policy is evaluated concurrently with the checking step. The evaluation mechanism is designed to assess the trust configuration policy's parameters and conditions while concurrently verifying the validity of the authority associated with the leaf policy.

[0106] In accordance with an embodiment, the trust configuration policy is evaluated prior to the checking step. Evaluating the trust configuration policy prior to the checking step ensures that the method 200 provides a well-defined baseline of trust criteria against which all subsequent evaluations are conducted. This preliminary step establishes the trust thresholds and assessment parameters for policies and delegations, ensuring consistency throughout the evaluation process. By virtue of configuring the trust conditions in advance, the method 200 manifests an enhanced ability to identify and prevent unauthorized or untrustworthy entities from proceeding further in the access control framework.

[0107] At step 208, the method 200 further comprises generating a plurality of recursive administration requests based on the checking step until the root DoAP is reached. The recursive administration requests refer to a process wherein administrative requests are repeatedly issued hierarchically to ensure comprehensive management of resources or tasks. Following the checking step 206, each applicable DoAP requiring authority verification is identified. For each such DoAP, a new recursive administrative request is generated to verify its authority. This recursive process continues until the root DoAP is reached. During this process, the initial administrative request is temporarily paused to await confirmation of the admissibility of the corresponding DoAP. The resolution of administrative requests is carried out in reverse order, starting from the root DoAP and progressing through the hierarchy. The step 208 is used to ensure that each DoAP is effectively verified, maintaining the integrity and security of the delegation chain.

[0108] At step 210, the method 200 further comprises, responding to each of the plurality of recursive administration requests to ensure that each DoAP is resolved, thereby evaluating a delegation of authority in the distributed access control system, where the responding is carried out in a reverse order, starting from the root DoAP. The delegation of authority refers to the process by which a principal assigns specific rights or responsibilities to an agent, empowering the agent to act on behalf of the principal within clearly defined parameters. The responding of each administration request is executed in the reverse order, beginning with the root DoAP and progressing sequentially toward the leaf policies. The root DoAP serves as the ultimate trusted authority within the delegation chain, and its validation establishes the foundational trust framework for all subsequent delegations. The step 210 provides the validity of each delegation is contingent on the confirmation of the preceding authority in the hierarchy. The step-by-step backward traversal systematically provides the validation to the entire trust chain, that all delegations within the distributed access control system comply with predefined trustworthiness and authorization criteria. This approach strengthens the security and integrity of the delegation process across the distributed access control system.

[0109] Thus, the method 200 introduces a groundbreaking approach to access control and policy management by leveraging generalized DoAPs, incorporating trust assessment criteria, and enabling multi-layered evaluation mechanisms. Unlike traditional systems, the method 200 extends the applicability of delegation mechanisms beyond conventional access control, offering versatility in systems like identity and access management (IAM) , certifications, network management, usage control, and data protection. By supporting multi-party policy issuers and regional localization, the method 200 ensures seamless integration into decentralized ecosystems while differentiating itself from existing solutions like Azure Attribute Based Access Control (ABAC) system, Google Zanzibar, and OPA Rego. Furthermore, the method 200 enhances trust and security by embedding trust assessment criteria into DoAPs, enabling compliance evaluation, policy integrity checks, and the enforcement of regional constraints.

[0110] The introduction of delegation edges trust assessment ensures that trust thresholds are verified between each delegator and delegate, guaranteeing security and reliability at every step of the delegation process. Moreover, root-level trust evaluation provides end-to-end assurance by evaluating the overall trustworthiness of the entire delegation chain, focusing on the path from root to leaf. The method 200 also offers the flexibility of independent trust and delegation evaluation, allowing tailored optimization for specific use cases. Additionally, embedding trust assessments directly into leaf policies provides localized and granular trust evaluation, making the method 200 adaptable to a wide range of scenarios. These innovative features position the method 200 as a transformative solution, ensuring security, scalability, and compliance while aligning with current standards and paving the way for future advancements like ALFA 2.0.

[0111] The steps 202 to 210 are only illustrative and other alternatives can also be provided where one or more steps are added, one or more steps are removed, or one or more steps are provided in a different sequence without departing from the scope of the claims herein.

[0112] There is provided a computer program product comprising instructions for carrying out all the steps of the method 200 when said computer program is executed on a computer system. The computer program can be implemented as an algorithm, embedded in a software stored in the non-transitory computer-readable storage medium having program instructions stored thereon, the program instructions being executable by the one or more processors in the computer system to execute the method 200. The non-transitory computer-readable storage means may include, but are not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. Examples of implementation of computer-readable storage medium, but are not limited to, an Electrically Erasable Programmable Read-Only Memory (EEPROM) , a Random Access Memory (RAM) , a Read Only Memory (ROM) , a Hard Disk Drive (HDD) , a Flash memory, a Secure Digital (SD) card, a Solid-State Drive (SSD) , a computer-readable storage medium, and / or a CPU cache memory.

[0113] FIG. 3 is a diagram that represents a hierarchical structure and components of a delegation of authority policy (DoAP) framework, in accordance with an embodiment of the present disclosure. FIG. 3 is described in conjunction with elements from FIGs. 1 and 2. With reference to FIG. 3, there is shown a diagram 300 that represents the hierarchical structure and components of a DoAP framework. The components of the DoAP framework include a delegation policy (DP) 302, policy characteristics 304, a plurality of rules 306, a delegation decision 308, an applicability condition 310, a delegate 312, other attributes 314, and delegated attributes 316. The delegate 312 corresponds to the delegate 120 (of FIG. 1) .

[0114] The DP 302 is a formal framework that defines the conditions, rules, and parameters under which an authority or rights are transferred from one entity (i.e., the delegator 118) to another entity (i.e., the delegate 120) within a distributed access control system (e.g., the system 100) . The DP 302 specifies the scope of the delegation, including the actions permitted, the resources involved, and any constraints or obligations that must be met. The DP 302 is significant in hierarchical and distributed environments, such as the system 100, to ensure that the delegation of authority is assigned securely and responsibly.

[0115] The policy characteristics 304 refers to the characteristics that define the policy identification. The policy characteristics 304 includes characteristics, such as the digital signature, and metadata that describe the policy’s creation, modification, and ownership. Examples of the policy characteristics 304 includes issuer characteristics, such as name of the issuer, Issuer ID, contact information, and digital signature certification.

[0116] The DP 302 includes the plurality of rules 306, which are the logic governing the delegation. Each rule has an applicability condition.

[0117] The delegation decision 308, refers to an outcome of evaluating a delegation policy to determine whether the transfer of authority from the delegator 118 to the delegate 120 is valid and admissible under the defined rules and conditions. The delegation decision 308 is based on criteria, such as the trustworthiness of the delegate, compliance with the delegation policy, and verification of the delegator's authority to assign such rights.

[0118] The applicability condition 310 refers to a specific set of criteria or rules that determine the circumstances under which a policy or delegation is applicable within a system. The applicability condition 310 is used to evaluate a particular policy, such as the DoAP or a leaf policy.

[0119] The delegate 312 refers to a user, group, or system to which a policy issuer temporarily transfers authority.

[0120] Other attributes 314 refer to additional data points or contextual information associated with a policy, subject, or resource that aid in evaluating the applicability, validity, or trustworthiness of a policy or action within a distributed access control system.

[0121] The delegated attributes 316 define aspects of the delegation, including the scope of delegated authority. Examples of the delegated attributes 316 include delegation time frame and delegated actions.

[0122] Referring to FIG. 3, the hierarchical structure of the DoAP facilitates a trust chain to validate authority delegations within a distributed access control system. At the top of the hierarchy the DP 302 lies, characterized by various attributes, such as issuer details, issuance date, and metadata, ensuring that each policy is a verifiable and reliable digital asset. The DP 302 comprises the plurality of rules 306 and the applicability condition 310, which define the delegation logic and specify where and how policies apply based on attributes like subject, resource, and environmental factors.

[0123] Further, the delegate 312 represents the recipient of the delegated authority, while the delegated attributes 316 delineate the scope of delegation, including timeframes, permissible actions, and conditions. The delegation decision 308 is responsible for determining the approval or denial of requests by rigorously evaluating compliance with the defined rules (i.e., the plurality of 306) and the applicability condition 310. This mechanism ensures that trust and policy compliance are maintained throughout the hierarchical delegation structure, thereby upholding the integrity and reliability of the access control system.

[0124] FIG. 4 is a flowchart that depicts a series of operations performed to make a final decision for an authorization request that triggers a leaf policy, in accordance with an embodiment of the present disclosure. FIG. 4 is described in conjunction with elements from FIGs. 1, 2, and 3. With reference to FIG. 4, there is shown a flowchart 400 that depicts a series of operations 402 to 426 performed to make a final decision for an authorization request that triggers the leaf policy. The final decision is made according to the results of the delegation evaluation, which is described in detail, in the flowchart 400.

[0125] At operation 402, a request (R) is made. The request may be triggered by user actions, system events, or other triggers. The request initiates the evaluation of leaf policies to determine the required actions.

[0126] At operation 404, the collection of leaf policy is performed. The evaluator (i.e., the delegation evaluator 112) is configured to collect all relevant leaf policies, which can include a variety of policies, such as authorization policies, business rules, network management policies, and other operational policies.

[0127] At operation 406, the evaluator (i.e., the delegation evaluator 112) may be configured to examine the context of the request, including the subject, resource, action, events, and environmental attributes, to determine which leaf policies are applicable.

[0128] At operation 408, each collected leaf policy is analyzed to determine its applicability based on the request and the examined context.

[0129] At operation 410, every applicable leaf policy has a decision (D) , which can be a permit, denial, or error (indeterminate decision) .

[0130] At operation 412, a leaf policy may have specific characteristics. If the leaf policy does not have any characteristics requiring authority verification, there is no requirement for further delegation checks and the decision is processed directly using combining decision logic (at operation 424) .

[0131] At operation 414, the leaf policy requires authority verification, the delegation evaluation is conducted to validate the authority of the policy. The delegation evaluation may result in one of three outcomes, such as either the decision is admissible, or the decision is indeterminate, or the decision is inadmissible.

[0132] At operation 416, if the decision is admissible, the leaf policy decision is included in the combining decision logic.

[0133] At operation 418, if the decision is indeterminate, the policy decision is marked indeterminate and considered an error during the combining decision logic phase.

[0134] At operation 420, if the decision is inadmissible, the policy decision is deemed invalid and the decision is disregarded (operation 422) in the combining decision logic.

[0135] At operation 422, the policy decision is disregarded.

[0136] At operation 424, once all the leaf policies are evaluated, the combining logic aggregates their decisions to form the final decision for the request. If additional policies require evaluation, the process may loop back for further analysis. There is a feedback loop labelled “check other leaf policy” that returns to the evaluation of applicable leaf policies.

[0137] At operation 426, concludes with the final decision of the request R.

[0138] FIGs. 5A and 5B collectively, is a flowchart depicting a series of operations performed during delegation evaluation, in accordance with an embodiment of the present disclosure. FIGs. 5A and 5B are described in conjunction with elements from FIGs. 1, 2, 3, and 4. With reference to FIGs. 5A and 5B, there is shown a flowchart 500 that depicts a series of operations 502 to 544 performed during delegation evaluation.

[0139] At operation 502, the process of delegation evaluation begins by identifying an applicable leaf policy that requires authority verification. To initiate this process, an administrative request is created for the leaf policy. The administrative request may also be referred to as an original administrative request.

[0140] At operation 504, all relevant DoAPs are gathered based on the administrative request.

[0141] At operation 506, a context examination is performed to gather all relevant DoAPs and context attributes related to the original administrative request. These attributes include the subject, resource, and environmental conditions required for the delegation evaluation.

[0142] At operation 508, the flowchart 500 iterates through each applicable DoAP to evaluate its admissibility.

[0143] At operation 510, all applicable DoAPs are evaluated.

[0144] At operation 512, check if all applicable DoA policies are indeterminate, and if no admissible policy exists.

[0145] At operation 514, if an indeterminate decision is encountered and no DoAP is evaluated as admissible, the decision is indeterminate.

[0146] At operation 516, if all applicable DoA policies are evaluated and no DoA policy is evaluated as admissible or indeterminate, the decision is inadmissible.

[0147] Referring to FIG. 5B, at operation 518, this is checked whether the DOA policy requires any authority verification.

[0148] At operation 520, if authority verification is required, a new recursive administrative request is generated.

[0149] At operation 522, the generated new recursive administrative request is paused until the admissibility of the applicable DoA policy is confirmed.

[0150] At operation 524, if the DoA policy is inadmissible, this is checked that if there are other applicable policies. If no other policies are admissible, the final decision for the original request is marked inadmissible.

[0151] At operation 526, if the evaluation results in an indeterminate decision, the flowchart 500 proceeds to evaluate any other applicable policies. If all applicable policies are indeterminate, and no admissible policy exists, the original request is marked as indeterminate.

[0152] At operation 528, if the applicable DoA policy is indeterminate, the decision is recorded as indeterminate, and the flowchart 500 checks in operation 508 to determine if there is another DoA policy applicable.

[0153] At operation 530, the recursive process continues until the root DoA policy is reached.

[0154] At operation 532, a decision is collected based on the evaluation, which can be one of the following: admissible, indeterminate, and inadmissible.

[0155] At operation 534, if the DoA policy meets the required trust and authority criteria, then decision is marked as admissible.

[0156] At operation 536, if the DoA policy cannot conclusively be evaluated, then the decision is marked as indeterminate.

[0157] At operation 538, the DoA policy fails to meet the required criteria, then the decision is marked as inadmissible.

[0158] At operation 540, if the applicable delegation of authority policies is admissible, it means that the decision of the applicable policy can be collected to answer the original administrative request.

[0159] At operation 542, this is checked if the decision of the DoA policy is admissible. If not, the decision of the DoA policy is inadmissible.

[0160] At operation 544, if “Yes” , the decision is admissible.

[0161] Referring to the FIGs. 5A and 5B, the flowchart 500 outlines a comprehensive mechanism for verifying the admissibility of the DoAP within a trust chain. The evaluation begins with the leaf policy that requires authority verification, and initiating an administrative request. Through a detailed context examination, all applicable DoAPs and associated attributes are gathered to determine their relevance to the request. For each applicable DoAP, a recursive process is triggered if authority verification is required, temporarily pausing the original request. This recursion ensures the admissibility of the DoAP is thoroughly validated, proceeding step-by-step up the chain to the root policy. At the root level, a final decision: admissible, inadmissible, or indeterminate, is collected, which cascades back to resolve the original administrative request. The flowchart 500 iteratively checks all applicable policies, ensuring only admissible policies contribute to the final decision while handling indeterminate and inadmissible cases appropriately. This flow ensures that trust and authority criteria are dynamically assessed, maintaining integrity and compliance throughout the delegation hierarchy.

[0162] FIG. 6 is a flowchart that depicts a series of operations during administrative request generation for a leaf policy, in accordance with an embodiment of the present disclosure. FIG. 6 is described in conjunction with elements from FIGs. 1, 2, 3, 4, and 5A-5B. With reference to FIG. 6, there is shown a flowchart 600 that depicts a series of operations 602 to 616 representing the administrative request generation for a leaf policy.

[0163] At operation 602, a leaf policy request is triggered by specific events or conditions. The triggered request may involve managing resources, enforcing business rules, applying event-condition-action policies, or handling network management tasks and authorization requirements.

[0164] At operation 604, the leaf policy retrieval: the delegation evaluator may be configured to retrieve all applicable leaf policies that might apply to the request. These policies can address various operational, business, or security aspects relevant to the request.

[0165] At operation 606, the context for the request is gathered, including details, such as the subject, resource, action, event, and environmental attributes. This context enables the evaluator (i.e., the delegation evaluator) to determine which leaf policies are relevant.

[0166] At operation 608, from the collected policies, the evaluator identifies those leaf policies that match the request criteria. The applicable leaf policies are those whose conditions align with the request attributes.

[0167] At operation 610, for each applicable leaf policy, the evaluator checks if the leaf policy requires authority verification according to its characteristics. The following are indicative examples:

[0168] Example 1 –issuer: if a leaf policy is characterized by an issuer, the authority verification checks if the issuer has the authority to issue the policy.

[0169] Example 2 –issuance date: if a leaf policy is characterized by an issue date, the authority verification checks if the date of issuance is still valid to consider the policy valid.

[0170] Example 3 –security level: if a leaf policy is characterized by network management or security levels, the authority verification checks if the designated network management entity has the required authorization and security clearance to implement network changes or protocols.

[0171] Example 4 –region: if a leaf policy is characterized by a geographical region, the authority verification checks if the policy complies with the regulations and authorizations specific to that region. For instance, data handling policies might need to comply with local data protection laws.

[0172] Example 5 –compliance: if a leaf policy is characterized by a compliance standard, the authority verification must check if the policy adheres to the relevant industry or regulatory standards.

[0173] At operation 612, if an applicable leaf policy requires authority verification, the evaluator generates an administrative request. The administrative request includes details about the policy and the relevant environmental context. For example, if the leaf policy is an authorization policy, the context is related to the subject seeking access to the resource, the object, and the authorization context.

[0174] At operation 614, if the leaf policy is not applicable, it will be ignored and will not undergo authority verification.

[0175] At operation 616, if the leaf policy does not require authority verification, the evaluator directly collects the decision from the policy. This decision can then be combined with other leaf policy decisions to form the final outcome for the request.

[0176] FIG. 7 is a flowchart that depicts a series of operations during administrative request generation for a delegation of authority (DoA) policy, in accordance with an embodiment of the present disclosure. FIG. 7 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 5A-5B, and 6. With reference to FIG. 7, there is shown a flowchart 700 that depicts a series of operations 702 to 716 representing the administrative request generation for the DoA policy.

[0177] At operation 702, an administrative request (AR) triggers the DoA process. The AR can originate from the leaf policy or another DoA policy requiring authority verification. The administrative request initiates the evaluation process for determining appropriate DoA actions.

[0178] At operation 704, the evaluator (i.e., the delegation evaluator 112) may be configured to retrieve all applicable DoA policies that may apply to the administrative request. The applicable DoA policies outline conditions and rules required for addressing the AR and ensuring that the AR adheres to delegation guidelines.

[0179] At operation 706, the evaluator (i.e., the delegation evaluator 112) may be configured to collect the environmental context associated with the administrative request. This includes attributes, such as:

[0180] Subject: Who is requesting or involved?

[0181] Resource: What is being accessed or acted upon?

[0182] Action: What action is being performed?

[0183] Event: Contextual events linked to the AR.

[0184] Ecological attributes: Additional conditions like time, location, or system state.

[0185] The collection of the relevant context aids in identifying which DoA policies are applicable to the administrative request.

[0186] At operation 708, the evaluator (i.e., the delegation evaluator 112) may be configured to filter the retrieved policies and identify those DoA policies that are applicable. The applicable policies are those whose conditions and rules align with the attributes of the administrative request.

[0187] At operation 710, each applicable DoA policy is assessed to determine whether authority verification is required. This assessment involves evaluating the characteristics of the DoA policy, such as:

[0188] Issuer: Validates if the issuer is authorized to establish the policy.

[0189] Issuance Date: Ensures the policy is still valid based on its issuance date.

[0190] Security Level: Verifies that required security authorizations are met.

[0191] Region: Confirms compliance with relevant regional regulations or laws.

[0192] Compliance Standards: Check adherence to industry or regulatory requirements.

[0193] At operation 712, if an applicable DoA policy requires authority verification, the evaluator (i.e., the delegation evaluator 112) may be configured to generate a new administrative request. This request includes details about the DoA policy, the environmental context, and information from the original administrative request. The new administrative request is used to verify the policy’s authority before proceeding further. For executing the new administrative request, there is a feedback loop that returns to the operation 702 for evaluation of the new administrative request.

[0194] At operation 714, if DoA policy is not applicable, the administrative request is ignored.

[0195] At operation 716, if the DoA policy does not require authority verification, it is treated as a trusted root policy. The evaluator (i.e., the delegation evaluator 112) may be configured to directly collect the decision based on the policy. This decision is then used to respond to the administrative request without generating additional verification steps.

[0196] During delegation evaluation, the establishment of a trust chain is required. The trust chain ensures that each policy, whether a leaf policy or a DoA policy, is validated through a hierarchical chain of trust. This validation ensures that all decisions and actions taken based on these policies are legitimate and trustworthy.

[0197] Furthermore, different exemplary scenarios of a trust chain comprising three policies, demonstrating different decision paths: an admissible path, a non-admissible path, and an indeterminate path are described, in the following way.

[0198] In an exemplary scenario of demonstrating an admissible path, the process begins with a request, such as an event action or access request, which is evaluated against the leaf policy. Based on the characteristics of the leaf policy, authority verification is required, leading to the generation of administrative request 1. The Delegation of Authority Policy 1 (DoA1) is identified as the applicable policy for the administrative request 1. However, due to the intermediate issuer characteristics of DoA1, additional authority verification is required, resulting in the generation of administrative request 2.The Delegation of Authority Policy 2 (DoA2) , serving as the root policy in the trust chain, is then evaluated in response to the administrative request 2. The DoA2 validates the request without requiring further authority verification and confirms that DoA1 is admissible. Consequently, the DoA1 answers the administrative request 1, confirming the admissibility of the leaf policy. As the admissibility decision propagates back through the trust chain, the access request is granted, affirming that the leaf policy satisfies the required conditions.

[0199] In another exemplary scenario of demonstrating an indeterminate path, a request for resource access follows the trust chain of the leaf policy and two DoA policies. The evaluation begins with the leaf policy, where administrative request 1 is generated due to the requirement for authority verification of the leaf policy. The DoA1, applicable to the administrative request 1, requires further verification, prompting administrative request 2. The root policy, DoA2, is then evaluated and produces a decision stating that DoA1's policy is indeterminate. Since DoA1 cannot be validated, its decision is overridden by the indeterminate status. This decision propagates throughout the trust chain, leading to the conclusion that the leaf policy is also indeterminate. As a result, the requested access remains unresolved due to the inability to establish trustworthiness or compliance in the trust chain.

[0200] In a yet another exemplary of non-admissible path, the access request again follows the trust chain involving the leaf policy and two DoA policies. After evaluating the leaf policy, administrative request 1 is generated due to the requirement of authority verification of the leaf policy. The DoA1 is applicable to this request but demands further verification, leading to administrative request 2. When the root policy, DoA2, is evaluated, it determines that DoA1 is not admissible. This conclusion means DoA1 cannot be validated, and its decision is considered non-admissible. Consequently, the non-admissible status propagates through the trust chain, resulting in the leaf policy being deemed as non-admissible. The access request is denied as the trust chain fails to validate the policies required to grant authority.

[0201] FIG. 8 is a diagram that represents a hierarchical structure and components of a DoAP incorporating trust conditions, in accordance with an embodiment of the present disclosure. FIG. 8 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 5A-5B, 6, and 7. With reference to FIG. 8, there is shown a diagram 800 that represents a hierarchical structure and components of a DoAP incorporating trust conditions. The components of the DoAP incorporating trust conditions include a trust condition 802, and a trust threshold value 804 in addition to the components (i.e., the DP 302, the policy characteristics 304, the plurality of rules 306, the delegation decision 308, the applicability condition 310, the delegate 312, the other attributes 314, and the delegated attributes 316) comprised by a generalized DoAP.

[0202] The trust condition 802 may be defined as a predefined criteria or rules used to evaluate the trustworthiness of an entity within a specific context. These conditions incorporate various factors, such as trust attributes (e.g., historical behavior, compliance levels, or security assurances) , logic-based assessments (e.g., weighted calculations or subjective evaluations) , and algorithms (e.g., Bayesian models or AI-driven analysis) to dynamically measure an entity's reliability.

[0203] The trust threshold value 804 refers to a predefined benchmark or limit that determines the minimum level of trustworthiness required for an entity to be considered eligible for specific responsibilities, access, or delegated authority. The trust threshold value 804 serves as a quantitative or qualitative measure against which trust attributes, such as trust scores or security assurances, are evaluated. If an entity's calculated trust score or evaluation meets or exceeds the trust threshold value 804, the entity is deemed trustworthy and eligible for delegation otherwise, the entity is disqualified.

[0204] Referring to the FIG. 8, the hierarchical structure of the generalized DoAP has been extended to incorporate trust assessment criteria, enabling a more granular and dynamic evaluation of a delegate's trustworthiness. At the top of the hierarchy lies the DP 302, serving as the foundational framework by defining the plurality of rules 306 and conditions for delegation. This structure is augmented with the trust condition 802 and the trust threshold value 804 to assess and enforce trust constraints more comprehensively. The trust condition 802 evaluates a delegate's trustworthiness through predefined criteria, such as trust attributes, which represent specific data points like trust scores derived from historical behavior, level of assurance, or other measurable parameters. The trust attributes are processed using a trust attribute reduction mechanism, which dynamically calculates trust scores by resolving trust objects, specialized components that encapsulate logic for trust evaluation. Advanced methodologies, such as weighted security score calculations, Bayesian models, or proprietary techniques like subjective logic, are used to refine these trust attributes into actionable insights.

[0205] To provide a holistic assessment, the trust condition 802 incorporates trust level expressions, which use functions or algorithms, ranging from simple logical constructs to complex AI-driven models, to analyze the aggregated trust attributes. These expressions dynamically assess the overall trustworthiness of the delegate 312 based on conditions like time, context, or past performance. The resulting trust score is then compared against the trust threshold value 804, a quantitative benchmark that determines whether the delegate 312 meets the required level of trustworthiness. The trust threshold value 804 ensures only entities meeting the specified level of assurance or trust criteria are granted authority, thereby enhancing the reliability and security of the delegation process. This integration of trust assessment criteria provides a robust mechanism for policy issuance and conditional assignment of responsibilities.

[0206] FIGs. 9A and 9B, collectively is a flowchart that depicts a series of operations of delegation evaluation process incorporating trust threshold determination and delegation chain evaluation, in accordance with an embodiment of the present disclosure. FIGs. 9A and 9B are described in conjunction with elements from FIGs. 1, 2, 3, 4, 5A-5B, 6, 7, and 8.With reference to FIGs. 9A and 9B, there is shown a flowchart 900 that depicts a series of operations 902 to 956 of the delegation evaluation process incorporating trust threshold determination and delegation chain evaluation.

[0207] Referring to FIG. 9A, the evaluation process begins with an applicable leaf policy that requires authority verification, triggering an administrative request (as elaborated in FIGs. 5A, and 5B) . The process, referred to as the original administrative request, starts by collecting all relevant DoAPs and attributes at the operations 904 and 906 based on the request's context. Additionally, trust attributes derived from these DoAPs are collected at the operation 908 for subsequent evaluations. For each DoA policy in the collection at the operation 910, the evaluation process is initiated at the operation 912.

[0208] Referring to FIG. 9B, if specified, trust attributes or conditions within the policy must be assessed at the operation 922. These trust conditions are evaluated to determine if they meet the required trust criteria at the operation 924. This trust evaluation is required and must occur before proceeding with authority verification. If the trust condition of a DoA policy is not satisfied at the operation 926, the evaluation moves to the next DoA policy in the collection. Conversely, if the trust condition is satisfied, the policy is deemed applicable, and further steps are taken to determine the evaluation result.

[0209] If the applicable DoA policy requires authority verification, determined at the operation 928, a new recursive administrative request is generated, at the operation 940. During this recursion, the delegation evaluation repeats, but the focus shifts to verifying the admissibility of the applicable DoA policy rather than the leaf policy. The initial administrative request, created at the operation 902, is paused until the admissibility of the applicable DoA policy is confirmed. When the administrative request reaches the root DoA policy, at the operation 930, a decision is collected. The collected decision (collected at step 932) may be admissible, at the operation 934. The collected decision may be indeterminate, at the operation 936. The collected decision may be inadmissible, at the operation 938.

[0210] If the applicable DoA policy is admissible, the decision is collected to answer the original administrative request, created at the operation 902, resulting in an admissible final decision at the operations 942, 952, 954 and 956. If the applicable DoA policy is inadmissible at the operation 946, the process checks for other applicable policies in the collection, at the operation 910. If the decision is indeterminate at the operation 948, it is recorded at the operation 950, and the evaluation continues with other applicable policies, at the operation 910. If no applicable DoA policy is admissible or indeterminate, the decision is inadmissible, represented at the operation 918. If an indeterminate decision is encountered but no applicable policy is admissible, the decision is indeterminate, as represented at the operation 916.

[0211] Referring to FIGs. 9A and 9B, the flowchart 900 ensures that any admissible leaf policy is verified through a trust chain where each edge satisfies the trust conditions of the corresponding DoA policy. This iterative and recursive mechanism ensures the delegation chain adheres to trust thresholds, trust conditions, and authority verifications at every level. By comparing the flow depicted in FIGs. 5A and 5B, it is evident that the flow in FIGs. 9A and 9B generates admissible leaf policies only when each edge of the trust chain meets the trust conditions of its corresponding DoA policy, thereby ensuring a robust evaluation framework.

[0212] FIGs. 10A and 10B, collectively is a flowchart that depicts a series of operations of root-level evaluation of trust for delegation path, in accordance with an embodiment of the present disclosure. FIGs. 10A and 10B are described in conjunction with elements from FIGs. 1, 2, 3, 4, 5A, 5B, 6, 7, 8 and 9A-9B. With reference to FIGs. 10A and 10B, there is shown a flowchart 1000 that depicts a series of operations 1002 to 1058 of root-level evaluation of trust for delegation path.

[0213] FIGs. 9A and 9B focus on the trust evaluation process at the individual DoA policy level, where trust attributes and conditions are assessed, and authority verification is recursively performed throughout the delegation chain. These figures outline the evaluation of trust thresholds at each stage and emphasize the recursive decision-making process to establish policy admissibility.

[0214] FIGs. 10A and 10B extend this evaluation to the entire delegation path, spanning from the leaf policy to the root policy, with a focus on path admissibility and aggregated trust assessments. FIGs. 10A and 10B introduce additional steps, such as recording admissible paths and performing trust assessments for the entire delegation path at the root policy level, ensuring the trust conditions align with the requirements specified by the root DoA.

[0215] The detailed steps for this process are as follows:

[0216] At operation 1002, the delegation evaluation begins with an applicable leaf policy that requires its authority to be verified, generating an administrative request.

[0217] At operations 1004 and 1006, all relevant DoA policies and attributes are gathered based on the context of the original administrative request.

[0218] At operation 1008, the trust attributes derived from the gathered DoA policies are collected.

[0219] For each DoA policy in the collection, at the operation 1010, the evaluation begins, at the operation 1020.

[0220] At operations 1022, 1024 and 1026, during the delegation evaluation, when the root policy is reached, the trust conditions for the entire recorded path are assessed. If the path's trust conditions are satisfied, the root policy considers the path applicable. However, additional delegation evaluations must be completed to determine the final admissibility decision.

[0221] At operation 1028, if a DoA policy is not applicable, the next DoA policy in the collection is evaluated. If a policy is satisfied, it is deemed applicable.

[0222] At operation 1030, each applicable and admissible delegation path is recorded, including issuer information, for the root policy to perform a trust assessment of the entire path. The recorded information is specific to each traversed path.

[0223] At operation 1032, if authority verification is required, a new recursive administrative request is generated at the operation 1044. The initial administrative request is paused until the admissibility of the applicable DoA policy is confirmed. During recursion, the delegation evaluation is repeated to verify the admissibility of the applicable DoA policy rather than the leaf policy.

[0224] At operations 1034, 1036, 1038, 1040, and 1042, when the administrative request reaches the root policy, the final decision is determined as admissible, at the operation 1038, indeterminate, at the operation 1040, or inadmissible, at the operation 1042.

[0225] At operations 1046, 1048, 1050, 1052, 1054, 1056 and 1058, if the DoA policy is admissible, its decision is collected to answer the original administrative request. If inadmissible (at the operation 1048) or indeterminate (at the operation 1050) , the evaluation continues with other applicable DoA policies in the collection.

[0226] At operations 1012, 1014, 1016 and 1018, if all applicable DoA policies are evaluated and none are admissible or indeterminate, the decision is deemed inadmissible (represented at the operation 1018) . If an indeterminate decision is encountered without any admissible policy, the decision is marked as indeterminate (represented at the operation 1018) .

[0227] The process ensures that a selected path is admissible only if its trust conditions are satisfied for the entire path, as specified by the root DoA policy. This ensures that trust assessments for the overall delegation path are robust and align with the requirements of the root policy, as demonstrated in FIGs. 10A and 10B.

[0228] The flowchart 1000 offers an alternative method for incorporating trust assessments into delegation graphs compared to the flowchart 900. Instead of evaluating trustworthiness at each delegation graph edge based on the corresponding DoA policy, the flowchart 1000 centralizes the trust evaluation at the root policy level. This approach takes into account a pre-formed trust chain created through a successfully established delegation path, ensuring that the overall path satisfies the trust conditions specified by the root policy.

[0229] By centralizing the trust assessment, the flowchart 1000 enables a more holistic and efficient evaluation of the delegation graph, making it especially applicable to systems where a unified trust evaluation is critical for ensuring the integrity and admissibility of authority chains.

[0230] FIG. 11 is a flowchart that depicts a series of operations of an independent trust assessment decoupled from delegation evaluation, in accordance with an embodiment of the present disclosure. FIG. 11 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 5A-5B, 6, 7, 8, 9A-9B, and 10A-10B. With reference to FIG. 11, there is shown a flowchart 1100 that depicts a series of operations 1102 to 1126 of an independent trust assessment decoupled from the delegation evaluation process.

[0231] The flowchart 1100 separates trust assessment from delegation evaluation by introducing a new type of policy called the trust policy, which specifies the trustworthiness constraints of leaf policy issuers.

[0232] The trust policy is issued by the same issuer as the root DoA policies and outlines the minimum trust requirements the root demands from leaf policy issuers. Specifically, the trust policy is not a DoA policy. Instead, it is an independent policy evaluated separately.

[0233] The trust policy does not impose constraints on the delegation path because trust chain formation and trust assessment evaluation are decoupled. The flowchart 1100 does not alter the functionality of standard delegation trust chains. However, this approach introduces an additional (or parallel) step to verify the trustworthiness of leaf policy issuers, making it an alternative or complementary method to previous systems.

[0234] The flowchart 1100 is described in the following way:

[0235] At operation 1102, the process begins with a specific request requiring the evaluation of leaf policies to determine the appropriate actions. This request can be triggered by various factors, such as user actions or system events.

[0236] At operation 1104, the evaluator (i.e., the delegation evaluator 112) may be configured to collect all relevant leaf policies and check their applicability.

[0237] At operations 1108 and 1110, the evaluations of the DoA policies and the trust policy can be conducted in parallel or in any sequence because they are decoupled. However, their results must be jointly considered to decide the admissibility of the corresponding leaf policy.

[0238] At operation 1118, a leaf policy decision is admissible if and only if the issuer of the leaf policy satisfies the trust conditions specified in the trust policy, determined at operations 1110 and 1112 and has a valid delegation chain according to the specifications of the Delegation of Authority Policies, determined at operations 1108 and 1116. These two conditions must hold together for the leaf policy to be admissible.

[0239] Key decision paths are:

[0240] At operations 1110 and 1112, if the leaf policy issuer does not meet the trust conditions outlined in the trust policy, the leaf policy will be deemed inadmissible, and its decision will be disregarded, as shown at the operation 1122, even if a valid delegation chain exists according to the DoA policies.

[0241] At operations 1108 and 1114, if the DoA policies fail to establish a valid delegation chain, the leaf policy will also be considered inadmissible, and its decision will be disregarded, as shown at the operation 1122 even if the issuer satisfies the trust conditions in the trust policy.

[0242] At operation 1120, if the leaf policy satisfies the conditions of the trust policy but the DoA policies return an indeterminate decision, the leaf policy decision will also be marked as indeterminate.

[0243] At operation 1124, the decisions of all admissible leaf policies are then combined according to the specified combination logic.

[0244] At operation 1126, this results in the final decision for the original request.

[0245] Moreover, the evaluation of the trust policy is handled by a Policy Decision Point (PDP) . The PDP must be implemented to evaluate the trust policy alongside, or in addition to, the delegation evaluation. In one embodiment, the PDP is configurable, allowing a configuration file to specify whether the trust policy should be evaluated. Alternatively, the trust policy itself can serve as a configuration file, specifying whether or not trust assessment is required.

[0246] For instance, the trust policy may mandate trust assessment only under certain conditions. If these conditions are not met, the trust policy skips the trust assessment and evaluates into a permit decision. In this case, the admissibility of the leaf policy decision depends solely on the delegation evaluation.

[0247] The decoupling of the trust assessment from the delegation evaluation enhances the robustness and adaptability of delegation graphs, offering a viable alternative or complement to prior methods. There are many use cases, such as command and control structures requiring overall assurance in authority chains, certification or audit referral networks, where the trustworthiness of nodes in the chain must be assessed independently and conference systems where expert reviewers evaluate papers within defined constraints without relying on external reviewers.

[0248] FIG. 12 is a flowchart that depicts a series of operations of embedding trust assessment in leaf policies and decoupling from delegation evaluation, in accordance with an embodiment of the present disclosure. FIG. 12 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 5A-5B, 6, 7, 8, 9A-9B, 10A-10B and 11. With reference to FIG. 12, there is shown a flowchart 1200 that depicts a series of operations 1202 to 1226 of embedding trust assessment in leaf policies and decoupling from delegation evaluation.

[0249] The flowchart 1200 introduces a trust policy to decouple trust assessment from delegation evaluation. Unlike prior methods, the trust policy is not a standalone policy evaluated separately. Instead, the trust policy is embedded within the evaluation of leaf policies and combined with their decisions through a new logical policy combination algorithm.

[0250] The flowchart 1200 ensures that a leaf policy is admissible only if the trust conditions of the trust policy are satisfied. A valid delegation chain to the root authority is established through delegation evaluation. This approach is particularly suitable when the trust evaluator has a direct trust relationship with the issuers of leaf policies and can independently evaluate their trustworthiness, regardless of the delegation path. Examples include delegation of authority in international corporations, unions of member states, and industrial IoT systems where leaf policies relate to registered and assessed sensors or monitors.

[0251] At operation 1202: Initiation of the process. The process begins when a specific request is made, requiring the evaluation of leaf policies to determine the appropriate actions. This request can be triggered by user actions, system events, or other defined triggers.

[0252] At operation 1204: Collection of relevant leaf policies. The evaluator collects all relevant leaf policies and checks their applicability. Only policies related to the request are considered for further evaluation.

[0253] At operation 1208: Evaluation of trust conditions. The trust policy is evaluated in conjunction with the leaf policy.

[0254] At operation 1210: if the trust policy conditions are not met, the combined result of the trust policy and leaf policy evaluation is deemed Inapplicable, and the leaf policy is disregarded, as shown at the operation 1222. As an optimization: some implementations may skip further delegation evaluation to optimize performance. If the trust policy evaluation results in an indeterminate decision (e.g., due to missing data or errors) , the combined result is also Inapplicable, and the leaf policy is disregarded regardless of delegation evaluation.

[0255] At operation 1212: Delegation evaluation. If the trust policy conditions are satisfied, delegation evaluation is performed to determine if a valid delegation chain to the root authority exists.

[0256] At operation 1214: If a valid delegation chain cannot be established, the leaf policy decision is deemed inadmissible, and the leaf policy is disregarded as shown and determined at the operation 1222.

[0257] At operation 1218: If a valid delegation chain is established, the combined result of the trust policy and leaf policy evaluation is the same as the decision of the leaf policy. In this case, the leaf policy is considered admissible, and its decision is included.

[0258] At operation 1220: If the delegation evaluation results in an Indeterminate decision (e.g., due to errors or missing information) , the decision of the leaf policy is marked as Indeterminate.

[0259] At operation 1226: Final Decision Combination. The decisions of all admissible leaf policies are combined using predefined logic. This ensures that only decisions meeting both trust and delegation requirements are included in the final decision. The result of the combined evaluation represents the final decision for the original request.

[0260] To address the technical problem of embedding trust assessment within leaf policy evaluation, the flowchart 1200 introduces a logical policy combination algorithm. The algorithm matches the issuance characteristics of the leaf policy with the conditions specified in the trust policy and confirms admissibility only if the match is successful, the condition is met, and a valid delegation chain is established. The flowchart 1200 also represents a protocol for decoupling trust assessment from delegation evaluation. The trust policy specifies trustworthiness constraints for leaf policy issuers. The admissibility decisions are made based on both trust assessment and delegation evaluation outcomes. This solution offers flexibility and robustness, particularly for scenarios where direct trust relationships with leaf policy issuers exist, and independent evaluation of their trustworthiness is feasible.

[0261] FIG. 13 is a diagram that illustrates an implementation of a Trust Level Evaluation Engine (TLEE) as a subordinate to Policy Decision Point (PDP) within a distributed access control system, in accordance with an embodiment of the present disclosure. FIG. 13 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 5A-5B, 6, 7, 8, 9A-9B, 10A-10B, 11 and 12. With reference to FIG. 13, there is shown a diagram that illustrates the deployment of the TLEE within a distributed access control system 1300. The core components of the distributed access control system 1300 include components, such as a Trust Level Evaluation Engine (TLEE) 1302 as a subordinate of a Policy Decision Point (PDP) 1304, a Policy Administration Point (PAP) 1306, a context handler 1308, a Policy Enforcement Point (PEP) 1310, a Policy Information Point (PIP) 1312, and an obligation service 1314. The distributed access control system 1300 corresponds to the system 100 (of FIG. 1) .

[0262] The TLEE 1302 is a specialized component within the distributed access control system 1300 designed to dynamically assess the trustworthiness of entities, such as policy issuers, users, or devices, during the decision-making process. The TLEE 1302 evaluates trust assessment conditions using predefined attributes, expressions, and reduction functions to compute trust levels based on complex criteria.

[0263] The PDP 1304 is a core component of the distributed access control system 1300 responsible for evaluating access requests against defined security policies to determine whether to grant or deny access. The PDP 1304 processes input from various sources, such as user attributes, resource metadata, environmental context, and policies provided by the PAP 1306. The PDP 1304 uses this information, often with the support of additional evaluators, like the TLEE 1302, to make decisions based on frameworks, such as the Attribute-Based Access Control (ABAC) system.

[0264] The PAP 1306 is a core component of access control architectures, like XACML. The PAP 1306 is responsible for managing and administering security policies within the distributed access control system 1300. The PAP 1306 is directly connected with the PDP 1304 and serves as the authoritative point for policy management. The primary function of the PAP 1306 is to create, store, maintain, and distribute access control policies that define who has access to what resources under what conditions.

[0265] The context handler 1308 is a component in the distributed access control system 1300, responsible for mediating interactions between the various functional elements, such as the PEP 1310 and the PDP 1304. The context handler 1308 gathers relevant contextual information about an access request, such as user attributes, environmental conditions, or resource properties, and provides it to the PDP 1304 for policy evaluation. Additionally, the context handler 1308 may interact with external data sources or attribute authorities to retrieve or validate attributes required for decision-making.

[0266] The PEP 1310 is a key component in the distributed access control system 1300 that acts as the gatekeeper for enforcing access decisions. The PEP 1310 is responsible for intercepting access requests from users or systems and forwarding them to the PDP 1304 for evaluation. Once the PDP 1304 provides a decision, such as "permit" or "deny" , the PEP 1310 enforces this decision by either allowing or blocking the requested action on the resource. The PEP 1310 ensures that access control policies are consistently applied at the point of interaction with the resource, making it a crucial part of securing systems and enforcing compliance with organizational policies.

[0267] The PIP 1312 is a component in the distributed access control system 1300 responsible for providing attribute information required for policy evaluation. The PIP 1312 serves as a source of data, delivering contextual, environmental, subject, or resource attributes to the PDP 1304. The PIP 1312 can retrieve these attributes from various internal or external sources, such as databases, directories, or sensors, and provides them in real-time to support dynamic decision-making.

[0268] The obligation service 1314 is a component of the distributed access control system 1300 that handles the execution of additional actions or conditions mandated by a policy decision. When the PDP 1304 evaluates an access request, it may include obligations specific tasks or requirements that must be fulfilled alongside the "permit" or "deny" decision. These obligations are enforced by the obligation service 1314 and can include actions, such as logging the access event, sending notifications, updating system states, or triggering workflows.

[0269] Referring to the FIG. 13, is an exemplary scenario of deploying the TLEE 1302 within the distributed access control system 1300, which may be a standardized Attribute-Based Access Control (ABAC) system, such as XACML. Here, the TLEE 1302 is integrated as a subordinate evaluator within the PDP 1304 to handle complex trust evaluations for DoA policies 104. The delegate 120 submits an access request to the PEP 1310, which forwards it to the PDP 1304. The PDP 1304 identifies all relevant authorization policies applicable to the request and evaluates each policy individually. If a policy includes a trust condition requiring an admissibility check, the PDP 1304 invokes the TLEE 1302 to compute the trust score based on predefined trust expressions, such as reputation scores or probabilistic logic expressions. For instance, the TLEE 1302 might calculate a trust score for an issuer using weighted biometric data or a Bayesian conformity check against EU regulations. Once the TLEE 1302 computes the trust level, the PDP 1304 compares it against the threshold specified in the trust assessment policy. If the trust score meets or exceeds the threshold, the policy is deemed admissible. Otherwise, it is disregarded. The admissible policy decisions are then aggregated using the PDP's combination logic, and the final decision is sent to the PEP 1310 for enforcement. This deployment strategy is particularly advantageous in scenarios requiring root policy evaluations with consistent trust metrics or multi-administration environments where trust assessment policies involve complex expressions. By integrating the TLEE 1302 in-line with the PDP 1304, the distributed access control system 1300 ensures robust and dynamic trust evaluations that adapt to evolving policy requirements while maintaining compliance with a standardized framework.

[0270] In an exemplary scenario, consider an organization where a third-party contractor requires access to sensitive project documentation stored in a cloud-based repository. The TLEE 1302 is deployed as the subordinate evaluator to the PDP 1304, enabling real-time trust assessment during access requests. When the contractor initiates an access request through the PEP 1310, the distributed access control system 1300 activates a comprehensive evaluation sequence. The PDP 1304 first retrieves relevant authorization policies, including specific trust conditions that evaluate the contractor's trust attributes such as previous project completion rate, security clearance level, and current contract status. The TLEE 1302 processes these trust attributes using predefined reduction functions to calculate a normalized trust score. For instance, if the contractor's historical project completion rate is 95%, security clearance is level 3, and the contractor has an active contract status, the TLEE 1302 might compute a composite trust score of 0.85 on a scale of 0 to 1. This score is then compared against the threshold specified in the trust assessment policy, for example 0.80, to determine policy admissibility. In this case, since the calculated trust score (0.85) exceeds the predetermined threshold (0.80) , the authorization policy would be deemed admissible, and the PDP 1304 would proceed with evaluating other access control criteria before reaching a final decision on granting access to the requested project documentation.

[0271] FIG. 14 is a diagram that illustrates an implementation of TLEE as an optional auxiliary function for attribute value retrieval within a distributed access control system, in accordance with an embodiment of the present disclosure. FIG. 14 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 5A-5B, 6, 7, 8, 9A-9B, 10A-10B, 11, 12 and 13. With reference to FIG. 14, there is shown a diagram that illustrates an implementation of the TLEE 1302 as an optional auxiliary function for attribute value retrieval within a distributed access control system 1400. The distributed access control system 1400 corresponds to the system 100 (of FIG. 1) .

[0272] Referring the FIG. 14, is another exemplary scenario of the distributed access control system 1400 utilizing embedded trust calculation instructions between the PIP 1312 and the TLEE 1302. The delegate 120 initiates an access request via the PEP 1310, which forwards the request to the PDP 1304. The PDP 1304 identifies applicable authorization policies and evaluates them individually. If a policy includes a trust condition requiring an admissibility check, the PDP 1304 defines trust attribute reductions within the policy. It then retrieves the required trust attributes from the PIP 1312. The PIP 1312 invokes the TLEE 1302, which calculates the trust level based on instructions embedded in the protocol. For instance, the TLEE 1302 might assess the trust score of a delegator using predefined algorithms, such as reputation analysis or probabilistic logic, and return the calculated value to the PIP 1312. The PDP 1304 uses the trust score to determine the policy's admissibility. If the policy fails to meet the required trust threshold, its decision is disregarded. The admissible policy decisions are combined based on specified combination logic, and the final decision is forwarded to the PEP 1310 for enforcement. This approach ensures semantic independence and self-contained trust calculations, making it particularly effective in scenarios requiring dynamic and context-sensitive trust assessments. By enabling trust values to be computed directly within the TLEE 1302 based on PIP 1312 instructions, this method simplifies trust evaluation in complex delegation frameworks while maintaining flexibility and compliance with access control requirements.

[0273] FIG. 15 is a diagram that illustrates a Policy Information Point (PIP) with a generic trust evaluator within a distributed access control system, in accordance with an embodiment of the present disclosure. FIG. 15 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 5A-5B, 6, 7, 8, 9A-9B, 10A-10B, 11, 12, 13, and 14. With reference to FIG. 15, there is shown a diagram that illustrates the PIP 1312 with a generic trust evaluator within the distributed access control system 1400.

[0274] Referring to FIG. 15, in a simplified trust evaluation strategy, trust levels are treated as attributes provided by the PIP 1312, making it ideal for straightforward trust evaluation functions or domain-specific algorithms tied to attribute semantics. The delegate 120 initiates an access request through the PEP 1310, and the PDP 1304 gathers applicable authorization policies for evaluation. If a policy requires an admissibility check, trust conditions are defined as attributes within the policy. The PDP 1304 retrieves these trust attributes from the PIP 1312, which responds with corresponding trust scores based on predefined criteria. The PDP 1304 uses these scores to determine policy admissibility, disregarding inadmissible policies. The admissible decisions are then combined using specified logic and forwarded to the PEP 1310 for enforcement. This approach is particularly effective in standardized evaluations and domain-specific scenarios, ensuring flexibility and efficiency in access control.

[0275] FIG. 16 illustrates an exemplary implementation scenario of authority delegation in a multi-administrative authority system, in accordance with an embodiment of the present disclosure. FIG. 16 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 5A-5B, 6, 7, 8, 9A-9B, 10A-10B, 11, 12, 13, 14, and 15. With reference to FIG. 16, there is shown an exemplary implementation scenario 1600 of authority delegation in a multi-administrative authority system. The exemplary implementation scenario 1600 in multi-level authority architectures, as exemplified by the patent’s delegation mechanism, policies are critical for defining and controlling the rights and responsibilities across different administrative levels. For instance, a higher authority, such as a security officer in Department 2, establishes a root policy (Policy P1) requiring delegates like Carol, a manager in Department 1, to meet a trustworthiness threshold (e.g., trust score > 80) to exercise delegated authority. This threshold is assessed by the TLEE 1302, which evaluates Carol’s trustworthiness using factors, like her compliance history and recent activities. Once Carol meets this requirement, she can issue subordinate policies (e.g., Policy P2) , enabling employees, like Bob to access specific resources, such as document 1, under her scope of authority. Supporting this process, are various components, including the PAP 1306, the PDP 1304, and the PEP 1310, which ensure secure and seamless policy creation, evaluation, and enforcement. The patent’s integrated system not only validates Carol’s authority but also facilitates secure delegation and access control, making it applicable to both single-level and complex multi-level delegation chains.

[0276] FIG. 17 illustrates an exemplary implementation scenario of data access through consent-based delegation of authority, in accordance with an embodiment of the present disclosure. FIG. 17 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 5A-5B, 6, 7, 8, 9A-9B, 10A-10B, 11, 12, 13, 14, 15 and 16. With reference to FIG. 17, there is shown an implementation scenario 1700 of data access through consent-based delegation of authority. The implementation scenario 1700 is applicable to a General Data Protection Regulation (GDPR) -compliant data management system, where the secure delegation of authority ensures that personal data access and processing rights align with the explicit consent of the data subject. The system enforces a multi-level policy evaluation process where permissions are passed down conditionally from the root authority (e.g., CISO) to intermediate roles (e.g., Data Subject and Manager) and ultimately to an end user (e.g., Bob) . For instance, when Bob requests access to retain data during working hours, the system evaluates policy P3, issued by Joe (the Manager) , which specifies this condition. To validate P3, the system examines policy P2, issued by Alice (the Data Subject) , which allows managers to define processing policies if their manager trust score exceeds, for example, 90. The TLEE 1302 assesses Joe’s trustworthiness to ensure compliance. Furthermore, the evaluation extends to Policy P1 (the root policy issued by the CISO) , granting Alice (the authority to delegate permissions) if her Data_Subject_Trust score is above 90. By confirming the trustworthiness at each level, P1 through P3, the system ensures that the entire delegation chain adheres to GDPR requirements and respects the Data Subject’s consent. Only when all policies meet the defined trust thresholds, Bob is permitted to proceed with data retention, demonstrating a robust mechanism for secure and compliant delegation.

[0277] The system 100 provided in the present disclosure significantly advances beyond traditional XACML and UCON+ frameworks by introducing a comprehensive trust-aware delegation mechanism that addresses limitations in existing systems. Unlike XACML's assumption of uniform trust across all policy issuers and UCON+'s limited scope in trust evaluation, the system 100 provides a flexible and extensible approach that considers the trustworthiness of both individual policies and entire delegation chains. The system's flexibility is particularly valuable as it can be applied across multiple policy implementations including OPA Rego, AWS Cedar, and RBAC, making it more versatile than XACML's limited administrative delegation profile. Additionally, while UCON+ with TLEE only considers trust in authorization logic, the system 100 comprehensively evaluates trustworthiness at both the individual policy level and across entire delegation chains, enabling more nuanced and secure policy management.

[0278] Modifications to embodiments of the present disclosure described in the foregoing are possible without departing from the scope of the present disclosure as defined by the accompanying claims. Expressions such as "including" , "comprising" , "incorporating" , "have" , "is" used to describe and claim the present disclosure are intended to be construed in a non-exclusive manner, namely allowing for items, components or elements not explicitly described also to be present. Reference to the singular is also to be construed to relate to the plural. The word "exemplary" is used herein to mean "serving as an example, instance or illustration" . Any embodiment described as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments and / or to exclude the incorporation of features from other embodiments. The word "optionally" is used herein to mean "is provided in some embodiments and not provided in other embodiments" . It is appreciated that certain features of the present disclosure, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the present disclosure, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable combination or as suitable in any other described embodiment of the disclosure.

Claims

1.A method (200) of evaluating a delegation of authority from a delegator (118) to a delegate (120) in a distributed access control system for governing access to a digital data resource (122) , wherein the distributed access control system is distributed across a plurality of geographical locations, the method (200) comprising steps of:(a) receiving a plurality of leaf policies (102) , wherein each leaf policy specifies actions and rules associated with access control in the distributed access control system, wherein each leaf policy requires an authority verification;(b) receiving a plurality of delegation of authority policies, DoAPs, (104) , wherein each DoAP specifies characteristics that define a policy identification, and wherein each DoAP, except for a root DoAP, requires an authority verification;(c) checking for an authority verification for each leaf policy and for each DoAP;(d) generating a plurality of recursive administration requests based on the checking step until the root DoAP is reached; and(e) responding to each of the plurality of recursive administration requests to ensure that each DoAP is resolved, thereby evaluating a delegation of authority in the distributed access control system, wherein the responding is carried out in a reverse order, starting from the root DoAP.2.The method (200) of claim 1, wherein trust assessment conditions are incorporated into the DoAPs.3.The method (200) of claim 2, wherein the trust assessment conditions include trust attributes representing a delegate’s trustworthiness.4.The method (200) of claim 2, wherein a trustworthiness path is selected based on the trust assessment conditions.5.The method (200) of claim 2, wherein the trust assessment conditions are checked at the checking step (c) .6.The method (200) of claim 1, wherein trust assessment conditions are incorporated into the root DoAP.7.The method (200) of claim 6, wherein the root DoAP includes trust assessment conditions for each of the plurality of DoAPs.8.The method (200) of claim 1, wherein an additional policy, designated as a Trust Configuration Policy, specifies the trustworthiness conditions required to allow a leaf policy to be considered admissible.9.The method (200) of claim 8, wherein a leaf policy is considered to be admissible when it passes: (i) the trustworthiness condition assessment of the leaf policy; and (ii) a delegation evaluation.10.The method (200) of claim 8, wherein the Trust Configuration Policy is evaluated concurrently with the checking step (c) .11.The method (200) of claim 8, wherein the Trust Configuration Policy is evaluated prior to the checking step (c) .12.The method (200) of claim 1, wherein a trust assessment policy is embedded into each leaf policy.13.The method (200) of claim 12, wherein the evaluation of the leaf policy takes place concurrently with the evaluation of the trust assessment policy.14.A system (100) comprising means adapted for carrying out all the steps of the method (200) according to any preceding method claim.15.A computer program comprising instructions for carrying out all the steps of the method (200) according to any preceding method claim, when said computer program is executed on a computer system.

Images