System and method of establishing trust between entities in decentralized data processing environment

Abstract

A method of establishing trust between entities in a decentralized data processing environment implementing a credentials bridge middleware platform. The method including steps of: receiving input claims at a claim normalizer component, where the input claims are represented in a plurality of assertion formats, parsing the received input claims at the claim normalizer component using a parser extension, transforming the parsed input claims at the claim normalizer component into a common syntactic representation, receiving, at a claim evaluator component, the transformed parsed claims in the common syntactic representation, along with normalized attributes, from the claim normalizer component, fetching, by the claim evaluator component, context attributes from an attribute interface component, evaluating, at the claim evaluator component, a claim transformation policy using the normalized attributes and the context attributes and generating, at the claim evaluator component, obligatory actions that is used to generate Claims Execution Policies (CXP) for establishing trust between entities in the decentralized data processing environment.

Description

SYSTEM AND METHOD OF ESTABLISHING TRUST BETWEEN ENTITIES IN DECENTRALIZED DATA PROCESSING ENVIRONMENTTECHNICAL FIELD

[0001] The present disclosure relates generally to the field of decentralized data processing environments; and more specifically, to a system and method of establishing trust between entities in a decentralized data processing environment implementing a credentials bridge middleware platform.BACKGROUND

[0002] In modern decentralized environments, the establishment of trust between entities through selective disclosure of identification information, credentials, and trust protocols is fundamental to secure data exchange and service utilization. This trust relationship typically involves three key parties: Issuers, Holders, and Verifiers. Issuers are entities that issue claims about a Subject to Holders, who maintain these claims in digital wallets. Verifiers are entities that verify these claims during interactions with Holders. However, several significant challenges hinder the effective implementation of trust frameworks and protocols in such environments. One challenge is protocol incompatibility in which the claims issued by trusted entities often rely on legacy protocols that may not be compatible with modern trust agreements. This incompatibility can prevent successful trust negotiations, especially in scenarios involving evolving identity systems or varying technical standards. Another issue arises from the inability to meeting the localization requirements for the claims across different jurisdictions impacting interoperability between different trust agreements. The claims issued by an authority in one jurisdiction often fail to meet the diverse legal and cultural requirements of other regions (or jurisdictions) . The static configurations for localization requirements make compliance difficult, particularly in cross-border interactions, where dynamic adaptability is fundamental. A further complication is the requirement for contextual customization of protocol execution. The trust negotiation protocols typically require multiple interactions between holders and verifiers. Customizing these interactions to align with the specific context of a transaction adds complexity, especially when entities operate across ecosystems governed by disparate trust frameworks. The static configurations often lead to rigid implementations, unable to adapt to the dynamic and evolving requirements of the environment.

[0003] Existing solutions partially address the aforementioned challenges but are inadequate in several respects. For instance, the conventional credential transformation methods often treat incoming credentials as monolithic entities, failing to account for the semantic and structural interdependencies within claims. The conventional methods are typically static, requiring significant manual intervention to accommodate changes in protocols or localization requirements. Additionally, the conventional methods do not differentiate between various stages in the lifecycle of credentials, nor do they incorporate policies that dynamically adapt to the context of credential exchange. Thus, there exists a technical problem wherein the conventional credential transformation methods lack in real-time adaptation of transformation policies and fail to support dynamic policy generation for selective disclosure, resulting in potential incompatibilities, compliance issues, and security vulnerabilities in decentralized trust environments.

[0004] Therefore, in light of the foregoing discussion, there exists a need to overcome the aforementioned drawbacks associated with the conventional credential transformation methods.SUMMARY

[0005] The present disclosure provides a system and method of establishing trust between entities in a decentralized data processing environment implementing a credentials bridge middleware platform. The present disclosure provides a solution to the existing problem where the conventional credential transformation methods lack in real-time adaptation of transformation policies and fail to support dynamic policy generation for selective disclosure, resulting in potential incompatibilities, compliance issues, and security vulnerabilities in decentralized trust environments. An aim of the present disclosure is to provide a solution that overcomes at least partially the problems encountered in prior art, and provide an improved system and method of establishing trust between entities in a decentralized data processing environment implementing a credentials bridge middleware platform.

[0006] 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.

[0007] In one aspect, the present disclosure provides a method of establishing trust between entities in a decentralized data processing environment implementing a credentials bridge middleware platform. The method comprises receiving input claims at a claim normalizer component of the credentials bridge middleware platform, wherein an input claim is an assertion made by an issuance authority regarding the attributes, rights or status of a subject, wherein the input claims are represented in a plurality of assertion formats. The method further comprises parsing the received input claims at the claim normalizer component using a parser extension corresponding to each of the plurality of assertion formats and transforming the parsed input claims at the claim normalizer component into a common syntactic representation. The method further comprises receiving, at a claim evaluator component of the credentials bridge middleware platform, the transformed parsed claims in the common syntactic representation, along with normalized attributes, from the claim normalizer component. The method further comprises fetching, by the claim evaluator component, context attributes from an attribute interface component of the credentials bridge middleware platform and evaluating, at the claim evaluator component, a claim transformation policy (CTP) using the normalized attributes and the context attributes. The method further comprises generating, at the claim evaluator component, obligatory actions for establishing trust between entities in the decentralized data processing environment, based on the results of the evaluating step.

[0008] The disclosed method provides comprehensive credential management capabilities, encompassing various types of transformations. The transformations include not only basic format conversions but also more sophisticated operations, such as semantical mapping with association preservation, credential aggregation, and the incorporation of derivative or additional credentials. The disclosed method uniquely combines credential transformation with usage policies and can transform credentials into policies that govern protocol execution. The disclosed method employs the CTP for mapping the input claims and the CXP that governs protocol behavior. This dual-policy approach allows for localized rule interpretation based on different contexts, such as specific regions or regulatory realms, making the method highly adaptable to various implementation requirements. The method can be employed in an extensible Usage Control (UCON+) policy framework which enhances the practical applicability of the method. These features contribute to significant advantages in terms of interoperability, allowing for seamless access across services using different protocols while supporting decentralized credentials and shared responsibility architectures. The method's flexibility makes the method particularly valuable for future solutions requiring decentralized credentials, as the method can adapt to different situations and localities while maintaining compatibility with existing policy framework technologies.

[0009] In an implementation form, a CTP management interface component of the credentials bridge middleware platform is configured to manage and provide the CTP to the claim evaluator component.

[0010] The integration of the CTP management interface component with the claim evaluator component results in a more cohesive system that can adapt to changing requirements and provide timely insights, thereby increasing overall system reliability and user satisfaction.

[0011] In a further implementation form, a session interface component of the credentials bridge middleware platform is configured to provide functionality to the CTP management interface component to initiate a session based on a specific CTP evaluation context.

[0012] The initiation of the session for the CTP evaluation ensures that the sessions are tailored to specific evaluation contexts, enhancing the relevance and accuracy of the CTP management process.

[0013] In a further implementation form, a claims execution policy (CXP) builder component of the credentials bridge middleware platform is configured to generate a CXP and a plurality of transformed claims based on the obligatory actions generated by the claim evaluator component.

[0014] The CXP builder component enables dynamic adaptation to varying claim scenarios, ensuring that the generated policies and claims are relevant and actionable, ultimately enhancing the overall performance of a credential management system.

[0015] In a further implementation form, the claim normalizer component is configured to utilize a read configuration file to obtain information on a parser extension and on context uniform resource identifier.

[0016] By utilizing the read configuration file, the method can be easily updated to support new formats or sources without requiring significant changes to the underlying architecture. This adaptability is required in environments where claims may come from diverse issuers with varying formats.

[0017] In a further implementation form, the claim normalizer component is configured to load a specific parser extension as specified in the read configuration file.

[0018] By validating the configuration file and determining the appropriate parser, the method can be used to handle various claim formats effectively, thereby enhancing the method’s flexibility and adaptability to different input scenarios.

[0019] In a further implementation form, the read configuration file is represented in a specific syntactic format which contains details regarding required parser extensions and corresponding version numbers.

[0020] By clearly defining the required parser extensions and their versions in the structured format, the method can dynamically adapt to different claim formats and assertion types. This ensures that the appropriate parsing capabilities are available when required, reducing the risk of errors and improving overall performance.

[0021] In a further implementation form, the claim evaluator component is configured to read a CTP from the CTP management interface component using a CTP identifier and loads a retrieved CTP for use in the evaluating step.

[0022] By using the unique identifier, the desired CTP can be quickly located and retrieved, which is required for maintaining accuracy and reliability in the evaluation process.

[0023] In a further implementation form, the claim evaluator component is configured to send the obligatory actions to the CXP builder component.

[0024] By sending the obligatory actions to the CXP builder component, a clear workflow is maintained while reducing the likelihood of errors and enhancing the overall performance.

[0025] In a further implementation form, wherein each of the obligatory actions is configured to hold a CXP identifier.

[0026] Such configuration is required to ensure that each obligatory action is directly linked to the specific CXP identifier, facilitating accurate retrieval \and processing of policies.

[0027] In a further implementation form, the CXP builder component is configured to download a CXP build extension based on extension details specified in the read configuration file.

[0028] By downloading extensions based on specified details, the CXP builder component can maintain flexibility, allowing for updates and modifications without manual intervention, thus enhancing user experience and operational efficiency.

[0029] In a further implementation form, the claim normalizer component is configured to compare a semantic meaning of attributes associated with the credentials bridge middleware platform with those associated with the received claims.

[0030] By comparing semantic meanings, the method can be used to identify discrepancies or misalignments in the data, which aids in the accurate assessment and categorization of claims.

[0031] In a further implementation form, the claim normalizer component is configured to store normalized attributes in a key value store for forwarding to the claim evaluator component.

[0032] The storage of the normalized attributes in the key-value store enhances data organization and retrieval efficiency.

[0033] In another aspect, the present disclosure provides a system comprising means adapted for carrying out all the steps of the method of the present disclosure.

[0034] The system achieves all the advantages and effects of the method after execution of the method.

[0035] In a yet another aspect, the present disclosure provides a computer program comprising instructions for carrying out all the steps of the method, when said computer program is executed on a computer system.

[0036] It is to be appreciated that all the aforementioned implementation forms can be combined.

[0037] It has to be noted that all devices, elements, circuitry, units and means described in the present application could be implemented in the software or hardware elements or any kind of combination thereof. All steps which are performed by the various entities described in the present application as well as the functionalities described to be performed by the various entities are intended to mean that the respective entity is adapted to or configured to perform the respective steps and functionalities. Even if, in the following description of specific embodiments, a specific functionality or step to be performed by external entities is not reflected in the description of a specific detailed element of that entity which performs that specific step or functionality, it should be clear for a skilled person that these methods and functionalities can be implemented in respective software or hardware elements, or any kind of combination thereof. It will be appreciated that features of the present disclosure are susceptible to being combined in various combinations without departing from the scope of the present disclosure as defined by the appended claims.

