Update on Connector descriptions

[ssteinbuss]

Review connector description

[HeinrichPet]

Plugfest discussion December 06th 2021

Process Layer:

• Define Interaction with other components
• Define Interaction between connectors (exchanging data, contract negotiation etc.)
• Defince Communication sequence (technology-independent) in general
• ParIs needs to be addressed in the communication sequence (DAT currently do not have a valid proofable Participant ID)
• Instead of defining IDS messages (like in the current Information model), we should focus on the attributes/parameters exchanged during interaction to allow for example the use of REST (which do not contain a Artefact request/response message)
• Enable out of band communication. We need to understand that topic for example by specifing it in IDS-G. It influence Connector interaction, Certification, Policy Enforcement, Identity and Access Management, etc. So we are aware that we can't address all parts fully till end of February, however, we should enable out of band communication in the RAM from a high level perspective as it is a important requirement at least for Catena-X and Mobility Data Space.
• Definition of a general API (technology-independent) e.g. public and private self description. One sentence is enough, to say that there is at least one API where everbody? (or IDS participants?) gets the self-description of the component (Connector, Broker, etc.).
• Update Architecture / Functional view first (where combining different aspects into one component is easier)
• Participant/User role
• Context model
• Information model
• Certification criteria

System Layer:

• Answer the questions: When do I use a connector for which context? Who should use the connector? Should I as a company use one or more connectors? ... -> Deployment scenarios
• "Integrating a federated catalog into a connector as an alternative to the broker?" -> Maybe abstract that by defining that a connector can query a catalog of metadata (not defining if it is a central or decentral metadata catalog instance)
• Integrating hyper ledger technologies into a connector as an alternative to the clearing house? -> Maybe abstract that by defining that their should be a way to tamper-proof log transactions.

Next discussion points for 13th December Plugfest meeting:

• User Identities, authentication authorization. Should we identify Users of a Connector in IDS? The requirement is that we want to provide data to a specific person inside a consumer company.
• First draft of a functional IDS Connector view

[HeinrichPet]

Plugfest discussion December 13th 2021

User Identities, authentication authorization discussion:

1. We need User identities for defining Usage Policies to only provide data to a specific person or group.
2. We need User identities for giving access to the Connector itself.

Ad 1) We have to discuss that in a usage policy related workshop.
Ad 2) This can be solved by connecting an LDAP or Keycloak. IDS does not define the roles for using the connector (admin, user, ...). Both is up to the connector implementation.

First draft of a functional IDS Connector view

• A Connector provides a self-description
• A Connector interacts with IDS components through IDS Protocol(s) to DAPS, App Store, IDS Broker, Clearing House and other IDS Connectors
• A Connector has access to a Data Source/Sink

A Connector contains:

• Data Management
• User Management
• Monitoring/Logging Service
• Configuration Service/Management
• Metadata Management
• Usage Contract Management (Note: This is mainly done at the Data Provider and have another focus then the PMP, whereas the PMP manages policies for enforecment mainly at the consumer)
• Policy Engine (PAP, PEP, PIP, PXP, PMP, PDP)
• Data App Management

Next discussion points for 20th December Plugfest meeting for the functional IDS Connector view:

• Data Transfer
• Create Data Offers
• Query Data Offers
• Cataloging
• Context Handling
• Clear Interfaces for Extensibility and Modularity

[HeinrichPet]

Missing Remote Attestation?

[gboege]

User Identities, authentication authorization discussion:
Looking forward, this should preferable enable "old" Auth/Auth but also SSI with Verifyable Credentials like in Gaia-x. For both Authorization and Authentication.

[gbrost]

Including a user model for accessing admin GUIs etc. is useful and would help to address the certification criteria, since these address user access management. Adding user models für usage control might be a bit tricky. This would impose a defined user model for all apps, data streams and workflows. This would also define a model how authentication and authorisation needs to be performed (see Gernots comment). User handling for these kind of applications should be part of the application layer. Maybe we need some kind of extension model. But we should not globally enforce a fixed model that would kill flexibility.

[HeinrichPet]

Regarding the section 3.5.2 in RAM 4.0 we need to discuss if we need :

• the distinction between configuration time and execution time
• to define Execution Core Container/Data Bus/Data Router (maybe both are not part of one container? maybe someone only use a data router?)
• the configuration manager/model, when there is no implementation for them

Do we need the special connectors section?

This brings us to the point to discuss the identity of a connector : #31

[HeinrichPet]

Plugfest discussion December 20th 2021

First draft of the Functional View