VC Issuance flow 2.0 incl revocation

[jjeroch]

Description

*please note, mentioned companies or systems are only examples and used for easier understanding

---

DRAFT
Implement a reliable and future oriented VC issuance flow for the CX dataspace enabling to connect any wallet (currently just one; soon multiple) to the core applications

Flow Details

• Operating Company will have a wallet tenant (manually configured)
• VCs are created from the issuer component and signed by the wallet (supported format JWT)
• Generic wallet API to issue and sign credentials of all types (Cofinity tenant)
  • Input: schema, credential type, credential subject, DID, signing key
  • Authenticated REST API (Authentication credentials can be downloaded from SAP Sub- Account)
• Catena-X Portal provides the opportunity for Catena- X members to see and download their VCs
• GAIA-X credential will also be provided from the portal
• Credential can be downloaded and must be stored in the customer wallet manually

---

In Scope:
all items displayed in the image below in red.

Out-of-scope:
– https://github.com/eclipse-tractusx/identity- trust/blob/main/specifications/M1/credential.issu ance.protocol.md

---

General Assumptions
• Development Closure 28.03.2024
• Credential format: JWT
• Revocation: credentialStatus
• DID method: web
• Operator hosts DIDDocument
• Schema version: http://json-schema.org/draft-07/schema#
• No Schemas with references
• No summary credential
• Credential schemas are defined
• Direct users of DIM have to sign a Test and Evaluation agreement

---

Implementation Details

1 IF to create Wallet Tenant

as-of PI planning - changes are expected and will get handled inside the actual implementation ticket #453
The wallet used as operator wallet (managed wallet for operator customers) MUST support a REST API Interface to support the tenant wallet creation by the operator.

Endpoint to be defined /create
Supposed content:
`

• CompanyName
• BPNL (which is the unique identifier)
  `

Result: Wallet Tenant is created. DID Document issues and responded with the DID
Interface Type: Synchron

NOTE: the DID Document is going to be published by the portal. This allows external wallet to be supported without an buy-in. (more flexible if wallet move is planned...etc.)

Depending on the wallet type: if the wallet is not managed/authenticated/secured by the operator env.; the response MUST include a client ID & secret which the portal needs to secure. The credentials are used to store later on the created VC inside the respective wallet client

2 IF Operator Tenant Signature

as-of PI planning - changes are expected and will get handled inside the actual implementation ticket #???
The wallet must provide an endpoint (details still in definition) to allow the request a signature of a unsigned credential (json credential) created by the issuer component. The issuer components provides the unsigned credential to the operator wallet, which signs it and provides the signed credential as verifiable credential back.

Endpoint to be defined: ????
Supposed content:
???

Result/Response: Signed VC

3 IF Store Credential inside Holder Wallet (interim solution)

as-of PI planning - changes are expected and will get handled inside the actual implementation ticket #???
The newly created verifiable credential need to be stored inside the holder wallet. The Issuer component is supposed to own this task for a certain time. To allow this, the wallet must provide an input endpoint via which the VC can get stored by the issuer component.
Authentication (operator internal; for external secured wallets the client id and secret will be used)

Endpoint to be defined: ????
Supposed content:
???

Result/Response: Success

B IF Wallet Revocation List Access

The wallet must provide an endpoint (details still in definition) which allows the issuer component to initiate a revocation of a credential - in the case the credential is revoked by the issuer or by the holder via the issuer.
Auto expiry handling to be defined

The used revocation list is StatusList21....

Endpoint to be defined: ????
Supposed content:
`

• verified_credential_ID
  `

Result: Success message/response

---

Impact

Portal; Wallet Provider; SD Factory

Additional information

Backend

• SSI Flow - Middle Layer/Wrapper of DIM functions portal-backend#479
• SSI Flow - Create Wallet Tenant // Adjust Process Worker Backend Job "CREATE_IDENTITY_WALLET" portal-backend#453
• SSI Flow - Publish didDocument portal-backend#478
• Previous SSI API endpoints under Administration Service Clean-up (placeholder) portal-backend#538

Issuer Component

• Establish Issuer Component Core ssi-credential-issuer#2
• Create BPN Credential ssi-credential-issuer#3
• Create Membership Credential ssi-credential-issuer#4
• Create Framework Credential ssi-credential-issuer#5
• Issuer Component - GET credential request endpoint (Requester) ssi-credential-issuer#6
• Issuer Component - POST create credential ssi-credential-issuer#7
• Issuer Component - Store & Signing Credential by IssuerWallet ssi-credential-issuer#9
• Issuer Component - GET credential request auditor endpoint ssi-credential-issuer#10
• (Dev/INT) Prepare to run BPN:DID Resolver Component ssi-credential-issuer#12
• Issuer Approval/Rejection process ssi-credential-issuer#13
• Credential Revocation by holder ssi-credential-issuer#14
• Credential Revocation by issuer ssi-credential-issuer#15
• Credential Expiry - by Automation ssi-credential-issuer#16
• Issuer Service Auditing ssi-credential-issuer#17
• ..

Others

• Implementation will be taken over from the portal team
• Standards will be written
  • standard input "create wallet" provided
  • standard input "useCaseFrameagreements" provided
• submit credential
• able to show credential on request/download?!?
• bpn resolver
• Policy Seeding 24.05. (SSI release relevant to achieve the e2e flow) Policy Seeding Data Update 24.05. Scope policy-hub#25
• Publish supported credentials inside the portal 'Dataspace' Page Information 'Dataspace' - update content (credentials) portal-frontend#575

[stephanbcbauer]

Hello @jjeroch , @evegufy

Since the feature is a 24.05 feature and the development phase for 24.08 is coming to an end, we need a status on the feature. Can you please update the status?

• Currently you are assigned (Responsible) → Is this correct? If not, please assign the correct contact person
• Please check whether the status (backlog, work in progress ...) is set correctly
• Please comment on the current status of the feature
• Are all SubTasks (issues from other repositories that deal with the feature) linked? → The easiest way is to mention the feature here in the issue (via the ID) so we can see which teams/repositories are involved.
• Is there a spillover planned?

If you need any clarification, please get in touch, thank you very much.

Stephan