[0038] 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

[0039] 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.

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

[0041] FIG. 1 illustrates a system of establishing trust between entities in a decentralized data processing environment implementing a credentials bridge middleware platform, in accordance with an embodiment of the present disclosure;

[0042] FIG. 2 is a flowchart of a method of establishing trust between entities in a decentralised data processing environment implementing a credentials bridge middleware platform, in accordance with an embodiment of the present disclosure;

[0043] FIG. 3 is a flowchart that depicts credential transformation using a credentials bridge middleware platform, in accordance with an embodiment of the present disclosure;

[0044] FIG. 4 illustrates an architecture of a credentials bridge middleware system, in accordance with an embodiment of the present disclosure;

[0045] FIG. 5 illustrates various exemplary interfaces of a claim normalizer component, in accordance with an embodiment of the present disclosure;

[0046] FIG. 6 is a flowchart of data flow between various interfaces of a claim normalizer component, in accordance with an embodiment of the present disclosure;

[0047] FIG. 7 illustrates a data flow in a parser interface of a claim normalizer component, in accordance with an embodiment of the present disclosure;

[0048] FIG. 8 is an exemplary implementation scenario of a claim normalizer component in an extensible Usage Control (UCON+) framework, in accordance with an embodiment of the present disclosure;

[0049] FIG. 9 illustrates various exemplary interfaces of a claim evaluator component, in accordance with an embodiment of the present disclosure;

[0050] FIG. 10 is a flowchart of data flow between various interfaces of a claim evaluator component, in accordance with an embodiment of the present disclosure;

[0051] FIG. 11 is an exemplary implementation scenario of a claim evaluator component in an UCON+ framework, in accordance with an embodiment of the present disclosure;

[0052] FIG. 12 illustrates various exemplary interfaces of a CXP builder component, in accordance with an embodiment of the present disclosure;

[0053] FIG. 13 is a flowchart of data flow between various interfaces of a CXP builder component, in accordance with an embodiment of the present disclosure;

[0054] FIG. 14 is an exemplary implementation scenario of a CXP builder component in a UCON+ framework, in accordance with an embodiment of the present disclosure;

[0055] FIG. 15 illustrates an exemplary implementation scenario of a credentials bridge middleware platform on a dataspace connector, in accordance with an embodiment of the present disclosure; and

[0056] FIG. 16 illustrates another exemplary implementation scenario of a credentials bridge middleware platform on an Artificial Intelligence (AI) agent, in accordance with an embodiment of the present disclosure.

[0057] 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

[0058] 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.

[0059] FIG. 1 illustrates a system of establishing trust between entities in a decentralized data processing environment implementing a credentials bridge middleware platform, in accordance with an embodiment of the present disclosure. With reference to FIG. 1, there is shown a system 100 of establishing trust between entities in a decentralized data processing environment implementing a credentials bridge middleware platform. There is shown a processor 104 configured to connect with each of a claim normalizer component 106, a claim evaluator component 108 and a Claims Execution Policy (CXP) builder component 110 of a credentials bridge middleware platform 102. There is further shown a Claim Transformation Policy (CTP) management interface component 112, a session interface component 114 and an attribute interface component 116, which are associated with the claim evaluator component 108. Optionally, the credentials bridge middleware platform 102 may have a memory 118 and a network interface 120 connected to each of the claim normalizer component 106, the claim evaluator component 108 and the CXP builder component 110. Moreover, each of the claim normalizer component 106, the claim evaluator component 108 and the CXP builder component 110 may operate either independent of the processor 104 or in conjunction with the processor 104.

[0060] There is provided the system 100 for establishing trust in a decentralized data processing environment which is configured to leverage the credentials bridge middleware platform to validate and transform claims between entities through configurable Claim Transformation Policies (CTPs) and Claim Execution Policies (CXPs) . Trust is established by normalizing incoming credential claims into a standardized format, evaluating the credential claims against predefined policies, and generating appropriate transformed claims or execution policies that satisfy the trust requirements of both the originating and receiving entities. This trusted bridge enables secure cross-domain interactions by ensuring that credentials from one trust domain can be properly evaluated, transformed, and accepted within another trust domain while maintaining the semantic meaning and security properties of the original claims. The system 100 may also be referred to as either a credentials management system or a credentials bridge middleware system.

[0061] The processor 104 may include suitable logic, circuitry, and / or interfaces that is configured to execute instructions stored in the memory 118. Examples of the processor 104 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 104 may refer to one or more individual processors, processing devices, a processing unit that is part of a machine.

[0062] The claim normalizer component 106 may include suitable logic, circuitry, and / or interfaces that is configured to standardize and transform input claims into a uniform format for efficient processing and validation. The claim normalizer component 106 may be a hardware module or a software module or a combination thereof. The claim normalizer component 106 may also be referred to as a claim normalization module or credential normalization module.

[0063] The claim evaluator component 108 may include suitable logic, circuitry, and / or interfaces that is designed to assess and analyze the validity and compliance of claims within a specified framework. The claim evaluator component 108 may be a hardware module or a software module or a combination thereof. The claim evaluator component 108 may also be referred to as a claim evaluation module.

[0064] The CXP builder component 110 may include suitable logic, circuitry, and / or interfaces that is designed to facilitate the construction and customization of credential exchange processes within the credentials bridge middleware platform 102, enabling seamless integration and management of user authentication and authorization workflows. The CXP builder component 110 may be a hardware module or a modular software module or a combination thereof. The CXP builder component 110 may also be referred to as a CXP building module.

[0065] The CTP management interface component 112 may be referred to as a software module that facilitates the interaction between users and the credentials bridge middleware platform 102, enabling the configuration, monitoring, and administration of credential transactions. The CTP management interface component 112 implements functionality to manage CTPs used by the claim evaluator component 108. The CTP management interface component 112 is configured to provide Application Programing Interfaces (APIs) for managing the CTPs which includes storing, listing and retrieving CTPs, with each CTP given a unique identifier. The CTP management interface component 112 is configured to provide drivers to integrate with different types of storage mediums (e.g., various databases or file storage) where the CTP is stored. The CTP management interface component 112 is configured to provide a user interface (UI) to the users to edit the CTP templates to guide users in authoring CTPs according to their requirements.

[0066] The session interface component 114 is configured to integrate with the claim evaluator component 108 to track and initiate a session for each CTP evaluation context. Each new CTP evaluation context is tracked using a session id.

[0067] The attribute interface component 116 may be referred to as a modular element within a software architecture that facilitates the interaction and manipulation of various attributes, enabling seamless integration and management of data within the system 100. The attribute interface component 116 is required to implement functionality to handle the attributes required by the claim evaluator component 108 from the context / environment of the evaluation. The claims of attributes include, but are not limited to, the following, attributes related to the context variables under which the claims being evaluated, attributes based on the system configuration and attributes required by verifying entities.

[0068] The memory 118 may include suitable logic, circuitry, and / or interfaces that is configured to store machine code and / or instructions executable by the processor 104. Examples of implementation of the memory 118 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. The memory 118 may store an operating system and / or a computer program product to operate the system 100. 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. The memory 118 may be configured to store an input (s) or an output (s) of either any or all of the claim normalizer component 106, the claim evaluator component 108 and the CXP builder component 110.

[0069] The network interface 120 may include suitable logic, circuitry, and / or interfaces by virtue of which the claim normalizer component 106 receives the input claims. Examples of each of the network interface 120 may include, but are not limited to, a radio frequency transceiver, a telematics unit, or any antenna suitable for use in the system 100.

[0070] In operation, the system 100 of establishing trust between entities in a decentralized data processing environment implements a credentials bridge middleware platform, the system 100 includes the processor 104 configured to receive input claims at the claim normalizer component 106 of the credentials bridge middleware platform 102, where an input claim is an assertion made by an issuance authority regarding the attributes, rights or status of a subject, and where the input claims are represented in a plurality of assertion formats.

[0071] The decentralized data processing environment is defined as a distributed computing architecture where data processing, storage, and computation tasks are performed across multiple independent nodes or entities without relying on a central authority for coordination or control. In this environment, each participating entity maintains autonomy over its resources and policies while still being able to collaborate and share data with other entities through standardized protocols and trust frameworks. The decentralized nature provides enhanced resilience, scalability, and privacy as no single entity has complete control over the system, while also introducing challenges around trust establishment, interoperability, and policy enforcement across different organizational boundaries. The system 100 resolves aforementioned challenges of trust establishment, interoperability, and policy enforcement across different organizational boundaries by implementing the credentials bridge middleware platform.

[0072] The credentials bridge middleware platform 102 is a specialized software layer that facilitates secure and interoperable credential exchange between different trust domains and identity systems by normalizing, evaluating, and transforming credential claims. The platform employs CTPs to define how credentials should be processed and CXPs are generated from the input claims using the CTPs. The generated CXPs are used to govern the behavior of protocols used in credential provisioning, enabling organizations to maintain their existing identity infrastructure while safely participating in cross-domain interactions. The platform acts as a trust bridge by ensuring that credentials issued in one domain can be properly understood, validated, and accepted in another domain while preserving their security properties and semantic meaning through its core modules for claim normalization, evaluation, and policy enforcement.

[0073] The term "input claims" refers to the assertions or statements provided by users or systems that specify the credentials or qualifications to be validated by the credentials bridge middleware platform 102. The term "issuance authority" refers to an entity or organization responsible for the generation and distribution of credentials within the credentials bridge middleware platform 102. The term "attributes" refers to the specific characteristics or properties associated with a credential that define its scope and applicability. The term "rights" refers to the permissions or entitlements granted to a credential holder, enabling access to certain resources or functionalities. The term "status" refers to the current condition or validity of a credential, indicating whether the credential is active, expired, or revoked. The term "subject" refers to an individual or entity to whom a credential is issued, representing the bearer of the associated rights and attributes. The term "assertion formats" refers to structured representations of claims or statements that convey specific information regarding the validity or attributes of credentials within the credentials bridge middleware platform 102, facilitating interoperability and communication between disparate systems.

[0074] The system 100 is configured to utilize the decentralized architecture to facilitate trust among various entities by employing the credentials bridge middleware platform 102. This platform acts as an intermediary that processes input claims, which are assertions made by the issuing authority. The credentials bridge middleware platform 102 verifies the input claims against established criteria and protocols, ensuring that the attributes, rights, or status of the subject are accurately represented and authenticated. The decentralized nature of the environment allows for distributed validation, reducing reliance on a single point of failure and enhancing security. By representing the input claims in multiple assertion formats, the system 100 accommodates the varying requirements and capabilities of different entities, promoting interoperability. This approach enhances user confidence and encourages participation in the decentralized network, as entities can verify claims in a manner that aligns with their specific protocols.

