15 review process layer and broker

README.md

@@ -59,7 +59,7 @@ README.md this file
 
 ### Others (TODO: valid for the old Latex files in the folder ./LaTex, not for the new structure)
 - [Media folder for pictures and other resources](./media)
-- [IDSA_RAM_4_0.tex as umbrella document](./IDSA_RAM_4_0.tex)
-- [list of authors](./authors_contributors.tex)
-- [bibliography](./bibliography.bib)
-- [front matter](./editor_contributing_projects.tex)
+- [IDSA_RAM_4_0.tex as umbrella document](./LaTex/IDSA_RAM_4_0.tex)
+- [list of authors](./LaTex/authors_contributors.tex)
+- [bibliography](./LaTex/bibliography.bib)
+- [front matter](./LaTex/editor_contributing_projects.tex)

documentation/3_Layers_of_the_Reference_Architecture_Model/3_3_Process_Layer/3_3_1_Onboarding.md

@@ -1,29 +1,32 @@
 ## ONBOARDING
 
-The overall “Onboarding” process consists of several sub processes. The first step for an organization to join the International Data Spaces as a Data Provider or Data Consumer is to acquire an identity to be used in the IDS. This identity, which forms the basis for establishing trusted communication in the IDS, is provided by the Certification Body and an Evaluation Facility in the form of a certificate issued by an Identity Provider. In a second step, the organization needs to request a Connector from a Software Provider. The Connector, being the core technical component for becoming part of the IDS, must then be installed. After that, it receives a digital certificate (X.509 certificate) to make sure it complies with IDS specifications and requirements. The digital certificate is based on the certification of the participant and the certification of the Connector (see section 3.1 and section 4.2). (**//TODO** insert link to  Business Layer and Certification Perspective) In a third step, the Connector needs to be configured for internal use and prepared for secure communication ([Security Setup](#security-setup)). In the final step, the Connector needs to be made available for other participants in the IDS so that it can finally enter live operation.
+The overall 'Onboarding' process consists of several sub-processes. The first step for an organization to join the International Data Spaces as a Data Provider or Data Consumer is to acquire an identity to be used in the IDS.  <!-- old: This identity, which forms the basis for establishing trusted communication in the IDS, is provided by the Certification Body and an Evaluation Facility in the form of a certificate issued by an Identity Provider. -->
+This identity, which forms the basis for establishing trusted communication in the IDS, is provided by an IDS Identity Provider in the form of a certificate issued by an accredited Certification Authority (CA).
+In a second step, the organization needs to either request a Connector from a Software Provider or create its own one. The Connector, being the core technical component for becoming part of the IDS, must then be installed. After that, it is provisioned with the previously mentioned a digital proof of its IDS identity (X.509 certificate) to make sure it complies with IDS specifications and requirements. The digital certificate is based on the organizational certification of the participant and the technical certification of the Connector (see section 3.1 and section 4.2). (**//TODO** insert link to the Business Layer and Certification Perspective) In a third step, the Connector needs to be configured for internal use and prepared for secure communication ([Security Setup](#security-setup)). In the final step, the Connector needs to be made available for other participants in the IDS so that it can finally enter live operation.
 
 
-The overall “Onboarding” process is illustrated in the following figure.
+The overall 'Onboarding' process is illustrated in the following figure.
 
 ![Onboarding process](../../media/image22.png)
 
 The following paragraphs describe each step of the onboarding process in more detail.
 
 ### ACQUIRE IDENTITY
-Any organization that wants to operate a connector in order to exchange data in the International Data Spaces as a Data provider or Data Consumer needs to acquire a unique identity in the form of a certificate. This certificate enables them to establish secure and trusted connections to other IDS participants (see section 3.1).
+Any organization that wants to operate an IDS Connector in order to exchange data in the International Data Spaces as a Data provider or Data Consumer needs to acquire a unique identity in the form of a digital certificate. This certificate enables them to establish secure and trusted connections to other IDS participants (see section 3.1). Please note that this identity certificate is by default not the same as the one necessary to encrypt the communication channel itself. Even though both may use the same standards (X509), the purposes are different and therefore different certificate files can be used. It might be even a best practice to distinguish them to reduce the risk of identity theft, even though the IDS itself does not determine how to preoceed.
 **//TODO** insert link to  Business Layer
 
 ### CONNECTOR CONFIGURATION AND PROVISIONING
-Each Connector that participates in the IDS ecosystem must provide a self-description for other IDS participants to read. The respective organization needs to create this description at the beginning of the connector configuration and provisioning sub process. The Connector self-description must contain information about the respective organization, about who maintains the Connector (i.e. the Service Provider), and about the content and type of the data offered or requested.
+Each Connector that participates in the IDS ecosystem must provide a Self-Description for other IDS Participants to read. The respective organization needs to create this description at the beginning of the connector configuration and provisioning sub process. The Connector Self-Description must contain information about the respective organization, about who maintains the Connector (i.e. the Service Provider), and about the content and type of the data offered or requested. The IDS Information Model (**//TODO** insert link to the IM section) defines the mandatory and optional attributes of the Self-Description.
 
-Another mandatory step for the organization to take is to orchestrate data flows for (future) data retrieval and data provisioning, respectively, and to set up system adapters and communication interfaces (“endpoints”). (Details on the configuration of the IDS Connector are described in section 3.5.1.1). **//TODO** insert link to  System Layer/Connector Configuration Model
+Another mandatory step for the organization to take is to orchestrate data flows for (future) data retrieval and data provisioning, respectively, and to set up system adapters and communication interfaces ('endpoints'). (Details on the configuration of the IDS Connector are described in section 3.5.1.1). **//TODO** insert link to  System Layer/Connector Configuration Model
 
-If needed, the organization can install and configure Data Apps acquired from the App Store Provider.
+If needed, the organization can install and configure Data Apps acquired from an App Store Provider or register its Connector Self-Description and the Self-Descriptions of the provided Data Resources at one or several IDS Metadata Brokers.
 
 ### SECURITY SETUP
-To enable secure communication, a Certification Authority issues a certificate to the Data Provider or Data Consumer. This certificate is deployed locally to enable Transport Layer Security (TLS) and identification of the respective IDS participant. On top of that, the Connector self-description must be correct and valid, which is ensured by requesting a Dynamic Attribute Token from the Identity Provider (section 4.1). The token is a signed attestation that the information the Connector states about itself has been verified and is actually true. The token is presented by each subsequent outgoing communication message of the Connector, so that also the communicating Connectors have a means to verify the trustfulness of their communication partners at any time.
-Furthermore, any organization that wants to assume the role of Data Provider or Data Consumer has the option to configure custom access restrictions for bilateral communications. For instance, a Data Provider may want to block certain Connectors or participants from accessing their services, or it may require specific access credentials. These configurations may be set up in the last step of the Security Setup sub process (see section 4.1). **//TODO** insert link to  Business Layer
+To enable secure communication, a Certification Authority issues a certificate to the Data Provider or Data Consumer. This certificate is deployed locally to enable Transport Layer Security (TLS) and identification of the respective IDS participant in combination with the Dynamic Attribute Token (IDS DAT). Note that the TLS certificate mentioned here and the previously mentioned IDS identity certificate may not be the same file. On top of that, the Connector Self-Description must be correct and valid, which is ensured by requesting and receiving a Dynamic Attribute Token from the Identity Provider (section 4.1). The token is a signed attestation that the security-critical information that the Connector states about itself has been verified and is actually true. The token is presented by each subsequent outgoing communication message of the Connector, so that also the communicating Connectors have a means to verify the trustfulness of their communication partners at any time. Important to understand is that the DAT only supports the claims that are actually contained in the token itself. Additional attributes or descriptions that are only part of the Self-Description files, for instance Contract Offers, licenses, or endpoint descriptions, are not verified by any IDS Identity Provider.
+
+Furthermore, an organization that wants to assume the role of Data Provider or Data Consumer has the option to configure custom access restrictions for bilateral communications. For instance, a Data Provider may want to block certain Connectors or Participants from accessing their services, as they are competitors in their respective industry or any other reason, or it may require specific access credentials. These configurations may be set up in the last step of the Security Setup sub-process (see section 4.1). **//TODO** insert link to  Business Layer
 
 ### AVAILABILITY SETUP
-After local Connector deployment and Security Setup, a Connector must be made available for other participants in the International Data Spaces. This is done by the provisioning of an “External Connector”, which runs in a so-called “Demilitarized Zone (DMZ)” and forwards or filters requests to the “Internal Connector”. Alternatively, proper adjustment of firewall rules may be sufficient (in less sensitive environments). Each Data Provider and Data Consumer can decide whether or not they want to announce their Connector (or the data resources accessible through their Connector) publicly on the IDS. If they do so, they can select a Broker from a
-set of available Broker services (i.e., a registry for Connector self-descriptions) to publish the self-description of their Connector (see above). The Broker provides functions for searching for and retrieving registered Connector self-descriptions (see section 3.5.2), including data sources, interfaces, security profiles, and current levels of trustworthiness.
+After local Connector deployment and Security Setup, a Connector must be made available for other Participants in the International Data Spaces. This is done by the provisioning of an 'External Connector', which may run in a so-called 'Demilitarized Zone (DMZ)' and forwards or filters requests to the 'Internal Connector'. Alternatively, proper adjustment of firewall rules may be sufficient (in less sensitive environments). Each Data Provider and Data Consumer can decide whether or not they want to announce their Connector (or the data resources accessible through their Connector) publicly on the IDS. If they do so, they can select a Metadata Broker from a
+set of available instances (i.e., a registry for Connector Self-Descriptions) to publish the Self-Description of their Connector (see above). The Metadata Broker provides functions for searching for and retrieving registered Connector Self-Descriptions (see section 3.5.2), including data sources, interfaces, security profiles, and current levels of trustworthiness.