Guide for DOME marketplace integration and federation
Table of Contents
NOTE: We want future Participants to integrate successfully and efficiently, therefore we provide a clear, structured, step-by-step Integration Guide that is comprehensive, self-contained, self-explanatory and actionable. This Integration Guide should:
- be the single point of entry for any stakeholder that wants to execute on integrating and federating a marketplace in DOME
- be the reference for what is currently available to integrators and with what level of stability vs. expected change
- not assume knowledge of DOME implementation details from the part of the reader
- be comprehensive so as to allow an executing IT/eng team to work autonomously
- provide detailed, self-contained, actionable instructions
- include context when appropriate to facilitate the comprehension of the Why, the What, the How and the with Whom at each step.
A complete and functioning integration of a marketplace in a federated DOME environment (contractual and business aspects not included).
x. need to be a legal entity of this type or another; have a registration number of this type or another; etc.
ex. have an eIDAS certificate; pointers to how one can be procured etc.
- What actions do I need to perform and where?
- What information do I need to provide, to whom, and in what form?
- What artefacts do I need to provide and to whom ? (ex. VCs)
- How do I obtain/produce/certify those artefacts ? (ex. GAIA-X compliance)
- What artefacts do I get out of the onboarding process how/where do I use them subsequently ? (ex. the signing key that will later be used by my Access Node)
Components that need to be operated by a federated participant.
To understand what the sub-components are, how they all work together and how they interact
ex. internal endpoint for the TMForum APIs ; external endpoint for the context broker API ; other endpoints between components ?
incl. where to find clean, versioned, infrastructure agnostic HELM charts.
Recommended configuration for all the sub-components, any considerations. When should I change them?
(validate that everything works)
- Management/admin APIs.
- Instrumentation, metrics, logs, alerts
Versioning, release notes, stability considerations
(similar to the Access Node section)
using wallets, OIDC4VC&VP. verification etc.
Samples & tutorials for implementing core federation scenarios using the TMForum APIs (with focus on semantics and workflow, beyond the API reference)
- How can a Service Provider create policies that concern the Products that they offer ?
- How can a Marketplace Operator create policites that concern the Products that they host ?
That only the federated marketplace needs to enforce locally.
That everyone in the federation needs to enforce.
i.e. marketplace -to- Access Node PEP, PDP - when are they needed and when not ?
i.e. Access Node -to- Access Node
Some content
Some table:
| Title 1 | Title 2 | Title 3 |
|---|---|---|
| abc | def | ghi |
| 123 | 456 | 789 |
| jkl | mno | pqr |
Some more content
Some mermaid diagram
graph TD;
A-->B;
A-->C;
B-->D;
C-->D;
Second content
-
Another table:
Title 1 Title 2 Title 3 abc def ghi 123 456 789 jkl mno pqr