[0075] The processor 104 may be further configured to parse the received input claims at the claim normalizer component 106 using a parser extension corresponding to each of the plurality of assertion formats. The system 100 is configured to utilize the claim normalizer component 106 that receives the input claims in various assertion formats. Each assertion format is associated with a specific parser extension that is designed to interpret the structure and semantics of the claims. Upon receiving the claims, the claim normalizer component 106 identifies the format and invokes the corresponding parser extension to extract relevant data and transform the input claims into a standardized representation. This process ensures that claims from different sources can be uniformly processed and understood within the system 100. This approach is implemented to facilitate interoperability among diverse entities operating in the decentralized environment. By normalizing the input claims from multiple assertion formats, the system 100 enhances communication and trust between entities, allowing the various entities to verify and validate claims efficiently. The system 100 addresses the challenges posed by varying data formats and ensures that all entities can engage with the information in a consistent manner.

[0076] In accordance with an embodiment, the claim normalizer component 106 is configured to utilize a read configuration file to obtain information on a parser extension and on context uniform resource identifier. The term "read configuration file" refers to the process of accessing and interpreting a designated file that contains parameters and settings utilized by a software application or system to configure its operational behavior. The term "context uniform resource identifier" refers to a specific type of identifier that provides a means to uniquely reference a resource within a particular context, facilitating the retrieval and interaction with that resource in a standardized manner. The claim normalizer component 106 is configured to utilize the read configuration file to extract required information regarding parser extensions and context uniform resource identifiers. This claim normalizer component 106 is configured to specify supported parser extensions based on the assertion format of the input claims. The configuration file is read to identify the appropriate parser extension required for processing the input claims, such as a JavaScript Object Notation for Linked Data (JSON-LD) parser for Verifiable Credentials using JSON-LD (VC-JSON-LD) formatted claims. Additionally, the claim normalizer component 106 is configured to retrieve links to vocabulary sources associated with specific claims or issuers, ensuring that the correct context is applied during parsing. This approach is implemented to ensure that the claim normalizer component 106 can dynamically adapt to various assertion formats and parser requirements specified by entities thereby, enhancing the system's flexibility and interoperability. By utilizing the configuration file, the system 100 can be easily updated to support new formats or sources without requiring significant changes to the underlying architecture. This adaptability is required in environments where claims may come from diverse issuers with varying formats.

[0077] In accordance with an embodiment, the claim normalizer component 106 is configured to load a specific parser extension as specified in the read configuration file. The claim normalizer component 106 is configured to access the configuration file that outlines the required parameters for loading a parser extension. Upon reading the configuration file, the claim normalizer component 106 identifies the specific parser extension required for processing the input claims. The claim normalizer component 106 is further configured to verify if the specified assertion format is supported or not. If the parser extension is available internally, the claim normalizer component 106 directly invokes the corresponding parser interface. If not, the claim normalizer component 106 retrieves the parser extension from an external source, as indicated in the configuration file, ensuring that the correct hub is utilized for loading the parser. This process is required to ensure that the claim is parsed accurately according to the specified assertion format. By validating the configuration file and determining the appropriate parser, the system 100 can handle various claim formats effectively, thereby enhancing its flexibility and adaptability to different input scenarios.

[0078] In accordance with an embodiment, the read configuration file is represented in a specific syntactic format which contains details regarding required parser extensions and corresponding version numbers. The term "syntactic format" refers to structured arrangement of symbols and rules that define the composition of data within a specific language or protocol. The term "parser extensions" refers to additional modules or components that enhance the functionality of a parser, enabling the parser to interpret and process a broader range of input formats or syntactic structures. The term "version numbers" refers to numerical identifiers assigned to different iterations of software or data formats, indicating the progression and compatibility of changes made over time. The configuration file is structured in the specific syntactic format, such as "YAML Ain't Markup Language" (originally "Yet Another Markup Language" ) , YAML, which allows for clear representation of data. The configuration file includes entries that specify the required parser extensions along with their corresponding version numbers. The claim normalizer component 106 is configured to read the configuration file to identify which parser extensions are required for processing the input claims. The claim normalizer component 106 ensures that only the relevant parser modules are initiated resulting in an optimized resource usage. The claim normalizer component 106 checks the configuration details to determine if the required parser extensions are available internally or require to be downloaded from external sources, facilitating a seamless integration of the required components. This approach is implemented to enhance the efficiency and flexibility of the system 100. By clearly defining the required parser extensions and their versions in the structured format, the system 100 can dynamically adapt to different claim formats and assertion types. This ensures that the appropriate parsing capabilities are available when required, reducing the risk of errors and improving overall performance.

[0079] The processor 104 may be further configured to transform the parsed input claims at the claim normalizer component 106 into a common syntactic representation. The term "parsed input claims" refers to structured representation of data extracted from user-provided credentials, which have been analyzed and organized for further processing within the credentials bridge middleware platform 102. The term "common syntactic representation" refers to a standardized format or structure utilized to ensure uniformity in the interpretation and handling of various data types across the credentials bridge middleware platform 102, facilitating interoperability and integration among disparate systems. The system 100 is configured to utilize the claim normalizer component 106 that receives parsed input claims from various entities. The claim normalizer component 106 processes the parsed input claims by applying a series of transformation algorithms that standardize the data into a uniform syntactic structure. This involves identifying key elements within the claims, mapping them to a predefined schema, and ensuring consistency in data representation across different formats. The normalization process may include data validation, error correction, and the application of rules to resolve ambiguities, resulting in a coherent output that can be easily interpreted by other system components. The transformation into the common syntactic representation is required for facilitating interoperability among diverse entities within the decentralized environment. By standardizing the parsed input claims, the system 100 reduces the complexity associated with varying data formats and enhances the reliability of trust establishment. This uniformity allows for more efficient processing, comparison, and validation of claims, ultimately fostering a more secure and trustworthy interaction between entities.

[0080] The processor 104 may be further configured to receive, at the claim evaluator component 108 of the credentials bridge middleware platform 102, the transformed parsed claims in the common syntactic representation, along with normalized attributes, from the claim normalizer component 106. The term "transformed parsed claims" refers to claims that have undergone a systematic process of extraction and reformatting to facilitate further analysis and evaluation. The term "normalized attributes" refers to standardized characteristics derived from claims that enable consistent comparison and assessment across different datasets or claim types. The system 100 is configured to utilize the claim evaluator component 108 that receives claims which have been transformed and parsed into the standardized format. This process involves converting various claim formats into the common syntactic representation, ensuring consistency across different data sources. Additionally, the claim normalizer component 106 is configured to normalize the attributes associated with the parsed input claims, allowing for uniform interpretation and processing. By normalizing the attributes, the system 100 ensures that all entities can accurately assess and validate claims, thereby fostering trust and collaboration. By ensuring that claims are consistently represented and attributes are normalized, the system 100 minimizes the risk of misinterpretation and enhances the overall efficiency of claim evaluation. This leads to improved security and reliability in transactions and interactions among the entities involved.

[0081] The processor 104 may be further configured to fetch, by the claim evaluator component 108 context attributes from the attribute interface component 116 of the credentials bridge middleware platform 102. The term "context attributes" refers to specific metadata or characteristics associated with a particular environment or situation that influence the behavior and functionality of a system (e.g., the system 100) . The claim evaluator component 108 is configured to retrieve the context attributes from the attribute interface component 116 by executing the fetch operation. This involves accessing the attribute interface component 116, which is designed to handle various implementations based on specific use cases. The context attributes are derived from the environment relevant to the evaluation process, ensuring that the claim evaluator component 108 has the required information to assess the CTP effectively. The retrieval process may vary depending on the configuration set by the entities or the specifications provided within the incoming claims, allowing for flexibility in how context attributes are sourced. Fetching the context attributes is required for accurately evaluating claims within the decentralized data processing environment. By obtaining relevant environmental attributes, the claim evaluator component 108 can make informed decisions based on the current context, which enhances the reliability and trustworthiness of the evaluation process. This approach ensures that the evaluation is not only based on static normalized attributes but also considers dynamic factors that may influence the outcome. By integrating the context attributes into the evaluation process, the system 100 can adapt to varying scenarios and conditions, leading to more precise and context-aware decision-making.

[0082] The processor 104 may be further configured to evaluate, at the claim evaluator component 108, a claim transformation policy (CTP) using the normalized attributes and the context attributes. The term "claim transformation policy (CTP) " refers to a set of predefined rules and procedures that govern the modification and adaptation of claims within a credentials management system (e.g., the system 100) , facilitating the conversion of claims from one format or structure to another in accordance with specified criteria and requirements. The system 100 is configured to utilize the claim evaluator component 108 that processes input data by applying a CTP. This involves analyzing both normalized attributes, which are standardized representations of parsed input claims, and context attributes, which provide situational information relevant to the input claims being evaluated. The evaluation process involves comparing these attributes against predefined criteria within the CTP to determine the validity and trustworthiness of the claims. By systematically evaluating claims through the CTP, the system 100 minimizes errors and enhances the integrity of the data processing environment, leading to more secure and reliable interactions.

[0083] In accordance with an embodiment, the CTP management interface component 112 of the credentials bridge middleware platform 102 is configured to manage and provide the CTP to the claim evaluator component 108. The CTP management interface component 112 is designed to facilitate the organization and oversight of the CTP, ensuring that the CTP is effectively integrated with the claim evaluator component 108. This is achieved through a series of protocols and data exchange mechanisms that allow for real-time updates and management of the CTP, enabling seamless communication between the two components. The CTP management interface component 112 employs user-friendly controls and dashboards that allow users to monitor and adjust the CTP parameters as required, ensuring enhanced performance. The integration of the CTP management interface component 112 with the claim evaluator component 108 results in a more cohesive system that can adapt to changing requirements and provide timely insights, thereby increasing overall system reliability and user satisfaction.

[0084] In accordance with an embodiment, the claim evaluator component 108 is configured to read the CTP from the CTP management interface component 112 using a CTP identifier and load a retrieved CTP for use in the evaluating step. The term "CTP identifier" refers to a unique alphanumeric code assigned to each credential type within the system, enabling precise identification and retrieval of credential information. The claim evaluator component 108 is configured to access the CTP management interface component 112 to obtain a specific CTP by utilizing the unique CTP identifier. This process involves sending a request to the CTP management interface component 112, which then queries the underlying database or data structure to locate the corresponding CTP. Once identified, the CTP is retrieved and loaded into the system's memory (e.g., the memory 118) to facilitate the evaluation process. The loading step ensures that the CTP is readily accessible for the subsequent evaluation of claims, allowing the claim evaluator component 108 to utilize the specific attributes and policy IDs defined within the CTP. This approach ensures that the correct CTP is accessed efficiently, minimizing the risk of errors associated with manual retrieval. By using the unique identifier, the system 100 can quickly locate and retrieve the desired CTP, which is required for maintaining accuracy and reliability in the evaluation process.

