Skip to content

Commit

Permalink
release(1.6.0-RC2): merge release into main (#109)
Browse files Browse the repository at this point in the history
  • Loading branch information
Phil91 committed Aug 1, 2023
1 parent 51d4d74 commit 1b4327b
Show file tree
Hide file tree
Showing 15 changed files with 528 additions and 71 deletions.
11 changes: 11 additions & 0 deletions CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,6 +2,17 @@

New features, fixed bugs, known defects and other noteworthy changes to each release of the Catena-X Portal Assets.

## 1.6.0-RC2

### Change
* Wallet Creation & Membership credential creation documentation as part of the technical registration approval documentation added
* Connector registration documentation (technical und functional) updated, covering the new input fields and api calls

### Feature
* SSI Credential Management (Request Flow) added
* App Instance URL change process added
* Notification user documentation added

## 1.6.0-RC1

### Change
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -487,6 +487,10 @@ Response "Success" => set status to "DONE"

##### Details "Activation"

<p align="center">
<img width="687" alt="image" src="https://github.com/catenax-ng/tx-portal-assets/assets/94133633/e5663f3b-6e45-46f1-aee7-d2f0a3d4f59e">
</p>p>

<br>
The complete company account activation (as a result of the successful application checklist finalization) is automatically executed when the following pre-requisites are fulfilled:
<br>
Expand All @@ -501,6 +505,7 @@ The complete company account activation (as a result of the successful applicati

With the execution of the application activation, the system will:

- call POST /api/credentials/issuer/membership to create membership credential for the registration party
- set company status inside portal.companies to "ACTIVE"
- set application status inside portal.company_application to"CONFIRMED"
- set company_application time stamp
Expand All @@ -510,6 +515,12 @@ With the execution of the application activation, the system will:
- add bpn to user(s)
- send a welcome email

<br>

> **_NOTE:_**
> * if the activation is not successful (due to any reason) the membership credential should not get set/send
> * if the membership credential call is unsuccessful, the "registration activation" should not take place. (rare scenario - since this would only happen if the wallet is down or the wallet has a major internal service error)
<br>
<br>

Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -32,13 +32,15 @@ DAPS is not directly reachable. Due to security regulations, the DAPS registrati

Request Body

{
"clientName":"string",
"securityProfile":"BASE_SECURITY_PROFILE",
"referringConnector": "connector.url+BPN (own connector: own bpn; managed connector: bpn of the provider)",
"file": "string($binary)"
}
```json
{
"clientName":"string",
"securityProfile":"BASE_SECURITY_PROFILE",
"referringConnector": "connector.url+BPN (own connector: own bpn; managed connector: bpn of the provider)",
"file": "string($binary)"
}
```

Details

* clientName: Name of a client we create a record for
Expand All @@ -57,37 +59,41 @@ With the success response from DAPS, the newly created DAPS clientID is getting
#### Details to the SD

The self description factory is getting triggered as part of the connector registration.
The asynchron interface is connected to the SD Factory which triggers the Clearinghouse Compliance Service; the Clearinghouse is validating the SD, signing and sends back the Self Description to the portal.
The asynchronous interface is connected to the SD Factory which triggers the Clearinghouse Compliance Service; the Clearinghouse is validating the SD, signing and sends back the Self Description to the portal.
<br>

##### #1 Self description request

Request body (refinement still needed):

{
"externalId": "connectorId"
"type": "LegalPerson or ServiceOffering",
"providedBy": "string",
"aggregationOf": "string"?,
"termsAndConditions": "string?",
"policies": "string",
"issuer": "string",
"holder": "string"
}

```json
{
"externalId": "connectorId"
"type": "LegalPerson or ServiceOffering",
"providedBy": "string",
"aggregationOf": "string"?,
"termsAndConditions": "string?",
"policies": "string",
"issuer": "string",
"holder": "string"
}
```

<br>

##### #2 Self description response (asynchron)
##### #2 Self description response (asynchronous)

Request body (refinement still needed):

{
"externalId":"connectorId",
"status":"CONFIRM or FAILED",
"message":"string",
"content": "string"
}

```json
{
"externalId":"connectorId",
"status":"CONFIRM or FAILED",
"message":"string",
"content": "string"
}
```

<br>

Execution:
Expand Down Expand Up @@ -128,7 +134,7 @@ Technical explanation: if the connector.daps_registration_successful is "true" a
>- BPNL's are allowed only. User need to add the BPNL. Validation needed that the input is exact 16 digits and starts with "BPNL"
>
>Authentication
>- only allowes .pem and .cert files
>- only allows .pem and .cert files
<br>
<br>
Expand All @@ -146,29 +152,28 @@ Technical explanation: if the connector.daps_registration_successful is "true" a
#### API Details

```diff
! POST /api/administration/connectors/daps
! POST /api/administration/Connectors
```

<br>

Request Body

{
"name": "string",
"connectorUrl": "string",
"location": "string",
"certificate": "string",
"technicalUserId": "uuid",
}

> **_NOTE:_** Connector certificate is the cert file holding the public key. Details regarding the certificate file creation can get found [here](/docs/02.%20Technical%20Integration/01.%20Connector%20Registration/07.%20FAQ.md#whats-a-public-key-and-how-do-i-create-the-public-key)
```json
{
"name": "string",
"connectorUrl": "string",
"location": "string",
"technicalUserId": "uuid",
}
```

> **_NOTE:_** Optionally an technical user id can get provided when creating the connector. With that the technical user connected with the connector is technically linked inside the portal as well. This supports an easier technical user management for consumer as well as provider (db: connector.company_service_account_id). The technical user need to belong to the same company id and the status of the user must be "ACTIVE"
<br>
<br>

## 2. Create new Connector Registration - managed 
## 2. Create new Connector Registration - managed

Service Provider can create a new registration for a company which subscribed for a service provider service

Expand Down Expand Up @@ -199,7 +204,7 @@ Technical explanation: if the connector.daps_registration_successful is "true" a
>- BPNL's are allowed only. User need to add the BPNL. Validation needed that the input is exact 16 digits and starts with "BPNL"
>
>Authentication
>- only allowes .pem and .cert files
>- only allows .pem and .cert files
<br>
<br>
Expand All @@ -224,20 +229,38 @@ Technical explanation: if the connector.daps_registration_successful is "true" a

Request Body

{
"name": "string",
"connectorUrl": "string",
"location": "string",
"providerBpn": "string",
"certificate": "string",
"technicalUserId": "uuid",
}

> **_NOTE:_** ProviderBPN is the BPN of the data provider / data consumer in which name the connector is supposed to act inside the dataspace.
> **_NOTE:_** Connector certificate is the cert file holding the public key. Details regarding the certificate file creation can get found [here](/docs/02.%20Technical%20Integration/01.%20Connector%20Registration/07.%20FAQ.md#whats-a-public-key-and-how-do-i-create-the-public-key)
```json
{
"name": "string",
"connectorUrl": "string",
"location": "string",
"subscriptionId": "uuid",
"technicalUserId": "uuid",
}
```

> **_NOTE:_** Optionally an technical user id can get provided when creating the connector. With that the technical user connected with the connector is technically linked inside the portal as well. This supports an easier technical user management for consumer as well as provider (db: connector.company_service_account_id). The technical user need to belong to the company ID of the providerBPN and the status of the user must be "ACTIVE".
<br>
<br>

> **_NOTE:_** Data mapping details for subscriptionId can get found below
> Used Endpoint: GET /api/administration/Connectors/offerSubscriptions?connectorIdSet=false
> .
> Response Body
> [
> {
> "subscriptionId": "uuid",
> "customerName": "string",
> "offerName": "string",
> "connectorIds": []
> }
> ]
>
> <img width="740" alt="image" src="https://github.com/catenax-ng/tx-portal-assets/assets/94133633/892595c3-6afa-41ec-bdcf-e09fc567541b">
>


<br>
<br>
Original file line number Diff line number Diff line change
@@ -0,0 +1,21 @@
## Managed Identity Wallet

### Wallet Creation

The wallet tenant per company is created as part of the dataspace registration.
This includes a didWeb.
The managed identity wallet is created and new credentials are issued by th portal.
A direct interface by the user is not provided.

<br>
<br>

### Initial Credentials

Each dataspace participant will receive (as part of the registration process) 2 credential types

* bpn credential (signed by the operator)
* membership credential (signed by the operator)

<br>
<br>
Original file line number Diff line number Diff line change
@@ -0,0 +1,97 @@
## Use Case Credentials

The use case participation page is created to enable data provider/consumer and solution providers to view their use case participation and to request the participation for new use cases.
The use case participation is a verified credential which is stored on the company wallet which generates trust and liability in the network. The company signing the framework agrees to the use case date sharing rules.

Functional Description: [here](/docs/06.%20Certificates/01.%20UseCase%20Participation.md)

<br>

### Process Flow

<br>

<p align="center">
<img width="700" alt="image" src="https://github.com/catenax-ng/tx-portal-assets/assets/94133633/87be492d-4b3c-4bd2-8801-6a69f3f1819a">
</p>

<br>
<br>

### Displaying available Credential Types

<br>
<img width="636" alt="image" src="https://github.com/catenax-ng/tx-portal-assets/assets/94133633/c5ded524-278e-4995-8013-3987a3af7938">
<br>
<br>

The available credential types are fetched from the portal db company_ssi_details and verified_credential_external_type_use_case_detail_versions.
The api response (see below) automatically includes the "ssiDetailData" which include the actual acting user company credential status. (e.g. if the company has one or several credentials of the use case framework requested or active already, it will be shown/displayed in the "ssiDetailData" section)

```diff
! GET /api/administration/companydata/useCaseParticipation
```

<br>

Request Body

[
{
"useCase": "string",
"description": "string",
"credentialType": "e.g. TRACEABILITY_FRAMEWORK",
"verifiedCredentials": [
{
"externalDetailData": {
"id": "uuid",
"verifiedCredentialExternalTypeId": "e.g. TRACEABILITY_CREDENTIAL",
"version": "string",
"template": "string",
"validFrom": "date",
"expiry": "date"
},
"ssiDetailData": {
"credentialId": "uuid",
"participationStatus": "e.g. PENDING",
"expiryDate": "uuid",
"document": {
"documentId": "uuid",
"documentName": "string"
}
}
}
]
}
]
<br>
<br>

### Submit Credential request

As part of the credential request submission (which is only possible if there is no PENDING request for the credential and version existing yet) the signed framework agreement need to get submitted.

```diff
! POST /api/administration/companydata/useCaseParticipation
```

<br>

Request Body

{
"verifiedCredentialTypeId": "uuid from the GET call",
"credentialType": "string from the GET call",
"document": "document file (only pdf are allowed)"
}


For the documents only pdf documents are allowed till 1 MB


<br>
<br>



Loading

0 comments on commit 1b4327b

Please sign in to comment.