Implementation of Onboarding Process and DCP Issuance Flow for BYOW

[hkny]

Overview

As a part of Bring Your Own Wallet (BYOW) efforts within the Catena-X to decentralize the wallet ecosystem in the network, it is necessary for some of the Tractus-X components (i.e. Portal Backend) to foster this movement and some of the components (i.e., ssi-credential-issuer) to be decommissioned and substituted by new components (tractusx-issuer-service)

Currently the ssi-credential-issuer requires clientID and secret for the individual wallet tenants within the SAP DIV Wallet, which is offered as a Core Service B from the operating company. This approach has several issues

• There are third-party components (i.e. ssi-credential-issuer) that must know the clientID and secret that is meant for the owner of the wallet; the best practice is to ensure that the clientID and secrets are not shared between organizations, let alone services.
• It is a custom solution and there are no specifications or protocols around it. Furthermore, it was thought as a temporary solution.

The solution is to implement a secure credential exchange protocol to make sure that components and services running in different domains / organizations can issue / store credential in a secure manner.

To address this issue, the Decentralized Claims Protocol (DCP) issuance flow is proposed to be the Catena-X Standard for issuing Verifiable Credentials (VC).

The ssi-credential-issuer is to be replaced by the new issuer service, that already brings the capabilities of the DCP Issuance Flow.

Onboarding Process
The decentralization of the wallet and different offerings, such as wallet-as-a-service of self-hosted wallets, it is required to implement different flows for the onboarding process. It will be necessary to make the necessary changes in the portal backend and frontend components.

Explain the topic in 2 sentences

Current issuance flow within Catena-X has flaws due to security reasons mentioned in Overview.
It is to be replaced by the DCP issuance flow
Replacement is to be done by replacing the ssi-credential-issuer with the issuer service
Onboarding Processes must be adapted for portal backend and frontend

What's the benefit?

Security
Enabling the decentralization of the wallets within the Catena-X network

What are the Risks/Dependencies ?

Interface Partners are the Portal backend and the Wallet (SAP DIV Wallet, Identity Hub, Wallet-stub)
Potential API changes that comes with the issuer service for Portal to visualize the active / archived / revoked Credentials
Potential API changes that comes from on-boarding, issuance, re-issuance, key rotation, off-boarding features to portal backend

Detailed explanation

To be refined

Current implementation

The onboarding / issuance flow:

• Wallet creation using the wallet-integration-layer (non TX component)
• The wallet information, including the clientID and secret to access the wallet is communicated with the Portal backend
• When a credential is to be signed, issued, and stored, the ssi-credential-issuer requires the same clientID and secret from the Portal backend to store the VC in the corresponding wallet

Proposed improvements

DCP issuance flow:

• The wallet owner creates an ID token with an access token in it to write VC into the wallet
• The ID token is sent to the issuer service
• The issuer service authenticates the ID token, extracts the access token to use it to store VCs in the wallet

Besides the DCP Issuance Flow as a secure exchange protocol, the improvement adds the key features like key rotation and off-boarding, which was missing in the Catena-X / Tractus-X as capabilities

Feature Team

Contributor

• @hkny
• @paullatzelsperger
• @jimmarino
• @leandro-cavalcante
• @nitin-vavdiya

Committer

• @paullatzelsperger
• @nitin-vavdiya
• @evegufy

User Stories

see sub-issues

To be refined

Acceptance Criteria

• The DCP Issuance Flow is implemented as per specification
• Decommissioning of ssi-credential-issuer
• Introduction of issuer service
• Dependency fixes around ssi-credential-issuer to integrate the issuer service to the Portal backend

Test Cases

To be refined

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.

In the context of the standards 126 and 127, typically only one is applicable, depending on the specific use case. Please cross out one of the two standards that does not apply.

• 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)
    • [?] CX-0126 Industry Core: Part Type 2.0.0
    • [?] CX-0127 Industry Core: Part Instance 2.0.0
  • Data Format:
    • The data model is based on a published Semantic Model
• [to be done] 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
• [to be done] 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)

To be created sub-issues

• When the new repository for the tractusx-issuer-service repository is created, additional sub-tasks for integration with portal (i.e., integration tests or any changes necessary) will be created
• When the new repository for identity hub is created, additional sub-tasks for integration with IH (i.e., integration tests) will be created

[stephanbcbauer]

adds value to https://github.com/catenax-eV/sig-roadmap/issues/348

[ma3u]

As a future enhancement we should discuss this suggestion to store the signed "Legal Participant Credential" of the Clearing House:

• Gaia-X VCs storage inside customer wallet #411

But its for Jupiter Release 25.09 or later

[evegufy]

@hkny could you please provide the diagrams we worked on the ssi expert group in the description?

cc: @marcelruland

[hkny]

@evegufy the issuance and re-issuance flows from https://github.com/catenax-eV/cx-ex-ssi/blob/docs/flows/docs/Issuance/issuance.md are added. Should we also include additional flows, like key Rotation and Revocation? In that case, we might want to increase the scope of this ticket from DCP Issuance flow to more set of capabilties required for the issuance service.

[marcelruland]

Relevant committers/contributors: @borisrizov-zf, @rafaelmag110, @bmg13, @leandro-cavalcante

[evegufy]

@evegufy the issuance and re-issuance flows from https://github.com/catenax-eV/cx-ex-ssi/blob/docs/flows/docs/Issuance/issuance.md are added. Should we also include additional flows, like key Rotation and Revocation? In that case, we might want to increase the scope of this ticket from DCP Issuance flow to more set of capabilties required for the issuance service.

@hkny yes, I think the additional flows should also be covered by this issue. From our previous discussions, I thought we were aligned on that this issues should cover all Bring/Host your own wallet related issues, for all relevant products/components (issuer service, identity hub, portal, ...)

[marcelruland]

@evegufy I like having just one issue covering all BYOW related issues for all relevant services, but then what does #1169 cover? There's also #1156, and the older #562 and maybe #291, which would then also be covered here.

[evegufy]

@evegufy I like having just one issue covering all BYOW related issues for all relevant services, but then what does #1169 cover? There's also #1156, and the older #562 and maybe #291, which would then also be covered here.

@marcelruland #1169 does cover multiple wallet provider (solution 1 in our ssi expert group lingo) and this one will cover solution 2.
regarding #1156: I figured this the initial identity hub setup
#562 was the concept for this issue
#291: we can also mark it as duplicate if it's covered by this issue.

[stephanbcbauer]

was presented in open planning 25.06