Modeling Ecosystems
This section will guide you through leveraging the Raidiam Connect platform to securely access data in a controlled environment, enabling you to trust the data you receive and foster new opportunities.
In the context of Raidiam Connect, effectively modelling an ecosystem involves the meticulous definition of key components:
- How you will model your ecosystem through:
- Authority, Domains, Roles and Metadata
- Who will be a part of it:
- Organisations, Data Providers, Data Receivers
- Required communication models:
- Types of certificates
Each of these elements plays a critical role in the structure and functionality of the ecosystem.
Defining Authority, Authorisation Domains, Roles and Metadata.
Authorities are central to the governance of the ecosystem. They are responsible for accrediting participants and assigning Authorisation Domains and Roles.
Operational Scope: While typically associated with a specific country, an Authority can operate across national boundaries if necessary.
Multiplicity and Collaboration: An ecosystem can have multiple Authorities, each contributing to the robustness and diversity of the ecosystem’s governance.
Authorisation Domains represent the highest level of authorisation categorisation in the ecosystem. They provide a primary framework for classifying and managing various activities and participants.
Customization and Flexibility: Domains can be tailored to accurately represent different segments or operational areas within the ecosystem. They avoid regional or country identifiers to maintain global applicability.
Roles, defined within each Authorisation Domain, specify the functions or permissions granted to different participants.
Diversity and Specificity: Roles can range from general categorisations of participants to specific operational permissions, such as data access or API management rights.
Role Claims and Assignments: The assignment of roles is based on Authority Domain Role Claims, ensuring that each participant’s capabilities and permissions are clearly defined and regulated.
Each Authorisation Domain Role can be associated with specific OAuth metadata types, dictating the permissions and access levels within the role.
Access Control: The assignment of specific OAuth metadata to roles enables a more granular and controlled access management within the ecosystem. This ensures that each organisation and data receiver operates within the boundaries of their assigned roles and permissions.
OAuth metadata types in Raidiam Connect include:
- Grant Types: These are methods through which an application gets an access token. Different grant types are suitable for different kinds of applications, depending on their level of trust and the kind of user experience they deliver.
- OAuth Scopes (scope): Scopes are used to specify what access privileges are being requested as part of the authorization. They define the extent of access that the application is requesting to the user's data.
- ID Claims (claim): Claims are pieces of information asserted about a user and are used in the context of ID Tokens in OpenID Connect. They can include user details such as the user's name, email, and other profile information.
- Response Types: These determine what authorization details are returned from the initial authorization request. Common response types include tokens and authorization codes.
Description: Detail the types of organizations that will participate in the ecosystem, such as financial institutions, insurance companies, tech firms, etc. Example: Banks, insurance providers, fintech startups, regulatory bodies.
Description: Identify the entities responsible for providing data within the ecosystem, including their obligations and the nature of the data they provide. Example: Financial institutions providing transaction data, insurance companies sharing policy details.
Description: Describe the entities that will receive or consume data, including how they can access data and the expected use cases. Example: Third-party developers accessing banking data to offer personalized financial services, insurance firms using data for risk assessment.
In Raidiam Connect, certificates play a crucial role in ensuring the security and integrity of data communication and transactions. Our platform supports a diverse range of certificates, catering to both signing and transport security needs. The format of these certificates can be configured to align with the specific requirements and standards of different ecosystems.
Signing Certificates
Purpose: Signing certificates are used to authenticate the identity of the entities involved in the transaction and to ensure the integrity and non-repudiation of the data being exchanged.
Example: Digital signatures in financial transactions or data exchange agreements that verify the sender’s identity and ensure the data hasn’t been tampered with.
Transport Certificates
Purpose: Transport certificates are used for securing data in transit. These include SSL/TLS certificates that encrypt data during transmission, protecting it from interception and tampering.
Example: SSL/TLS certificates used in HTTPS connections for secure communication between financial institutions and third-party applications within the Open Banking domain.
Configurable Formats
Flexibility: Understanding that different ecosystems may have varying requirements and standards, Raidiam Connect offers the flexibility to configure the format of these certificates. This includes supporting a range of certificate formats like PEM, DER, PFX, etc., based on ecosystem specifications.
Example: In an Open Insurance ecosystem, the platform might be configured to use PEM format certificates, while in an Open Healthcare context, DER format could be preferred, depending on the regulatory and technical requirements of each domain.
Integration with Ecosystem Specifications
Adaptability: The platform is designed to adapt to the specific security and authentication standards of various ecosystems. This includes complying with regional regulations, industry-specific security practices, and custom authentication flows.
Example: Adhering to PSD2 regulatory standards in the European Open Banking ecosystem, or aligning with HIPAA compliance in healthcare data exchanges in the United States.
Raidiam Connect also offers its own PKI, which you can find more details here.
These elements work in concert to create a coherent and functional ecosystem. Together, they dictate how participants interact, the scope of their operations, and the overall governance structure of the ecosystem.
Authority: In an Open Banking ecosystem, the Authority might be a financial regulatory body such as the UK Financial Conduct Authority (FCA). This Authority is responsible for accrediting participants and ensuring compliance with relevant regulations.
Authorisation Domains: The FCA might establish Authorisation Domains like 'Retail Banking', 'Commercial Banking', and 'Open Insurance'. Each domain represents a distinct segment of the financial services ecosystem.
Roles: Within these domains, specific roles are defined. For instance, in the 'Retail Banking' domain, roles could include 'Data Provider', responsible for supplying customer financial data, and 'Data Receiver', authorized to access and use this data. In 'Open Insurance', roles might include 'Policy Information Provider' and 'Claims Processor'.
Metadata: Grant types like 'authorization_code' might be used for web applications, while scopes like 'read_accounts' or 'write_payments' define the specific actions an app can perform with user data.
Organisations:
- Banks and Financial Institutions: Providing banking services and financial data.
- Fintech Companies: Offering innovative financial solutions and services.
- Regulatory Bodies: Ensuring adherence to open banking standards and regulations.
- Other suppliers: Other suppliers that might need access to the platform
Data Providers:
- Banks: Offering access to customer financial data such as account information and transaction histories.
- Financial Service Providers: Supplying credit scores, loan details, and other financial data.
Data Receivers:
- Third-Party Application Developers: Creating applications that use financial data for services like budgeting tools or investment advice.
- Other Financial Institutions: Using data for purposes like credit assessment or fraud detection.
Authorisation Domain | Authorisation Domain Role | Technical Metadata Type | Technical Metadata value |
|---|---|---|---|
PSD2 | PISP | scope | openid payments |
PSD2 | PISP | grant_type | authorisation_code |
Open Banking | DADOS | response_type | code id_token |
Retail Banking | Data Provider | scope | make:payments |
Commercial Banking | Data Receiver | grant_type | authorisation_code |
Authority: A national health authority or a specialized healthcare data governance body.
Authorisation Domains: Domains such as 'Patient Data Management', 'Healthcare Provider Services', and 'Medical Research'.
Roles: In 'Patient Data Management', roles could encompass 'Data Custodian' (managing patient data storage and protection) and 'Data Accessor' (such as healthcare providers accessing patient records). 'Medical Research' might include roles like 'Research Entity' (entities conducting medical research) and 'Data Contributor' (institutions providing data for research).
Metadata: For a healthcare data sharing platform, ID claims might include sensitive health data attributes, and response types could be carefully managed to ensure patient data confidentiality.
Organisations:
- Hospitals and Clinics: Managing patient care and health data.
- Research Institutions: Conducting medical research and studies.
- Healthcare Technology Companies: Developing healthcare solutions and platforms.
Data Providers:
- Healthcare Providers: Offering patient health records and clinical data.
- Public Health Agencies: Supplying epidemiological data and health statistics.
Data Receivers:
- Medical Researchers: Using health data for research and studies.
- Healthcare Analytics Firms: Analyzing health data for insights and trends.
Authority: An educational oversight body or a consortium of educational institutions.
Authorisation Domains: Domains may include 'Curriculum Development', 'Student Data Management', and 'Online Learning Platforms'.
Roles: 'Curriculum Developer' and 'Curriculum Reviewer' in the 'Curriculum Development' domain, 'Student Data Analyst' and 'Data Protection Officer' in 'Student Data Management', and roles like 'Content Provider' and 'Platform Administrator' in 'Online Learning Platforms'.
Metadata: Scopes can be limit third-party educational applications to accessing just the necessary student resources
Organisations:
- Educational Institutions: Schools, colleges, and universities providing education.
- E-Learning Platform Providers: Offering online learning tools and resources.
- Educational Regulatory Bodies: Setting standards and overseeing education quality.
Data Providers:
- Schools and Universities: Providing student academic records and curriculum details.
- Online Course Platforms: Supplying educational content and learning resources.
Data Receivers:
- EdTech Companies: Developing educational technologies using student data.
- Academic Researchers: Conducting research in educational methodologies and outcomes.
The "Open Milk" ecosystem is defined and regulated by the Ministry of Agriculture as a collaborative environment for sharing data related to cheese production and its derivatives. Participants in this ecosystem include:
- Data Receivers: Entities that can access information from the different Milk Producing Entities, as defined by the Ministry of Agriculture, they can be authorized to obtain Data from Milk Data Holders, Cheeses Data Holders or the Derivatives Data Holders, after being correctly onboarded
- Milk Data Holders: Entities that provide data on milk used in cheese production.
- Cheese Data Holders: Entities that provide information on their various types of cheeses.
- Derivatives Data Holders: Entities that provide information on their various types of milk derivatives.
For the Ecosystem Above we will have the following information to be configured:
- Authority: Ministry of Agriculture
- Domain Name: Open Milk
- Roles: Milk Data Receiver (MDR) , Cheese Data Receiver (CDR), Derivatives Data Receiver (DDR)
Once the information above has been set and correctly linked, the Ecosystem will then be required to define the OAuth 2.0 metadata that will be granted by each role, which includes the grant_types, scopes, claims...
For the metadata added to each of the following Roles
Role | Role Description | Scopes | Grant type | Claims |
|---|---|---|---|---|
MDR | Milk Data Receiver | skim-milk, whole-milk | authorisation_code | national_id |
CDR | Cheese Data Receiver | gouda, cheddar, parmesan | client_credentials | national_id |
DDR | Derivatives Data Reciver | yogurt | authorisation_code, client_credentials | national_id |
Customization and Adaptability:
- Raidiam Connect is adaptable to various types of ecosystems, each with its unique requirements and regulatory environments.
Structured Governance and Operations:
- This structured approach ensures that every participant in the ecosystem understands their role, the rules governing their actions, and the scope of their operations, leading to a well-regulated and efficient ecosystem.
Enhanced Compliance and Efficiency:
- By clearly defining these elements, ecosystems can ensure compliance with relevant regulations and standards, and operate more efficiently by streamlining interactions among participants.