Onboarding Service Provider (OSP) API and FE Improvements

[ybidois]

Overview

Explain the topic in 2 sentences

To improve the OSP functionality, we plan to bring OSP API and FE improvements

What's the benefit?

Increase security and efficiency of onboarding through OSPs.

What are the Risks/Dependencies ?

No dependency

Detailed explanation

Current implementation

Current implementation lacks some key features needed to make sure the OSP functionality can be scaled on the Operator side.

Proposed improvements

• Backend API can validate data and return error messages to OSP provider when they send a registration request
• Customers have the possibility to edit their company details before validating their registration
• Improvement Managed and Owned IDP creation logic
• CX-Operator has access to a management dashboard to see registrations from all OSPs
• CX-Operator can see in the Application Requests table which registrations come from OSPs and from which OSPs

  Feature Team

Contributor

• @dhiren-singh-007
• @Usmanfee
• @ybidois

Committer

• @oyo
• @ntruchsess
• @Phil91
• @evegufy

User Stories

• Acceptance Criteria

• [ ] Backend API can validate data submitted by OSP and return error messages
• [ ] Backend API can validate data and return error messages to OSP provider when they send a registration request
• [ ] Customers have the possibility to edit their company details before validating their registration
• [ ] CX-Operator has access to a management dashboard to see registrations from all OSPs
• [ ] CX-Operator can see in the Application Requests table which registrations come from OSPs and from which OSPs

Test Cases

Test cases will be developed in the User Stories by our QA @Sana

Architectural Relevance

The following items are ensured (answer: yes) after this issue is implemented:

• [ ] This feature aligns with our current architectural guidelines
  • Data Sovereignty: All data sharing activities across company boundaries follow the Catena-X Regulatory Framework, in particular the Data Exchange Governance, and the Dataspace Protocol via a compliant Connector (like the tractusx-edc or similar, see Connector KIT)
  • [ ] CX-0010 Business Partner Number
  • [ ] CX-0013 Identity of Member Companies
  • [ ] CX-0018 Data Space Connectivity (EDC)
  • [ ] CX-0049 DID Document Schema
  • [ ] CX-0050 Framework Agreement Credential
  • [ ] CX-0149 Verified Company Identity
  • Interoperability: Digital Twins are used (compliant to the Digital Twin KIT and the Industry Core KIT)
  • [ ] CX-0001 EDC Discovery API
  • [ ] CX-0002 Digital Twins in Catena-X
  • [ ] CX-0018 Data Space Connectivity (EDC)
  • Data Format:
  • [ ] The data model is based on a published Semantic Model
• [ ] The impact on the overall system architecture has been assessed. The Feature does not require changes to the architecture or any existing standard? Please have a look here on the overarching architecture
• [ ] Potential risks or conflicts with existing architecture has been assessed

Justification: (Fill this out, if at least one of the checkboxes above cannot be ticked. Contact the Architecture Management Committee to get an approval for the justification)

Additional information

• [ ] I am aware that my request may not be developed if no developer can be found for it. I'll try to contribute a developer (bring your own developer)

[stephanbcbauer]

Some hints from Release Management (@ther3sa) and Tractus-X Project Lead (@stephanbcbauer)

• Status currently in Inbox. ⇾ Only features with status backlog are considered in open planning
• Please add missing sections from the feature template, or fill them out
• Please add committer

[evegufy]

Committers: @oyo @ntruchsess @Phil91 @evegufy