[0085] The processor 104 may be further configured to generate, at the claim evaluator component 108, obligatory actions for establishing trust between entities in the decentralized data processing environment, based on the results of the evaluating step. The term "obligatory actions" refers to specific tasks or procedures which can be performed by users or systems within the framework of the credentials bridge middleware platform 102 to ensure proper functionality and compliance with established protocols. The term "entities" refers to the distinct individuals, organizations, or systems that interact with the credentials bridge middleware platform 102, each possessing unique identifiers and roles within the operational context. The system 100 is configured to employ the claim evaluator component 108 that receives normalized attributes from the claim normalizer component 106 and fetches the context attributes from the attribute interface component 116. The claim evaluator component 108 is configured to evaluate the CTP using these attributes and generate the obligatory actions, which comprises two sets: PolicyID and AttributeSet sets. The PolicyID set includes unique identifiers UUIDs that correspond to predefined CXP or CXP templates, allowing the retrieval of the relevant policy or template. The AttributeSet includes attribute values that serve as inputs for the CXP building process. The CXP builder component 110 then receives these obligatory actions and stages them for the construction of the CXP. By generating the obligatory actions based on the evaluation, the system 100 facilitates a structured approach to trust establishment, allowing for consistent and reliable interactions between entities in the decentralized environment.

[0086] In accordance with an embodiment, the session interface component 114 of the credentials bridge middleware platform 102 is configured to provide functionality to the CTP management interface component 112 to initiate a session based on a specific CTP evaluation context. The term "CTP evaluation context" refers to the specific environment or parameters within which credential evaluation processes are conducted, encompassing the criteria, rules, and data sources utilized to assess the validity and appropriateness of credentials. The session interface component 114 is designed to interact with the CTP management interface component 112 by utilizing a set of predefined protocols and data structures. The session interface component 114 processes input parameters related to the CTP evaluation context, which may include user preferences, system states, and evaluation criteria. Upon receiving a request, the session interface component 114 triggers the initiation of a session by establishing a communication link and configuring the required resources to support the evaluation process. This approach is implemented to ensure that sessions are tailored to specific evaluation contexts, enhancing the relevance and accuracy of the CTP management process. By providing a dedicated interface (i.e., the session interface component 114) for session initiation, the credentials bridge middleware platform 102 allows for a more organized and efficient handling of evaluations, ultimately improving user experience and performance of the system 100.

[0087] In accordance with an embodiment, the claim evaluator component 108 is configured to send the obligatory actions to the CXP builder component 110. The claim evaluator component 108 is configured to analyze the transformed parsed claims and determines the required actions based on predefined criteria. The claim evaluator component 108 is configured to process the information to identify which actions are obligatory and formats them appropriately. Subsequently, the claim evaluator component 108 is configured to establish a communication link with the CXP builder component 110, ensuring that the actions are transmitted in a structured manner that the builder can interpret and execute effectively. This process is required to ensure that the CXP builder component 110 receives accurate and timely instructions, enabling the CXP builder component 110 to construct the desired output efficiently. By sending the obligatory actions to the CXP builder component 110, the system 100 maintains a clear workflow, reducing the likelihood of errors and enhancing overall performance. The transmission of obligatory actions results in improved synchronization between components, leading to a more streamlined operation. This enhances the system's responsiveness and reliability, ultimately contributing to a more effective and efficient overall process.

[0088] In accordance with an embodiment, each of the obligatory actions is configured to hold a CXP identifier. The term "CXP identifier" refers to a unique alphanumeric code or string utilized within the credentials bridge middleware platform 102 to facilitate the identification and authentication of user credentials across disparate systems and services. Each obligatory action is generated by the claim evaluator component 108, which creates two sets: PolicyID and AttributeSet. The PolicyID set contains unique identifiers UUIDs that correspond to predefined CXP or CXP templates. These identifiers are required for retrieving the relevant policy or policy template, which is then utilized in the CXP building process. The AttributeSet provides required attribute values that serve as inputs during this process. The CXP builder component 110 takes these obligatory actions, along with any specified external claims, to initiate the CXP building process, ensuring that each action is associated with the specific CXP identifier. This configuration is required to ensure that each obligatory action is directly linked to the specific CXP identifier, facilitating accurate retrieval and processing of policies. By maintaining this association, the system 100 can effectively manage and build CXP instances based on predefined templates and input attributes, ensuring consistency and reliability in the claims management process. Such configuration results in the streamlined generation of CXP instances that are accurately aligned with the corresponding policies and attributes. This leads to improved efficiency in claims processing, reduced errors in policy retrieval, and enhanced overall system performance in managing claims.

[0089] In accordance with an embodiment, the CXP builder component 110 of the credentials bridge middleware platform 102 is configured to generate a CXP and a plurality of transformed claims based on the obligatory actions generated by the claim evaluator component 108. The term "CXP" refers to a credentials exchange platform that facilitates the secure transfer and verification of user credentials across various systems and applications. The term "transformed claims" refers to assertions or statements that have been modified or adapted to align with specific requirements or formats for enhanced clarity and applicability within a given context. The CXP builder component 110 is configured to utilize algorithms to analyze input data from the claim evaluator component 108. The CXP builder component 110 is configured to process the obligatory actions identified by the claim evaluator component 108 to construct a comprehensive CXP and multiple claims. This involves parsing the actions, applying predefined rules, and generating outputs that align with regulatory requirements and operational standards. The implementation of the CXP builder component 110 leads to improved processing speed and accuracy in claims management. The CXP builder component 110 enables dynamic adaptation to varying claim scenarios, ensuring that the generated policies and claims are relevant and actionable, ultimately enhancing the overall performance of the claims processing system (i.e., the system 100) .

[0090] In accordance with an embodiment, the CXP builder component 110 is configured to download a CXP build extension based on extension details specified in the read configuration file. The term "CXP build extension" refers to a modular component designed to enhance the capabilities of a credentials exchange platform by facilitating the integration of additional functionalities and services, thereby enabling seamless interoperability and improved user experience within the system architecture. The CXP builder component 110 is configured to access the configuration file that contains specific details about the desired CXP build extension. Upon reading the configuration file, the CXP builder component 110 identifies the required parameters, such as version, compatibility, and source location. The CXP builder component 110 then initiates a download process, retrieving the specified extension from a designated repository or server, ensuring that the extension aligns with the provided details. This process is implemented to ensure that the CXP builder component 110 can dynamically adapt to varying requirements and configurations. By downloading extensions based on specified details, the system 100 can maintain flexibility, allowing for updates and modifications without manual intervention, thus enhancing user experience and operational efficiency.

[0091] In accordance with an embodiment, the claim normalizer component 106 is configured to compare a semantic meaning of attributes associated with the credentials bridge middleware platform 102 with those associated with the received claims. The term "semantic meaning" refers to the interpretation and significance of information conveyed within a specific context, particularly in relation to the claims being analyzed. The term "received claims" refers to the assertions or statements that have been submitted to the system for evaluation and processing. The claim normalizer component 106 may be configured to utilize natural language processing techniques to analyze the attributes linked to the platform and the received claims. The claim normalizer component 106 may be configured to extract key semantic elements from both sets of attributes, employing algorithms to assess their meanings and relationships. This involves tokenization, part-of-speech tagging, and semantic similarity measures to ensure an accurate comparison of the underlying concepts. This process is required to ensure that the attributes from different sources are interpreted consistently. By comparing semantic meanings, the system 100 can identify discrepancies or alignments in the data, which aids in the accurate assessment and categorization of claims. This has a particular significance in contexts where terminology may vary but the underlying concepts remain similar. Such comparison reduces the likelihood of misinterpretation of claims due to semantic differences, thereby increasing the reliability of the system's outputs and facilitating better integration of diverse data sources.

[0092] In accordance with an embodiment, the claim normalizer component 106 is configured to store normalized attributes in a key value store for forwarding to the claim evaluator component 108. The term "key value store" refers to a type of data storage architecture that utilizes a simple associative array as its fundamental data model, where each unique key is associated with a corresponding value, facilitating efficient data retrieval and storage. The claim normalizer component 106 processes incoming data to extract relevant attributes, which are then transformed into the standardized format. These normalized attributes are subsequently stored in the key-value store, where each attribute is associated with a unique key for efficient retrieval. Such storage mechanism allows for quick access and manipulation of the data, facilitating seamless communication with the claim evaluator component 108. The storage of the normalized attributes in the key-value store enhances data organization and retrieval efficiency. This approach minimizes the complexity of data handling, ensuring that the claim evaluator component 108 can quickly access the required information without the overhead of parsing unstructured data. The use of the key-value store also supports scalability, allowing the system 100 to handle increasing volumes of claims without degradation in performance. The use of the key-value store for normalized attributes results in improved performance and responsiveness of the system 100. The use of the key-value store enables rapid data access, which is required for real-time claim evaluation. Additionally, such storage architecture promotes modularity, allowing for easier updates and maintenance of the claim normalization and evaluation processes.

[0093] Thus, the present disclosure introduces a sophisticated system (i.e., the system 100) designed to establish trust between entities within the decentralized data processing environment, leveraging the credentials bridge middleware platform 102 that enhances the interoperability and reliability of claims made by various issuance authorities. The architecture of the system 100 is centered around the claim normalizer component 106 that is configured to handle the input claims represented in multiple assertion formats, ensuring that the input claims are parsed and transformed into the unified syntactic representation. By employing the parser extension tailored to each assertion format, the claim normalizer component 106 not only facilitates the extraction of relevant attributes but also ensures that the semantic meaning of these attributes is preserved and accurately mapped to a common framework. This normalization process is required as it allows the claim evaluator component 108 to seamlessly integrate the normalized attributes with the context attributes fetched from the attribute interface component 116, thereby enabling a comprehensive evaluation of CTPs. The synergistic interaction between the claim normalizer component 106 and the claim evaluator component 108 ensures that the system 100 can dynamically adapt to varying input formats while maintaining a high level of semantic integrity, ultimately generating obligatory actions that foster trust between entities. This capability is particularly advantageous in decentralized environments where diverse data formats and sources can complicate trust assessments, as it streamlines the process of validating claims and enhances the overall security and reliability of the interactions between entities operating in the decentralized data processing environment.

[0094] FIG. 2 is a flowchart of a method of establishing trust between entities in a decentralised data processing environment implementing a credentials bridge middleware platform, 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 214. The claim normalizer component 106, the claim evaluator component 108 and the CXP builder component 110 of the credentials bridge middleware platform 102 are configured to execute the method 200.

[0095] There is provided the method 200 of establishing trust between entities in a decentralised data processing environment implementing the credentials bridge middleware platform 102. The method 200 is used to establish trust between various entities operating in the decentralized data processing environment by employing the credentials bridge middleware platform 102.

