Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Enable issuance flow for multiple wallet providers #1169

Open
19 tasks
evegufy opened this issue Jan 23, 2025 · 0 comments
Open
19 tasks

Enable issuance flow for multiple wallet providers #1169

evegufy opened this issue Jan 23, 2025 · 0 comments
Labels
portal Feature/Bug for Portal component Prep-R25.06 ssi Self-Sovereign Identity

Comments

@evegufy
Copy link
Contributor

evegufy commented Jan 23, 2025

Overview

Explain the topic in 2 sentences

Operating companies should be able to choose between multiple wallet solutions when onboarding customers to the network. The issuance / onbarding flow in the portal should be enabled accordingly.

The solution is similar to the state of implementation with the Catena-X Jupiter release but the operating company has the option to choose between multiple wallet providers.

What's the benefit?

In the current implementation state the operating company is technically restricted to one wallet provider which is leading to a potential vendor lock-in situation.

Enabling the option to choose between multiple wallet solutions in the issuance flow would mitigate that risk.

What are the Risks/Dependencies ?

Potentially required changes to the ssi-credential-issuer need to be clarified.

Detailed explanation

Current implementation

Proposed improvements

Feature Team

Contributor

  • Contributor 1
  • Contributor 2

Committer

User Stories

  • Issue 1, linked to specific repository
  • Issue 2, linked to another specific repository

Acceptance Criteria

  • Criteria 1
  • Criteria 2
  • Criteria 3

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.

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.

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)

relates to

@evegufy evegufy added portal Feature/Bug for Portal component Prep-R25.06 ssi Self-Sovereign Identity labels Jan 23, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
portal Feature/Bug for Portal component Prep-R25.06 ssi Self-Sovereign Identity
Projects
Status: Inbox
Development

No branches or pull requests

1 participant