Description (Problem to be solved and requirements to satisfy)
We face 4 problems in general:
Contracts / Transfer History on provider side does not contain any consumer details aside of URL and ID
Logging House only knows ID
On provider side with ProviderConfirmationPolicy no information about the consumer are available
On consumer side no validatable information are available. Workaround to set details by provider in asset details exists. But these details are not validated.
The goal is that a user of an EDC can use the participant ID to lookup to receive validated organization details from Authority Portal API.
Benefits
Verifiable and trustable information about participants
Complies with participant information service of IDSA architecture
No adjustment in DSP necessary
Stakeholders
MDS
Mobilithek: Feature is required to comply with requirements and enhances compatibility with Mobilithek
The implementation shall take into consideration that in the future the lookup service might be externalized with a write-through cache to satisfy high-load scenarios.
Out of scope
request
Processes
Developer UX via API
As an developer I call an API either with one ID or a set of IDs and receive necessary organization details: participant ID, Legal Name, Commerce Register Number, Website, Main Address, Main Contact (name+email)
Iterations
PoC Implement Participant Details Lookup Service endpoint to receive validated information about specific ID; Protect via (to be refined) secret parameter/path mapping; This enables manual lookup of participant information. Authority Portal Catalog UI adjustment adding a hint about necessary confirmation;
MvP Implement ParticipantInformationDetails EDC Extension. Integrate extension into EDC.
Later Integrate extension into Logging House.
Work Breakdown
### EDC-CE / API Wrapper
- [ ] Add another API Wrapper endpoint for Contract Details which adds all organization details of the counter-party consumer/provider.
### Authority Portal
- [ ] Implement API endpoint
- [ ] Secure API endpoint with parameter/path mapping (TBD)
Feature
Description (Problem to be solved and requirements to satisfy)
We face 4 problems in general:
The goal is that a user of an EDC can use the participant ID to lookup to receive validated organization details from Authority Portal API.
Benefits
Stakeholders
References
Solution Design
Affected Areas and Components
General Requirements
Out of scope
requestProcesses
Developer UX via API
Iterations
Work Breakdown
Architecture