Optimize the service / app subscription process

[maximilianong]

Overview

Explain the topic in 2 sentences

When customers subscribe to the Golden Record Service, a technical user is created in their profile but is inaccessible due to private settings, and the operator uses it to manage assets in the EDC. The proposed update will notify customers of the technical user’s creation for operator use, grouping it separately in their profile without revealing sensitive details.

What's the benefit?

Security and user experience.

The technical users cannot be used because the network settings for these endpoints are set to private. However, if a release or other circumstances were to mistakenly change this setting, this solution provides an added layer of security.

UX: The customer sees something in the process that they cannot use and may not understand its purpose.

What are the Risks/Dependencies ?

What happens to the current implementation, where the customer has access to those technical users?

Detailed explanation

Current implementation

When the customer/user clicks "subscribe" to the Golden Record Service from BPDM, they are shown a technical user in their profile that they cannot use. This is because the service endpoints are "private" and accessible only via EDC as a proxy. However, the operator still requires the technical users generated in step 2 to create the assets within the EDC.

Proposed improvements

Before the subscription process, the customer must acknowledge that a technical user linked to their identity will be created and used by the operator. Once the subscription is approved, a pop-up will notify the customer that the technical user has been created, but no details will be displayed. In the section where the customer can view all their technical users, there will be a separate segment listing the technical users utilized by the operator, again without detailed information (such as client secrets, etc.).

Feature Team

Contributor

• @manojava-gk

Committer

• @manojava-gk
• Committer 2

User Stories or related features

eclipse-tractusx/portal-iam#168
#918

Acceptance Criteria

Before completing the subscription process, the customer must see and confirm an acknowledgment message stating that a technical user linked to their identity will be created and managed by the operator for service operation.

Upon successful subscription, a pop-up notification appears to inform the customer that the technical user has been created. This pop-up will not display any technical details about the user.

In the customer's technical user section, a dedicated segment will list technical users utilized by the operator.
This segment will display only minimal information (e.g., user name) without exposing sensitive details such as client secrets or access tokens.

Only the operator can access and use these technical users.

Test Cases

Test Case 1

Steps

1. Do something
2. Click something
3. Add something

Expected Result

1. Expectation
2. Expectation
3. Expectation

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

[MaximilianHauer]

@maximilianong on the implementation we would need to discuss , evtly it would be good to include @dorkabcox and @ybidois to discuss the implementation also from cofinity perspective

[evegufy]

Committers:
@oyo
@ntruchsess
@Phil91
@evegufy

[MaximilianHauer]

userstory that will implement this feature

• sig#987 - Enhance App/Service configuration by new checkbox + section portal-frontend#1408
• sig#987 - Enhance API by new parameter displayTechnicalUser portal-backend#1210
• sig#987 - Filter technical User that are not owned and have displayTechnicalUser = false (apps/Services) portal-backend#1211