[0096] At step 202, the method 200 comprises receiving input claims at the claim normalizer component 106 of the credentials bridge middleware platform 102, where an input claim is an assertion made by an issuance authority regarding the attributes, rights or status of a subject, wherein the input claims are represented in a plurality of assertion formats. The credentials bridge middleware platform 102 verifies the input claims against established criteria and protocols, ensuring that the attributes, rights, or status of the subject are accurately represented and authenticated.

[0097] At step 204, the method 200 further comprises parsing the received input claims at the claim normalizer component 106 using a parser extension corresponding to each of the plurality of assertion formats. The parsing of the received input claims is performed using the parser extension corresponding to each of the plurality of assertion formats to extract relevant data and ensure that claims from different sources are uniformly processed and understood.

[0098] At step 206, the method 200 further comprises transforming the parsed input claims at the claim normalizer component 106 into a common syntactic representation. The claim normalizer component 106 processes the parsed input claims by applying a series of transformation algorithms that standardize the data into a uniform syntactic structure. By standardizing the parsed input claims, the complexity associated with varying data formats is reduced and the reliability of trust establishment is enhanced.

[0099] At step 208, the method 200 further comprises receiving, at the claim evaluator component 108 of the credentials bridge middleware platform 102, the transformed parsed claims in the common syntactic representation, along with normalized attributes, from the claim normalizer component 106. By normalizing the attributes, this can be ensured that all entities can accurately assess and validate claims, thereby fostering trust and collaboration in the decentralized data processing environment. By ensuring that claims are consistently represented and attributes are normalized, the method 200 results in minimizing the risk of misinterpretation and enhancing the overall efficiency of claim evaluation.

[0100] At step 210, the method 200 further comprises fetching, by the claim evaluator component 108, context attributes from the attribute interface component 116 of the credentials bridge middleware platform 102. The context attributes are derived from the environment relevant to the evaluation process, ensuring that the claim evaluator component 108 has the required information to assess the CTP effectively. Fetching the context attributes is required for accurately evaluating claims within the decentralized data processing environment.

[0101] At step 212, the method 200 further comprises evaluating, at the claim evaluator component 108, a claim transformation policy (CTP) using the normalized attributes and the context attributes. The evaluation process involves comparing the normalized attributes and the context attributes against predefined criteria within the CTP to determine the validity and trustworthiness of the claims.

[0102] At step 214, the method 200 further comprises generating, at the claim evaluator component 108, obligatory actions for establishing trust between entities in the decentralized data processing environment, based on the results of evaluation at the step 212. The claim evaluator component 108 is configured to evaluate the CTP using the normalized attributes and the context attributes and generate the obligatory actions which are further forwarded to the CXP builder component 110.

[0103] In accordance with an embodiment, the CTP management interface component 112 of the credentials bridge middleware platform 102 is configured to manage and provide the CTP to the claim evaluator component 108. The CTP management interface component 112 is designed to facilitate the organization and oversight of the CTP, ensuring that the CTP is effectively integrated with the claim evaluator component 108.

[0104] In accordance with an embodiment, the session interface component 114 of the credentials bridge middleware platform 102 is configured to provide functionality to the CTP management interface component 112 to initiate a session based on a specific CTP evaluation context. The session interface component 114 processes input parameters related to the CTP evaluation context, which may include user preferences, system states, and evaluation criteria. Upon receiving a request, the session interface component 114 triggers the initiation of a session by establishing a communication link and configuring the required resources to support the evaluation process.

[0105] In accordance with an embodiment, the CXP builder component 110 of the credentials bridge middleware platform 102 is configured to generate a CXP and a plurality of transformed claims based on the obligatory actions generated by the claim evaluator component 108. The CXP builder component 110 is configured to process the obligatory actions identified by the claim evaluator component 108 to construct a comprehensive CXP and multiple claims, described in detail, for example, in FIG. 1.

[0106] In accordance with an embodiment, the claim normalizer component 106 is configured to utilize a read configuration file to obtain information on a parser extension and on context uniform resource identifier. The read configuration file is used to extract required information regarding parser extensions and context uniform resource identifiers, have been described in detail, for example, in FIG. 1.

[0107] In accordance with an embodiment, the claim normalizer component 106 is configured to load a specific parser extension as specified in the read configuration file. Once the read configuration file is analyzed and the specific parser extension as specified in the read configuration file is identified, the claim normalizer component 106 is configured to check whether the specific parser extension is available internally or not. In case of the availability of the specific parser extension, the claim normalizer component 106 directly invokes the corresponding parser interface. If not, the claim normalizer component 106 retrieves the parser extension from an external source, as indicated in the read configuration file, ensuring that the correct hub is utilized for loading the parser.

[0108] In accordance with an embodiment, the read configuration file is represented in a specific syntactic format which contains details regarding required parser extensions and corresponding version numbers. The read configuration file includes entries that specify the required parser extensions along with their corresponding version numbers. The claim normalizer component 106 is configured to read the configuration file to identify which parser extensions are required for processing the input claims.

[0109] In accordance with an embodiment, the claim evaluator component 108 is configured to read a CTP from the CTP management interface component 112 using a CTP identifier and loads a retrieved CTP for use in the evaluating step. The reading of the CTP from the CTP management interface component 112 using the CTP identifier and loading the retrieved CTP for use in the evaluation, has been described in detail, for example, in FIG. 1.

[0110] In accordance with an embodiment, the claim evaluator component 108 is configured to send the obligatory actions to the CXP builder component 110. The claim evaluator component 108 is configured to process the information to identify which actions are obligatory and formats them appropriately. Subsequently, the claim evaluator component 108 is configured to establish a communication link with the CXP builder component 110, ensuring that the actions are transmitted in a structured manner that the builder can interpret and execute effectively.

[0111] In accordance with an embodiment, each of the obligatory actions is configured to hold a CXP identifier. The CXP builder component 110 takes these obligatory actions, along with any specified external claims, to initiate the CXP building process, ensuring that each action is associated with the specific CXP identifier. This configuration is required to ensure that each obligatory action is directly linked to the specific CXP identifier, facilitating accurate retrieval and processing of policies.

[0112] In accordance with an embodiment, the CXP builder component 110 is configured to download a CXP build extension based on extension details specified in the read configuration file. The CXP builder component 110 is configured to access the configuration file that contains specific details about the desired CXP build extension. Upon reading the read configuration file, the CXP builder component 110 identifies the required parameters, such as version, compatibility, and source location, have been described in detail, for example, in FIG. 1.

[0113] In accordance with an embodiment, the claim normalizer component 106 is configured to compare a semantic meaning of attributes associated with the platform with those associated with the received claims. By comparing semantic meanings, any discrepancy or misalignment in the data can be identified, aiding to the accurate assessment and categorization of claims.

[0114] In accordance with an embodiment, the claim normalizer component 106 is configured to store the normalized attributes in a key value store for forwarding to the claim evaluator component 108. The storage of the normalized attributes in the key value store allows for quick access and manipulation of the data, facilitating seamless communication with the claim evaluator component 108.

[0115] Thus, the method 200 provides comprehensive credential management capabilities, encompassing various types of transformations. The transformations include not only basic format conversions but also more sophisticated operations, such as semantical mapping with association preservation, credential aggregation, and the incorporation of derivative or additional credentials. The method 200 uniquely combines credential transformation with usage policies and can transform credentials into policies that govern protocol execution. The method 200 employs the CTP for mapping claims and the CXP that governs protocol behavior. This dual-policy approach allows for localized rule interpretation based on different contexts, such as specific regions or regulatory realms, making the method 200 highly adaptable to various implementation requirements. The method 200 can be employed in an extensible Usage Control (UCON+) policy framework which enhances the practical applicability of the method 200. These features contribute to significant advantages in terms of interoperability, allowing for seamless access across services using different protocols while supporting decentralized credentials and shared responsibility architectures. The method's flexibility makes the method 200 particularly valuable for future solutions requiring decentralized credentials, as the method 200 can adapt to different situations and localities while maintaining compatibility with existing policy framework technologies. The technical benefits extend to advanced credential transformation capabilities, a policy-driven approach to trust establishment, and support for selective disclosure, making the method 200 especially suitable for modern data processing environments where flexibility, security, and regulatory compliance are paramount considerations.

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

[0117] 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.

[0118] FIG. 3 is a flowchart that depicts credential transformation using a credentials bridge middleware platform, 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 flowchart 300 that depicts credential transformation in the credentials bridge middleware platform 102 (of FIG. 1) . The flowchart 300 includes a series of operations 302 to 320. The operations 302 to 306 are grouped into step 1, the operations 308 to 314 are grouped into step 2 and the operations 316 to 320 are grouped into step 3.

[0119] At operation 302, the input claims are provided as an input to the claim normalizer component 106.

[0120] At operation 304, the claim normalizer component 106 is configured to prepare normalized attributes of the input claims. The normalized attributes are evaluated by the claim evaluator component 108. The process of normalization ensures that the attributes within the claims are standardized and harmonized into a common semantic meaning and mapped to a common syntactic format that can be interpreted by the claim evaluator component 108.

[0121] At operation 306, the claim normalizer component 106 is configured to generate normalized claims (or transformed parsed claims) and send the normalized claims to the claim evaluator component 108.

[0122] At operation 308, the claim evaluator component 108 is configured to evaluate a CTP obtained from the CTP management interface component 112, at operation 310, with the normalized claims received from the claim normalizer component 106 and context attributes obtained from the attribute interface component 116, at operation 312. The context attributes are attributes obtained from the environment in the context of the evaluation of the CTP. The form and retrieval method of context attributes depend on the use cases, entailing different implementations of the attribute interface component 116.

[0123] At operation 314, the claim evaluator component 108 is configured to generate obligatory actions and send the generated obligatory actions to the CXP builder component 110 for generation of a CXP.

[0124] At operation 316, the generated obligatory actions are provided as an input to the CXP builder component 110. Based on the subject configuration, the CXP builder component 110 first instantiates and configures the CXP build extension that takes the generated obligatory actions and any external claims specified as an input, at operation 318. The CXP builder component 110 starts the building process and outputs the CXP and transformed claims, at operation 320.

[0125] FIG. 4 illustrates an architecture of a credentials bridge middleware system, 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 an architecture 400 of the credentials bridge middleware system 402. In the architecture 400, there is shown an extensible Usage Control (UCON+) framework, comprising the claim evaluator component 108 (or a CTP Engine) of the credentials bridge middleware platform 102. The credentials bridge middleware system 402 corresponds to the system 100 (of FIG. 1) .

[0126] The UCON+ framework is a comprehensive access control model that extends traditional access control by considering attributes, obligations, and conditions before, during, and after an access request, making it suitable for managing continuous and mutable authorization decisions in modern distributed systems and cloud environments.

