SSI Flow - Create Wallet Tenant // Adjust Process Worker Backend Job "CREATE_IDENTITY_WALLET"

[jjeroch]

Summary

As-Is: the current "CREATE_IDENTITY_WALLET" step is implemented to create based on the body

• company name
• bpnl

a wallet tenant and the bpnl credential.

In the new SSI Flow the process is changing. The process step only creates the Wallet Tenant (..not the BPNL credential). Therefore following data are supposed to get submitted via the REST API endpoint

Submitt Body

• businessPartnerNumber: {companies.business_partner_number} (bpn => unique company ID)
• companyName: {company.name} (companyName => human readable name of the company)
• didUrl (needs to get configured; if there is no company url stored; use the default portal location {hostname}:{customerBPNL})

*the businessPartnerNumber and company name is expected to get merged into a tenantName => {companies.business_partnernumber}{company.name}

{
  "businessPartnerNumber": "string",
  "companyName": "string",
  "didUrl": "string"
} 

Response Body Based on the submitted data, the wallet will perform all necessary steps to create the customer wallet tenant, possible technical users as well as the didDocument. To enable to provider to send back the didDocument and other details - an asynchron resposne endpoint is needed. The endpoint body is defined below

Note: in our 24.05. integration scenario the outgoing interface spec as well as the ingoing interface spec does not directly connect to the wallet; instead we (portal) are running against the DIM wrapper

---

API In-Going Spec Details:

Asynchron POST API needed at which the DIM Wrapper can submit the didDocument; tech user, etc. Note - the did as well as the didDocument must get validated before storing them.

Primary Key for submission: businessPartnerNumber

Endpoint: POST /api/administration/registration/didDocument Permission: store_didDocument

Response Body

{
  "didDocument": "string",
  "authenticationDetails": [
    {
       "authenticationServiceUrl": "string",
       "clientID": "uuid",
       "clientSecret": "****"
    }
  ]
} 

- did document (to be stored inside the portal db, connected to the company; and to be published by the operator/portal)
- authenticationServiceUrl (to be stored since we need this later for being able to push VCs into the walletTenant)
- clientId (to be stored since we need this later for being able to push VCs into the walletTenant)
- clientSecret (to be stored since we need this later for being able to push VCs into the walletTenant)
- tbc: walletCustomerInstanceUrl (under clarification; might be not relevant)

Below the validation details are added

did the did created MUST follow the following structure "did:web:{url}:{BPN123}" ..no further validations planned at this step of time, however ticket #517 created to resolve the did in a later stage the

didDocument the received did document need to get validated against the expected didDocument structure as per the cx standard (shared below).

{
  "@context": [
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/suites/ed25519-2020/v1"
  ],
  "id": "did:web:example.com:BPN123",
  "verificationMethod": [
     {
         "id": ["did:web:example.com:BPN123#key-0"],
         "type": "JsonWebKey2020",
         "publicKeyJwk": {
            "kty": "JsonWebKey2020",
            "crv": "Ed25519",
            "x": "3534354354353"
         }
     }
  "services": [
     {
         "id": ["did:web:example.com:BPN123#key-0"],
         "type": "CredentialStore",
         "serviceEndpoint": "{url}"
     }
  ]
}

In case the structure does not fit to the expected structure - the process step need to get set to "failed". Also the service "CredentialStore" is mandatorily needed with an serviceEndpoint defined.

If the did as well as the didDocument are fine; store the same inside the portal and set the process step "CREATE_IDENTITY_WALLET" to "DONE"

Special Error Scenarios:

• the didDocument and credential details can only get submitted to the portal if the application_checklist_statuses "CREATE_IDENTITY_WALLET" is in "IN_PROGRESS" state

Note - the stored didDocument needs to get published by the portal - to be rechecked with the SSI Architect how the publishing should happen in detail for standardization. The whole task is managed under the following ticket https://github.com/eclipse-tractusx/portal-backend/issues/478 and is not part of this ticket

---

ACCs

• [ ] new branch created (we should not yet put it on dev)
• [ ] implement the change locally
• [ ] run tests locally (integrative with the DIM Wrapper)
• [ ] validation of did and didDocument successfully implemented

[jjeroch]

@Phil91 ticket details updated. Regarding the discussion today of submitting the applicationID - any chance we switch this to businessPartnerNumber insteadß

[Phil91]

@Phil91 ticket details updated. Regarding the discussion today of submitting the applicationID - any chance we switch this to businessPartnerNumber insteadß

@jjeroch sure, that should be possible since the bpn is a unique identifier as well. but we would pass the bpn as a separate field to the dim right? since we have a combination of bpn and company name for the tenantName I can't just split it in half

[Phil91]

I've created the merge of the code into the repo provided by SAP:

https://github.com/SAP/ssi-dim-middle-layer/pull/1