Replies: 3 comments 2 replies
-
Discussion after Sebastian Bader left:
Maybe not highest priority at the moment:
|
Beta Was this translation helpful? Give feedback.
-
Proposal to move ahead with our workdistinguish between different packages: FoundationThis is the common foundation for all subsequent activities foundational standards (references)please list relevant things here that we use that already exist. Information ModelOne common model that is used in every other package List of information models that we use + list of IDS-specific attributes/classes/packages/. Identities
Trust Frameworks
Policies (authorization and Policy Description)
Data Sharing (Conector)Contract Negotiationpart of the control plane
Data Transferpart of the data plane. How data is exchanged with focus on communication and not on how the data plane is built.
Catalog (Publish and query meta-data)
Registration
Audit loggingcurrently out of scope Vocabulariescurrently out of scope part of the system layer in RAMWhat has to be realized into a solution and not part of the communication:
|
Beta Was this translation helpful? Give feedback.
-
Just as a pointer to some work that we did on the IDSCP2. After establishing the trusted connection, you could either do agreement on the data plane communication or run IDS message exchange directly. |
Beta Was this translation helpful? Give feedback.
-
Several issues appeared during the implementation efforts facing the communication patterns. The following things are required:
only synchronous message exchange handled in/from one component in one process at one endpoint
-> How to establish context and how to use the context in different components and across different sessions (in time)?
-> What are the state transitions in each defined sequence? (When are we allowed to e.g. forget the history of a communication?)
->
-> What is 'context' for us? How do we define it? Where? Which attributes are needed for the context of which sequences? Context can e.g. a negotiation history, a ContractAgreement, session IDs etc.
-> What are requirements coming from streaming data?
Communication description is driven by the view from the infrastructure components. Should be the other way around, the component interfaces shall be defined based on generic communication patterns.
Beta Was this translation helpful? Give feedback.
All reactions