[0127] The credentials bridge middleware system 402 handles the transformation of claims within ID tokens. The architecture 400 shows a series of interconnected components with directional flows, centered around the UCON+ framework comprising the CTP Engine as the core component. The CTP engine corresponds to the claim evaluator component 108. The flow begins with input claims being processed through the claim normalizer component 106, which converts the input claims into a standardized JSON format. The normalized claims then flow into the UCON+ framework comprising the CTP Engine, which also receives an input (i.e., a CTP) from the CTP management interface component 112 and context attributes from the attribute interface component 116. The claim evaluator component 108 (i.e., the CTP engine) processes these inputs according to configured CTP policies and produces outputs that can include either unchanged claims with associated CXP, transformed claims (such as converting from JSON Web Token (JWT) to JSON-LDP-VC format) with CXP, or solely CXP policies that govern protocol behavior.

[0128] FIG. 5 illustrates various exemplary interfaces of a claim normalizer component, in accordance with an embodiment of the present disclosure. FIG. 5 is described in conjunction with elements from FIGs. 1, 2 and 3. With reference to FIG. 5, there is shown a block diagram showing various exemplary interfaces of the claim normalizer component 106. The claim normalizer component 106 includes four interfaces, namely, a request processor interface 502, a parser interface 504, a configuration interface 506 and a vocabulary interface 508.

[0129] The request processor interface 502 enables the claim normalizer component 106 to read the input claims (or incoming claims) and understand the assertion format in which the input claims are represented, and accordingly, call the parser interface 504. Before calling the parser interface 504, the request processor interface 502 is configured to check with the configuration interface 506 to see if the specified assertion format is supported (for example, based on the availability of the parser extension either internally or from an external source) . If the parser extension is available internally, the request processor interface 502 is configured to call the corresponding interface (i.e., the parser interface 504) otherwise, the request processor interface 502 is configured to instruct the parser interface 504 to load the parser extension from an external source by providing the details of source (the hub that requires to be used is specified in the configuration file) .

[0130] The parser interface 504 enables the claim normalizer component 106 to parse the input claims and fetch the attributes (i.e., the normalized attributes) from the input claims. In case, if the input claims are attested by Issuers (An “Issuer" is an entity that issue claims to a holder about a subject which could be either a nature person, legal entity, protocol or document. The issuer is responsible for issuing claims which could be attested and communicating with wallet according to claim issuance protocols, ensuring that the claim is securely stored in the wallet) then, this is verified based on the verification method associated with the input claims. The normalized attributes are stored as key-value pairs and passed to the vocabulary interface 508. The parser extension is specific to each assertation format of the input claims and the configuration interface 506 is used in order to support with extensibility. The overall flow of the parser interface 504 is shown and described, in detail, for example, in FIG. 7.

[0131] The configuration interface 506 implements capabilities for different entities operating in the decentralized data processing environment to specify the supported parser extensions in a configuration file. The parser extensions are used to read the attributes from the input claims, represented in a specific assertion format. For example, if the input claims are defined using VC-JSON-LD assertion format, the parser interface 504 requires a JSON-LD parser extension. The configuration interface 506 enables the claim normalizer component 106 to read the configuration file, where the entities specify the parser extension name and source (internal or external) . Additionally, the configuration interface 506 is configured to read the links to the source of the vocabulary associated with the input claims or issuers as specified in the configuration file.

[0132] The vocabulary interface 508 implements functionality to understand the semantic meaning of the attributes from the parsed input claims. To get the semantic meaning, the vocabulary interface 508 is configured to download the vocabulary associated with the input claims and compares the downloaded vocabulary with the vocabulary internal to the credentials bridge middleware platform 102. The link to the source of the vocabulary for the input claims are either configured by the entities or specified in the input claims themselves specified by the issuer. In the former case, the vocabulary interface 508 is required to call the configuration interface 506 to get the link to the vocabulary source, in the latter case, the vocabulary interface 508 is required to fetch the vocabulary source specified in the input claims. The semantically checked attribute set is passed back to the request processor interface 502, which is then configured to instantiate the claims evaluator component 108.

[0133] FIG. 6 is a flowchart of data flow between various interfaces of a claim normalizer component, in accordance with an embodiment of the present disclosure. FIG. 6 is described in conjunction with elements from FIGs. 1, 2, 3, and 5. With reference to FIG. 6, there is shown a flowchart 600 of data flow between various interfaces (e.g., the request processor interface 502, the parser interface 504, the configuration interface 506 and the vocabulary interface 508) of the claim normalizer component 106. The flowchart 600 includes three steps, 602 to 606.

[0134] At step 602, the request processor interface 502 is instantiated based on the configuration details specified in the configuration file. The request processor interface 502 is configured to read the configuration file using the configuration interface 506, which implements the required functionality to read from the configuration file that is updated by entities operating in a decentralized data processing environment.

[0135] At step 604, after instantiation, the request processor interface 502 is configured to wait for the input claims. Once the request processor interface 502 gets the input claims, the request processor interface 502 is further configured to determine an assertion format in which the input claims are represented and pass the assertion format details to the parser interface 504 along with the input claims. The parser interface 504 is configured to instantiate the parser extension corresponding to the assertion format and attributes from the input claims and store the attributes as a key-value pair called the parsed attribute set.

[0136] At step 606, the parsed attribute set obtained at the step 604, is passed to the vocabulary interface 508, which is configured to check for semantic correctness based on the obtained vocabulary from an internal or external source specified in the configuration file. The normalized attribute set is passed to the request processor interface 502, which represents the normalized attribute in a common syntactic form and passes the normalized attributes to the claim evaluator component 108.

[0137] FIG. 7 illustrates a data flow in a parser interface of a claim normalizer component, in accordance with an embodiment of the present disclosure. FIG. 7 is described in conjunction with elements from FIGs. 1, 2, 3, 5 and 6. With reference to FIG. 7, there is shown a flowchart 700 of data flow in the parser interface 504 of the claim normalizer component 106.

[0138] The claim normalizer component 106 is configured to use the parser interface 504 to parse the input claims depending on the associated assertation format. For example, if the assertation type is VC-JSON-LD then, the JSON-LD parser extension is used, however, the configuration interface 506 is configured to ensure that the supported assertation formats are specified in the configuration file before the credentials bridge middleware is deployed so that the parser extensions are instantiated correctly by a parser loading interface. The following are the functionality of the parser interface 504.

[0139] The parser interface 504 is configured to firstly check if the parser extension required for a specific assertion format of the input claims is installed or not. If yes, then the parser interface 504 is configured to send an initialize parser extension message to a parser which initialize the specified parser extension that support the parse attributes in the input claims. If the specified parser extension is not instantiated, then the parser loading interface gets the parser extension either from external or internal sources and load the parser extension. After loading of the parser extension, the parser interface 504 is configured to send the initialize parser extension message in a similar way as done in the previous step.

[0140] FIG. 8 is an exemplary implementation scenario of a claim normalizer component in an extensible Usage Control (UCON+) framework, in accordance with an embodiment of the present disclosure. FIG. 8 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 5, 6 and 7. With reference to FIG. 8, there is shown an exemplary implementation scenario 800 of the claim normalizer component 106 in an extensible Usage Control (UCON+) framework 802.

[0141] The claim normalizer component 106 is configured to process and normalize the input claims, particularly those represented in IDToken (e.g., JWT (JSON Web Token) assertion format) . At its core, the data flow begins with the input claims flowing into the request processor interface 502, which serves as the primary coordination point for the normalization process. The request processor interface 502 works in conjunction with the configuration interface 506 that reads and interprets a YAML-format configuration file, providing required details about supported parser extensions and context URIs associated with identity providers. In the exemplary implementation scenario 800, the claims are represented in JWT assertion format. However, this is not required that the parser interface 504 requires to support all the assertation formats, it is up to the subject to configure the supported assertation format in the configuration file.

[0142] When the input claim arrives, the request processor interface 502 checks for the availability of appropriate parsers through the parser interface 504. If the required parser extension (such as the JWT parser) isn't already loaded, the parser extension manager is configured to download and load the parser extension from an external source. Once the appropriate parser extension is available, the request processor interface 502 instantiates the parser extension within the parser interface 504. This dynamic parser loading supports multiple parser extensions, allowing the platform to handle various assertion formats as required.

[0143] The parser extension in the parser interface 504 fetches the claims from the IDToken and passes the parsed claims to the vocabulary interface 508 along with the context URI associated with the input claims. The vocabulary interface 508 is configured to firstly check if the context URI is already cached, if yes, then the vocabulary interface 508 initiates the semantic comparison between terms used in the context associated with the input claims and those used within the credentials bridge middleware. If not, the vocabulary interface 508 downloads the vocabulary from the context URI that points to a vocabulary hub before starting the comparison process. Thereafter, the input claims are harmonized into a common semantic form (miss-match between the terms are resolved) and represented in a common syntactic JSON representation.

[0144] The following are the tasks of the parser interface 504. The parser interface 504 is configured to verify the input claims if there is a verification method associated with the input claims. For example, the verification method attribute in the VC-JSON-LD specifies how to verify the claims contained in it or the JWS in the IDToken. Verifying the claims ensures the authenticity and integrity of the claims. The parser interface 504 is further configured to parse the input claims and store them as attribute key-value pairs, for example, { "name" : "bob" } in a map data structure (this does not require to be stored in the database) . The parser interface 504 is further configured to download the vocabulary from the vocabulary hub based on the context URI, if it is not cached within the credentials bridge middleware. The terms are then stored in the external context store HashMap called externalContextSet and compared with the credentials bridge middleware vocabulary that is stored in the internal context store HashMap called in the internalContextSet. This step ensures that the terms and corresponding URIs are the same across all the attributes used for the claim evaluation. For example, in both externalContextSet and internalContextSet, the vocabulary of the attribute "name" should correspond to the name of a natural person. However, if the vocabulary in the externalContextSet specifies the attribute "name" as the name of a legal entity, then there is an inconsistency, and the credentials bridge will wrongly interpret the "name" attribute. The attribute values that are correctly interpreted and consistent with internalContextSet are stored in an in-memory requestAttributeSet map data structure.

[0145] The final stage involves normalizing the processed claims into a standardized JSON format. This normalization ensures consistency in how claims are represented throughout the process. The architecture demonstrates clear separation of concerns, with distinct components handling configuration, parser management, request processing, and vocabulary harmonization. This modular design allows for flexible expansion of supported assertion formats while maintaining consistent claim normalization across the platform. The entire process ensures that input claims are not only parsed correctly but also semantically aligned with the system's internal vocabulary, preventing misinterpretation of claim attributes.

[0146] FIG. 9 illustrates various exemplary interfaces of a claim evaluator component, in accordance with an embodiment of the present disclosure. FIG. 9 is described in conjunction with elements from FIGs. 1, 2, 3, and 4. With reference to FIG. 9, there is shown a block diagram showing various exemplary interfaces of the claim evaluator component 108. The claim evaluator component 108 includes four interfaces, namely, a CTP engine interface 902, the CTP management interface component 112, the session interface component 114 and the attribute interface component 116.

[0147] The CTP engine interface 902 is configured to implement a policy engine to evaluate a CTP with the set of attributes obtained from the input claims and a set of contextual attributes. The CTP engine interface 902 is configured to query the CTPs for evaluation from the CTP management interface component 112 and the contextual attributes from the attribute interface component 116.

[0148] The CTP management interface component 112 may be configured to implement functionalities to ensure that subjects and other interfaces in the credentials bridge middleware platform 102 can add, delete, update and query CTPs. The subjects use the endpoints of this module (i.e., the CTP management interface component 112) to add new CTPs which can be queried by the CTP engine interface 902.

[0149] The session interface component 114 may be configured to implement functionalities to instantiate a session associated with context of evaluation of each CTP. The session interface component 114 may be further configured to closely monitor each session and associated changes that is happening to the attributes within that session. If the session interface component 114 finds changes to any of the attributes in that context, then the session interface component 114 can trigger re-evaluation of the CTP associated with the context.

[0150] The attribute interface component 116 may be configured to implement a set of functions that collects different internal attributes associated with a specific context of mapping of the input claims. For example, a set of functions that can read internal configuration files and derive attributes from the configuration details.

[0151] FIG. 10 is a flowchart of data flow between various interfaces of a claim evaluator component, in accordance with an embodiment of the present disclosure. FIG. 10 is described in conjunction with elements from FIGs. 1, 2, 3, 4 and 9. With reference to FIG. 10, there is shown a flowchart 1000 of data flow between various interfaces (e.g., the CTP engine interface 902, the CTP management interface component 112, the session interface component 114 and the attribute interface component 116) of the claim evaluator component 108. The flowchart 1000 includes steps, 1002 and 1004.

[0152] At step 1002, the CTP engine interface 902 is configured to evaluate the CTP (s) provided by the CTP management interface component 112 with context attributes obtained from the attribute interface component 116 and attributes derived from normalized claims. The CTP management interface component 112 is configure to provide Application Programming Interfaces (APIs) to the subject to add, delete, update and edit functionality on the CTP.

[0153] At step 1004, if the CTPs are applicable for the specific context of evaluation, then the CTP engine interface 902 is configured to generate the obligatory actions, else, the CTP engine interface 902 is configured to generate an alert mentioning the inability to process the input claims.

[0154] FIG. 11 is an exemplary implementation scenario of a claim evaluator component in an UCON+ framework, in accordance with an embodiment of the present disclosure. FIG. 11 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 9 and 10. With reference to FIG. 11, there is shown an exemplary implementation scenario 1100 of the claim evaluator component 108 in a UCON+ framework 1102.

[0155] The UCON+ claim evaluation engine (i.e., the claim evaluator component 108 combined with the UCON+ framework 1102) evaluates CTPs with attributes from the input claims and CTP Policy Information Point (PIP) . The CTP is written by the entity that manages the credentials bridge middleware or the entity delegating the right to other users. In said exemplary implementation scenario 1100, Abbreviated Language for Authorization (ALFA) is the language that is used to write CTP.

[0156] The input claims are stored in requestAttributeSet map data structure after normalization and is used by the UCON+claim evaluation engine. In addition to the normalized claims, the UCON+ CTP Engine considers contextual attributes, such as environment variables, user configuration, verifier requirements (presentation exchange) and so on. The contextual attributes are fetched using CTP PIP based on the source from which these attributes require to be fetched. These attributes key-value pairs are cached locally in internalAttributeSet by the CTP PIP and would be used across difference instance of the credentials bridge middleware with different input claims.

[0157] The CTPs rules about transforming claims to localized and contextualized claims with CXP or associating claims with CXPs or CXPs that governs the behavior of protocol that uses these claims. For example, the CXP controls the behavior of the selective disclosure protocol that is used for privacy-preserving presentation of the claims to a verifier (A “Verifier” is any entity whether a natural person or legal entity or a Service that verify claims by the holder) . The CTPs are stored and managed through the CTP Policy Administration Point (PAP) .

[0158] The result of the evaluation process is a set of obligatory actions that give instruction on how to be selected or build CXPs based on a set of attributes and policy IDs that are specified in the CTPs.

[0159] FIG. 12 illustrates various exemplary interfaces of a CXP builder component, in accordance with an embodiment of the present disclosure. FIG. 12 is described in conjunction with elements from FIGs. 1, 2, 3, and 4. With reference to FIG. 12, there is shown a block diagram showing various exemplary interfaces of the CXP builder component 110. The CXP builder component 110 includes four interfaces, namely, a CXP extension management interface 1202, a build configuration interface 1204, a CXP building extension interface 1206, and an extension loading interface 1208.

[0160] The CXP extension management interface 1202 provides key functionality to instantiate extensions that lead to build or select a CXP which govern the behavior of a protocol used by an application (An "Application" is a software program or suite of programs designed to perform specific tasks or functions on behalf of a holder. Applications interact with service to execute operations, retrieve information, or provide services, thereby acting as intermediaries that facilitate the goals or actions of the holder) that manages input claims. The CXP extension management interface 1202 is configured to check with the build configuration interface 1204 to get the details about supported CXP building extensions managed by the CXP building extension interface 1206. If the extension is not available, then the CXP building extension interface 1206 can be configured to start the process of installing the extension, if available in specified external repository.

[0161] The build configuration interface 1204 is configured to read the configuration file related to the extension that is used to build the CXP that govern the behavior of the application.

[0162] The CXP building extension interface 1206 provides the functionality to manage various extensions that leads to build the CXPs.

[0163] The extension loading interface 1208 provides the functionality to loading extension that is used in building the CXPs based on the user configuration.

[0164] FIG. 13 is a flowchart of data flow between various interfaces of a CXP builder component, in accordance with an embodiment of the present disclosure. FIG. 13 is described in conjunction with elements from FIGs. 1, 2, 3, 4 and 12. With reference to FIG. 13, there is shown a flowchart 1300 of data flow between various interfaces (e.g., the CXP extension management interface 1202, the build configuration interface 1204, the CXP building extension interface 1206, and the extension loading interface 1208) of the CXP builder component 110. The flowchart 1300 includes steps, 1302 to 1308.

[0165] At step 1302, the CXP extension management interface 1202 is configured with extensions to build the CXP using the build configuration interface 1204.

[0166] At step 1304, the CXP extension management interface 1202 is called with the obligatory action as an input. The CXP extension management interface 1202 checks if the required extension is loaded. If not, then the step 1306 is executed.

[0167] At step 1306, the extension loading interface 1208 (may also be referred to as an extension instantiation interface) is configured to download the CXP extension kit from an external or internal source based on the configuration and load the downloaded CXP extension into the CXP building extension interface 1206.

[0168] At step 1308, the CXP extension management interface 1202 initializes the loaded extension in the CXP building extension interface 1206 with the obligatory actions and outputs the CXP and transformed claims.

[0169] FIG. 14 is an exemplary implementation scenario of a CXP builder component in a UCON+ framework, in accordance with an embodiment of the present disclosure. FIG. 14 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 12 and 13. With reference to FIG. 14, there is shown an exemplary implementation scenario 1400 of the CXP builder component 110 in an obligation framework module 1402.

[0170] The CXP builder component 110 is configured to execute following tasks when implemented in the obligation framework module 1402.

[0171] Based on the policyID values in the obligatory actions, the CXP extension management interface 1202 is configured to check with the build configuration interface 1204 whether the corresponding CTP with the same policyID has been already loaded or not. If yes, then no action is required. Further, the CXP extension management interface 1202 is configured to check for the supported extensions in the CXP building extension interface 1206. The extensions are simple build extension, template build extension, and automated build extension. Each extension has different level of complexity and functionality and require to be initiated based on preference of either a user or an administrative authority or an entity operating in the decentralized data processing environment. The CXP building extension interface 1206 is configured to instantiate the configured CXP building extension with attributeSet and policyID.

[0172] Furthermore, the CXP building extension interface 1206 is used by the build configuration interface 1204 to build CXP based on the policyID and attributeSet sets. Three CXP building extensions (i.e., the simple build extension, the template build extension, and the automated build extension) are considered in the present disclosure, which are described in detail in the following way.

[0173] Simple build extension (simple selection) : In the exemplary implementation scenario 1400, predefined CXPs are stored as {key, value} pairs, where the key is the ID and the value is base64-encoded CXP string (e.g., policyStore = {ID: base64encode (policy) } ) . The extension retrieves all predefined CXP from the policyStore (different from CTP manager) that correspond to the IDs in the PolicyID set. These retrieved CXPs are then associated with the claim or govern the behavior of the protocol. In simple term, the extension just selects CTPs from pre-defined set making it the simplest approach in mapping claims with CXPs.

[0174] Template build extension (CXP from template) : The CXP building extension interface 1206 leverages attribute values from attributeSet. The policyStore contains policy templates corresponding to the policyID, which require to be populated with attribute values from attributeSet. This can be achieved by directly comparing the keys in the attributeSet with the attributes in the policy template. Since any inconsistencies at the vocabulary level have been resolved with the claim normalizer component 106, a direct string comparison allows for correct key mapping. Once the keys are mapped, the policy template is populated with the values from the attributeSet.

[0175] Automated build extension (policy synthesis with automation) : This extension utilizes Artificial Intelligence (AI) or other machine learning techniques to synthesize a CXP. The synthesis process takes values from the attributeSet and CXP templates. The main challenge lies in training the models with appropriate CXP templates and attribute values to ensure the accuracy of the synthesized CXP. Moving forward, this is challenging to ensure the formal correctness of the CXP once it is generated.

[0176] FIG. 15 illustrates an exemplary implementation scenario of a credentials bridge middleware platform on a dataspace connector, in accordance with an embodiment of the present disclosure. FIG. 15 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12 and 13. With reference to FIG. 15, there is shown an exemplary implementation scenario 1500 of the credentials bridge middleware platform 102 on a dataspace connector 1502.

[0177] The exemplary implementation scenario 1500 illustrates a comprehensive architecture for data exchange and trust establishment between a data provider 1504 and a data consumer 1506, organized across three distinct layers. The topmost layer shows credentials mapping policy and credentials bridge components facilitating Trust Establishment between parties. The middle control plane layer contains connectors with PEP, UCON+ components, and negotiation policies managing contract negotiation processes. The bottom data plane layer shows the actual data storage and data exchange mechanisms, also incorporating PEP and data usage policies.

[0178] This architecture demonstrates how the credentials bridge middleware platform 102 integrates with the dataspace connector 1502 to enable credential transformation and trust establishment while enforcing policy controls. The bi-directional arrows between corresponding layers (for trust establishment, contract negotiation, and data exchange) indicate the symmetrical nature of interactions between the data provider 1504 and the data consumer 1506. Each layer serves a specific purpose in ensuring secure, policy-compliant data exchange while maintaining appropriate access controls and credential management, with the credentials bridge middleware platform 102 playing a central role in automating credential mapping and enforcing sovereignty requirements.

[0179] The dataspace connector 1502, enabled by the credentials bridge middleware platform 102, automates the mapping of principal credentials (managed internally by the participant) to the participant within a dataspace and facilitates access control for the principal accessing various dataspace services on behalf of the participant. Within the realm of dataspaces, only the participant is formally recognized, principals typically access services on behalf of the participant. It is the responsibility of the participant to implement appropriate access control mechanisms for its principals. In addition, the credentials bridge middleware platform 102 also support lifecycle policies, that governs the protocols that manages the claims.

[0180] In another exemplary implementation scenario, the credentials bridge middleware platform 102 can be deployed in a dataspace to provide interoperability between a locally deployed identity system based on OpenID Connect (OIDC) and the dataspace’s identity requirement. This leads to provide a mapping between internal identity of a user with the organization’s verifiable credential based decentralized identity recognized within the dataspace.

[0181] FIG. 16 illustrates another exemplary implementation scenario of a credentials bridge middleware platform on an Artificial Intelligence (AI) agent, in accordance with an embodiment of the present disclosure. FIG. 16 is described in conjunction with elements from FIGs. 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14 and 15. With reference to FIG. 16, there is shown another exemplary implementation scenario 1600 of the credentials bridge middleware platform 102 on an AI agent 1602.

[0182] There is shown a comprehensive workflow illustrating the credentials bridge's operational lifecycle across four key steps, each represented by a distinct state in the process. There is shown two policy types, namely, credentials transformation policies and credentials lifecycle policies -that govern the overall operation.

[0183] The workflow begins with the step 1 (configuration state) , where the credentials bridge middleware platform 102 is initialized with policy configurations. It then progresses to the step 2 (verification state) , where user credentials are transformed and localized based on the input claims. The step 3 (composition state) represents a waiting period for user consent and handles the composition of additional claims, which are fetched as required. Finally, the step 4 (revocation state) manages the revocation process. The diagram shows clear state changes between various steps (indicated by recycling symbols) and two possible outcomes: either proceeding to claim storage or ending the session with deletion of claims presentation. Throughout the process, the credentials bridge's policy / rule engine remains consistent at each step, handling the policy enforcement and transformations. Each state transition is triggered by specific inputs: user credentials for the step 2, yes / no consent for step 3, and revocation instructions for step 4. This structured approach ensures proper governance of AI agent 1602 interactions while maintaining security and compliance requirements.

[0184] Other implementation scenarios of the system 100 implementing the credentials bridge middleware platform 102 are described in the following way:

[0185] The credentials bridge middleware platform 102 may be implemented as Software-as-a-Service (SaaS) : The credentials bridge SaaS deployment offers cloud-based access to core credentials bridge functionalities, ideal for organizations seeking quick deployment with minimal infrastructure investment. It features tiered subscription plans based on usage metrics, API integration capabilities with existing wallet and identity systems, and access to a custom policy engine for CTP evaluation. This model particularly benefits startups and individuals requiring training purposes.

[0186] The credentials bridge middleware platform 102 can be implemented as on-premise solution. This deployment option allows organizations to host the credentials bridge locally, catering to entities with strict privacy and regulatory requirements in credential management. It provides enhanced control over infrastructure and can be customized through domain-specific policies and extension modules, whether hosted in-house or in a controlled cloud environment.

[0187] The credentials bridge middleware platform 102 offers three specialized standalone modules, such as Bridge-as-an-Issuer (BaaI) for credential-issuing institutions, Bridge-as-a-Holder (BaaH) for wallet providers requiring advanced presentation capabilities, and Bridge-as-a-Verifier (BaaV) for entities requiring normalized verification of multi-source credentials. Each module can be licensed and integrated with existing digital identity solutions.

[0188] The credentials bridge middleware platform 102 can be employed in an AI agent module. This specialized extension provides AI-powered automation for trust negotiation and credential management. It's particularly valuable in sectors like e-commerce, banking, healthcare, and government services where AI agents handle complex transactions requiring sophisticated credential management.

[0189] The credentials bridge middleware platform 102 can be implemented as a Software Developer Kit (SDK) . The developer toolkit enables third-party integration of credentials bridge functionalities into custom applications. It includes APIs for credential transformation and exchange, prebuilt bridge function modules with custom sentinel implementations, and comprehensive documentation for integration with existing identity management systems.

[0190] Credential Transformation Policy Templates: these pre-configured, industry-specific policies serve as add-ons to the credentials bridge middleware platform 102. They are particularly valuable for businesses in regulated sectors that require compliance-specific transformations, offering ready-to-use policy configurations that meet industry standards.

[0191] Additionally, the credentials bridge middleware platform 102 can be used for transformation and compliance of claims across decentralized identity networks and ecosystems. The credentials bridge middleware platform 102 can utilize different technologies in order to enable claims exchange between entities operating in different ecosystems.

[0192] The credentials bridge middleware platform 102 transforms claims issued in one ecosystem (e.g., a Dataspace Participant in Supply Chain ecosystem) as a JWT Token into a verifiable credential format, mapped to the W3C Verifiable Credentials (VC) standard that is accepted in a different ecosystem (e.g., Manufacturing ecosystem) . In an example of credential transformation, an ID issued to an employee of an organization who is a participant in a dataspace is transformed into a Decentralized Identifier (DID) -linked verifiable credential, for use across the global dataspace on behalf of the organization.

[0193] The Claims are dynamically transformed to meet the local regulatory requirements based on the dataspace's trust frameworks. In an example of cross-border compliance, a person with Indian driving license can only drive in Germany for 6 months, beyond this period the Indian driving license must be exchanged for EU driving license, once additional driving test certificates are obtained.

[0194] The credential bridge manages credential semantics and integration with trust framework to enable interoperability across dataspaces without the requirement of additional interventions. The lifecycle policies ensure that credential transformations and exchanges are secure, compliant, and revocable when required. In an example of interoperability across decentralized ecosystems, participant organization in an international dataspace requires to share health information about citizens traveling across countries. The credentials bridge can support the citizen to transform or exchange credentials related to home health card of the citizen, visa, and travel insurance to a temporary pass for the health service of the designation country for the duration of the travel. If health record information is required for interactions with the designation health service, the credential bridge can support the designation health authorities to obtain and temporarily access required information about the health record of the traveller on a need-to-know basis in compliance with home and designation regulations.

[0195] Additionally, the integration of AI-powered agents with the credentials bridge middleware platform 102 represents a sophisticated approach to managing verifiable credentials and ensuring compliance in automated service interactions. Such integration demonstrates how the credentials bridge serves as a key middleware layer, facilitating secure and compliant credential management while leveraging key technologies, such as DIDs, VCs, selective disclosure protocols, and policy frameworks (i.e., CTP and CXP) . The platform's functionality spans across several prominent areas, from AI-assisted credential presentation to comprehensive compliance monitoring and lifecycle management. Through practical examples, such as hotel bookings and healthcare service interactions, the system 100 demonstrates its capability to handle complex trust negotiations while maintaining privacy and regulatory compliance. The integration supports dynamic protocol adaptation and automated trust negotiation, ensuring that AI agents can effectively represent users while adhering to required security and privacy requirements. This implementation showcases how the credentials bridge can enhance the security and efficiency of AI-assisted interactions while maintaining strict control over credential disclosure and usage. The combination of AI capabilities with robust credential management creates a powerful solution for modern digital identity challenges, particularly in scenarios requiring automated service interactions while maintaining high standards of security and compliance. This approach effectively bridges the gap between AI automation and secure credential management, providing a foundation for trusted digital interactions in an increasingly automated world.

[0196] 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 establishing trust between entities in a decentralized data processing environment implementing a credentials bridge middleware platform (102) , the method (200) comprising steps of:receiving input claims at a claim normalizer component (106) of the credentials bridge middleware platform (102) , wherein an input claim is an assertion made by an issuance authority regarding the attributes, rights or status of a subject, wherein the input claims are represented in a plurality of assertion formats;parsing the received input claims at the claim normalizer component (106) using a parser extension corresponding to each of the plurality of assertion formats;transforming the parsed input claims at the claim normalizer component (106) into a common syntactic representation;receiving, at a claim evaluator component (108) of the credentials bridge middleware platform (102) , the transformed parsed claims in the common syntactic representation, along with normalized attributes, from the claim normalizer component (106) ;fetching, by the claim evaluator component (108) , context attributes from an attribute interface component (116) of the credentials bridge middleware platform (102) ;evaluating, at the claim evaluator component (108) , a claim transformation policy, CTP, using the normalized attributes and the context attributes; andgenerating, at the claim evaluator component (108) , obligatory actions for establishing trust between entities in the decentralized data processing environment, based on the results of the evaluating step.2.The method (200) of claim 1, wherein a CTP management interface component (112) of the credentials bridge middleware platform (102) is configured to manage and provide the CTP to the claim evaluator component (108) .3.The method (200) of claim 2, wherein a session interface component (114) of the credentials bridge middleware platform (102) is configured to provide functionality to the CTP management interface component (112) to initiate a session based on a specific CTP evaluation context.4.The method (200) of claim 1, wherein a claims execution policy, CXP, builder component (110) of the credentials bridge middleware platform (102) is configured to generate a CXP and a plurality of transformed claims based on the obligatory actions generated by the claim evaluator component (108) .5.The method (200) of claim 1, wherein the claim normalizer component (106) is configured to utilize a read configuration file to obtain information on a parser extension and on context uniform resource identifier.6.The method (200) of claim 5, wherein the claim normalizer component (106) is configured to load a specific parser extension as specified in the read configuration file.7.The method (200) of claim 5, wherein the read configuration file is represented in a specific syntactic format which contains details regarding required parser extensions and corresponding version numbers.8.The method (200) of claim 2, wherein the claim evaluator component (108) is configured to read a CTP from the CTP management interface component (112) using a CTP identifier and loads a retrieved CTP for use in the evaluating step (f) .9.The method (200) of claim 4, wherein the claim evaluator component (108) is configured to send the obligatory actions to the CXP builder component (110) .10.The method (200) of claim 7, wherein each of the obligatory actions is configured to hold a CXP identifier.11.The method (200) of claim 5, wherein the CXP builder component (110) is configured to download a CXP build extension based on extension details specified in the read configuration file.12.The method (200) of claim 1, wherein the claim normalizer component (106) is configured to compare a semantic meaning of attributes associated with the credentials bridge middleware platform (102) with those associated with the received claims.13.The method (200) of claim 1, wherein the claim normalizer component (106) is configured to store normalized attributes in a key value store for forwarding to the claim evaluator component (108) .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