diff --git a/.conf/Dockerfile b/.conf/Dockerfile
new file mode 100644
index 000000000..df2226eae
--- /dev/null
+++ b/.conf/Dockerfile
@@ -0,0 +1,47 @@
+###############################################################
+# Copyright (c) 2021, 2023 Contributors to the Eclipse Foundation
+#
+# See the NOTICE file(s) distributed with this work for additional
+# information regarding copyright ownership.
+#
+# This program and the accompanying materials are made available under the
+# terms of the Apache License, Version 2.0 which is available at
+# https://www.apache.org/licenses/LICENSE-2.0.
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+# License for the specific language governing permissions and limitations
+# under the License.
+#
+# SPDX-License-Identifier: Apache-2.0
+###############################################################
+
+#
+# usage:
+# export NAME=tx-portal-assets
+# export IMAGE=ghcr.io/catenax-ng/$NAME
+# docker build -t $IMAGE -f .conf/Dockerfile .
+# docker run --rm -d -p 3000:8080 --name $NAME $IMAGE
+# docker exec $NAME find /usr/share/nginx/html/
+# docker stop $NAME
+# docker push $IMAGE
+#
+
+# Step 1
+FROM alpine:3.17 as build-step
+COPY public /public
+WORKDIR /public/assets
+RUN find . -type f | cut -c 3- | sort > index.txt
+WORKDIR /public/documentation
+RUN find . -type f | cut -c 3- | sort > index.txt
+
+# Step 2
+FROM nginxinc/nginx-unprivileged:alpine
+# temp fix for CVE-2023-0286
+USER root
+RUN apk upgrade --no-cache libssl3 libcrypto3
+COPY .conf/nginx.conf /etc/nginx/conf.d/default.conf
+COPY --from=build-step /public/assets /usr/share/nginx/html/assets
+COPY --from=build-step /public/documentation /usr/share/nginx/html/documentation
+USER 101
diff --git a/.conf/nginx.conf b/.conf/nginx.conf
new file mode 100644
index 000000000..8d7d69f44
--- /dev/null
+++ b/.conf/nginx.conf
@@ -0,0 +1,30 @@
+###############################################################
+# Copyright (c) 2021, 2023 Contributors to the Eclipse Foundation
+#
+# See the NOTICE file(s) distributed with this work for additional
+# information regarding copyright ownership.
+#
+# This program and the accompanying materials are made available under the
+# terms of the Apache License, Version 2.0 which is available at
+# https://www.apache.org/licenses/LICENSE-2.0.
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+# License for the specific language governing permissions and limitations
+# under the License.
+#
+# SPDX-License-Identifier: Apache-2.0
+###############################################################
+
+server {
+
+ listen 8080;
+ server_name localhost;
+
+ location / {
+ root /usr/share/nginx/html;
+ index index.html;
+ }
+
+}
\ No newline at end of file
diff --git a/.github/workflows/build.yml b/.github/workflows/build.yml
new file mode 100644
index 000000000..d3c3cb3e5
--- /dev/null
+++ b/.github/workflows/build.yml
@@ -0,0 +1,96 @@
+###############################################################
+# Copyright (c) 2021, 2023 Contributors to the Eclipse Foundation
+#
+# See the NOTICE file(s) distributed with this work for additional
+# information regarding copyright ownership.
+#
+# This program and the accompanying materials are made available under the
+# terms of the Apache License, Version 2.0 which is available at
+# https://www.apache.org/licenses/LICENSE-2.0.
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+# License for the specific language governing permissions and limitations
+# under the License.
+#
+# SPDX-License-Identifier: Apache-2.0
+###############################################################
+
+name: build
+
+on:
+ push:
+ branches:
+ - 'main'
+
+env:
+ REGISTRY: ghcr.io
+ IMAGE_NAME: ${{ github.repository }}
+ COMMIT_SHA: ${{ github.sha }}
+
+jobs:
+ build-and-push-image:
+ runs-on: ubuntu-latest
+ permissions:
+ contents: read
+ packages: write
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v3
+
+ - name: Install Dependencies
+ run: yarn
+
+ - name: Build Library and Portal
+ run: yarn build
+
+ - name: Login to GitHub Container Registry
+ uses: docker/login-action@v1
+ with:
+ registry: ${{ env.REGISTRY }}
+ username: ${{ github.actor }}
+ password: ${{ secrets.GITHUB_TOKEN }}
+
+ - name: Extract Metadata (tags, labels) for Docker
+ id: meta
+ uses: docker/metadata-action@v3
+ with:
+ images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
+
+ - name: Build and push Docker image
+ uses: docker/build-push-action@v2
+ with:
+ context: .
+ file: .conf/Dockerfile
+ push: true
+ # build tag :main with commit-sha and latest
+ tags: ${{ steps.meta.outputs.tags }}_${{ env.COMMIT_SHA }}, ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest
+ labels: ${{ steps.meta.outputs.labels }}
+
+ auth-and-dispatch:
+ needs: build-and-push-image
+ runs-on: ubuntu-latest
+
+ steps:
+ - name: Get token
+ id: get_workflow_token
+ uses: peter-murray/workflow-application-token-action@v1
+ with:
+ application_id: ${{ secrets.ORG_PORTAL_DISPATCH_APPID }}
+ application_private_key: ${{ secrets.ORG_PORTAL_DISPATCH_KEY }}
+
+ # The triggered workflow isn't enabled for branch names / github.ref_name containing special characters like '/' for example 'feature/...'
+ - name: Trigger workflow
+ id: call_action
+ env:
+ TOKEN: ${{ steps.get_workflow_token.outputs.token }}
+ run: |
+ curl -v \
+ --request POST \
+ --url https://api.github.com/repos/catenax-ng/tx-portal-cd/actions/workflows/portal-assets-image-update.yml/dispatches \
+ --header "authorization: Bearer $TOKEN" \
+ --header "Accept: application/vnd.github.v3+json" \
+ --data '{"ref":"helm-environments", "inputs": { "new-image":"${{ github.ref_name }}_${{ env.COMMIT_SHA }}" }}' \
+ --fail
diff --git a/.github/workflows/kics.yml b/.github/workflows/kics.yml
new file mode 100644
index 000000000..1d170bd6d
--- /dev/null
+++ b/.github/workflows/kics.yml
@@ -0,0 +1,71 @@
+###############################################################
+# Copyright (c) 2021, 2023 Contributors to the Eclipse Foundation
+#
+# See the NOTICE file(s) distributed with this work for additional
+# information regarding copyright ownership.
+#
+# This program and the accompanying materials are made available under the
+# terms of the Apache License, Version 2.0 which is available at
+# https://www.apache.org/licenses/LICENSE-2.0.
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+# License for the specific language governing permissions and limitations
+# under the License.
+#
+# SPDX-License-Identifier: Apache-2.0
+###############################################################
+
+name: "KICS"
+
+on:
+ push:
+ branches: [main, master]
+ # pull_request:
+ # The branches below must be a subset of the branches above
+ # branches: [main, master]
+ # paths-ignore:
+ # - "**/*.md"
+ # - "**/*.txt"
+ schedule:
+ - cron: "0 0 * * *"
+
+jobs:
+ analyze:
+ name: Analyze
+ runs-on: ubuntu-latest
+ permissions:
+ actions: read
+ contents: read
+ security-events: write
+
+ steps:
+ - uses: actions/checkout@v3
+
+ - name: KICS scan
+ uses: checkmarx/kics-github-action@master
+ with:
+ # Scanning directory .
+ path: "."
+ # Fail on HIGH severity results
+ fail_on: high
+ # when provided with a directory on output_path
+ # it will generate the specified reports file named 'results.{extension}'
+ # in this example it will generate:
+ # - results-dir/results.json
+ # - results-dir/results.sarif
+ output_path: kicsResults/
+ output_formats: "json,sarif"
+ # If you want KICS to ignore the results and return exit status code 0 unless a KICS engine error happens
+ # ignore_on_exit: results
+ # GITHUB_TOKEN enables this github action to access github API and post comments in a pull request
+ # token: ${{ secrets.GITHUB_TOKEN }}
+ # enable_comments: true
+
+ # Upload findings to GitHub Advanced Security Dashboard
+ - name: Upload SARIF file for GitHub Advanced Security Dashboard
+ if: always()
+ uses: github/codeql-action/upload-sarif@v2
+ with:
+ sarif_file: kicsResults/results.sarif
diff --git a/.github/workflows/release.yml b/.github/workflows/release.yml
new file mode 100644
index 000000000..271ed6cf8
--- /dev/null
+++ b/.github/workflows/release.yml
@@ -0,0 +1,110 @@
+###############################################################
+# Copyright (c) 2021, 2023 Contributors to the Eclipse Foundation
+#
+# See the NOTICE file(s) distributed with this work for additional
+# information regarding copyright ownership.
+#
+# This program and the accompanying materials are made available under the
+# terms of the Apache License, Version 2.0 which is available at
+# https://www.apache.org/licenses/LICENSE-2.0.
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+# License for the specific language governing permissions and limitations
+# under the License.
+#
+# SPDX-License-Identifier: Apache-2.0
+###############################################################
+
+name: release
+
+on:
+ push:
+ tags:
+ - '*'
+
+env:
+ REGISTRY: ghcr.io
+ IMAGE_NAME: ${{ github.repository }}
+
+jobs:
+ build-and-push-release:
+ runs-on: ubuntu-latest
+ permissions:
+ contents: read
+ packages: write
+
+ steps:
+ - name: Get tag name
+ id: git-tag
+ run: echo ::set-output name=git-version::${GITHUB_REF/refs\/tags\//}
+
+ - name: Checkout repository
+ uses: actions/checkout@v3
+ with:
+ ref: ${{ steps.git-tag.outputs.git-version }}
+
+ - name: Output versions
+ run: echo building relase from git ${{ steps.git-tag.outputs.git-version }}
+
+ - name: Install Dependencies
+ run: yarn
+
+ - name: Build Library and Portal
+ run: yarn build
+
+ - name: Login to GitHub Container Registry
+ uses: docker/login-action@v1
+ with:
+ registry: ${{ env.REGISTRY }}
+ username: ${{ github.actor }}
+ password: ${{ secrets.GITHUB_TOKEN }}
+
+ - name: Extract Metadata (tags, labels) for Docker
+ id: meta
+ uses: docker/metadata-action@v3
+ with:
+ images: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}
+
+ - name: Build and push Docker image
+ uses: docker/build-push-action@v2
+ with:
+ context: .
+ file: .conf/Dockerfile
+ push: true
+ tags: ${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:${{ steps.git-tag.outputs.git-version }}
+ labels: ${{ steps.meta.outputs.labels }}
+
+ auth-and-dispatch:
+ needs: build-and-push-release
+ runs-on: ubuntu-latest
+
+ steps:
+
+ - name: Get tag name
+ id: git-tag
+ run: echo ::set-output name=git-version::${GITHUB_REF/refs\/tags\//}
+
+ - name: Set env
+ run: echo "RELEASE_VERSION=${{ steps.git-tag.outputs.git-version }}" >> $GITHUB_ENV
+
+ - name: Get token
+ id: get_workflow_token
+ uses: peter-murray/workflow-application-token-action@v1
+ with:
+ application_id: ${{ secrets.ORG_PORTAL_DISPATCH_APPID }}
+ application_private_key: ${{ secrets.ORG_PORTAL_DISPATCH_KEY }}
+
+ - name: Trigger workflow
+ id: call_action
+ env:
+ TOKEN: ${{ steps.get_workflow_token.outputs.token }}
+ run: |
+ curl -v \
+ --request POST \
+ --url https://api.github.com/repos/catenax-ng/tx-portal-cd/actions/workflows/portal-assets-int-release-image-update.yml/dispatches \
+ --header "authorization: Bearer $TOKEN" \
+ --header "Accept: application/vnd.github.v3+json" \
+ --data '{"ref":"helm-environments", "inputs": { "new-image":"${{ env.RELEASE_VERSION }}" }}' \
+ --fail
diff --git a/.github/workflows/trivy.yml b/.github/workflows/trivy.yml
new file mode 100644
index 000000000..c2443a5d9
--- /dev/null
+++ b/.github/workflows/trivy.yml
@@ -0,0 +1,104 @@
+###############################################################
+# Copyright (c) 2021, 2023 Contributors to the Eclipse Foundation
+#
+# See the NOTICE file(s) distributed with this work for additional
+# information regarding copyright ownership.
+#
+# This program and the accompanying materials are made available under the
+# terms of the Apache License, Version 2.0 which is available at
+# https://www.apache.org/licenses/LICENSE-2.0.
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+# License for the specific language governing permissions and limitations
+# under the License.
+#
+# SPDX-License-Identifier: Apache-2.0
+###############################################################
+
+# Depending on the location of your Docker container
+# you need to change the path to the specific Docker registry.
+#
+name: "Trivy"
+
+on:
+ push:
+ branches: [ main ]
+ # pull_request:
+ # The branches below must be a subset of the branches above
+ # branches: [ main ]
+ # paths-ignore:
+ # - "**/*.md"
+ # - "**/*.txt"
+ schedule:
+ # Once a day
+ - cron: "0 0 * * *"
+ workflow_dispatch:
+ # Trigger manually
+
+env:
+ REGISTRY: ghcr.io
+ IMAGE_NAME: ${{ github.repository }}
+
+jobs:
+ analyze-config:
+ runs-on: ubuntu-latest
+ permissions:
+ actions: read
+ contents: read
+ security-events: write
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v3
+
+ - name: Run Trivy vulnerability scanner in repo mode
+ uses: aquasecurity/trivy-action@master
+ with:
+ scan-type: "config"
+ # ignore-unfixed: true
+ exit-code: "1"
+ hide-progress: false
+ format: "sarif"
+ output: "trivy-results1.sarif"
+ severity: "CRITICAL,HIGH"
+
+ - name: Upload Trivy scan results to GitHub Security tab
+ uses: github/codeql-action/upload-sarif@v2
+ if: always()
+ with:
+ sarif_file: "trivy-results1.sarif"
+
+ analyze-portal-assets:
+ runs-on: ubuntu-latest
+ permissions:
+ actions: read
+ contents: read
+ security-events: write
+
+ steps:
+ - name: Checkout repository
+ uses: actions/checkout@v3
+
+ # It's also possible to scan your private registry with Trivy's built-in image scan.
+ # All you have to do is set ENV vars.
+ # Docker Hub needs TRIVY_USERNAME and TRIVY_PASSWORD.
+ # You don't need to set ENV vars when downloading from a public repository.
+ # For public images, no ENV vars must be set.
+ - name: Run Trivy vulnerability scanner
+ if: always()
+ uses: aquasecurity/trivy-action@master
+ with:
+ # Path to Docker image
+ image-ref: "${{ env.REGISTRY }}/${{ env.IMAGE_NAME }}:latest"
+ format: "sarif"
+ output: "trivy-results2.sarif"
+ exit-code: "1"
+ severity: "CRITICAL,HIGH"
+
+ - name: Upload Trivy scan results to GitHub Security tab
+ if: always()
+ uses: github/codeql-action/upload-sarif@v2
+ with:
+ sarif_file: "trivy-results2.sarif"
diff --git a/.github/workflows/veracode.yaml b/.github/workflows/veracode.yaml
new file mode 100644
index 000000000..dcd23a802
--- /dev/null
+++ b/.github/workflows/veracode.yaml
@@ -0,0 +1,50 @@
+###############################################################
+# Copyright (c) 2021, 2023 Contributors to the Eclipse Foundation
+#
+# See the NOTICE file(s) distributed with this work for additional
+# information regarding copyright ownership.
+#
+# This program and the accompanying materials are made available under the
+# terms of the Apache License, Version 2.0 which is available at
+# https://www.apache.org/licenses/LICENSE-2.0.
+#
+# Unless required by applicable law or agreed to in writing, software
+# distributed under the License is distributed on an "AS IS" BASIS, WITHOUT
+# WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the
+# License for the specific language governing permissions and limitations
+# under the License.
+#
+# SPDX-License-Identifier: Apache-2.0
+###############################################################
+
+# yaml-language-server: $schema=https://json.schemastore.org/github-workflow.json
+name: Veracode
+
+# run on manual trigger or once a week
+on:
+ push:
+ branches: [main]
+ workflow_dispatch:
+ schedule:
+ - cron: "0 0 * * 0"
+
+jobs:
+ static_analysis:
+ name: Static Analysis
+ runs-on: ubuntu-latest
+
+ steps:
+ - name: Check out main branch
+ uses: actions/checkout@v3
+
+ - name: Zip Sources for Static Analysis
+ run: yarn build:sources
+
+ - name: Veracode Upload And Scan
+ uses: veracode/veracode-uploadandscan-action@0.2.1
+ with:
+ appname: 'Portal Assets'
+ createprofile: false
+ filepath: 'portal-assets.zip'
+ vid: '${{ secrets.ORG_VERACODE_API_ID }}'
+ vkey: '${{ secrets.ORG_VERACODE_API_KEY }}'
diff --git a/.gitignore b/.gitignore
new file mode 100644
index 000000000..8800349bb
--- /dev/null
+++ b/.gitignore
@@ -0,0 +1,3 @@
+**/.DS_Store
+node_modules
+public/documentation/js/lib
\ No newline at end of file
diff --git a/CHANGELOG.md b/CHANGELOG.md
new file mode 100644
index 000000000..f4d8d50d9
--- /dev/null
+++ b/CHANGELOG.md
@@ -0,0 +1,131 @@
+## Unreleased
+
+## 1.0.0-RC8
+
+### Change
+* Documentation v8 released (content and structural updates along the whole documentation and OpenAPI docu added)
+
+### Feature
+n/a
+
+### Technical Support
+n/a
+
+### Bugfix
+n/a
+
+
+## 1.0.0-RC7
+
+### Change
+* Documentation v7 released (content and structural updates along the whole documentation)
+
+### Feature
+n/a
+
+### Technical Support
+n/a
+
+### Bugfix
+n/a
+
+
+## 1.0.0-RC6
+
+### Change
+* Documentation v6 released (content and structural updates along the whole documentation)
+* Split of user and developer documentation
+* added web application search functionality across all the md files / documentation files
+
+### Feature
+n/a
+
+### Technical Support
+* temp fix for cve-2023-0286
+
+### Bugfix
+* fixed security findings
+
+
+## 1.0.0-RC5
+
+### Change
+* Documentation v5 released (restructuring, adding developer docu, etc.)
+
+### Feature
+* help/documentation web application updated with search mechanism and document tree structure
+
+### Technical Support
+n/a
+
+### Bugfix
+n/a
+
+
+## 1.0.0-RC4
+
+### Change
+* Documentation v4 released (service subscription; registration approval flow and docu)
+* Use Case introduction content updated and enhanced
+
+### Feature
+* help/documentation web application released (based on md file content)
+
+### Technical Support
+n/a
+
+### Bugfix
+n/a
+
+
+## 1.0.0-RC3
+
+### Change
+* Documentation v3 released (idp/auth developer docu)
+* Use Case introduction content updated and enhanced
+
+### Feature
+n/a
+
+### Technical Support
+n/a
+
+### Bugfix
+n/a
+
+
+## 1.0.0-RC2
+
+### Change
+* Documentation v2 released
+
+### Feature
+* Static page contents for portal company role and use case introductions released as part of assets/contents
+
+### Technical Support
+* n/a
+
+### Bugfix
+* n/a
+
+
+## 1.0.0-RC1
+
+### Change
+* n/a
+
+### Feature
+* Documentation
+ * Created user documentation (initial version)
+ * Created admin/developer documentation (initial version)
+ * Created architecture documentation (initial version)
+ * Created interface documentatio (initial version)
+* Portal Fonts implemented
+* Portal api json for news section implemented
+* Portal standard images loaded (email, frame, icons, logos)
+
+### Technical Support
+* Repo build worklfows created and security scan enabled
+
+### Bugfix
+* n/a
diff --git a/DEPENDENCIES b/DEPENDENCIES
new file mode 100644
index 000000000..461fd9c21
--- /dev/null
+++ b/DEPENDENCIES
@@ -0,0 +1,296 @@
+yarn licenses v1.5.1
+├─ (WTFPL OR MIT)
+│ └─ opener@1.5.2
+│ ├─ URL: https://github.com/domenic/opener.git
+│ ├─ VendorName: Domenic Denicola
+│ └─ VendorUrl: https://domenic.me/
+├─ 0BSD
+│ └─ tslib@2.5.0
+│ ├─ URL: https://github.com/Microsoft/tslib.git
+│ ├─ VendorName: Microsoft Corp.
+│ └─ VendorUrl: https://www.typescriptlang.org/
+├─ Apache-2.0
+│ └─ rxjs@7.8.0
+│ ├─ URL: https://github.com/reactivex/rxjs.git
+│ ├─ VendorName: Ben Lesh
+│ └─ VendorUrl: https://rxjs.dev/
+├─ BSD-3-Clause
+│ └─ qs@6.11.0
+│ ├─ URL: https://github.com/ljharb/qs.git
+│ └─ VendorUrl: https://github.com/ljharb/qs
+├─ ISC
+│ ├─ cliui@8.0.1
+│ │ ├─ URL: https://github.com/yargs/cliui.git
+│ │ └─ VendorName: Ben Coe
+│ ├─ get-caller-file@2.0.5
+│ │ ├─ URL: git+https://github.com/stefanpenner/get-caller-file.git
+│ │ ├─ VendorName: Stefan Penner
+│ │ └─ VendorUrl: https://github.com/stefanpenner/get-caller-file#readme
+│ ├─ y18n@5.0.8
+│ │ ├─ URL: https://github.com/yargs/y18n.git
+│ │ ├─ VendorName: Ben Coe
+│ │ └─ VendorUrl: https://github.com/yargs/y18n
+│ ├─ yargs-parser@21.1.1
+│ │ ├─ URL: https://github.com/yargs/yargs-parser.git
+│ │ └─ VendorName: Ben Coe
+│ └─ zero-md@2.4.0
+│ ├─ URL: https://github.com/zerodevx/zero-md.git
+│ ├─ VendorName: Jason Lee
+│ └─ VendorUrl: https://zerodevx.github.io/zero-md/
+└─ MIT
+ ├─ ansi-regex@5.0.1
+ │ ├─ URL: https://github.com/chalk/ansi-regex.git
+ │ ├─ VendorName: Sindre Sorhus
+ │ └─ VendorUrl: sindresorhus.com
+ ├─ ansi-styles@3.2.1
+ │ ├─ URL: https://github.com/chalk/ansi-styles.git
+ │ ├─ VendorName: Sindre Sorhus
+ │ └─ VendorUrl: sindresorhus.com
+ ├─ ansi-styles@4.3.0
+ │ ├─ URL: https://github.com/chalk/ansi-styles.git
+ │ ├─ VendorName: Sindre Sorhus
+ │ └─ VendorUrl: sindresorhus.com
+ ├─ array-back@3.1.0
+ │ ├─ URL: https://github.com/75lb/array-back.git
+ │ └─ VendorName: Lloyd Brookes
+ ├─ array-back@4.0.2
+ │ ├─ URL: https://github.com/75lb/array-back.git
+ │ └─ VendorName: Lloyd Brookes
+ ├─ async@2.6.4
+ │ ├─ URL: https://github.com/caolan/async.git
+ │ ├─ VendorName: Caolan McMahon
+ │ └─ VendorUrl: https://caolan.github.io/async/
+ ├─ basic-auth@2.0.1
+ │ └─ URL: https://github.com/jshttp/basic-auth.git
+ ├─ call-bind@1.0.2
+ │ ├─ URL: git+https://github.com/ljharb/call-bind.git
+ │ ├─ VendorName: Jordan Harband
+ │ └─ VendorUrl: https://github.com/ljharb/call-bind#readme
+ ├─ chalk@2.4.2
+ │ └─ URL: https://github.com/chalk/chalk.git
+ ├─ chalk@4.1.2
+ │ └─ URL: https://github.com/chalk/chalk.git
+ ├─ color-convert@1.9.3
+ │ ├─ URL: https://github.com/Qix-/color-convert.git
+ │ └─ VendorName: Heather Arthur
+ ├─ color-convert@2.0.1
+ │ ├─ URL: https://github.com/Qix-/color-convert.git
+ │ └─ VendorName: Heather Arthur
+ ├─ color-name@1.1.3
+ │ ├─ URL: git@github.com:dfcreative/color-name.git
+ │ ├─ VendorName: DY
+ │ └─ VendorUrl: https://github.com/dfcreative/color-name
+ ├─ color-name@1.1.4
+ │ ├─ URL: git@github.com:colorjs/color-name.git
+ │ ├─ VendorName: DY
+ │ └─ VendorUrl: https://github.com/colorjs/color-name
+ ├─ command-line-args@5.2.1
+ │ ├─ URL: https://github.com/75lb/command-line-args
+ │ └─ VendorName: Lloyd Brookes
+ ├─ command-line-usage@6.1.3
+ │ ├─ URL: https://github.com/75lb/command-line-usage
+ │ └─ VendorName: Lloyd Brookes
+ ├─ concurrently@7.6.0
+ │ ├─ URL: https://github.com/open-cli-tools/concurrently.git
+ │ └─ VendorName: Kimmo Brunfeldt
+ ├─ corser@2.0.1
+ │ ├─ URL: https://github.com/agrueneberg/Corser.git
+ │ └─ VendorName: Alexander Grüneberg
+ ├─ date-fns@2.29.3
+ │ └─ URL: https://github.com/date-fns/date-fns
+ ├─ debug@3.2.7
+ │ ├─ URL: git://github.com/visionmedia/debug.git
+ │ └─ VendorName: TJ Holowaychuk
+ ├─ deep-extend@0.6.0
+ │ ├─ URL: git://github.com/unclechu/node-deep-extend.git
+ │ ├─ VendorName: Viacheslav Lotsmanov
+ │ └─ VendorUrl: https://github.com/unclechu/node-deep-extend
+ ├─ directory-tree@3.5.1
+ │ ├─ URL: https://github.com/mihneadb/node-directory-tree
+ │ ├─ VendorName: Mihnea Dobrescu-Balaur
+ │ └─ VendorUrl: https://github.com/mihneadb/node-directory-tree
+ ├─ emoji-regex@8.0.0
+ │ ├─ URL: https://github.com/mathiasbynens/emoji-regex.git
+ │ ├─ VendorName: Mathias Bynens
+ │ └─ VendorUrl: https://mths.be/emoji-regex
+ ├─ escalade@3.1.1
+ │ ├─ URL: https://github.com/lukeed/escalade.git
+ │ ├─ VendorName: Luke Edwards
+ │ └─ VendorUrl: https://lukeed.com
+ ├─ escape-string-regexp@1.0.5
+ │ ├─ URL: https://github.com/sindresorhus/escape-string-regexp.git
+ │ ├─ VendorName: Sindre Sorhus
+ │ └─ VendorUrl: sindresorhus.com
+ ├─ eventemitter3@4.0.7
+ │ ├─ URL: git://github.com/primus/eventemitter3.git
+ │ └─ VendorName: Arnout Kazemier
+ ├─ find-replace@3.0.0
+ │ ├─ URL: https://github.com/75lb/find-replace.git
+ │ └─ VendorName: Lloyd Brookes
+ ├─ follow-redirects@1.15.2
+ │ ├─ URL: git@github.com:follow-redirects/follow-redirects.git
+ │ ├─ VendorName: Ruben Verborgh
+ │ └─ VendorUrl: https://github.com/follow-redirects/follow-redirects
+ ├─ function-bind@1.1.1
+ │ ├─ URL: git://github.com/Raynos/function-bind.git
+ │ ├─ VendorName: Raynos
+ │ └─ VendorUrl: https://github.com/Raynos/function-bind
+ ├─ get-intrinsic@1.2.0
+ │ ├─ URL: git+https://github.com/ljharb/get-intrinsic.git
+ │ ├─ VendorName: Jordan Harband
+ │ └─ VendorUrl: https://github.com/ljharb/get-intrinsic#readme
+ ├─ has-flag@3.0.0
+ │ ├─ URL: https://github.com/sindresorhus/has-flag.git
+ │ ├─ VendorName: Sindre Sorhus
+ │ └─ VendorUrl: sindresorhus.com
+ ├─ has-flag@4.0.0
+ │ ├─ URL: https://github.com/sindresorhus/has-flag.git
+ │ ├─ VendorName: Sindre Sorhus
+ │ └─ VendorUrl: sindresorhus.com
+ ├─ has-symbols@1.0.3
+ │ ├─ URL: git://github.com/inspect-js/has-symbols.git
+ │ ├─ VendorName: Jordan Harband
+ │ └─ VendorUrl: https://github.com/ljharb/has-symbols#readme
+ ├─ has@1.0.3
+ │ ├─ URL: git://github.com/tarruda/has.git
+ │ ├─ VendorName: Thiago de Arruda
+ │ └─ VendorUrl: https://github.com/tarruda/has
+ ├─ he@1.2.0
+ │ ├─ URL: https://github.com/mathiasbynens/he.git
+ │ ├─ VendorName: Mathias Bynens
+ │ └─ VendorUrl: https://mths.be/he
+ ├─ html-encoding-sniffer@3.0.0
+ │ ├─ URL: https://github.com/jsdom/html-encoding-sniffer.git
+ │ ├─ VendorName: Domenic Denicola
+ │ └─ VendorUrl: https://domenic.me/
+ ├─ http-proxy@1.18.1
+ │ ├─ URL: https://github.com/http-party/node-http-proxy.git
+ │ └─ VendorName: Charlie Robbins
+ ├─ http-server@14.1.1
+ │ └─ URL: git://github.com/http-party/http-server.git
+ ├─ iconv-lite@0.6.3
+ │ ├─ URL: git://github.com/ashtuchkin/iconv-lite.git
+ │ ├─ VendorName: Alexander Shtuchkin
+ │ └─ VendorUrl: https://github.com/ashtuchkin/iconv-lite
+ ├─ is-fullwidth-code-point@3.0.0
+ │ ├─ URL: https://github.com/sindresorhus/is-fullwidth-code-point.git
+ │ ├─ VendorName: Sindre Sorhus
+ │ └─ VendorUrl: sindresorhus.com
+ ├─ lodash.camelcase@4.3.0
+ │ ├─ URL: https://github.com/lodash/lodash.git
+ │ ├─ VendorName: John-David Dalton
+ │ └─ VendorUrl: https://lodash.com/
+ ├─ lodash@4.17.21
+ │ ├─ URL: https://github.com/lodash/lodash.git
+ │ ├─ VendorName: John-David Dalton
+ │ └─ VendorUrl: https://lodash.com/
+ ├─ mime@1.6.0
+ │ ├─ URL: https://github.com/broofa/node-mime
+ │ ├─ VendorName: Robert Kieffer
+ │ └─ VendorUrl: http://github.com/broofa
+ ├─ minimist@1.2.7
+ │ ├─ URL: git://github.com/minimistjs/minimist.git
+ │ ├─ VendorName: James Halliday
+ │ └─ VendorUrl: https://github.com/minimistjs/minimist
+ ├─ mkdirp@0.5.6
+ │ ├─ URL: https://github.com/substack/node-mkdirp.git
+ │ ├─ VendorName: James Halliday
+ │ └─ VendorUrl: http://substack.net
+ ├─ ms@2.1.3
+ │ └─ URL: https://github.com/vercel/ms.git
+ ├─ object-inspect@1.12.3
+ │ ├─ URL: git://github.com/inspect-js/object-inspect.git
+ │ ├─ VendorName: James Halliday
+ │ └─ VendorUrl: https://github.com/inspect-js/object-inspect
+ ├─ portfinder@1.0.32
+ │ ├─ URL: git@github.com:http-party/node-portfinder.git
+ │ └─ VendorName: Charlie Robbins
+ ├─ reduce-flatten@2.0.0
+ │ ├─ URL: https://github.com/75lb/reduce-flatten.git
+ │ └─ VendorName: Lloyd Brookes
+ ├─ require-directory@2.1.1
+ │ ├─ URL: git://github.com/troygoode/node-require-directory.git
+ │ ├─ VendorName: Troy Goode
+ │ └─ VendorUrl: https://github.com/troygoode/node-require-directory/
+ ├─ requires-port@1.0.0
+ │ ├─ URL: https://github.com/unshiftio/requires-port
+ │ ├─ VendorName: Arnout Kazemier
+ │ └─ VendorUrl: https://github.com/unshiftio/requires-port
+ ├─ safe-buffer@5.1.2
+ │ ├─ URL: git://github.com/feross/safe-buffer.git
+ │ ├─ VendorName: Feross Aboukhadijeh
+ │ └─ VendorUrl: https://github.com/feross/safe-buffer
+ ├─ safer-buffer@2.1.2
+ │ ├─ URL: git+https://github.com/ChALkeR/safer-buffer.git
+ │ ├─ VendorName: Nikita Skovoroda
+ │ └─ VendorUrl: https://github.com/ChALkeR
+ ├─ secure-compare@3.0.1
+ │ ├─ URL: https://github.com/vdemedes/secure-compare.git
+ │ ├─ VendorName: Vadim Demedes
+ │ └─ VendorUrl: https://github.com/vdemedes/secure-compare
+ ├─ shell-quote@1.8.0
+ │ ├─ URL: http://github.com/ljharb/shell-quote.git
+ │ ├─ VendorName: James Halliday
+ │ └─ VendorUrl: https://github.com/ljharb/shell-quote
+ ├─ side-channel@1.0.4
+ │ ├─ URL: git+https://github.com/ljharb/side-channel.git
+ │ ├─ VendorName: Jordan Harband
+ │ └─ VendorUrl: https://github.com/ljharb/side-channel#readme
+ ├─ spawn-command@0.0.2-1
+ │ ├─ URL: https://github.com/mmalecki/spawn-command
+ │ └─ VendorName: Maciej Małecki
+ ├─ string-width@4.2.3
+ │ ├─ URL: https://github.com/sindresorhus/string-width.git
+ │ ├─ VendorName: Sindre Sorhus
+ │ └─ VendorUrl: sindresorhus.com
+ ├─ strip-ansi@6.0.1
+ │ ├─ URL: https://github.com/chalk/strip-ansi.git
+ │ ├─ VendorName: Sindre Sorhus
+ │ └─ VendorUrl: sindresorhus.com
+ ├─ supports-color@5.5.0
+ │ ├─ URL: https://github.com/chalk/supports-color.git
+ │ ├─ VendorName: Sindre Sorhus
+ │ └─ VendorUrl: sindresorhus.com
+ ├─ supports-color@7.2.0
+ │ ├─ URL: https://github.com/chalk/supports-color.git
+ │ ├─ VendorName: Sindre Sorhus
+ │ └─ VendorUrl: sindresorhus.com
+ ├─ supports-color@8.1.1
+ │ ├─ URL: https://github.com/chalk/supports-color.git
+ │ ├─ VendorName: Sindre Sorhus
+ │ └─ VendorUrl: https://sindresorhus.com
+ ├─ table-layout@1.0.2
+ │ ├─ URL: https://github.com/75lb/table-layout.git
+ │ └─ VendorName: Lloyd Brookes
+ ├─ tree-kill@1.2.2
+ │ ├─ URL: git://github.com/pkrumins/node-tree-kill.git
+ │ ├─ VendorName: Peteris Krumins
+ │ └─ VendorUrl: https://github.com/pkrumins/node-tree-kill
+ ├─ typical@4.0.0
+ │ ├─ URL: https://github.com/75lb/typical
+ │ └─ VendorName: Lloyd Brookes
+ ├─ typical@5.2.0
+ │ ├─ URL: https://github.com/75lb/typical
+ │ └─ VendorName: Lloyd Brookes
+ ├─ union@0.5.0
+ │ ├─ URL: http://github.com/flatiron/union.git
+ │ └─ VendorName: Charlie Robbins
+ ├─ url-join@4.0.1
+ │ ├─ URL: git://github.com/jfromaniello/url-join.git
+ │ ├─ VendorName: José F. Romaniello
+ │ └─ VendorUrl: http://joseoncode.com
+ ├─ whatwg-encoding@2.0.0
+ │ ├─ URL: https://github.com/jsdom/whatwg-encoding.git
+ │ ├─ VendorName: Domenic Denicola
+ │ └─ VendorUrl: https://domenic.me/
+ ├─ wordwrapjs@4.0.1
+ │ ├─ URL: https://github.com/75lb/wordwrapjs.git
+ │ └─ VendorName: Lloyd Brookes
+ ├─ wrap-ansi@7.0.0
+ │ ├─ URL: https://github.com/chalk/wrap-ansi.git
+ │ ├─ VendorName: Sindre Sorhus
+ │ └─ VendorUrl: https://sindresorhus.com
+ └─ yargs@17.6.2
+ ├─ URL: https://github.com/yargs/yargs.git
+ └─ VendorUrl: https://yargs.js.org/
+Done in 0.23s.
diff --git a/NOTICE.md b/NOTICE.md
index 37b5f6657..9b86294cb 100644
--- a/NOTICE.md
+++ b/NOTICE.md
@@ -25,10 +25,19 @@ The project maintains the following source code repositories in the GitHub organ
* https://github.com/eclipse-tractusx/portal-frontend-registration
* https://github.com/eclipse-tractusx/portal-frontend
* https://github.com/eclipse-tractusx/portal-backend
+* https://github.com/eclipse-tractusx/portal-assets
+* https://github.com/eclipse-tractusx/portal-cd
+* https://github.com/eclipse-tractusx/portal-iam
## Third-party Content
-This project leverages no third party content.
+This project leverages the following third party content:
+
+* License: Open Font License 1.1
+* Licence Path: https://github.com/impallari/Libre-Franklin/blob/master/OFL.txt
+* Source URL: https://github.com/impallari/Libre-Franklin
+
+See DEPENDENCIES file.
## Cryptography
diff --git a/README.md b/README.md
index fe14e9baa..c3bf021de 100644
--- a/README.md
+++ b/README.md
@@ -1,3 +1,20 @@
# Catena-X Portal Assets
-This repository containes the documenation and static image content for Catena-X Portal.
+This repository contains the documentation and static image content for Catena-X Portal.
+
+The Catena-X Portal application consists of
+
+* [portal-frontend](https://github.com/eclipse-tractusx/portal-frontend),
+* [portal-frontend-registration](https://github.com/eclipse-tractusx/portal-frontend-registration),
+* [portal-assets](https://github.com/eclipse-tractusx/portal-assets) and
+* [portal-backend](https://github.com/eclipse-tractusx/portal-backend).
+
+![Tag](https://img.shields.io/static/v1?label=&message=LeadingRepository&color=green&style=flat) The helm chart for installing the Catena-X Portal is available in [portal-cd](https://github.com/eclipse-tractusx/portal-cd).
+
+The Catena-X Portal is designed to work with the [Catena-X IAM](https://github.com/eclipse-tractusx/portal-iam).
+
+## Steps to run local
+
+ yarn
+ yarn build
+ yarn start
diff --git a/developer/01. Onboarding/01. Invite/01. Summary.md b/developer/01. Onboarding/01. Invite/01. Summary.md
new file mode 100644
index 000000000..8b2aa5722
--- /dev/null
+++ b/developer/01. Onboarding/01. Invite/01. Summary.md
@@ -0,0 +1,23 @@
+## Summary
+
+
+
+
+
+Scenario: New Member gets an individual invite by the CX Organization or Operator
+
+
+Functional Description
+Inside the CX Portal, users with the role of an CX Administrator will be able to invite new companies to the CX Network.
+The invite itself will be started with the
+
+- Company Name
+- Initial Contact Person (email, first name and last name)
+
+
+The initial contact person (which could be the CEO, a Manager or Business Consultant) will receive two emails by Catena-X, after the CX Administrator has initiated the invite.
+
+One email has the registration portal URL and the second email the user individual password to start the registration.
+
+
+
diff --git a/developer/01. Onboarding/01. Invite/02. Overview Invited Companies.md b/developer/01. Onboarding/01. Invite/02. Overview Invited Companies.md
new file mode 100644
index 000000000..81fe13cdb
--- /dev/null
+++ b/developer/01. Onboarding/01. Invite/02. Overview Invited Companies.md
@@ -0,0 +1,51 @@
+## Get Invited Companies
+
+Get all applications with there state and invited company name.
+
+
+
+#### API Details
+
+```diff
+! GET api/administration/registration/applicationsWithStatus
+```
+
+
+
+Response Body
+
+ {
+ "meta": {
+ "totalElements": 0,
+ "totalPages": 0,
+ "page": 0,
+ "contentSize": 0
+ },
+ "content": [
+ {
+ "applicationId": "uuid",
+ "applicationStatus": "e.g. CREATED",
+ "dateCreated": "2023-02-13T17:37:47.544Z",
+ "companyName": "string",
+ "email": "string",
+ "firstName": "string",
+ "lastName": "string"
+ }
+ ]
+ }
+
+
+
+Endpoints supports pagination & search by company name
+
+
+
+The endpoint does support search via the company name
+
+>Validation
+>
+>Search
+>- Search field added (already available inside the table component but needs to get activated)
+>- User can add a company name (minimum 3 digits) and receives in realtime (without pressing enter) the results
+>- There is a typing validation logic implemented, if the user is not typing for 1 seconds, the serach results will show up, below 1 seconds, the system will wait if any additional characters are getting added
+>- the serach field is validating the input, only letters, spaces, "!", "?", "&", "@", ".", "_", "-" and numbers are allowed
diff --git a/developer/01. Onboarding/01. Invite/03. Invite Company : Create Application.md b/developer/01. Onboarding/01. Invite/03. Invite Company : Create Application.md
new file mode 100644
index 000000000..125ebea9b
--- /dev/null
+++ b/developer/01. Onboarding/01. Invite/03. Invite Company : Create Application.md
@@ -0,0 +1,33 @@
+## Invite Company
+
+The invitation is the starting point of a company onboarding.
+A user of the company is getting invited by the CX Admin and the invitation endpoint is triggering in the backend the creation of the identity relevant elements.
+
+
+
+
+
+
+#### API Details
+
+```diff
+! POST api/administration/invitation
+```
+
+
+
+Request Body
+
+ {
+ "userName": "string",
+ "firstName": "string",
+ "lastName": "string",
+ "email": "string",
+ "organisationName": "string"
+ }
+
+
+
+Please note that a standard realm config got configured inside the endpoint to ensure that all security and structural factory are considered - under following page you can find the configuration details **to be added**
+
+
diff --git a/developer/01. Onboarding/02. Registration/01. Login.md b/developer/01. Onboarding/02. Registration/01. Login.md
new file mode 100644
index 000000000..e1487f77c
--- /dev/null
+++ b/developer/01. Onboarding/02. Registration/01. Login.md
@@ -0,0 +1,54 @@
+# Intro
+
+
+The registration process includes the onboarding of an organization. A natural person does not need an onboarding in Catena-X.
+
+
+The registration process of an organization involves a person belonging to the organization and who is authorized acting on behalf of the organization.
+
+Pre-condition: The authorized organization onboarding party must have received a Catena-X invite and needs to have valid documents of the organization (e.g. commercial register excerpt, certifications).
+
+
+
+#### Registration Login
+
+After receiving the CX invite email (incl. registration login URL and one-time-password), the user can directly start the login to the company registration.
+
+
+
+
+
+After selecting the company for login; the user can login via the email and password (first time; the one-time-password shared via email)
+
+
+
+
+After the successfull login; the user can directly start to proceed with the company registration form.
+
+
+
+
+### Registration Login Details
+
+With the login of the user to the registration, first the application record with status is getting loaded via the portal db.
+Based on the fetched status; the frontend logic will decide how the user proceeds.
+
+
+1. If the status is any status before "SUBMITTED" (< id "7"); the company registration form gets displayed; starting with the introduction screen.
+If company registration data have been previously added/saved already, the data will be displayed inside the registration form; otherwise an empty registration form woll be displayed.
+3. If the status is in status "SUBMITTED" (= id "7"); the information screen "application in validation" screen is getting displayed.
+
+
+5. If the status is in status "APPROVED" (= id "8"); the user should get redirected to the portal "home" page
+
+7. If the status is in status "DECLINED" (= id "9"); the information screen "application declined and closed" screen is getting displayed
+
+
+
+
+
+## Portal Login
+
+no change / update; same design as used for the registration
+
+
diff --git a/developer/01. Onboarding/02. Registration/02. Add Company Data.md b/developer/01. Onboarding/02. Registration/02. Add Company Data.md
new file mode 100644
index 000000000..10af83583
--- /dev/null
+++ b/developer/01. Onboarding/02. Registration/02. Add Company Data.md
@@ -0,0 +1,220 @@
+# Implementation
+
+
+
+## Enter / Verify Company Data
+
+
+
+In step 1, the user is asked to add the company details
+
+* a) via BPN search and automatic data load
+
+* b) adding the data manually
+ * Legal Entity Name
+ * Registration Name
+ * Legal Entity Street
+ * House Number
+ * Postal Code
+ * City
+ * Country
+ * NEW Unique ID such as Handelsregister, Tax ID, etc.
+
+
+
+#### API Details
+
+##### Display Company Data Registration Details (pre-saved)
+
+###### a) via BPN search and automatic data load
+
+```diff
+! GET /api/registration/legalEntityAddress/{bpn}
+```
+
+The endpoint is fetching the company data (if existing) from the bpdm data pool.
+Portal backend transfers the bpdm data pool response for the protal FE to display all relevant information. (similar structure as the portal db GET response)
+
+ {
+ "bpn": "BPNL00000007OH84",
+ "countryAlpha2Code": "DE",
+ "name": "TEST_GAIA_X",
+ "shortName": "TEST_GAIA_X",
+ "city": "Sindelfingen",
+ "streetName": "Hauptstrasse 2",
+ "region": null,
+ "streetAdditional": null,
+ "streetNumber": "2",
+ "zipCode": "71067",
+ "uniqueIds": [
+ {
+ "type": "COMMERCIAL_REG_NUMBER",
+ "value": "HRB2344553"
+ },
+ {
+ "type": "VAT_ID",
+ "value": "DE78338833"
+ }
+ ]}
+
+
+
+
+###### a) adding the data manually
+
+```diff
+! GET /api/registration/application/{applicationId}/companyDetailsWithAddress
+```
+
+.....
+
+
+
+Flow diagram for option a) and b)
+
+Details about the BPDM data call can get found in the Interface / API Call specification: BPDM - Get/Post Company Data
+
+
+
+
+##### Unique Identifier
+
+The company unique identifier is a company specific identifier which is used to help companies to prove their identity. In Catena-X registration party needs to add minimum one unqiue identifier which is later used inside the application verification flow to identifier the companies identity.
+To support the user entry and ensure that human errors are reduced, an endpoint to fetch the allowed unique identifier (per country) as well as field input validations are implemented.
+
+
+##### Logic implemented for the country specific identifier
+
+The unique identifier is a location based attribute; means, after the user entered a country code; the FE needs to fetch the possible company identifier via an api call an display them inside the new FE dropdown field (see details below)
+
+initially when opening the registration form step 1 "company data"; the unique identifier section is not displayed.
+Only when entering the country code; the unique id section is getting displayed (see screen below)
+
+
+
+```dif
+! GET /api/registration/company/country/{alpha2Code}/uniqueidentifiers
+```
+
+
+
+###### API Response
+
+ [
+ {
+ "id": 1,
+ "label": "COMMERCIAL_REG_NUMBER"
+ },
+ {
+ "id": 2,
+ "label": "VAT_ID"
+ }
+ ]
+
+
+
+###### Result on UI
+
+
+
+Translation of technical api response keys to human readable titles:
+
+
+
+
+**NOTE**
+Unique identifier handling
+3 possible scenarios; when fetching the co
+
+* no unique identifier
+* only one unique identifier (happy path)
+* multiple identifier
+
+#A - no unique identifier
+Same as the manual flow => user needs to select the unique identifier type and enter the id
+
+#B - only one unique identifier (happy path)
+The ID is getting auto displayed and can not get changed by the user
+
+#C - multiple identifier
+In case that multiple identifier are submitted, the user needs to be able to select the preferred used identifier.
+
+
+Below you can find an example of the implemented design for "multiple identifier"
+
+
+
+
+
+
+###### Implemented Pattern
+
+
+
+
+
+
+
+###### POST allowed Unique Identifier
+
+no post call existing. The data will get stored as part of the POST /companyDetailsWithAddress endpoint
+
+
+
+
+
+##### Store / Save Company Data Registration Details
+
+Via the post request, all company details will get stored/saved inside the portal db. The endpoint is used for both methods (manual data entering as well as the bpdm interface usage).
+
+
+```diff
+! POST /api/registration/application/{applicationId}/companyDetailsWithAddress
+```
+
+
+
+>Validation
+>
+>Search
+>- input must have exact 16 characters
+>- input must start with "BPNL"
+>- A-Z
+>- 0-9
+>
+>BPN - out of scope, user cant edit the field
+>
+>Legal Entity Name - minlength: 3, maxlength: 50; pattern:
+>- A – Z; a-z
+>- numbers (0 – 9)
+>- or any of the following special characters: ! # ' $ @ & % ( ) * + , - _ . / : ; = < > ? [ ] \ ^
+>- name must start with a letter or a number
+>- space
+>
+>Registered Name - minlength: 3, maxlength: 60; pattern:
+>- A – Z; a-z
+>- numbers (0 – 9)
+>- or any of the following special characters: ! # ' $ @ & % ( ) * + , - _ . / : ; = < > ? [ ] \ ^
+>- name must start with a letter or a number
+>- space
+>
+>Street with House Number - minlength: 3, maxlength: 60; pattern:
+>- A – Z; a-z
+>- numbers (0 – 9)
+>- or any of the following special characters: -
+>- name must start with a letter or a number
+>- space
+>
+>Postal Code - minlength: 0, maxlength: 10; pattern:
+>- A – Z; a-z
+>- numbers (0 – 9)
+>
+>City - minlength: 3, maxlength: 20; pattern:
+>- A-Z
+>- a-z
+>
+>Country - minlength: 3, maxlength: 20; pattern:
+>- A-Z
+>- a-z
+
+
diff --git a/developer/01. Onboarding/02. Registration/03. Add Additional Users.md b/developer/01. Onboarding/02. Registration/03. Add Additional Users.md
new file mode 100644
index 000000000..dc9f2d3a3
--- /dev/null
+++ b/developer/01. Onboarding/02. Registration/03. Add Additional Users.md
@@ -0,0 +1,21 @@
+# Implementation
+
+
+## Add Aditional Users
+
+
+
+As part of the registration and onboarding process a number of users will be needed to support
+
+* Signing Manager
+* Legal Admin
+
+
+
+#### API Details
+
+```diff
+- to be added
+```
+
+
diff --git a/developer/01. Onboarding/02. Registration/04. Company Role & Consent.md b/developer/01. Onboarding/02. Registration/04. Company Role & Consent.md
new file mode 100644
index 000000000..636536f23
--- /dev/null
+++ b/developer/01. Onboarding/02. Registration/04. Company Role & Consent.md
@@ -0,0 +1,39 @@
+# Implementation
+
+
+## Select company role & sign terms and conditions
+
+
+
+For the company role selection the Company Admin can select the company role within the network
+
+* Active Participant
+* App Provider
+* ...
+
+Additionally to the roles, the role related agreements are displayed.
+
+
+If an agreement as an assigned document, the document can get downloaded by the user by clicking on the document name. A help text is statically pushed to provide the context to the document.
+
+
+In the scenario of no document linked to the agreement, the agreement name will get displayed inside the user interface for approval.
+
+
+
+#### API Details
+
+#1 Roles and agreements are fetched from the consent endpoint
+```diff
+! Get /api/registration/company/companyRoles
+```
+
+
+#2 Consent Post
+Via the endpoint post consent, the consent given by the user to the respective agreements is getting stored against the company application
+
+```diff
+! Post /api/registration/application/{applicationId}/companyRoleAgreementConsents
+```
+
+
diff --git a/developer/01. Onboarding/02. Registration/05. Document Upload.md b/developer/01. Onboarding/02. Registration/05. Document Upload.md
new file mode 100644
index 000000000..72367f3bc
--- /dev/null
+++ b/developer/01. Onboarding/02. Registration/05. Document Upload.md
@@ -0,0 +1,70 @@
+# Implementation
+
+
+## Upload registration relevant documents
+
+
+
+In Step 4, the users are asked to upload the company identification.
+
+All documents uploaded under the same application register form are shown. If a second user has already uploaded a doc, the user will be able to see as well as delete this document as weel; as long as the users belong to the same company application.
+
+
+
+#### API Details
+
+##### #1 API Get Documents
+Fetching documents already loaded by a company assigned user which is connected to the current application.
+
+
+```diff
+! GET /api/registration/application/{applicationId}/documentType/{documentTypeId}/documents
+```
+
+
+
+##### #2 API Upload Document
+Documents are uploaded into the portal.document table and are connected via the user_id and document_type to the respective application.
+
+
+```diff
+! POST /api/registration/application/{applicationId}/documentType/{documentTypeId}/documents
+```
+
+
+
+
+##### #3 API Delete Document
+Documents can get deleted as long as the documents are still in the right/respective status.
+
+
+```diff
+! DELETE /api/registration/documents/{documentId}
+```
+
+
+
+Important: only documents under the same application are deletable. Additional the application needs to be in any status beside submitted; approved and declined.
+
+The document deletion does also validate the document type. Only types related to the registration can get deleted.
+
+
+
+##### #4 API Download Document
+Uploaded documents can also get viewed / downloaded by the user. To do this, the user needs to open the document by clicking on the document name. Automatically the document will get downloaded.
+
+
+```diff
+! GET /api/registration/Documents/{documentId}
+```
+
+
+
+>Validation
+>* only pdf documents are allowed to get uploaded (api and fe secured)
+>* maximum size of document upload: 8MB (api secured)
+>* authentication and authorization are FE and BE implemented
+>* backend validation: only users which are linked to the correct company and application can run the respective endpoints
+
+
+
diff --git a/developer/01. Onboarding/02. Registration/06. Verify Registration Data.md b/developer/01. Onboarding/02. Registration/06. Verify Registration Data.md
new file mode 100644
index 000000000..26cc95afd
--- /dev/null
+++ b/developer/01. Onboarding/02. Registration/06. Verify Registration Data.md
@@ -0,0 +1,32 @@
+# Implementation
+
+
+## Verify your data
+...
+
+...
+
+##### #1 Get application data
+...
+
+
+```diff
+! GET POST /api/registration/application/{applicationID}/registrationData
+```
+
+
+
+##### #2 Submit Registration
+
+text text text
+
+The endpoint triggers the
+* submission of the applicaton (status update to "SUBMITTED")
+* all documents related to the application get "locked"
+
+
+```diff
+! POST /api/registration/application/{applicationID}/submitregistration
+```
+
+
diff --git a/developer/01. Onboarding/03. Registration Approval/01. Summary.md b/developer/01. Onboarding/03. Registration Approval/01. Summary.md
new file mode 100644
index 000000000..c3028c8ec
--- /dev/null
+++ b/developer/01. Onboarding/03. Registration Approval/01. Summary.md
@@ -0,0 +1,37 @@
+## Summary
+
+The registration approval board is created for the CX Admin to managed registration applications to the Catena-X network.
+
+Acting user: CX Admin (Operator)
+
+
+The board supports filter, serach and the actual approval / validation function of new company registration requests.
+
+
+
+
+
+
+
+## Functional Details
+
+
+
+
+
+### Display Application Details
+
+With using the application details button, application details such as
+
+
+
+ * Company Data
+ * Company application role
+ * Documents, and
+ * details to the approval flow status
+
+
+
+
+
+
diff --git a/developer/01. Onboarding/03. Registration Approval/02. View Company Application(s).md b/developer/01. Onboarding/03. Registration Approval/02. View Company Application(s).md
new file mode 100644
index 000000000..a9e0e5f76
--- /dev/null
+++ b/developer/01. Onboarding/03. Registration Approval/02. View Company Application(s).md
@@ -0,0 +1,180 @@
+## View Company Application(s)
+
+
+## 1 Get Applications
+
+Get all applications in status "submitted", "confirmed" or "declined" with the respective application data entered by the registration company member.
+
+
+Response Body / Details:
+
+
+
+Response Body
+
+ {
+ "meta": {
+ "totalElements": 0,
+ "totalPages": 0,
+ "page": 0,
+ "contentSize": 0
+ },
+ "content": [
+ {
+ "applicationId": "uuid",
+ "applicationStatus": "e.g. CREATED",
+ "dateCreated": "2023-02-13T17:36:36.586Z",
+ "companyName": "string",
+ "documents": [
+ {
+ "documentId": "uuid",
+ "documentType": "e.g. CX_FRAME_CONTRACT"
+ }
+ ],
+ "companyRoles": [
+ "e.g. ACTIVE_PARTICIPANT"
+ ],
+ "applicationChecklist": [
+ {
+ "typeId": "e.g. REGISTRATION_VERIFICATION",
+ "statusId": "e.g. TO_DO"
+ }
+ ],
+ "email": "string",
+ "bpn": "string"
+ }
+ ]
+ }
+
+
+
+Pagination, Filtering as well as search is enabled to support the user to easily find application requests.
+
+
+
+###### Filtering
+Review: {hostname}/api/administration/registration/applications?page=0&size=20&companyApplicationStatusFilter=InReview
+Closed: {hostname}/api/administration/registration/applications?page=0&size=20&companyApplicationStatusFilter=Close
+All: {hostname}/api/administration/registration/applications?page=0&size=20
+
+
+###### Search
+Search is enabled by company name.
+
+
+#### Logical flow of the service
+* Get all applications which are submitted for review or where review is finished
+* Applications in any status beside the three mentioned status above will not get included in the response.
+
+
+#### API Details
+
+```diff
+! GET api/administration/registration/applications?page=0&size=4
+```
+
+Endpoints supports pagination and search via companyName
+
+
+
+## 2 Get Application Details
+
+
+
+
+Additionally to the endpoint of #1 where application key data are included, the GET application details endpoint is used to provide additional details to the operator / application approval buddy.
+This mainly covers:
+- address details
+- unique identifier
+- agreement/consent status per company role
+- users running under the application
+
+
+#### API Details Get Company Registration Data
+
+```diff
+! GET api/administration/registration/application/{applicationId}/companyDetailsWithAddress
+```
+
+##### Response Body / Details:
+
+ {
+ "companyId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
+ "name": "string",
+ "shortName": "string",
+ "bpn": "string",
+ "city": "string",
+ "streetName": "string",
+ "countryAlpha2Code": "string",
+ "region": "string",
+ "streetAdditional": "string",
+ "streetNumber": "string",
+ "zipCode": "string",
+ "countryDe": "string",
+ "companyRoles": [
+ {
+ "companyRole": "ACTIVE_PARTICIPANT",
+ "agreements": [
+ {
+ "agreementId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
+ "consentStatus": "ACTIVE"
+ }
+ ]
+ }
+ ],
+ "companyUser": [
+ {
+ "userId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
+ "firstName": "string",
+ "lastName": "string",
+ "email": "string"
+ }
+ ],
+ "uniqueIdentifier": [
+ {
+ "type": "VAT_ID",
+ "value": "string"
+ }
+ ]
+ }
+
+
+
+
+#### API Details Get Company Checklist Status
+The endpoint regsitration/application will provide the checklist status details which are used to fill the data inside the overlay tab two "Registration Process"
+
+
+
+```diff
+! GET: api/administration/registration/applications
+```
+
+
+
+
+
+## 3 Download Documents
+
+The API is downloading the document which is selected by the user.
+
+
+
+
+
+
+
+
+#### Logical flow of the service
+* By clicking on the document name, the document is fetched from the db and auto downloaded
+
+
+
+#### API Details
+
+```diff
+! GET /api/administration/registration/documents/{documentId}
+```
+
+
+
diff --git a/developer/01. Onboarding/03. Registration Approval/03. Registration Approval Process.md b/developer/01. Onboarding/03. Registration Approval/03. Registration Approval Process.md
new file mode 100644
index 000000000..ebae85b47
--- /dev/null
+++ b/developer/01. Onboarding/03. Registration Approval/03. Registration Approval Process.md
@@ -0,0 +1,491 @@
+## Summary
+
+The registration approval board is created for the CX Admin to manage registration applications to the Catena-X network.
+
+Acting user: CX Admin (Operator)
+
+
+The board supports filter, search, and the actual approval/validation function of new company registration requests.
+
+
+
+
+
+
+
+### Approval Overlay/Status
+
+Via an overaly, which is getting displayed as soon as the user clicks on any of the confirmation steps in the approval board, the detailed steps and status of the different application validation steps can get viewed.
+
+
+```diff
+! GET /api/administration/registration/application/{applicationId}/checklistDetails
+```
+
+
+
+Response Body
+
+ applicationChecklist: [
+ {
+ "type": "e.g. Registration_Verification",
+ "value": "e.g. DONE",
+ "details": "string - can be empty",
+ "retriggerable": "process_step"
+ },
+ {
+ "type": "e.g. Business_Partner_Number",
+ "value": "e.g. IN_PROGRESS",
+ "details": "string - can be empty",
+ "retriggerable": "process_step"
+ }
+ ]
+
+IMPORTANT: the "retriggerable" attribute is relevant / important for the FE business logic to decide; if the retrigger button is getting displayed or not.
+
+
+##### #1 Registration Validation
+
+
+
+
+##### #2 BPN Creation
+
+
+
+
+##### #3 Managed Identity Wallet
+
+
+
+
+##### #4 Clearinghouse
+
+
+
+
+##### #5 Self Description LP
+
+
+
+
+
+
+### Approval Flow
+
+The company registration approval flow is covering the manual and automatic checks of the company application including the setup of the company to participate inside the data space.
+
+The list below shows an overview of all application approval steps:
+
+
+
+
+
+
+
+
+
+As the highlevel displayed above; the registration approval flow consists of 6 steps. These can be partially executed in parallel, but always run in a predefined sequence.
+The 6 steps shown above are mapped as a checklist. To ensure that the operator knows the status of the company registration, each step can have one of the following statuses:
+
+- Open
+- In Progress
+- Done
+- Failed
+
+The checklist is processed as far as possible automatically by a worker process. Therfore a checklist item has at least one corresponding process step, these are created for processing in the worker. The distribution of the process steps to the checklist steps is listed in the respective checklist step.
+
+In case of a failed process step, the error code (if any) is recorded for the checklist step of the registration application and can be viewed by the operator.
+
+
+
+
+#### Details "Manual Validation"
+
+
+Associated Process Steps: VERIFY_REGISTRATION
+
+The "manual validation" checklist item is covering the company application validation by the operator. In this step, the application gets manually checked and 'approved' or 'declined'.
+Depending on the decision the checklist item "Registration_Verification" is set to DONE or FAILED.
+
+In the scenario of FAILED, a comment/message must be submitted by the operator.
+
+
+
+##### Scenario: Approve
+
+The endpoint "approve" sets the "Registration_Verification" checklist item to "DONE".
+The endpoint can only get triggered/executed if the application is in the status "submitted" and the "Registration_Verification" in the Status "TO_DO".
+
+
+```diff
+! PUT /api/administration/registration/application/{applicationId}/approve
+```
+
+
+
+##### Scenario: Decline
+
+
+
+
+
+The endpoint "decline" sets the "Registration_Verification" checklist item to "FAILED" incl. a time stamp, as well as the decline message added by the operator.
+The endpoint can only get triggered/executed if the application is in status "submitted" and the "Registration_Verification" in the Status "TO_DO".
+Additionally the endpoint sets the Application Status to "DECLINED" and the status of the company to "REJECTED". The users of the applying company will get an email after the process informing about the rejection including the decline message of the operator.
+
+
+```diff
+! PUT /api/administration/registration/application/{applicationId}/decline
+```
+
+Request Body:
+
+ {
+ "comment": "string"
+ }
+
+
+
+
+##### Details "Create Business Partner Number (if necessary)"
+
+
+The status "Business_Partner_Number" is getting updated based on the application registration content.
+
+
+
+##### Scenario 1 - Registration with BPN
+
+If the registration application is getting submitted by the registration party for approval with a BPN, the checklist item "Business Partner Number" is getting set to "DONE".
+In this case; nothing is needed anymore regarding the business partner number checklist item.
+
+
+
+##### Scenario 2 - Registration without BPN
+
+
+Associated Process Steps: CREATE_BUSINESS_PARTNER_NUMBER_PUSH, CREATE_BUSINESS_PARTNER_NUMBER_PULL
+
+If the registration application is getting submitted by the registration party for approval without a BPN, the checklist item "Business Partner Number" is kept in status "TO_DO"
+
+This process will be executed automatically by the worker. While processing the "CREATE_BUSINESS_PARTNER_NUMBER_PUSH" process step for the "Business Partner Number" checklist item, the worker will fetch all company data of the registration company and submit them to the business partner golden record gateway to validate the record and generate a business partner number. There are two possible outcomes to the external push.
+
+1. The call to the external system was successful. Then the process step "CREATE_BUSINESS_PARTNER_NUMBER_PUSH" is set to done and the checklist item "Business Partner Number" is set to "IN_PROGRESS". After that the process item "CREATE_BUSINESS_PARTNER_NUMBER_PULL" is created. Currently there is not implementation to push the data back to the portal. Therefore as soon as the process item "CREATE_BUSINESS_PARTNER_NUMBER_PULL" is created the portal will try to pull a response from the bpdm to get the bpn for the company. When receiving the valid bpn the checklist item "Business Partner Number" is set to "DONE", if the "VERFIY REGISTRATION" is already in state "DONE", the process item "CREATE_IDENTITY_WALLET" is created.
+
+2. The call to the external system failed. The checklist item "BUSINESS_PARTNER_NUMBER" is set to "FAILED". A process item "RETRIGGER_BUSINESS_PARTNER_NUMBER_PUSH" is created afterwards to enable the restart a failed BPN process.
+
+With executing the endpoint below, a failed bpn process can be retriggered to be executed again.
+
+```diff
+! POST /api/administration/registration/application/{applicationId}/trigger-bpn
+```
+
+
+
+
+ Please note - in the current implementation, the bpn gate response does mainly handle success scenarios. In the Scenario of a fail (due to incorrect/not matching company data) the failure response is not yet available and will be delivered by the bpdm product team asap.
+
+
+
+##### Scenario 3 - manually add BPN as an operator (interim supported workflow)
+
+For the interim process of the need to add the BPN of the new CX participant manually, the operator can use the endpoint to add the business partner number to the application.
+This endpoint is interim only and supposed to get disabled; as soon as the BPN Gateway is providing stable feedback on provided company data.
+
+
+```diff
+! POST /api/administration/registration/application/{applicationId}/{bpn}/bpn
+```
+
+
+
+Standard validations apply:
+
+- bpn has to be 16 digits long
+- bpn must start with "bpnl" / "BPNL"
+- company status inside portal db needs to be in "pending"
+- input value for the bpn is expected alphanumeric
+
+
+
+
+
+
+
+
+##### Details "Create Managed Identity Wallet"
+
+
+Associated Process Steps: CREATE_IDENTITY_WALLET
+
+
+The IF to the identity wallet is getting automatically triggered to create the company identity wallet when the following pre-requisites are fulfilled:
+
+
+- application checklist status "Business_Partner_Number" = "DONE"
+- application checklist status "Registration_Verification" = "DONE"
+- application is in status "submitted"
+
+ Details of the company identity wallet can get found inside the identity wallet product description.
+
+With triggering the registration; the company name as well as the bpn are getting submitted and stored inside the company wallet.
+
+Depending on the API response, the system will behave in the following way:
+
+- Response "Fail" => store the error message in the checklist table under checklist.comment and set the status to "FAILED"
+- Response "Success" => set status to "DONE" and store the did provided by the response body inside the comment attribute inside the table checklist.comment
+
+If for some reason the call to the identity wallet failes, a new process item "RETRIGGER_IDENTITY_WALLET" is created. This process item allows the operator to manually retrigger the process with the following endpoint:
+
+```diff
+! POST /api/administration/registration/application/{applicationId}/trigger-identity-wallet
+```
+
+ Please note: the scenario of "bring your own company wallet" is currently not supported and will get rechecked in H2 2023.
+
+
+
+
+#### Details "Clearinghouse Check"
+
+
+Associated Process Steps: START_CLEARING_HOUSE, END_CLEARING_HOUSE
+
+
+The "Clearinghouse Check" is getting automatically triggered when the following pre-requisites are fulfilled:
+
+
+- application checklist status "Business_Partner_Number" = "DONE"
+- application checklist status "Registration_Verification" = "DONE"
+- application checklist status "Identity_Wallet" = "DONE"
+- application is in status "submitted"
+
+
+
+
+
+The interface is an asynchrony interface - due to this the application checklist item associates with two process steps; the interface is explained below in two steps
+
+###### Step 1 - Send company data to clearinghouse
+
+The checklist worker checks for the existence of the "START_CLEARING_HOUSE" process item in state "TODO", when existing the process will automatically get the DID from the Identity Wallet for the company and send the company data displayed below to the clearinghouse endpoint. A new process item "END_CLEARING_HOUSE" is created. And the status of the "CLEARING_HOUSE" checklist item is set to "IN_PROGRESS"
+
+ {
+ "participantDetails": {
+ "name": "string",
+ "city": "string",
+ "street": "string",
+ "bpn": "string",
+ "region": "string",
+ "zipCode": "string",
+ "country": "string",
+ "countryAlpha2Code": "string"
+ },
+ "identityDetails": {
+ "did": "string",
+ "uniqueIds": [
+ {
+ "type": "string",
+ "value": "string"
+ }
+ ]
+ }
+ }
+
+If for some reason the call to the identity wallet or clearinghouse fails, a new process item "RETRIGGER_CLEARING_HOUSE" is created, to allow the manual retriggering of the process with the endpoint:
+
+```diff
+! POST /api/administration/registration/application/{applicationId}/retrigger-clearinghouse
+```
+
+
+
+
+###### Step 2 - Clearinghouse response
+
+In the asyncron call of the clearinghouse check; the portal provides a POST endpoint, which can get triggered by the clearinghouse to update the checklist status.
+
+
+the clearinghouse needs to be able to store a fail/success message. the message is supposed to get stored inside the checklist comment of the record attribute "clearing_house"
+
+
+```diff
+! POST /api/administration/registration/application/clearinghouse
+```
+
+ {
+ "bpn": "string",
+ "status": "string",
+ "message": "string"
+ }
+
+The bpn inside the request body is used to fetch the correct application Id. (application in status "submitted")
+The status can only get changed/updated; if the status of the application checklist item "CLEARING_HOUSE" is "IN_PROGRESS".
+
+If the clearinghouse service response contains the status CONFIRM the "CLEARING_HOUSE" checklist item is set to status DONE, if the response status is DECLINE a new process item "TRIGGER_OVERRIDE_CLEARING_HOUSE" is created.
+
+The new process item provides the possibility to override the clearinghouse state by calling the following endpoint:
+
+```diff
+! POST /api/administration/registration/application/{applicationId}/override-clearinghouse
+```
+
+
+
+
+##### Details "Self-Description Creation LegalPerson"
+
+
+
+Associated Process Steps: START_SELF_DESCRIPTION_LP, FINISH_SELF_DESCRIPTION_LP
+
+
+
+
+
+
+
+The "Self_Description_Legal_Person" is getting automatically triggered when the following pre-requisites are fulfilled:
+
+
+- application checklist status "Business_Partner_Number" = "DONE"
+- application checklist status "Registration_Verification" = "DONE"
+- application checklist status "Identity_Wallet" = "DONE"
+- application checklist status "Clearinghouse_Check" = "DONE"
+- application checklist status "Self_Description_LP" = "TO_DO"
+- application is in status "submitted"
+
+
+The interface is an asynchrony interface - due to this the application checklist item associates with two process steps; the interface is explained below in two steps
+
+###### Step 1 - Create SelfDescription - send company data to SD Factory
+
+The checklist worker checks for the existence of the "START_SELF_DESCRIPTION_LP" process item in state "TODO", when existing the process will automatically post the necessarry data to the SD-Factory to register the self description. A new process item "FINISH_SELF_DESCRIPTION_LP" is created. And the status of the "SELF_DESCRIPTION_LP" checklist item is set to "IN_PROGRESS".
+
+Request Body for SD-Factory call
+
+ {
+ "type": "LegalPerson",
+ "externalId": "{applicationId}",
+ "registrationNumber": [
+ {
+ "type":"string",
+ "value": "string"
+ }
+ ],
+ "headquarterAddress.country": "alpha2code of the registration company country",
+ "legalAddress.country": "alpha2code of the registration company country",
+ "bpn": "company bpn of the application company",
+ "issuer": "Catena-X bpn of the portal operator",
+ "holder": "company bpn of the application company"
+ }
+
+###### Step 2 - Save self description document
+
+To receive the asyncronos call from the SD-Factory the portal provides a POST endpoint, which can get triggered by the SD-Factory to pass the self description document and or a failed status with a explaining message.
+
+
+```diff
+! POST /api/administration/registration/application/clearinghouse/selfDescription
+```
+
+ {
+ "externalId": "Guid",
+ "status": "string",
+ "message": "string"
+ "selfDescriptionDocument": "string"
+ }
+
+with calling the endpoint; the SD Factory submittes a self-description of the legal person. The portal backend is storing the self-description inside the portal db linked to the company.
+
+With triggering the endpoint and submitting a document, the status of the checklist item "Self_Description_LP" is set to "DONE".
+
+
+Response "Error" => store the error message in the checklist table under checklist.comment and set the status to "FAILED"
+Response "Success" => set status to "DONE"
+
+ "registratioNumber": [
+
+ {
+ "type": "technicalKey",
+ "value": "value from db"
+ }
+ ]
+
+###### DB Table Content
+
+| ID | Portal DB Key | Interface Key for SD |
+| --- | --------------------- | -------------------- |
+| 1 | COMMERCIAL_REG_NUMBER | local |
+| 2 | VAT_ID | vatID |
+| 3 | LEI_CODE | leiCode |
+| 4 | VIES | EUID |
+| 5 | EORI | EORI |
+
+
+
+
+##### Details "Activation"
+
+
+The complete company account activation (as a result of the successful application checklist finalization) is automatically executed when the following pre-requisites are fulfilled:
+
+
+- application checklist status "Business_Partner_Number" = "DONE"
+- application checklist status "Registration_Verification" = "DONE"
+- application checklist status "Identity_Wallet" = "DONE"
+- application checklist status "Clearinghouse_Check" = "DONE"
+- application checklist status "Self_Description_LP" = "DONE"
+- application is in status "submitted"
+
+
+With the execution of the application activation, the system will:
+
+- set company status inside portal.companies to "ACTIVE"
+- set application status inside portal.company_application to"CONFIRMED"
+- set company_application time stamp
+- set invitation of all users to "CLOSED"
+- set invitation time stamp
+- update user roles (portal db and keycloak)
+- add bpn to user(s)
+- send a welcome email
+
+
+
+
+### Add/Update BPN for the registration company
+
+
+The bpn can get manually added (as a workaround) if the registration company request doesn't have a business partner number added and the registration request is in the status "submitted".
+
+
+
+BPNs can only get added by CX Admins.
+As mentioned above, the implementation is a workaround only and will get replaced by the actual bpn connection as soon as the reference implementation is available.
+
+
+
+### Status endpoint - Checklist Details
+
+To fetch the specific details of the checklist items; status; possible available comment as well as the re-triggerable status, the following endpoint needs to get called
+
+
+```diff
+! GET api/administration/registration/application/{applicationId}/checklistDetails
+```
+
+
+
+Response Body
+
+ {
+ "type": "e.g. REGISTRATION_VERIFICATION",
+ "status": "e.g. TO_DO",
+ "details": "string",
+ "retriggerableProcessSteps": [
+ "e.g. VERIFY_REGISTRATION"
+ ]
+ }
+
+
diff --git a/developer/01. Onboarding/03. Registration Approval/04. Decline Application.md b/developer/01. Onboarding/03. Registration Approval/04. Decline Application.md
new file mode 100644
index 000000000..d69122988
--- /dev/null
+++ b/developer/01. Onboarding/03. Registration Approval/04. Decline Application.md
@@ -0,0 +1,44 @@
+## Decline Company Application
+
+While the company application is processing the application validations; the administrator can decline the application whenever wanted.
+To decline the application the "Cancel Application" Button is enabled for all applications which did not reach the "CONFIRMED" / "DECLINED" status so far.
+
+
+
+
+
+##### API Implementation
+
+The endpoint "decline" sets the "Registration_Verification" checklist item to "FAILED" incl. a time stamp, as well as the decline message added by the operator.
+The endpoint can only get triggered/executed if the application is in status "submitted" and the "Registration_Verification" in the Status "TO_DO".
+Additionally the endpoint sets the Application Status to "DECLINED" and the status of the company to "REJECTED". The users of the applying company will get an email after the process informing about the rejection including the decline message of the operator.
+
+
+```diff
+! PUT /api/administration/registration/application/{applicationId}/decline
+```
+
+
+
+Request Body:
+
+ {
+ "comment": "string"
+ }
+
+
+
+
+> **Warning**
+> In the current state of implementation the checklist worker and manual process intervention such as the cancellation have no validation/check implemented where the services can validate if the other service might already run. Means; in the unlikely case that the cancellation is triggered while the activation is running in parallel; the activation might overrule the cancellation.
+> The scenario is very unlikely and will get handled in an upcomming release.
+
+
+
+
+Input field validations input field FE
+* All Characters / Digits/ Numbers are allowed
+* Not allowed is: start with "="
+
+
+
diff --git a/developer/02. Technical Integration/01. Connector Registration/01. Summary.md b/developer/02. Technical Integration/01. Connector Registration/01. Summary.md
new file mode 100644
index 000000000..a149eb5fa
--- /dev/null
+++ b/developer/02. Technical Integration/01. Connector Registration/01. Summary.md
@@ -0,0 +1,24 @@
+# Summary
+
+For a full technical onboarding and to enable the network to browse through and find available data connectors, each data provider or connector owner is in ownership to register their connectors in the network which will trigger on top a self description (GAIA-X).
+
+
+The details below show the user interface as well as the available endpoints to trigger the registration.
+
+
+In the technical integration / setup of the connector, 3 different scenarios are available
+
+
+- connector as a service (request a service via a service provider)
+- bring your own connector
+- no connector required
+
+
+Connector stakeholders are mainly app providers and data provider (active CX participants along the automotive value chain).
+
+
+For the scenario "bring your own connector", the user will be able to register the connector by entering the relevant information. In the case of a "connector as a service" case, the relevant data fields need to get still defined by the Product Team CaaS (not in scope for release 1)
+
+
+
+
diff --git a/developer/02. Technical Integration/01. Connector Registration/02. View Connector.md b/developer/02. Technical Integration/01. Connector Registration/02. View Connector.md
new file mode 100644
index 000000000..b86672301
--- /dev/null
+++ b/developer/02. Technical Integration/01. Connector Registration/02. View Connector.md
@@ -0,0 +1,62 @@
+## View Connector
+
+
+
+
+
+
+## Details
+
+
+##### Status:
+
+Status uses the chipcard instead of the status icon. API response data mapping explained below:
+
+
+
+
+
+##### SD Registration:
+
+MUI Element/Icon used to display status based on the API response:
+
+
+
+In the scenario where the documentId is NULL; tooltip is implemented with an additional information about the self-description status.
+
+
+
+##### Host:
+
+Host displayed based on the API response:
+
+
+
+
+
+
+## Implementation/APIs
+
+### 1 Get all MY Connector Registrations
+
+The user can retrieve all connectors which are connected to his/her company as consumer
+
+
+
+#### Logical flow of the service
+* fetch the user id from the user token calling the GET call
+* from the user token user_id get via the table iam_user the company_user_id
+* use the company_user_id to retrieve the company_id
+* now get all connectors where company_id is added as consumer
+
+
+
+#### API Details
+
+```diff
+! GET /api/administration/connectors
+```
+
+Endpoints supports pagination
+
+
diff --git a/developer/02. Technical Integration/01. Connector Registration/03. Create new Connector Registration.md b/developer/02. Technical Integration/01. Connector Registration/03. Create new Connector Registration.md
new file mode 100644
index 000000000..54842a677
--- /dev/null
+++ b/developer/02. Technical Integration/01. Connector Registration/03. Create new Connector Registration.md
@@ -0,0 +1,192 @@
+## 1. Create new Connector Registration - self-owned
+
+
+
+
+
+
+The user can create a new connector registration by using the connector POST call.
+
+The registration will automatically
+* register the connector in the daps authentication service (with the public key uploaded inside the connector registration UI / endpoint)
+* trigger the SD Factory to create the self-description of the connector
+
+
+
+
+#### Details to the DAPS
+
+still to be added
+
+
+#### Details to the SD
+
+The self description factory is getting triggered as part of the connector registration.
+The asinchron 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.
+
+
+##### #1 Self description request
+
+Request body (refinement still needed):
+
+ {
+ "externalId":"connectorId",
+ "status":"CONFIRM or FAILED",
+ "message":"string",
+ "content": "string"
+ }
+
+
+
+##### #2 Self description response (asynchron)
+
+Request body (refinement still needed):
+
+ {
+ "externalId":"connectorId",
+ "status":"CONFIRM or FAILED",
+ "message":"string",
+ "content": "string"
+ }
+
+
+
+Execution:
+
+In case of status "success"
+* content is stored as json file inside the portal db
+* connector status:
+ * Active - if the daps auth has status "true" set the connector status to "ACTIVE"
+ * Pending - if the connector.daps_registration_successful is "false" and connector.self_description_document_id is != NULL
+ * Pending - if the connector.daps_registration_successful is "false" and connector.self_description_document_id is = NULL
+ * Pending - if the connector.daps_registration_successful is "true" and connector.self_description_document_id is = NULL
+
+
+
+In case of status "fail"
+* set status of the "Self_Description_SO" to "FAILED" and store the message inside the checklist comment field application_checklist.comment
+
+
+
+Technical explanation: if the connector.daps_registration_successful is "true" and connector.self_description_document_id is != NULL; connector status is "ACTIVE"
+
+
+
+
+
+>Connector Name
+>- length: min 2; max 20
+>- A-z
+>- spaces
+>- numbers
+>- @
+>
+>Validate the connector URL
+>- data input should start with "https:"
+>- and input validation: ^(?:https:\/\/)([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]{0,61}[a-zA-Z0-9])[.]([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]{0,61}[a-zA-Z0-9])[.]([a-zA-Z0-9][a-zA-Z0-9][a-zA-Z0-9])*$
+>
+>Connector Owner
+>- 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
+
+
+
+#### Logical flow of the service
+
+* fetch the user id from the user token calling the POST call
+* from the user token user_id get via the table iam_user the company_user_id
+* fetch via the company_user_id the company id which is used has host and provider of the edc
+* input data as well as the backend fetched company id's are send to the SD factory to create the connector self-description with connection to the wallet
+* after successful self-description creation, the edc details as well as the self-description document are getting stored inside the portal database
+* last the daps is getting triggered to register the connector inside the daps authentication service; in case the service fails; the user will get informed and needs to retrigger the daps
+
+
+
+#### API Details
+
+```diff
+! POST /api/administration/connectors
+```
+
+
+
+Request Body
+
+ {
+ "name": "string",
+ "connectorUrl": "string",
+ "location": "string",
+ "certificate": "string"
+ }
+
+
+
+
+## 2. Create new Connector Registration - managed
+
+Service Provider can create a new registration for a company which subscribed for a service provider service
+
+Same as for self-owned connectors, the connector registration will automatically
+* register the connector in the daps authentication service (with the public key uploaded inside the connector registration UI / endpoint)
+* trigger the SD Factory to create the self-description of the connector
+
+
+
+If connector data have been successfully stored; DAPS auth has been successful and SD is created and stored; the connector record will receive the status "ACTIVE".
+Technical explanation: if the connector.daps_registration_successful is "true" and connector.self_description_document_id is != NULL; connector status is "ACTIVE"
+
+
+
+
+>Connector Name
+>- length: min 2; max 20
+>- A-z
+>- spaces
+>- numbers
+>- @
+>
+>Validate the connector URL
+>- data input should start with "https:"
+>- and input validation: ^(?:https:\/\/)([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]{0,61}[a-zA-Z0-9])[.]([a-zA-Z0-9]|[a-zA-Z0-9][a-zA-Z0-9\-]{0,61}[a-zA-Z0-9])[.]([a-zA-Z0-9][a-zA-Z0-9][a-zA-Z0-9])*$
+>
+>Connector Owner
+>- 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
+
+
+
+#### Logical flow of the service
+
+* fetch the user id from the user token calling the POST call
+* from the user token user_id get via the table iam_user the company_user_id
+* use the company_user_id to retrieve the company_id
+* validate if a service request is active between service provider company and to be registered connector company
+* if record found, proceed
+* if not, block and send back an error
+
+
+
+#### API Details
+
+```diff
+! POST /api/administration/connectors/managed
+```
+
+
+
+Request Body
+
+ {
+ "name": "string",
+ "connectorUrl": "string",
+ "location": "string",
+ "providerBpn": "string",
+ "certificate": "string"
+ }
+
+
+
diff --git a/developer/02. Technical Integration/01. Connector Registration/04. DAPS Registration.md b/developer/02. Technical Integration/01. Connector Registration/04. DAPS Registration.md
new file mode 100644
index 000000000..b68adbe1e
--- /dev/null
+++ b/developer/02. Technical Integration/01. Connector Registration/04. DAPS Registration.md
@@ -0,0 +1,36 @@
+## 4 Retrigger DAPS
+
+In case the DAPS registration failed as part of the connector registration, the user will be able to retrigger the endpoint directly.
+For this endpoint; following data will be pushed
+
+
+
+
+
+
+
+
+>Validation:
+>
+>* connectorId existing
+>* validate is daps registration flag is false (if not, dont run the daps registration)
+>* if the endpoint gets an error => send the error back to the front-end and keep the connector daps registration flag on "false"
+>* if the endpoint result is "success" => set the connector daps registration flag to "true" and send success message to the FE
+
+
+
+#### API Details
+
+```diff
+! POST /api/administration/connectors/trigger-daps/{connectorId}
+```
+
+
+
+Request Body:
+
+ file (certificate)
+
+
+
+
diff --git a/developer/02. Technical Integration/01. Connector Registration/05. Self Description.md b/developer/02. Technical Integration/01. Connector Registration/05. Self Description.md
new file mode 100644
index 000000000..3a7121ea2
--- /dev/null
+++ b/developer/02. Technical Integration/01. Connector Registration/05. Self Description.md
@@ -0,0 +1,70 @@
+## Self Description
+
+As part of the connector registration; the self-description is created.
+In case the self-description interface failed; the connector registration is in status "PENDING".
+
+
+
+
+> **Note**
+> Currently, there is no support / option to retrigger the SD creation - neither for the customer; nor for the operator
+
+
+
+
+### Implementation Details
+
+
+
+
+
+
+
+
+#### Send Company Data to SD Factory (Create SD)
+
+As part of the connector registration the SD Factory is getting triggered with following data
+
+Request Body:
+
+ {
+ "type": "ServiceOffering",
+ "externalId": "connectorId",
+ "providedBy": "url of the company (legalPerson) sd",
+ “aggregationOf”: "",
+ ”termsAndConditions”: "",
+ “policies”: "",
+ "issuer": "portal operator bpn",
+ "holder": "bpn of the provider received inside the request body of the POSt /connector endpoint"
+ }
+
+
+
+
+#### SD CallBack Service
+
+The SD callback endpoint is provided by the portal to enable Self-Description-Issuer can call the CX Operation Application and provide the SD content.
+
+
+
+```diff
+! POST /api/administration/Connectors/clearinghouse/selfDescription
+```
+
+
+
+Request Body:
+
+ {
+ "externalId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
+ "status": "Confirm",
+ "message": "string",
+ "selfDescriptionDocument": "string"
+ }
+
+
+
+To trigger the endpoint a technical user is needed. This technical user is issued by the portal adminsitrator only. Own creation of the technical user is not possible.
+
+
+
diff --git a/developer/02. Technical Integration/01. Connector Registration/06. Delete Connector.md b/developer/02. Technical Integration/01. Connector Registration/06. Delete Connector.md
new file mode 100644
index 000000000..42372cbbe
--- /dev/null
+++ b/developer/02. Technical Integration/01. Connector Registration/06. Delete Connector.md
@@ -0,0 +1,34 @@
+## 5 Delete Connector
+
+Delete own connector. The deletion will disable the discovery service for the connector.
+
+
+
+
+
+
+
+
+
+> **Note**
+> In the current implementation; the deactivation of the SD document as well as the deletion of the DAPS Auth is not yet included
+
+
+
+
+#### API Details
+
+
+```diff
+! DELETE /api/administration/connectors/{connectorID}
+```
+
+
+
+Request Body
+
+ n/a
+
+
+
+
diff --git a/developer/02. Technical Integration/02. Identity Provider Management/01. Summary.md b/developer/02. Technical Integration/02. Identity Provider Management/01. Summary.md
new file mode 100644
index 000000000..4d56cc74f
--- /dev/null
+++ b/developer/02. Technical Integration/02. Identity Provider Management/01. Summary.md
@@ -0,0 +1,13 @@
+# Summary
+
+The IdP Switch function is used to integrate / connect company idp's or switch back to catena-x shared idp usage.
+
+
+The integration of company idp's is suspected to be the most used scenario when considering the use of idp switch. Companies which want to use their own company authentication can connect their company idp with the catena-x shared idp by using user federation.
+
+
+In this scenario - authentication is delivered by the company idp and authorization is still managed inside keycloak.
+
+
+The biggest positive element on ownCompany idp usage is the comfort of the login, as well as the user credentials which are not shared with an operator.
+
diff --git a/developer/02. Technical Integration/02. Identity Provider Management/02. Configure Company IdP.md b/developer/02. Technical Integration/02. Identity Provider Management/02. Configure Company IdP.md
new file mode 100644
index 000000000..4d25b3d0a
--- /dev/null
+++ b/developer/02. Technical Integration/02. Identity Provider Management/02. Configure Company IdP.md
@@ -0,0 +1,97 @@
+# User Description
+
+How to connect the own idp:
+
+
+- Request a idp connection
+- Upload your company-idp metadata file (please note, CX will mainly support OIDC)
+- Manually add client-id and secret
+- Confirm the IdP config, we will share the authentication URL with you
+
+
+
+After successful setup, the user migration/invite need to take place, before the previous used idp is getting deactivated and deleted.
+
+
+
+Details regarding the IAM architecture (applies for shared as well as own IdP usage)
+
+
+
+
+
+
+
+
+
+
+
+### Register your company IdP
+
+To register your company idp, login with administration rights and open the "Identity Provider Config" via the top right user navigation.
+Inside the config, you will find your current registered (enabled and disabled) identity providers - quite oftne this will only be one identity provider. As well as the option to register a new identity provider (such as you company idp).
+
+
+
+
+
+
+
+
+
+
+
+ Please note - for the company identity provider conenction you will need to prepare certain information to be able to connect your company IdP. Please ansure that all necessary information are available.
+
+Currenly only the connection for OIDC idp's is supported.
+
+
+
+#### Create the new idp record
+
+Click on "Add Identity Provider" to start the registration.
+Inside the overlay a idp name will need to get added. This will be the display name of your IdP. Means users which try to login to CX will see this login option. Use a name which users can understand and know that this belongs to their company.
+
+
+
+
+
+
+
+
+By clicking on "Confirm".
+
+On the upcoming screen the idp relevant connection information need to get added.
+Those are
+- metadata url (available in your local/company IdP - ending with /.well-known/openid-configuration)
+- client ID (created in your company IdP)
+- client secret (created in your company IdP)
+
+
+
+
+
+
+
+
+if the config was sucessful, you will get asked to add your personal company idp unique identifier. In this step you will connect your exosting catena-x user account (with your already assigned roles and customized configurations) with your company IdP. To do this successfully, you need to add your company IdP unqiue ID.
+
+
+
+
+
+
+
+
+With the confirm/submit button the value will get stored successfully and you can now test the successful company IdP integration by doing a logout and trying to login with your company credentials and company IdP.
+Please note: in this moment, your user is connected with the Catena-X Shared IdP as well as your company IdP. This means, if after the logout and new login via your company IdP you might find out, that the login via the company IdP might not work (due to wrong configuration) you still can login to catena-X with the previous used IdP and correct the IdP config.
+
+
+As soon as you have successfully tested the login, please proceed with the user migration => see next chapter.
+
+
+
+PLEASE NOTE - THIS PAGE IS STILL UNDER REWORK AND WILL CHANGE IN THE UPCOMING WEEKS
+
+
+
diff --git a/developer/02. Technical Integration/02. Identity Provider Management/03. User Migration.md b/developer/02. Technical Integration/02. Identity Provider Management/03. User Migration.md
new file mode 100644
index 000000000..b7d2f8beb
--- /dev/null
+++ b/developer/02. Technical Integration/02. Identity Provider Management/03. User Migration.md
@@ -0,0 +1,27 @@
+#### Migrate existing user accounts to the new created IdP
+
+With the configuration of a new IdP, existing user accounts should not get lost. In the previous section "Create the new idp record" it was already described, how the admin user can connect his/her existing user account with the new company idp. In this section the user migration of additional available user accounts is handled.
+
+
+For the migration of additional existing user accounts, which have been created under the shared IdP previously, the administrator can call the user migration list via the IdP config page.
+
+
+
+
+By clicking on the "Users" sub-navigation icon, a overlay with the user migration list as json or csv file is getting displayed.
+
+
+
+Download the list and add for each user, which is supposed to get migrated, the company idp unique identifier into the list as ProviderUserID upload the list again by placing in inside the upload area and wait for the success message that all the users have been migrated / added.
+
+
+
+
+
+With that, the user migration is successfully done - you can validate the user list again by re-opening the users list of the IdP.
+After the successful config, the new IdP can get enabled and the old IdP can get disabled.
+
+
+
+
+PLEASE NOTE - THIS PAGE IS STILL UNDER REWORK AND WILL CHANGE IN THE UPCOMING WEEKS
diff --git a/developer/02. Technical Integration/02. Identity Provider Management/04. FAQ.md b/developer/02. Technical Integration/02. Identity Provider Management/04. FAQ.md
new file mode 100644
index 000000000..74bb7c0be
--- /dev/null
+++ b/developer/02. Technical Integration/02. Identity Provider Management/04. FAQ.md
@@ -0,0 +1,17 @@
+### FAQ
+
+
+####
+
+
+
+####
+
+
+
+####
+
+
diff --git a/developer/03. User Management/01. User Account/01. Summary.md b/developer/03. User Management/01. User Account/01. Summary.md
new file mode 100644
index 000000000..f744c36da
--- /dev/null
+++ b/developer/03. User Management/01. User Account/01. Summary.md
@@ -0,0 +1,8 @@
+# Summary
+
+Company Administrators as well as IT Administrators of the company can create new user accounts.
+With the Catena-X user account, the user can access the Catena-X Portal including the apps marketspace, direct access to subscribed company apps, semantic data models, digital twins, service offers, etc.
+
+
+
+
diff --git a/developer/03. User Management/01. User Account/02. User Account.md b/developer/03. User Management/01. User Account/02. User Account.md
new file mode 100644
index 000000000..efc902770
--- /dev/null
+++ b/developer/03. User Management/01. User Account/02. User Account.md
@@ -0,0 +1,90 @@
+## User Permissions
+
+In the view "my user account" and "user account" the user assigned app permissions will get displayed
+
+
+
+
+## API Details
+
+### #1 Get company user details
+Retrieve user details and permissions assigned per offer (app, service, core service)
+
+
+```diff
+! GET api/administration/user/ownUser
+```
+
+
+
+user details are fetched from the company_users table as well as company_users_assigned_roles and company_users_assigned_business_partners
+
+
+
+
+Response Body
+
+ {
+ "companyUserId": "uuid",
+ "created": "2023-02-11T16:45:58.201Z",
+ "bpn": [
+ "string"
+ ],
+ "company": "string",
+ "status": "e.g. ACTIVE",
+ "assignedRoles": [
+ {
+ "appId": "uuid",
+ "roles": [
+ "string"
+ ]
+ }
+ ],
+ "firstName": "string",
+ "lastName": "string",
+ "email": "string"
+ }
+
+
+
+
+### #1 Get company user details
+Retrieve user details and permissions assigned per offer (app, service, core service)
+
+
+```diff
+! GET api/administration/user/owncompany/users/{companyUserId}
+```
+
+
+
+user details are fetched from the company_users table as well as company_users_assigned_roles and company_users_assigned_business_partners
+
+
+
+
+Response Body
+
+ {
+ "companyUserId": "uuid",
+ "created": "2023-02-11T16:55:43.898Z",
+ "bpn": [
+ "string"
+ ],
+ "company": "string",
+ "status": "e.g. ACTIVE",
+ "assignedRoles": [
+ {
+ "appId": "uuid",
+ "roles": [
+ "string"
+ ]
+ }
+ ],
+ "firstName": "string",
+ "lastName": "string",
+ "email": "string"
+ }
+
+
+
diff --git a/developer/03. User Management/01. User Account/03. Create new user account (single) - UPDATE NEEDED.md b/developer/03. User Management/01. User Account/03. Create new user account (single) - UPDATE NEEDED.md
new file mode 100644
index 000000000..a969fdc94
--- /dev/null
+++ b/developer/03. User Management/01. User Account/03. Create new user account (single) - UPDATE NEEDED.md
@@ -0,0 +1,20 @@
+## Create a new user account (single)
+
+User with the respective user management rights can access the user management via the top right user navigation.
+As soon as the user management is displayed, the user can direct via the button "Identity User Management" or scroll down the page to get to the Identity User Management section where new user accounts can get created.
+
+Select the "Add User" Button to trigger the new user account creation dialog.
+Inside the dialog, add the users first name, last name and email. Additionally to the user information, a network role need to get selected. Based on the network role, the user will be able to have a certain permissions inside the portal.
+
+
+
+
+
+
+
+
+As soon as the confirm button is selected, an invite email is send to the user including a one-time-password (otp) for login.
+With the first login, the user will be asked to set a own password, password policies are to be followed.
+
+
+
diff --git a/developer/03. User Management/01. User Account/04. Create new user account (bulk) - UPDATE NEEDED.md b/developer/03. User Management/01. User Account/04. Create new user account (bulk) - UPDATE NEEDED.md
new file mode 100644
index 000000000..cd11e220c
--- /dev/null
+++ b/developer/03. User Management/01. User Account/04. Create new user account (bulk) - UPDATE NEEDED.md
@@ -0,0 +1,3 @@
+## Create a new user account (bulk)
+
+Currently not supported
diff --git a/developer/03. User Management/02. Edit User Account/01. Summary.md b/developer/03. User Management/02. Edit User Account/01. Summary.md
new file mode 100644
index 000000000..c087c48ac
--- /dev/null
+++ b/developer/03. User Management/02. Edit User Account/01. Summary.md
@@ -0,0 +1,14 @@
+# User Account Details
+
+
+The "User Account Details" function is a detailed view of one user, which the company administrator can open by clicking on "details" of any users under his organization.
+
+
+
+
+# My CX Account
+
+
+The "My User Account Details" function is a detailed view of your own user account and can get viewed by the user owner only.
+
+
diff --git a/developer/03. User Management/02. Edit User Account/02. Password Reset.md b/developer/03. User Management/02. Edit User Account/02. Password Reset.md
new file mode 100644
index 000000000..321032250
--- /dev/null
+++ b/developer/03. User Management/02. Edit User Account/02. Password Reset.md
@@ -0,0 +1,41 @@
+## Password Reset
+
+The "Reset password" button is available in the user account detail page and can get triggered by the administrator with the respective (modify_user_account) right.
+The picture below includes the service details
+
+
+
+
+
+### Error message handling for password reset
+
+* If the reset is triggered 10 times already, the next time an error will get submitted with which the FE can submit the message "You have triggered the maximum time of password resets, please try it later again". For that, the backend need to respond with an error that FE can display the right error message
+* For any other errors, the error message will be "The password reset was unsuccessful. We phased an issue, please try It later again"
+* If policy is failing (company is using ownIdP), the backend service will enable the FE to submit a scenario specific error message
+
+
+
+### Password reset policy
+
+* User for whom password reset is triggered needs to be under the same org/tenant => to be checked as part of the service
+* Before triggering the password reset, check the company id => password reset is only valid for SharedIdP customers. Check in table identity_providers if the identity_provider_category_id for the company is Shared IdP (value: '1')
+* SharedIdP user id need to get retrieved via the user token and transferred to the sharedIdP user ID
+ * take user id handed over by FE
+ * transfer the user id to the centralIdP user id (via iam_user) table
+ * transfer centralIdP user id to sharedIdP user id
+
+
+
+```diff
+! PUT api/administration/user/owncompany/users/ac1cf001-7fbc-1f2f-817f-bce0575a0011/resetPassword
+```
+
+
+
+Request body
+
+ n/a
+ managed via endpoint path
+
+
+
diff --git a/developer/03. User Management/02. Edit User Account/03. User Permissions - UPDATE NEEDED.md b/developer/03. User Management/02. Edit User Account/03. User Permissions - UPDATE NEEDED.md
new file mode 100644
index 000000000..efc902770
--- /dev/null
+++ b/developer/03. User Management/02. Edit User Account/03. User Permissions - UPDATE NEEDED.md
@@ -0,0 +1,90 @@
+## User Permissions
+
+In the view "my user account" and "user account" the user assigned app permissions will get displayed
+
+
+
+
+## API Details
+
+### #1 Get company user details
+Retrieve user details and permissions assigned per offer (app, service, core service)
+
+
+```diff
+! GET api/administration/user/ownUser
+```
+
+
+
+user details are fetched from the company_users table as well as company_users_assigned_roles and company_users_assigned_business_partners
+
+
+
+
+Response Body
+
+ {
+ "companyUserId": "uuid",
+ "created": "2023-02-11T16:45:58.201Z",
+ "bpn": [
+ "string"
+ ],
+ "company": "string",
+ "status": "e.g. ACTIVE",
+ "assignedRoles": [
+ {
+ "appId": "uuid",
+ "roles": [
+ "string"
+ ]
+ }
+ ],
+ "firstName": "string",
+ "lastName": "string",
+ "email": "string"
+ }
+
+
+
+
+### #1 Get company user details
+Retrieve user details and permissions assigned per offer (app, service, core service)
+
+
+```diff
+! GET api/administration/user/owncompany/users/{companyUserId}
+```
+
+
+
+user details are fetched from the company_users table as well as company_users_assigned_roles and company_users_assigned_business_partners
+
+
+
+
+Response Body
+
+ {
+ "companyUserId": "uuid",
+ "created": "2023-02-11T16:55:43.898Z",
+ "bpn": [
+ "string"
+ ],
+ "company": "string",
+ "status": "e.g. ACTIVE",
+ "assignedRoles": [
+ {
+ "appId": "uuid",
+ "roles": [
+ "string"
+ ]
+ }
+ ],
+ "firstName": "string",
+ "lastName": "string",
+ "email": "string"
+ }
+
+
+
diff --git a/developer/03. User Management/02. Edit User Account/04. Manage user assigned BPN.md b/developer/03. User Management/02. Edit User Account/04. Manage user assigned BPN.md
new file mode 100644
index 000000000..724afd86c
--- /dev/null
+++ b/developer/03. User Management/02. Edit User Account/04. Manage user assigned BPN.md
@@ -0,0 +1,99 @@
+#x Add BPN
+
+
+
+
+
+
+
+### Details
+
+
+* added edit button
+* when clicking on the edit button, the overlay/modal opens up with the bpn's of the user
+* the user is able to delete bpn's or add new bpn's via the input field
+* if the user clicks the "close" button on the overlay/modal, the user gets directed back to the user account view
+
+
+### Validations
+
+
+* bpn input field needs following validations
+ * only 16 characters are allowed, if the user is entering more or less characters, an error will show up in real time below the input field "Invalid BPN Number. Please enter a valid number."
+ * The input value need to start with "BPN" otherwise show an error message "Invalid BPN Number. Please enter a valid number."
+
+
+### Success/Error Messages
+
+
+* no actual success message needed if a BPN was added, the user can see the successful added BPN when its getting displayed above the input field
+
+
+
+#x Delete BPN
+
+
+
+
+
+
+
+### Details
+
+
+* when clicking on the "bin" icon, the respective bpn will get triggered for deletion (via API)
+* if the user clicks the "close" button on the overlay/modal, the user gets directed back to the user account view
+
+
+
+### Success/Error Messages
+
+
+* no actual success message needed if a BPN was deleted, the user can see that the BPN is not existing anymore in the list
+
+
+
+## API Details
+
+### #1 API Endpoint Details: Add BPN
+
+Add a bpn to the respective user
+
+Currently no bpn validation implemented. Reason: waiting for bpn family tree from bpdm product team. Otherwise the validation is not possible.
+
+
+
+```diff
+! PUT: api/administration/user/owncompany/users/(userId}/businessPartnerNumbers/{bpn}
+```
+
+
+
+Request body
+
+ n/a
+ managed via endpoint path
+
+
+
+
+
+### #2 API Endpoint Details: Delete BPN
+
+Delete a bpn of the respective user
+
+
+
+```diff
+! DELETE: api/administration/user/owncompany/users/(userId}/businessPartnerNumbers/{bpn}
+```
+
+
+
+Request body
+
+ n/a
+ managed via endpoint path
+
+
+
diff --git a/developer/03. User Management/02. Edit User Account/05. Suspend User.md b/developer/03. User Management/02. Edit User Account/05. Suspend User.md
new file mode 100644
index 000000000..69f15e3cb
--- /dev/null
+++ b/developer/03. User Management/02. Edit User Account/05. Suspend User.md
@@ -0,0 +1,3 @@
+# Suspend User
+
+currently not supported
diff --git a/developer/03. User Management/02. Edit User Account/06. Delete User.md b/developer/03. User Management/02. Edit User Account/06. Delete User.md
new file mode 100644
index 000000000..550153e55
--- /dev/null
+++ b/developer/03. User Management/02. Edit User Account/06. Delete User.md
@@ -0,0 +1,108 @@
+## Delete User
+
+Inside the portal, a user will be able to delete an user - the function is differentiated into 2 functions
+
+* Delete your own user account
+* Delete an user account of a user inside your organization (only available for the IT Administrator)
+
+
+
+User accounts might be companyIdP federated or CX user accounts. In both scenarios the user deletion is implemented and will effect the user account itself, the user favorites, user roles as well as user attributes.
+
+The deletion of users is audit relevant and will be audit logged inside the db.
+
+More details to the audit logging can get found here: https://github.com/catenax-ng/tx-portal-assets/blob/945546d91065b8870aa8f69ce94b48eac7a5ade2/docs/Technical%20Details/Auditing.md
+
+
+### Own User Deletion Flow
+
+
+
+
+
+
+### Company User Deletion Flow
+
+
+
+
+
+
+## Functionality and impacted Keycloak layers
+
+
+
+
+
+
+
+## API Details
+
+### #1 Delete my user
+
+Delete own user account.
+
+Important - due to the audit relevance, we dont delete directly all user related connections.
+
+Instead user will get set to "DELETED", and following information/details will get deleted
+
+
+
+* User credential/account
+* User favorites
+* User assigned roles
+* User invitation record
+* User assigned bpn's
+
+
+
+```diff
+! DELETE api/administration/user/ownUser/{companyUserId}
+```
+
+
+
+Request body
+
+ n/a
+ managed via endpoint path
+
+
+
+
+With the deletion an automatic logic will get processed. After latest 5 seconds, the user token will get disabled and the user will be logged out.
+
+
+
+
+### #2 Delete user {userId}
+
+Delete an user of the same company inside the portal DB and keycloak.
+
+Important - due to the audit relevance, we dont delete directly all user related connections.
+
+Instead user will get set to "DELETED", and following information/details will get deleted
+
+
+
+* User credential/account
+* User favorites
+* User assigned roles
+* User invitation record
+* User assigned bpn's
+
+
+
+```diff
+! DELETE api/administration/user/owncompany/users
+```
+
+
+
+Request body
+
+ n/a
+ managed via endpoint path
+
+
+
diff --git a/developer/03. User Management/02. Edit User Account/index.md b/developer/03. User Management/02. Edit User Account/index.md
new file mode 100644
index 000000000..e1bbc4840
--- /dev/null
+++ b/developer/03. User Management/02. Edit User Account/index.md
@@ -0,0 +1,17 @@
+# Summary
+
+User Account, or My User Account is implemented to retrieve details of the current user or an user of the company (for admins only).
+
+Inside the user account page, a number of services/actions can get triggered.
+
+
+
+* Add BPN
+* Delete BPN
+* Delete User
+* Password Reset
+* Suspend User
+* Change User Roles
+
+
+
diff --git a/developer/03. User Management/03. Technical User/01. Summary.md b/developer/03. User Management/03. Technical User/01. Summary.md
new file mode 100644
index 000000000..f7c01f05f
--- /dev/null
+++ b/developer/03. User Management/03. Technical User/01. Summary.md
@@ -0,0 +1,29 @@
+# Summary
+
+The CX Portal User Management is enhanced by the technical user management which is used to manage technical users for a company. Technical users are relevant for backend to backend service connections.
+Example use case: register Digital Twins via the DFT to the digital twin registry.
+
+
+Technical user permissions are created by the operator and need to get loaded as part of the static data.
+
+Currently the portal doesn't support the technical user permission creation by an administrator operator board. In future releases, the functionality is planned to get implemented. Till that, technical users need to get deployed to keycloak as well as the portal db.
+
+
+CX Member companies can create their technical users on their needs and map them to the pre-defined roles.
+
+
+
+### Customer Functionalities covered in the function
+* Create new technical user under my org
+* View all my technical users (including technical user details)
+* Delete a technical user
+
+
+### Available technical user roles
+* Connector User
+* Identity Wallet Management
+* BPDM Management
+* BPDM Gateway
+* Dataspace Discvoery
+* App Tech User
+* Service Management
diff --git a/developer/03. User Management/03. Technical User/02. View Technical Users.md b/developer/03. User Management/03. Technical User/02. View Technical Users.md
new file mode 100644
index 000000000..eb8182f43
--- /dev/null
+++ b/developer/03. User Management/03. Technical User/02. View Technical Users.md
@@ -0,0 +1,44 @@
+## View technical users
+
+
+
+
+
+
+
+
+
+
+## Implementation - API Details
+
+### #1 Get Service Accounts
+
+The endpoint provides the possibility to look up all service accounts of my company (how: service accounts are connected to companies. Retrieve the current accounts with the company_id via the user_id inside the user token)
+
+Permission: "view_tech_user_management"
+
+```diff
+! GET: api/administration/serviceaccount/owncompany/serviceaccounts
+```
+
+ {
+ "meta": {
+ "totalElements": 0,
+ "totalPages": 0,
+ "page": 0,
+ "contentSize": 0
+ },
+ "content": [
+ {
+ "serviceAccountId": "uuid",
+ "clientId": "string",
+ "name": "string",
+ "serviceAccountType": "MANAGED/OWN",
+ "offerSubscriptionId": "uuid"
+ }
+ ]
+ }
+
+
+
+
diff --git a/developer/03. User Management/03. Technical User/03. Create Technical User.md b/developer/03. User Management/03. Technical User/03. Create Technical User.md
new file mode 100644
index 000000000..f39d8003d
--- /dev/null
+++ b/developer/03. User Management/03. Technical User/03. Create Technical User.md
@@ -0,0 +1,165 @@
+## Create a new technical user
+User with the respective user management rights can access the user management via the top right user navigation.
+As soon as the user management is displayed, a button "Technical User Management" shows up to switch from real users to technical users.
+
+
+
+
+
+
+
+## Implementation - API Details
+
+
+### Get Service Account Role Profiles
+
+Technical users are currently managed under one single client. "Tech_User_Management" client.
+All technical user roles are created inside this client as "composite role". With that, permissions of the actual client where the technical client will need to get access to, can get assigned to the roles inside the client "Tech_User_Management".
+
+On the FE side, for role assignment, only the composite roles will be visible for the user
+
+Data flow details are drawn below
+
+
+
+```diff
+! GET: /api/administration/serviceaccount/user/roles
+```
+
+
+
+Response Body
+
+ {
+ "meta": {
+ "totalElements": 0,
+ "totalPages": 0,
+ "page": 0,
+ "contentSize": 0
+ },
+ "content": [
+ {
+ "serviceAccountId": "uuid",
+ "clientId": "string",
+ "name": "string",
+ "serviceAccountType": "e.g. MANAGED",
+ "offerSubscriptionId": "uuid"
+ }
+ ]
+ }
+
+
+
+> **Note**
+> The service account type gives an information if the service account is a own created service account or a service account which is created by app/service provider of an managed offer subscribtion.
+
+
+
+
+### Create Service Account
+
+Create new service account under the same company as the executing user
+Permission: "add_tech_user_management"
+
+
+With the POST api, the backend service will
+
+* creates the user inside keycloak central idp
+* updates the data inside portal iam_service_accounts
+* updates the data inside portal company_service_accounts
+ * service_account type is automatically set to "own"
+ * subscription_id NULL
+* updates the data inside portal company_service_accounts_assigned_roles
+* As part of the user creation, the user gets set to "ACTIVE" inside the portal db.
+
+
+
+```diff
+! POST: api/administration/serviceaccount/owncompany/serviceaccounts
+```
+
+
+Request Body
+
+ {
+ "name": "string",
+ "description": "string",
+ "authenticationType": "JWT",
+ "roleIds": [
+ "uuid"
+ ]
+ }
+
+
+
+
+### Show Tech. Service Account Details (of just created Account)
+
+The endpoint provides the possibility to look up technical user details
+Permission: "view_tech_user_management"
+
+
+Technical Service Account Detail information
+
+* id
+* company
+* clientId
+* clientCredential
+* role
+
+
+
+```diff
+! GET: api/administration/serviceaccount/owncompany/serviceaccounts/{serviceAccountId}
+```
+
+
+Request Body
+
+ {
+ "serviceAccountId": "uuid",
+ "clientId": "string",
+ "name": "string",
+ "description": "string",
+ "authenticationType": "JWT",
+ "roles": [
+ {
+ "roleId": "uuid",
+ "clientId": "string",
+ "roleName": "string"
+ }
+ ],
+ "companyServiceAccountTypeId": "e.g. MANAGED",
+ "secret": "string",
+ "subscriptionId": "uuid"
+ }
+
+
+
+
+
+### Service Accounts Created via service/app subscription
+
+If the service account is created due to a servce/app activation; the service account user is created by the app/service provider; but connected to the actual customer (owner of the user).
+With that, the customer as well as the offer provider should be able to view the service account with certain privileges.
+
+With the POST api, the backend service will
+
+* creates the user inside keycloak central idp
+* updates the data inside portal iam_service_accounts
+* updates the data inside portal company_service_accounts
+ * service_account type is automatically set to "managed"
+ * subscription_id is filled by the customer app/service subscriptionID
+* updates the data inside portal company_service_accounts_assigned_roles
+* As part of the user creation, the user gets set to "ACTIVE" inside the portal db.
+
+```diff
+Part of the following endpoint:
+POST: /api/apps/autoSetup as well as POST: /api/service/autoSetup
+```
+
+More details available inside the autosetup service description.
+
+
+
+
diff --git a/developer/03. User Management/03. Technical User/04. Delete Technical User.md b/developer/03. User Management/03. Technical User/04. Delete Technical User.md
new file mode 100644
index 000000000..240b5c80a
--- /dev/null
+++ b/developer/03. User Management/03. Technical User/04. Delete Technical User.md
@@ -0,0 +1,46 @@
+## Delete an user
+Technical users created under the same company id can get deleted by user administrators.
+To delete an user, just open up the user details and click the "delete" button.
+
+
+
+
+
+
+
+
+#### Currently not supported:
+
+update technical user secret
+
+
+
+
+### Delete Service Account
+
+Delete an existing service account
+Only service accounts of the own company can get deleted.
+Permission: "delete_tech_user_management"
+
+
+As part of the deletion API, the following tasks get executed:
+
+* Delete service account inside the central identity provider
+* Technical user record is set to "INACTIVE"
+
+
+```diff
+! DELETE: api/administration/owncompany/serviceaccounts/{serviceAccountId}
+```
+
+
+
+
+
+Request body
+
+ n/a
+ managed via endpoint path
+
+
+
diff --git a/developer/03. User Management/04. App Access Management/01. Summary.md b/developer/03. User Management/04. App Access Management/01. Summary.md
new file mode 100644
index 000000000..b0f0105a4
--- /dev/null
+++ b/developer/03. User Management/04. App Access Management/01. Summary.md
@@ -0,0 +1,18 @@
+# Summary
+
+The app access management is a function enabled by the portal where a company can manage for their active subscribed apps the user access for their own company users.
+
+
+IT Administrator of each company can access the User Management via the User Menu and directly jump into the app access management page.
+
+The App Access Management page include information about
+
+* Available App Roles
+* Users which have access to this app and their related role
+* option to add a user with a role to the app
+* option to add a to an existing app user another role or switch the role
+
+
+#### Pre-Requisite
+The functionality of app user management for a specific app is only available to a company if the company has an active app subscription.
+
diff --git a/developer/03. User Management/04. App Access Management/02. Assign App Role Page Overview.md b/developer/03. User Management/04. App Access Management/02. Assign App Role Page Overview.md
new file mode 100644
index 000000000..b7b32bb68
--- /dev/null
+++ b/developer/03. User Management/04. App Access Management/02. Assign App Role Page Overview.md
@@ -0,0 +1,87 @@
+## App Role Management
+
+
+### #1 Get App Roles and Descriptions
+Retrieving all app roles and the respective description from the portal backend to display them on the portal screen.
+
+
+
+```diff
+! GET api/administration/user/owncompany/app/{appId}/roles
+```
+
+
+
+Response body
+
+ {
+ "offerId": "uuid",
+ "roles": [
+ {
+ "roleId": "uuid",
+ "role": "string",
+ "description": "string"
+ }
+ ]
+ }
+
+
+
+
+### #2 Get Company App Users & Serach
+Retrieving all company users which have a roles assigned/not assigned for the pre-selected app.
+
+The response will include users under the same company and != status "DELETED"
+
+API supports
+
+* Pagination
+* Has role of the app assigned: true/false (optional parameter)
+
+
+
+```diff
+! GET /api/administration/user/owncompany/apps/{appId}/users?page=0&size=15
+```
+
+
+
+Response body
+
+ {
+ "meta": {
+ "totalElements": 0,
+ "totalPages": 0,
+ "page": 0,
+ "contentSize": 0
+ },
+ "content": [
+ {
+ "companyUserId": "uuid",
+ "status": "e.g. ACTIVE",
+ "firstName": "string",
+ "lastName": "string",
+ "email": "string",
+ "roles": [
+ "string"
+ ]
+ }
+ ]
+ }
+
+
+
+App Access Management user list as well as the app assign role user list is using the endpoint to display the respective user.
+
+Example:
+
+
+
+
+
+In case the api is responding with an empty array, the UI will display following messages:
+
+
+
+
+
diff --git a/developer/03. User Management/04. App Access Management/03. Assign App Role.md b/developer/03. User Management/04. App Access Management/03. Assign App Role.md
new file mode 100644
index 000000000..da60ebbb2
--- /dev/null
+++ b/developer/03. User Management/04. App Access Management/03. Assign App Role.md
@@ -0,0 +1,52 @@
+## Assign App Role
+
+
+### #1 Add App Role
+Add an app role to a company user.
+
+Validation:
+
+* active app subscription must be existing
+* client must be existing
+* company user needs to belong to the same company
+
+
+```diff
+! PUT api/administration/user/{companyUserId}/app/{appId}/roles
+```
+
+
+Request body
+
+ [
+ "string"
+ ]
+
+
+
+
+### #2 Update App Role
+Update user roles works with an easy method. FE provides all role assignments via the endpoint request body.
+The backend will use this input and freshly reset the user assigned user roles. With this mechanism, the endpoint can get used for assignment as well as unassignment of roles in the same manner.
+
+Validation:
+
+* active app subscription must be existing
+* client must be existing
+* company user needs to belong to the same company
+
+
+```diff
+! PUT api/administration/user/{companyUserId}/app/{appId}/roles
+```
+
+
+
+Request body
+
+ [
+ "string"
+ ]
+
+
+
diff --git a/developer/03. User Management/index.md b/developer/03. User Management/index.md
new file mode 100644
index 000000000..a29f30901
--- /dev/null
+++ b/developer/03. User Management/index.md
@@ -0,0 +1,10 @@
+# User Management
+
+User accounts are the basic entities to access resources in Catena-X.
+Learn how to manage different kinds of user accounts in the Catena-X Portal.
+Read more details in the following sections:
+
+- [User Account](./1%20User%20Account/)
+- [Edit User Account](./2%20Edit%20User%20Account/)
+- [Technical User](./3%20Technical%20User/)
+- [App Access Management](./4%20App%20Access%20Management/)
diff --git a/developer/04. Apps/01. Marketplace/01. App Overview.md b/developer/04. Apps/01. Marketplace/01. App Overview.md
new file mode 100644
index 000000000..e09250b01
--- /dev/null
+++ b/developer/04. Apps/01. Marketplace/01. App Overview.md
@@ -0,0 +1,28 @@
+## Summary
+
+...description to be added...
+
+
+
+Links:
+
+[Design](/docs/App(s)/Marketplace/Design.md)
+[FAQ](/docs/App(s)/Marketplace/FAQ.md)
+
+
+
+
+
+## Implementation
+
+### #1 App Overview
+
+API is used to display the active apps of the CX network based on the released apps. If an app is under review or creation, the app wont show up in this view.
+
+
+```diff
+! GET: /api/apps/active
+```
+
+
+
diff --git a/developer/04. Apps/01. Marketplace/02. App Details.md b/developer/04. Apps/01. Marketplace/02. App Details.md
new file mode 100644
index 000000000..915b79c16
--- /dev/null
+++ b/developer/04. Apps/01. Marketplace/02. App Details.md
@@ -0,0 +1,52 @@
+## Summary
+
+...description to be added...
+
+
+
+Links:
+
+[Design](/docs/App(s)/Marketplace/Design.md)
+[FAQ](/docs/App(s)/Marketplace/FAQ.md)
+
+
+
+
+
+## Implementation
+
+### #1 App Details
+
+The api is responding with all app details for a specific app id. Within the path, the app id is getting send. Additionally language can get set as optional parameter. If no value is send for "language" inside the request call, english will be used as default language setting for the app detail response.
+Additionally the app subscription status is included.
+
+
+The app details endpoint include
+- app title
+- app leadimage id
+- app detail image id's
+- provider URI
+- provider name
+- provider contact email
+- provider contact number
+- app supported use cases
+- app long description
+- app price tag
+- app tags
+- subscription status (for the respective company of the api calling user)
+- app supported languages
+- app documents (documents of type APP_CONTRACT, APP_DATA_DETAILS, ADDITIONAL_DETAILS, APP_TECHNICAL_INFORMATION)
+
+
+
+```diff
+! GET /api/apps/{appId}
+```
+
+Subscription Status Management:
+The "Subscribe" button shows different state and color depending on the company subscription status. Below the button states are shown:
+
+
+
+
+
diff --git a/developer/04. Apps/01. Marketplace/03. App Favorites.md b/developer/04. Apps/01. Marketplace/03. App Favorites.md
new file mode 100644
index 000000000..3ad02a7ca
--- /dev/null
+++ b/developer/04. Apps/01. Marketplace/03. App Favorites.md
@@ -0,0 +1,28 @@
+## Summary
+
+...description to be added...
+
+
+
+Links:
+
+[Design](/docs/App(s)/Marketplace/Design.md)
+[FAQ](/docs/App(s)/Marketplace/FAQ.md)
+
+
+
+
+
+## Implementation
+
+### #1 Store User Favorites
+The App favourite function is offered in the app marketplace to highlight an app easily and ensure that I as an user can quickly find the app again.
+User favorites are stored inside the DB - the portal db will know which user has which favorite selected and can easily retrieve the information for the Front-End
+
+
+```diff
+! GET: /api/apps/favourites
+```
+
+
+
diff --git a/developer/04. Apps/01. Marketplace/04. My Business Apps.md b/developer/04. Apps/01. Marketplace/04. My Business Apps.md
new file mode 100644
index 000000000..758658d1b
--- /dev/null
+++ b/developer/04. Apps/01. Marketplace/04. My Business Apps.md
@@ -0,0 +1,42 @@
+## Summary
+
+...description to be added...
+
+
+
+Links:
+
+[Design](/docs/App(s)/Marketplace/Design.md)
+[FAQ](/docs/App(s)/Marketplace/FAQ.md)
+
+
+
+
+
+## Implementation
+
+### #1 My Business Application
+
+#### DB Details
+
+Relevant DB tables
+
+* company_user_assigned_roles
+* user_roles
+* app_assigned_clients
+* company_assigned_offers
+
+
+#### Get my Business Applications
+The API Backend call is retrieving all apps, where the current user is having an active role assigned.
+The service call is getting triggered for an individual user as soon as this user logs in to the application.
+
+Important for the function is an active company subscription of the assigned users company.
+
+
+```diff
+! GET: /api/apps/business
+```
+
+
+
diff --git a/developer/04. Apps/02. App Release Process/App Release Process.md b/developer/04. Apps/02. App Release Process/App Release Process.md
new file mode 100644
index 000000000..4472574e6
--- /dev/null
+++ b/developer/04. Apps/02. App Release Process/App Release Process.md
@@ -0,0 +1,367 @@
+# Summary
+
+The "App Release Publishing Process" is accessible via the "App Release Process" as well as the "App Management".
+
+The App Provider has access to both of the start screens to trigger a new app for marketplace publishing.
+
+The app publishing process includes the submission of relevant app details, adding app images, documents as well as testing and technical connection (where suitable).
+
+
+# Implementation
+
+#### Trigger the Publishing Process
+
+Option 1: Via the app management page
+
+
+
+
+
+
+Option 2: Via the App Release Process
+
+
+
+
+
+
+#### Step 1 - App Card Details
+
+
+
+In the Step 1 of the publishing process, the app card details are getting filled first
+
+* app name
+* provider
+* app lead picture
+* language support
+* pricing information
+* etc.
+
+
+##### Implementation Details
+
+* create a new app in table portal.apps with the data send in the request body
+ * store the value "title" in the attribute name
+ * store the value "provider" in the attribute provider
+ * store the value "leadPictureUri" in the attribute thumbnail_url
+ * the status of the app is getting set to "CREATED" => "1"
+* portal.apps attribute provider_company_id is set based on the users company id
+* the "descriptions" in de and en are stored in the table portal.app_descriptions (linked to the table portal.apps via the new created app id)
+* the "supportedLanguageCodes" are stored in the table portal.app_languages (linked to the table portal.apps via the new created app id)
+* the "useCaseIds" (supported app use_case(s)) are stored in the portal.app_assigned_use_cases table (linked to the table portal.apps via the new created app id)
+* the "price" is stored in the portal.app_assigned_licenses table (linked to the table portal.apps via the new created app id)
+
+
+
+
+##### API Details
+
+###### #1 Get Languages
+Get language api endpoint is used to provide the user a dropdown function in which the provider can select which language the respective app supports
+
+```diff
+! GET /api/administration/staticdata/languagetags
+```
+
+
+
+
+###### #2 Get Use Cases
+Get use cases api endpoint is used to provide the user a dropdown function in which the provider can select which use cases the respective app serves
+
+
+
+```diff
+! GET /api/administration/staticdata/usecases
+```
+
+
+
+
+###### #3 Get Sales Manager
+Get possible sales manager (under my company) which I can add as Sales Manager of my app. The Sales Manager is useful to assign specific notifications when an app get's a subscribe request.
+
+```diff
+! GET /api/apps/appreleaseprocess/ownCompany/salesManager
+```
+
+
+
+
+###### #4 GET/POST App LeadImage
+
+The endpoints enable the user to store and retrieve the app leadimage id.
+Using the document id of the response body, the document base64 encoding can get retireved and turned to the actual image.
+
+
+Supported formats: JPEG and PNG
+
+
+```diff
+! PUT /api/apps/appreleaseprocess/updateappdoc/{appId}/documentType/{documentTypeId}/documents
+! GET /api/apps/appreleaseprocess/{appId}/appStatus
+! GET /api/administration/documents/{documentId}
+```
+
+
+
+
+###### #5 Create App
+Created a new app for the current active app provider
+
+```diff
+! POST /api/apps/createapp
+```
+
+Endpoint exception handling:
+
+....more to add....
+ SalesManaer
+can be NULL
+validate if the SalesManager uuid is a valid uuid of an user with the role "SalesManager"
+validation is needed if the SalesManager belongs to the same company as the acting user
+
+
+
+
+
+>Input Validations
+>
+>* App Title - minlength: 5, maxlength: 40; pattern:
+> * A-Z
+> * a-z
+> * .
+> * :
+> * _
+> * -
+> * @
+> * &
+> * 0-9
+> * space
+>
+>* App Provider - minlength: 3, maxlength: 30; pattern:
+> * A-Z
+> * a-z
+> * space
+>
+>* Short Description (en) - minlength: 10, maxlength: 255; pattern:
+> * a-zA-Z0-9 !?@'"()_-=/*.,;:
+>
+>* Short Description (de) - minlength: 10, maxlength: 255; pattern
+> * a-zA-ZÀ-ÿ0-9 !?@'"()_-=/*.,;:
+>
+>* Use Case/Category - Dropdown element (see also https://portal.dev.demo.catena-x.net/_storybook/?path=/story/form--multi-select-list) - pattern:
+> * A-Z
+> * a-z
+>
+>* App Language - Multi Select List (see also https://portal.dev.demo.catena-x.net/_storybook/?path=/story/form--multi-select-list) - pattern:
+> * A-Z
+> * a-z
+> * space
+>
+>* Pricing Information - minlength: 1, maxlength: 15; pattern
+> * A-Z
+> * a-z
+> * 0-9
+> * /
+> * €
+> * space
+>
+>* App Icon/Image - dropzone (see also https://portal.dev.demo.catena-x.net/_storybook/?path=/story/dropzone–dropzone)
+> * only png und jpeg allowed
+
+
+
+
+#### Step 2 - App Page Details
+
+
+
+In the Step 2 of the publishing process, the app detail page is getting filled
+
+* app description
+* app images
+* documents/contract information
+* etc.
+
+
+##### Implementation Details
+
+to be added
+
+
+
+
+##### API Details
+
+###### #1 ...
+Description
+
+```diff
+! endpoint
+```
+
+
+
+
+
+###### #2 ...
+Description
+
+```diff
+! endpoint
+```
+
+
+
+
+
+###### #3 ...
+Description
+
+```diff
+! endpoint
+```
+
+
+
+
+>Input Validations
+>
+>* LongDescription (en) - maxlength: 2000; pattern:
+> * a-zA-Z0-9 !?@'"()[]_-+=<>/*.,;:
+>
+>* LongDescription (de) - maxlength: 2000; pattern:
+> * a-zA-ZÀ-ÿ0-9 !?@'"()[]_-+=<>/*.,;:
+>* Image
+> * only png and jpeg are allowed
+>* Provider Homepage
+> * A-Z
+> * a-z
+> * .
+> * :
+> * @
+> * 0-9
+> * !
+> * &
+>* Email Contact
+> * A-Z
+> * a-z
+> * .
+> * :
+> * @
+> * 0-9
+> * !
+> * &
+>* Phone Contact
+> * +
+> * (
+> * )
+> * 0-9
+
+
+
+
+#### Step 3 - Terms & Conditions / Consent
+
+
+
+
+
+
+##### Implementation Details
+
+to be added
+
+
+
+
+##### API Details
+
+###### #1 ...
+Description
+
+```diff
+! endpoint
+```
+
+
+
+
+#### Step 4 - Tenant Concept and Integration
+
+
+
+
+
+
+##### Implementation Details
+
+to be added
+
+
+
+
+##### API Details
+
+###### #1 ...
+Description
+
+```diff
+! endpoint
+```
+
+
+
+
+#### Step 5 - Beta Test Runs
+
+
+
+
+
+
+##### Implementation Details
+
+to be added
+
+
+
+
+##### API Details
+
+###### #1 ...
+Description
+
+```diff
+! endpoint
+```
+
+
+
+
+#### Step 6 - Validate & Submit for Publishing check
+
+
+
+
+
+##### Implementation Details
+
+to be added
+
+
+
+
+##### API Details
+
+###### #1 ...
+Description
+
+```diff
+! endpoint
+```
+
+
+
diff --git a/developer/04. Apps/03. App Release Approval/01. App Approval Board Overview.md b/developer/04. Apps/03. App Release Approval/01. App Approval Board Overview.md
new file mode 100644
index 000000000..35f85a7b7
--- /dev/null
+++ b/developer/04. Apps/03. App Release Approval/01. App Approval Board Overview.md
@@ -0,0 +1,69 @@
+## App Approval Board
+
+The Page "App Approval Board" is accessible via the top main menu for CX Admins.
+
+The main focus / scope of the page is to enable the operator to manage apps releases for the CX marketplace.
+
+
+
+
+
+
+### #1 App Release Overview
+Display all apps under review as well as those which are approved.
+Endpoint is supporting pagination.
+
+
+```diff
+! GET: /api/apps/appreleaseprocess/inReview
+```
+
+
+
+Response Body
+
+ {
+ "meta": {
+ "totalElements": 0,
+ "totalPages": 0,
+ "page": 0,
+ "contentSize": 0
+ },
+ "content": [
+ {
+ "appId": "uuid",
+ "name": "string",
+ "provider": "string",
+ "status": "e.g. IN_REVIEW"
+ }
+ ]
+ }
+
+
+
+Details to the data mapping:
+
+
+
+
+
+#### Sorting
+
+
+
+
+Sorting by "Newest First": {hostname}/api/apps/AppReleaseProcess/inReview?page=0&size=15&sorting=DateDesc
+Sorting by "App Title A-Z": {hostname}/api/apps/AppReleaseProcess/inReview?page=0&size=15&sorting=NameAsc
+
+
+
+#### Views
+
+
+
+
+All: {hostname}/api/apps/AppReleaseProcess/inReview?page=0&size=15&sorting=DateDesc
+Request Only: {hostname}/api/apps/AppReleaseProcess/inReview?page=0&size=15&sorting=DateDesc&statusID=INREVIEW
+
+
+
diff --git a/developer/04. Apps/03. App Release Approval/02. App Details.md b/developer/04. Apps/03. App Release Approval/02. App Details.md
new file mode 100644
index 000000000..8278041bb
--- /dev/null
+++ b/developer/04. Apps/03. App Release Approval/02. App Details.md
@@ -0,0 +1,96 @@
+## App details
+
+For apps under release process and ready to get validated by the marketplace operator; the app details may get displayed to verify all details.
+To display the details the app data get displayed by clicking on the app card on the administrator board.
+
+
+
+
+
+
+
+
+
+### #1 Display App details
+
+
+
+```diff
+! GET /api/apps/{appId}
+```
+
+
+
+Response Body
+
+ {
+ "id": "uuid",
+ "title": "string",
+ "leadPictureId": "uuid",
+ "images": [
+ "uuid"
+ ],
+ "providerUri": "string",
+ "provider": "string",
+ "contactEmail": "string",
+ "contactNumber": "string",
+ "useCases": [
+ "string"
+ ],
+ "longDescription": "string",
+ "price": "string",
+ "tags": [
+ "string"
+ ],
+ "isSubscribed": "e.g. PENDING",
+ "languages": [
+ "string"
+ ],
+ "documents": {
+ "additionalProp1": [
+ {
+ "documentId": "uuid",
+ "documentName": "string"
+ }
+ ],
+ "additionalProp2": [
+ {
+ "documentId": "uuid",
+ "documentName": "string"
+ }
+ ],
+ "additionalProp3": [
+ {
+ "documentId": "uuid",
+ "documentName": "string"
+ }
+ ]
+ },
+ "privacyPolicies": [
+ "e.g. COMPANY_DATA"
+ ]
+ }
+
+
+
+
+> **Note**
+> Currently the app marketplace app details endpoint is used but will get replaced in R#3.1 with a own endpoint specificly for the functionality.
+
+
+
+
+### #2 Display Images
+
+App images displayed in the app detail page get fetched by using the image document id which is received via the endpoint '#1 Display App details'.
+The document id is send with the GET documents endpoint (see below) which is responding with the respective image file.
+
+
+
+```diff
+! GET: /api/apps/{appId}/appImages/{documentId}
+```
+
+
+
+
diff --git a/developer/04. Apps/03. App Release Approval/03. Approve App Release.md b/developer/04. Apps/03. App Release Approval/03. Approve App Release.md
new file mode 100644
index 000000000..995c69c9a
--- /dev/null
+++ b/developer/04. Apps/03. App Release Approval/03. Approve App Release.md
@@ -0,0 +1,30 @@
+## Implementation
+
+With the app release approval, the app is getting activated for the app marketplace.
+The approval is triggered by clicking on the approval icon inside the app card:
+
+
+
+
+
+
+
+### #1 Approve App Release
+The approve app release function is used to release an app which is in status "In Review" to the marketplace.
+
+With the approval the status of the app is getting updated to "ACTIVE" and the app provider (app manager) is getting informed about the successful release.
+
+
+```diff
+! PUT /api/apps/appreleaseprocess/{appId}/approveApp
+```
+
+
+
+With the approval of the app, the releaseDate is getting set => offers.released_date
+
+
+Details regarding the notification can get found in the notification service documentation: Notification Service
+
+
+
diff --git a/developer/04. Apps/03. App Release Approval/04. Decline App Release.md b/developer/04. Apps/03. App Release Approval/04. Decline App Release.md
new file mode 100644
index 000000000..5f1f1e591
--- /dev/null
+++ b/developer/04. Apps/03. App Release Approval/04. Decline App Release.md
@@ -0,0 +1,34 @@
+## App Decline Details
+
+The app release decline icon can get triggered by clicking on the decline icon inside the app card. Additionally to the cancellation, a message can get added which will get provided to the app manager(s) of the respective company.
+
+
+
+
+
+
+
+
+
+### #1 Decline App Release
+The decline app release function is used to reject apps and sending the them back to the status "CREATED" .
+
+With the rejection the app manager will receive an notification as well as an email regarding the rejection and rejection details via a message field.
+
+
+
+```diff
+! PUT /api/apps/{appId}/declineApp
+```
+
+
+
+Details regarding the notification can get found in the notification service documentation: Notification Service
+
+
+
+
+##### Email Example
+
+
+
diff --git a/developer/04. Apps/04. App Provider Management Board(s)/01. App Board.md b/developer/04. Apps/04. App Provider Management Board(s)/01. App Board.md
new file mode 100644
index 000000000..1088e8eed
--- /dev/null
+++ b/developer/04. Apps/04. App Provider Management Board(s)/01. App Board.md
@@ -0,0 +1,85 @@
+## App Board
+
+The Page "App Overview" is accessible via the top main menu for app providers.
+
+The main focus / scope of the page is to enable app providers to manage their apps under the release process, inside the marketplace or inactive apps, as well as starting the release process for a complete new app.
+
+The page includes following functions
+
+* search
+* filter
+* trigger app registration (link to be added)
+
+
+
+
+
+
+
+
+
+### #1 App Overview
+The app overview displays all apps provided by the company to which the user belongs.
+
+
+
+```diff
+! GET: /api/apps/provided
+```
+
+
+Response Body
+
+ [
+ {
+ "id": "uuid",
+ "name": "string",
+ "leadPictureId": "uuid",
+ "provider": "string",
+ "status": "e.g. CREATED",
+ "lastChanged": "2023-02-11T18:16:36.624Z"
+ }
+ ]
+
+
+
+Details to the data mapping:
+
+
+
+
+
+
+
+### #2 "Last Changed" Apps
+Last changed apps is showing the 4 apps latest changed.
+
+The function is only supported, if the company has more then minimum 6 apps. Otherwise this section does not exist.
+
+
+```diff
+! GET: /api/apps/provided
+```
+
+
+Response Body
+
+ [
+ {
+ "id": "uuid",
+ "name": "string",
+ "leadPictureId": "uuid",
+ "provider": "string",
+ "status": "e.g. CREATED",
+ "lastChanged": "2023-02-11T18:16:36.624Z"
+ }
+ ]
+
+
+
+Details to the data mapping:
+
+
+
+
+
diff --git a/developer/04. Apps/05. App-Subscription Kopie/App Subscription Request Management - IMPL.md b/developer/04. Apps/05. App-Subscription Kopie/App Subscription Request Management - IMPL.md
new file mode 100644
index 000000000..ea56854c6
--- /dev/null
+++ b/developer/04. Apps/05. App-Subscription Kopie/App Subscription Request Management - IMPL.md
@@ -0,0 +1,69 @@
+# Summary
+
+The Page "App Subscription Management" is accessible via the top main menu for app providers.
+
+The main focus / scope of the page is to enable app providers to manage their app subscriptions (active as well as requests)
+
+The page includes following functions
+
+* search
+* filter
+* trigger subscription activation
+
+
+
+
+Links:
+
+[Design](/docs/App(s)/Subscription-Management/Design.md)
+[FAQ](/docs/App(s)/Subscription-Management/FAQ.md)
+
+
+
+
+# Implementation
+
+### Function: View Subscriptions (Requests and Active)
+
+=> Requests: https://portal-backend.dev.demo.catena-x.net/api/Apps/provided/subscription-status?page=0&size=15&statusId=PENDING
+=> Active: https://portal-backend.dev.demo.catena-x.net/api/Apps/provided/subscription-status?page=0&size=15&statusId=ACTIVE
+
+
+
+
+### Function: Sorting
+
+=> By Customer A-Z: https://portal-backend.dev.demo.catena-x.net/api/Apps/provided/subscription-status?page=0&size=15&sorting=CompanyNameDesc
+=> By Offer: https://portal-backend.dev.demo.catena-x.net/api/Apps/provided/subscription-status?page=0&size=15&sorting=OfferIdAsc
+
+
+
+
+### #1 View Subscriptions
+The endpont shows all subscription requests and active subscriptions.
+
+
+Data mapping details:
+
+
+
+
+```diff
+! GET: /api/Apps/provided
+```
+
+
+
+
+
+### #2 Subscription Activation
+The app subscription activation is used to activate the customer app tenant. The endpoint can only get triggered if the app subscription is in sttaus "PENDING".
+By entering the tenant url, the client is getting registered inside the portal db and the catena-x idp.
+
+
+```diff
+! POST: /api/apps/autoSetup
+```
+
+
+
diff --git a/developer/04. Apps/05. App-Subscription Kopie/Subscription Flow - Implementation.md b/developer/04. Apps/05. App-Subscription Kopie/Subscription Flow - Implementation.md
new file mode 100644
index 000000000..949c5dff8
--- /dev/null
+++ b/developer/04. Apps/05. App-Subscription Kopie/Subscription Flow - Implementation.md
@@ -0,0 +1,86 @@
+## Implementation
+
+### #1 POST Subscribe Request
+
+The post subscribe request is triggered by the customer / interested company via the app marketplace "Subscribe" function.
+The request triggers a request to the app provider (via portal notifications and email).
+Via the subscribe request service, the app provider gets informed about the raised customer interest and can take the following actions to activate the app usage.
+
+
+Business Logic:
+With the POST api, the backend service will
+* create a record inside the company_assigned_apps table
+* status_id for the record will get set to "PENDING"
+
+
+
+```diff
+! POST /api/apps/{appId}/subscribe
+```
+
+
+
+
+### #2 Subscription Activation
+
+To activate a customer subscription request, the /autosetup endpoint is provided to autosetup the app client, create relevant technical users and activate the app for the customer.
+
+The activation will allow the customer company to assign the app user roles to existing user accounts. With the assigned roles, the respective users will find the app inside the "My Business App" feature on the home page.
+=> details to "My Business Apps" can be found here https://github.com/catenax-ng/tx-portal-assets/blob/b482f54b1601c61f957c898b045d43b6fa486818/docs/Marketplace(s)/HowTo-App-Marketplace.md
+
+
+Business Logic:
+* create app instance / client in central idp to enable tenant authentication/authorization
+* create app_subscription_details record with customer app tenant url
+* store app instance / client details inside the portal db
+* update the status of the 'company x appId' record insight the table offer_subscriptions to "ACTIVE"
+
+
+
+```diff
+! POST /api/apps/autoSetup
+```
+
+
+
+
+### #3 Manage (own) App Subscription
+Get Subscription Customer Endpoint is used to receive all the subscriptions which the company has subscribed for.
+
+Subscriptions with status PENDING, ACTIVE and INACTIVE will get distracted.
+
+
+
+```diff
+! GET /api/apps/subscribed/subscription-status
+```
+
+
+
+
+### #4 Manage App Subscriptions
+Get Subscription Provider Endpoint is used to receive all subscriptions or subscription requests of my offered apps.
+
+Subscriptions with status PENDING, ACTIVE and INACTIVE will get distracted.
+
+
+
+```diff
+! GET /api/apps/provided/subscription-status
+```
+
+
+
+
+### #4 Put Inactivate App Subscriptions
+
+text needed
+
+
+
+```diff
+! PUT /api/apps/{appId}/unsubscribe
+```
+
+
+
diff --git a/developer/04. Apps/06. App Change Process/App Deactivation.md b/developer/04. Apps/06. App Change Process/App Deactivation.md
new file mode 100644
index 000000000..aebb5769c
--- /dev/null
+++ b/developer/04. Apps/06. App Change Process/App Deactivation.md
@@ -0,0 +1,21 @@
+## Summary
+
+
+The app deactivation function allows users to easily and conveniently deactivate their app from the app marketplace. This feature gives users the power to control their own offers and allows them to easily stop or start offer whenever they like.
+
+
+
+## Implementation
+
+```diff
+PUT /apps/{appID}/deactivateApp
+```
+
+
+
+Request Body
+
+ n/a
+
+
+
diff --git a/developer/05. Service(s)/01. Service Marketplace/01. Service Marketplace.md b/developer/05. Service(s)/01. Service Marketplace/01. Service Marketplace.md
new file mode 100644
index 000000000..af3eb60fd
--- /dev/null
+++ b/developer/05. Service(s)/01. Service Marketplace/01. Service Marketplace.md
@@ -0,0 +1,101 @@
+## Service Marketplace
+
+The service marketplace is providing a list of services (such as consultancy but also datapsace services) to enable CX members to participate in the dataspace.
+
+Beside the generic list, services can get viewed in specific pre-configured views
+
+
+
+
+Links:
+
+* [Functional Description](/docs/05.%20Service(s)/Service%20Marketplace/01.%20Service%20Marketplace.md)
+* [FAQ](/docs/05.%Service(s)/01.%Marketplace/FAQ.md)
+
+
+
+
+## Implementation Details
+
+### #1 Search
+
+The search is front-end enabled currently.
+Means the whole search is acting on the front end loaded services.
+Its planned to change this as soon as a search engine is implemented.
+
+
+
+
+### #2 Filter
+
+Filters provide two different views which can get easily switched by the user
+
+
+
+ Endpoints
+ - for "Dataspace Service": {host/domain}/api/Services/active?page=0&size=15&serviceTypeId=DATASPACE_SERVICE
+ - for "Consultant Service": {host/domain}/api/Services/active?page=0&size=15&serviceTypeId=CONSULTANCE_SERVICE
+
+
+
+
+### #3 Sorting
+
+Sorting is enabled and works jointly with the filters
+
+ Endpoint
+ - ALL - Newest First: {host/domain}/api/Services/active?page=0&size=15&sorting=ReleaseDateDesc
+ - Dataspace Service - Newest First: {host/domain}/api/Services/active?page=0&size=15&sorting=ReleaseDateDesc&serviceTypeId=DATASPACE_SERVICE
+ - Consultant Service - Newest First: {host/domain}/api/Services/active?page=0&size=15&sorting=ReleaseDateDesc&serviceTypeId=CONSULTANCE_SERVICE
+
+ - ALL - Provider: {host/domain}/api/Services/active?page=0&size=15&sorting=ProviderDesc
+ - Dataspace Service - Provider: {host/domain}/api/Services/active?page=0&size=15&sorting=ProviderDesc&serviceTypeId=DATASPACE_SERVICE
+ - Consultant Service - Provider: {host/domain}/api/Services/active?page=0&size=15&sorting=ProviderDesc&serviceTypeId=CONSULTANCE_SERVICE
+
+
+
+
+### #4 Get all active services
+
+API is used to display the active services of the CX network based on the released services. If a service is under review or creation, the service wont show up in this view.
+Only those services in status "ACTIVE" are getting displayed.
+
+
+```diff
+! GET /api/services/active
+```
+
+
+Data Mapping View:
+
+
+
+
+API Response:
+
+ {
+ "meta": {
+ "totalElements": 0,
+ "totalPages": 0,
+ "page": 0,
+ "contentSize": 0
+ },
+ "content": [
+ {
+ "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
+ "title": "string",
+ "provider": "string",
+ "leadPictureUri": "string",
+ "contactEmail": "string",
+ "description": "string",
+ "price": "string",
+ "serviceTypeIds": [
+ "DATASPACE_SERVICE"
+ ]
+ }
+ ]
+ }
+
+
+
+
diff --git a/developer/05. Service(s)/01. Service Marketplace/02. Service Details.md b/developer/05. Service(s)/01. Service Marketplace/02. Service Details.md
new file mode 100644
index 000000000..74bd33bce
--- /dev/null
+++ b/developer/05. Service(s)/01. Service Marketplace/02. Service Details.md
@@ -0,0 +1,95 @@
+## Service Offer Details
+
+The service marketplace is providing a list of services (such as consultancy but also datapsace services) to enable CX members to participate in the dataspace. Via a click on the service card; the service offer details will get displayed.
+
+
+Beside the generic list, services can get viewed in specific pre-configured views
+
+
+
+
+Links:
+
+* [Functional Description](/docs/05.%20Service(s)/01.%20Service%20Marketplace/02.%20Service%20Details.md)
+* [FAQ](/docs/05.%Service(s)/01.%Marketplace/FAQ.md)
+
+
+
+
+## Implementation Details
+
+### #1 Get Service Offer Details
+
+When selecting an offered service, the service details are getting fetched.
+
+Data mapping logic:
+
+
+
+
+
+```diff
+! PUT Get /api/services/{serviceID}
+```
+
+
+
+ {
+ "id": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
+ "title": "string",
+ "provider": "string",
+ "contactEmail": "string",
+ "description": "string",
+ "price": "string",
+ "offerSubscriptionDetailData": [
+ {
+ "offerSubscriptionId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
+ "offerSubscriptionStatus": "PENDING"
+ }
+ ],
+ "serviceTypeIds": [
+ "DATASPACE_SERVICE"
+ ],
+ "documents": {
+ "additionalProp1": [
+ {
+ "documentId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
+ "documentName": "string"
+ }
+ ],
+ "additionalProp2": [
+ {
+ "documentId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
+ "documentName": "string"
+ }
+ ],
+ "additionalProp3": [
+ {
+ "documentId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
+ "documentName": "string"
+ }
+ ]
+ }
+ }
+
+
+
+
+
+### #2 Get Service Order Details
+
+When the user is accessing a service detail page and in case there are already active or pending subscriptions, the subscription status will show up below the "Subscribe" button.
+Details regarding active subscriptions will be included in the get service details endpoint.
+
+
+```diff
+! PUT Get /api/services/{serviceID}
+```
+
+
+Details on the UI implementation
+
+
+
+
+
diff --git a/developer/05. Service(s)/02. Service Release Process/01. Service Publish Process.md b/developer/05. Service(s)/02. Service Release Process/01. Service Publish Process.md
new file mode 100644
index 000000000..684b246f2
--- /dev/null
+++ b/developer/05. Service(s)/02. Service Release Process/01. Service Publish Process.md
@@ -0,0 +1,139 @@
+## Summary
+
+The service publish process is currently under creation and will be UI supported in release 3.1 or 3.2
+
+Till that, the service publication is only available via api endpoints. Users can trigger those endpoints to generate a new service. The service approval (which is needed to get the service published on the marketplace, needs to get triggered by the portal administrator)
+
+
+
+
+Links:
+
+* [Functional Description](/docs/05.%20Service(s)/01.%20Service%20Release%20Process/01.%20Release%20Flow.md)
+* [FAQ](/docs/05.%20Service(s)/01.%20Service%20Release%20Process/02.%20FAQ.md)
+
+
+
+
+## Implementation
+
+### #1 Create Service Offering
+
+Via create service offerings; service provider can initiate the service release process by creating the offer in an initial state (not yet ready for the marketplace offering)
+
+
+```diff
+! POST: /api/services/addservice
+```
+
+
+
+Request body:
+
+
+ {
+ "title": "string",
+ "price": "string",
+ "contactEmail": "string",
+ "salesManager": "uuid",
+ "descriptions": [
+ {
+ "languageCode": "e.g. de",
+ "longDescription": "string",
+ "shortDescription": "string"
+ }
+ ],
+ "serviceTypeIds": [
+ "e.g. DATASPACE_SERVICE"
+ ]
+ }
+
+Hints:
+* Sales Manager: uuid company user with role sales manager
+* LanguageCode: two digit language short code (e.g. en, de, jp, pt, etc.)
+* Service Type Ids: service type label (currently available: DATASPACHE_SERVICE & CONSULTING_SERVICE)
+
+
+
+
+### #2 Update Service Offering
+
+Service Providers are able to update their own service offering by calling the put endpoint.
+
+
+```diff
+! PUT: /api/services/{serviceId}
+```
+
+
+
+Request body:
+
+
+ {
+ "title": "string",
+ "descriptions": [
+ {
+ "languageCode": "e.g. de",
+ "longDescription": "string",
+ "shortDescription": "string"
+ }
+ ],
+ "serviceTypeIds": [
+ "e.g. DATASPACE_SERVICE"
+ ],
+ "price": "string",
+ "contactEmail": "string",
+ "salesManager": "uuid"
+ }
+
+
+
+
+### #3 Update Service Documentation / Additional Details
+
+Service Providers are able to update their own service offering by calling the put endpoint.
+
+
+```diff
+! PUT /api/service/updateappdoc/{serviceId}/documentType/{documentTypeId}/documents
+```
+
+
+
+Request body:
+
+
+ n/a
+
+
+
+Supported Document Types:
+* Only "Additional_Details" are allowed
+
+Service Pre-requisite:
+* Service needs to be under creations (Status: "CREATED")
+* Only those users belonging to the same company as under which the service was created are allowed to upload date
+
+Logic:
+With the document uplaod; a new data record inside the table documents is created and document is saved connected to the company to which the user belongs as well as to the actual offer for which the document was uplaoded (table: offer_assigned_document)
+Document status is "PENDING".
+
+
+
+
+### #4 Submit new Service Offering for release/publishing
+
+The endpoint is used to submit a service for release/publish validation by the operator of the marketplace.
+Services created by a company can get pushed to the "In Review" state of the service is owned by the company and all respective needed data inputs are filled.
+
+
+```diff
+! PUT /api/services/{serviceId}/submit
+```
+
+
+Please note, a notification will get created and is documented in the notification service documentation: Notification Service
+
+
+
diff --git a/developer/05. Service(s)/02. Service Release Process/02. Service Publish Approval.md b/developer/05. Service(s)/02. Service Release Process/02. Service Publish Approval.md
new file mode 100644
index 000000000..66acf27d9
--- /dev/null
+++ b/developer/05. Service(s)/02. Service Release Process/02. Service Publish Approval.md
@@ -0,0 +1,78 @@
+## Summary
+
+The service publish process is currently under creation and will be UI supported in release 3.1 or 3.2
+
+Till that, the service publication is only available via api endpoints. Users can trigger those endpoints to generate a new service. The service approval (which is needed to get the service published on the marketplace, needs to get triggered by the portal administrator)
+
+
+
+
+Links:
+
+* [Functional Description]()
+* [FAQ](/docs/05.%20Service(s)/01.%20Service%20Release%20Process/02.%20FAQ.md)
+
+
+
+
+## Implementation
+
+### #1 Approve Service Request
+
+A service publish request can get approved by an CX Admin.
+The approval will trigger the service publish on the marketplace, the service manager will get informed about the successful publishing of the service.
+
+
+```diff
+! PUT /api/service/{serviceId}/approveService
+```
+
+
+Please note, a notification will get created and is documented in the notification service documentation: Notification Service
+
+
+
+With the approval of the app, the releaseDate is getting set => offers.released_date
+
+
+
+
+### #2 Decline Service Request
+A service publish request can get declined by an CX Admin.
+The respective service which was declined is getting set back to the status "CREATED" and a message will get stored and submitted which holds the details regarding the decline reason.
+
+
+```diff
+! PUT /api/service/{serviceId}/declineService
+```
+
+
+Please note, a notification will get created and is documented in the notification service documentation: Notification Service
+
+
+
+Request body:
+
+
+ {
+ "message": "string"
+ }
+
+
+
+
+Details of the api logic/business logic
+
+* update status from "IN REVIEW" to "CREATED"
+* create a notification for the service provider about the decline details
+* Service Manager of the company will receive the notification (means, with the rejection of the service release, a notification for all the company related users with the role "Service Manager" of the offer "Portal" will get created)
+* Notification type: "SERVICE_RELEASE_REJECTION" (new notification type)
+* Notification topic "OFFER"
+* Notification content
+ * "ServiceName":"{add here the ServiceName from offer.name}",
+ * "OfferId":"{add here the ServiceName from offer.id}"
+ * "Message":"{decline reason}"
+* On top of the notification, the rejection details should also get send via email
+
+
+
diff --git a/developer/05. Service(s)/03. Service Subscription/01. Service Subscription.md b/developer/05. Service(s)/03. Service Subscription/01. Service Subscription.md
new file mode 100644
index 000000000..537c6d490
--- /dev/null
+++ b/developer/05. Service(s)/03. Service Subscription/01. Service Subscription.md
@@ -0,0 +1,97 @@
+# Summary
+
+Service purchasing is describing the subscribe/purchase process of an service inside the catena-x service marketplace.
+
+
+
+
+Links:
+
+[Design](/docs/Service(s)/Subscription/Service-Subscription.md)
+[FAQ](/docs/Service(s)/Subscription/FAQ.md)
+
+
+
+
+
+# Implementation
+
+### #1 Get Service Agreements
+
+When the user is requesting to subscribe a service, the service agreements show up which the user needs to "confirm".
+Via api, the agreements will get fetched from the backend to display them to the user.
+
+
+Data mapping:
+
+
+
+
+
+
+```diff
+! GET /api/services/serviceAgreementData/{serviceId}
+```
+
+Request Body
+
+
+ {
+ "agreementId": "uuid",
+ "name": "string"
+ }
+
+
+
+
+### #2 Post Subscription Request
+
+The post subscribe request is triggered by the customer / interested company via the app marketplace "Subscribe" function. The request triggers a request to the app provider (via portal notifications and email). Via the subscribe request service, the app provider gets informed about the raised customer interest and can take the following actions to activate the app usage.
+
+Business Logic: With the POST api, the backend service will
+
+* create consent agreements inside the consensts table
+* create a record inside the company_assigned_apps table
+* status_id for the record will get set to "PENDING"
+* if a autosetup url is configured; the service provider if will get triggered. Details to the service can get found here: Service Autosetup Interface
+
+
+```diff
+! POST /api/services/{serviceId}/subscribe
+```
+
+Request Body
+
+
+ [
+ {
+ "agreementId": "uuid",
+ "consentStatusId": "ACTIVE"
+ }
+ ]
+
+Important: all agreements need to get approved/confirmed; otherwise the endpoint will run on fail.
+
+
+
+
+### #3 Activate Subscription & Tenant
+
+For all tenant based services / apps, an endpoint is created where app/service provider can active the customer subscription by creating the relevant auth client and enables the customer to assign app roles to their users and login via SSO into the service.
+Additionally the interface will send a technical user with credentials to the respective service provider. With those credentials, the service provider can enable the AAS registration, DAPS and create the Self Description.
+
+
+```diff
+! POST /api/services/autoSetup
+```
+
+Request Body
+
+
+ {
+ "requestId": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
+ "offerUrl": "string"
+ }
+
+
+
diff --git a/developer/Technical Documentation/Architecture/Architecture Constraints.md b/developer/Technical Documentation/Architecture/Architecture Constraints.md
new file mode 100644
index 000000000..d62a0ebb8
--- /dev/null
+++ b/developer/Technical Documentation/Architecture/Architecture Constraints.md
@@ -0,0 +1,28 @@
+# Architecture Constraints
+
+## General
+
+* Homogenous UI/UX design across all user facing elements.
+
+* Run anywhere: can be deployed as a docker image, e. g. on Kubernetes (platform-independent, cloud, on prem or local).
+
+* Modular design: core-components are loosely coupled.
+
+* Freedom of choice for technology components stops where UX is negatively impacted. (currently under revision by the overall catena architecture roundtable)
+
+* Multi Language: German and english to be supported as a minimum
+
+## Developer
+
+* OpenSource software first - FOSS licenses approved by the eclipse foundation has to be used. It could represent the initial set that the CX community agrees on to regulate the content contribution under FOSS licenses.
+
+* Coding guidelines for FE and BE are defined and are to be followed for all portal related developments.
+
+* Apache License 2.0 - Apache License 2.0 is one of the approved licenses which should be used to respect and guarantee Intellectual property (IP).
+
+* Code Analysis, Linting and Code Coverage - Consistent style increases readability and maintainability of the code base. Hence, we use analyzers to enforce consistency and style rules. We enforce the code style and rules in the CI to avoid merging code that does not comply with standards.
+
+## Code analysis, linting and code coverage
+
+--comming soon---
+(Veracode; Eslinter, Sonarcloud, etc.)
diff --git a/developer/Technical Documentation/Architecture/Building block view.md b/developer/Technical Documentation/Architecture/Building block view.md
new file mode 100644
index 000000000..c8fea76f9
--- /dev/null
+++ b/developer/Technical Documentation/Architecture/Building block view.md
@@ -0,0 +1,15 @@
+# Building Block View
+
+The Portal as an overall product is a complex composition of several interacting solution building blocks, each comprised of a backend (including api and db) and frontend component, depicted in the following blackbox-illustration:
+
+
+
+Beyond this view, the portal allows for component integration of other (sub-products) that need to expose user-faced ui-functionality to the Catena-X community members (company and user level).
+
+Currently integrated (or in the process of being integrated) products are:
+
+* Semantic Hub
+* BPDM
+* Self-Description Factory
+* Clearing House / Gaia-X
+* Digital Twin Registry
diff --git a/developer/Technical Documentation/Architecture/Context and scope.md b/developer/Technical Documentation/Architecture/Context and scope.md
new file mode 100644
index 000000000..2df603e3e
--- /dev/null
+++ b/developer/Technical Documentation/Architecture/Context and scope.md
@@ -0,0 +1,8 @@
+# Content and Scope
+
+## Business Context
+Any uses-case, value stream, function within Catena-X can be exposed an accessed via the portal. It builds the foundation for x-company interaction and collaboration and further provides access to the overall value proposition of Catena-X.
+
+## Technical Context
+The provided components (see building block view) comprise the technical foundation for interaction, integration, authentication, authorization, provisioning, monitoring, auditing and further functionalities. They are state of the art in terms of technology portfolio, consist of open-source components whenever possible and are open-sourced themselves 100%.
+
diff --git a/developer/Technical Documentation/Architecture/Development Concept.md b/developer/Technical Documentation/Architecture/Development Concept.md
new file mode 100644
index 000000000..a561faf42
--- /dev/null
+++ b/developer/Technical Documentation/Architecture/Development Concept.md
@@ -0,0 +1,31 @@
+# Development Concept
+
+## Build, test, deploy
+Details to the build, test and deploy process can get found under following link/md file:
+https://github.com/catenax-ng/tx-portal-assets/blob/945546d91065b8870aa8f69ce94b48eac7a5ade2/docs/Release-Process.md
+
+
+
+## Development Guidelines
+The portal is using following key frameworks:
+
+* Javascript / React
+* .Net
+* i18n
+* Keycloak
+
+
+
+#### Swagger
+The API uses OpenAPI annotations to describe the endpoints with all necessary information. The annotations are then used to automatically generate the OpenAPI specification file, which can be viewed in the Swagger UI that is deployed with the application.
+
+
+
+## Migration
+To run the portal, migrations are needed to load the initial data inside the identity provider and the portal db to enable the portal to work.
+The migration will consist of an initial migration as well as delta migration files with future releases. As part of a new release, a migration file (if applicable) will get released and can get loaded via a delta load.
+
+
+
+## Configurability
+Portal configuration is mainly possible via the appsetting files as well as the static data migration files.
diff --git a/developer/Technical Documentation/Architecture/Requirements.md b/developer/Technical Documentation/Architecture/Requirements.md
new file mode 100644
index 000000000..1e36ec15b
--- /dev/null
+++ b/developer/Technical Documentation/Architecture/Requirements.md
@@ -0,0 +1,19 @@
+# Requirements overview
+
+## What is the Portal & Marketplace Product?
+
+The Portal & Marketplace Product combines 4 main components of the Catena-X core services:
+- Registration Front End
+- Portal & Marketplace Front End
+- Registration, Portal and Marketplace API services
+- Identity & Access Management
+
+## Requirements
+
+For Catena-X Member Companies
+|ID|Title|Requirement|
+|--------|--------|--------|
+|REQ-C-001|Easy Onboarding|Company Onboarding must be simple, transparent, reliable, and quick.|
+|REQ-C-002|BPN-Integration|Each member company is integrated with its global BPN the enable unified identification (also cross-network)|
+|REQ-C-003|Cross-Network|Companies already verified in other (supported/friendly) networks will receive fast-lane onboarding|
+|REQ-C-004|Identity Integration|Authentication is done vis IdP Federation to minimize administration overhead and to simplify logins. Authorization not included, this must be done Catena-X specific by the Central-IdP|
diff --git a/developer/Technical Documentation/Architecture/Solution strategy.md b/developer/Technical Documentation/Architecture/Solution strategy.md
new file mode 100644
index 000000000..9841b80ca
--- /dev/null
+++ b/developer/Technical Documentation/Architecture/Solution strategy.md
@@ -0,0 +1,6 @@
+# Solution Strategy
+
+* The technology portfolio and development stack are kept simple, based on commodity and oss components and products.
+* APIs are always REST-based with token authentication.
+* OIDC is used for authentication and authorization.
+* IaC is fully realized via helm charts.
diff --git a/developer/Technical Documentation/Architecture/Whitebox Overall System.md b/developer/Technical Documentation/Architecture/Whitebox Overall System.md
new file mode 100644
index 000000000..d07ee9b2e
--- /dev/null
+++ b/developer/Technical Documentation/Architecture/Whitebox Overall System.md
@@ -0,0 +1,42 @@
+# Whitebox Overall System
+
+
+## Summary
+
+
+
+
+
+## Contained Building Blocks
+
+### Portal
+
+Integration: Portal, Marketplace, Backend, Wallets, BPDM, SD Factory, AutoSetup, Discovery and more:
+
+
+
+
+### Registration (Company Onboarding)
+
+
+
+
+
+### Central IdP & Shared IdP
+
+
+
+
+
+
+
+
+### Marketplace
+
+
+
+
+
+### Important Interfaces
+
+*** to be added ****
diff --git a/developer/Technical Documentation/Architecture/operational-concept.md b/developer/Technical Documentation/Architecture/operational-concept.md
new file mode 100644
index 000000000..a6dedf243
--- /dev/null
+++ b/developer/Technical Documentation/Architecture/operational-concept.md
@@ -0,0 +1,30 @@
+# Operational concepts
+
+## Administration
+
+### Configuration
+The Portal can be configured using two methods:
+
+### appsettings.json
+If you build the Portal, you can modify the appsettings.json for each backend service, to individually configure to a certain extend. This file contains all possible config entries for the application.
+
+### Helm Chart
+The most relevant config properties are exposed as environment variables and must be set in the Helm chart so the application can run at all. Check the Portal Helm chart in Git for all available variables.
+
+### DB Migration File
+Static Data migration files provide a certain configuration possibility by adding or deleting static data records before the deployment. Be aware that touching static data files will always impact the application business process. It is suggested to always test the application with the planned changes carefully in INT before releasing to a productive env.
+
+## Disaster-Recovery
+Note: will be added soon
+
+## Scaling
+If the number of consumers raises, the IRS can be scaled up by using more resources for the Deployment Pod. Those resources can be used to utilize more parallel threads to handle Job execution.
+
+## Clustering
+Note: will be added soon
+
+## Logging
+The portal supports application and db logging. Details are stored here: https://github.com/catenax-ng/tx-portal-assets/blob/945546d91065b8870aa8f69ce94b48eac7a5ade2/docs/Technical%20Details/Auditing.md
+
+## Monitoring
+Note: Prometheus and Grafana are planned
diff --git a/developer/Technical Documentation/DB Views and Details/App - DB - View.md b/developer/Technical Documentation/DB Views and Details/App - DB - View.md
new file mode 100644
index 000000000..92b0e6bac
--- /dev/null
+++ b/developer/Technical Documentation/DB Views and Details/App - DB - View.md
@@ -0,0 +1,50 @@
+## App
+
+
+
+#### App DB Connection
+
+
+
+
+
+
+
+#### App Images
+2 different types of app images do exist
+
+- app lead picture (used for the marketplace app card)
+- app detail pictures (used for app details view)
+
+Images are handled inside the portal db. Via the documents table and offer_assigned_documents available app images can get loaded.
+
+Related Endpoints:
+- POST: /api/apps/appreleaseprocess/createapp
+- PUT: /api/apps/appreleaseprocess/{appId}
+- GET /api/apps/appreleaseprocess/{appId}/appStatus
+- GET: /api/apps/{appId}
+
+
+
+
+#### App Release Date
+
+with the activation of app/service the app release date is getting set
+
+Triggering Endpoints:
+PUT: /api/apps/appreleaseprocess/{appId}/approveApp
+
+The app release data is important for the app marketplace; only those apps with a release date in the past are getting displayed.
+With the app release date future scenarios such as: release app before publishing can get supported
+
+
+
+
+#### App Use Case
+
+app offers are aways use_case linked.
+Table relation use_cases - 1:m - app_assigned_use_cases - m:1 - offers
+
+
+
+
diff --git a/developer/Technical Documentation/DB Views and Details/Connector - DB - View.md b/developer/Technical Documentation/DB Views and Details/Connector - DB - View.md
new file mode 100644
index 000000000..93f577489
--- /dev/null
+++ b/developer/Technical Documentation/DB Views and Details/Connector - DB - View.md
@@ -0,0 +1,6 @@
+## Connector DB
+
+
+
+
+
diff --git a/developer/Technical Documentation/DB Views and Details/Documents - DB - View.md b/developer/Technical Documentation/DB Views and Details/Documents - DB - View.md
new file mode 100644
index 000000000..337324259
--- /dev/null
+++ b/developer/Technical Documentation/DB Views and Details/Documents - DB - View.md
@@ -0,0 +1,22 @@
+## Documents
+
+## Document DB Connection
+
+Documents are managed inside the postgresql db.
+
+Mainly 4 tables are used for the documents itself
+
+* documents
+* document_types
+* document_status
+* offer_assigned_documents
+* agreement_assigned_documents
+
+
+
+
+
+
+
+
+Details to the documents service implementation can get found [here](/developer/Technical%20Documentation/Services/Document_Management.md#summary)
diff --git a/developer/Technical Documentation/DB Views and Details/Subscription - DB - View.md b/developer/Technical Documentation/DB Views and Details/Subscription - DB - View.md
new file mode 100644
index 000000000..8407455df
--- /dev/null
+++ b/developer/Technical Documentation/DB Views and Details/Subscription - DB - View.md
@@ -0,0 +1,27 @@
+## Subscription
+
+### Subscription DB Connection
+
+
+
+
+
+
+#### Difference Offer_Subscription and App_Subscriptionn_Details
+
+The offer_subscription table is holding all subscription requests; active subscriptions as well as inactive subscriptions.
+When a user is triggering the subscription request for anything on the marketplace; the request/record will get saved inside the offer_subscription table.
+
+The app_subscription_details table is only used when an app subscription request is getting activated. In that case; the app subscription details (such as the tenant url) is getting stored inside this table.
+Endpoints such as "My Busines Application" are using those details to provide the right tenant/url to the respective user.
+
+
+
+
+#### Display Name
+
+Currently not used but will be needed in future as preparation for multi tenant subscription/purchasing.
+Planned release 3.2
+
+
+
diff --git a/developer/Technical Documentation/Dev Process/01. Development-Deployment (CI-CD).md b/developer/Technical Documentation/Dev Process/01. Development-Deployment (CI-CD).md
new file mode 100644
index 000000000..4072fc32a
--- /dev/null
+++ b/developer/Technical Documentation/Dev Process/01. Development-Deployment (CI-CD).md
@@ -0,0 +1,7 @@
+## Development / Deployment (CI/CD)
+
+
+
+
+
+
diff --git a/developer/Technical Documentation/Dev Process/02. How to contribute.md b/developer/Technical Documentation/Dev Process/02. How to contribute.md
new file mode 100644
index 000000000..853423df2
--- /dev/null
+++ b/developer/Technical Documentation/Dev Process/02. How to contribute.md
@@ -0,0 +1,60 @@
+## Contribution details
+
+
+If you are not a a Team Member, the contribution to the portal code is still possible by using the Eclipse Fork function.
+
+Below you can find the detailed "how to" for contribution
+
+
+
+### #1 Login
+
+Login or register to eclipse. If you dont have an Github/eclipse user yet, please create a new account by using he "Sign up" function.
+
+
+
+
+
+### #2 Open the repo
+
+Use the top right search to get to the repository to which you want to contribute
+
+
+
+
+
+### #3 Create a fork
+
+Open the repo and create a fork of the repo (top right menu)
+
+
+
+
+
+### #4 Fork setup
+
+Setup the fork name and make sure that you unselect the "main branch only" selection
+
+
+
+Click "Create fork"
+
+
+
+### #5 Fork work & commit
+
+ With your own fork, you can now start to contribute by creating a new branch (see info below) and start to implement the planned changes or develop new features.
+
+ Info:
+
+ * Branch naming should follow the naming convention => “{Ticketnumber}-{short summary}”
+ * Ideally pre-discuss with the respective team from which original branch your own branch should get created from.
+
+
+ As soon as you are done, commit your change in your own branch and create a pull request against the original repository "DEV" branch.
+
+ Now, wait for the original repo owners to validate your pr and work on fix review comments as well as possible sonar or auto security/quality check findings.
+
+
+
+ As soon as all issues are solved, the repo owners will approve and merge the pr.
diff --git a/developer/Technical Documentation/Dev Process/Enumeration Handling.md b/developer/Technical Documentation/Dev Process/Enumeration Handling.md
new file mode 100644
index 000000000..67307de0b
--- /dev/null
+++ b/developer/Technical Documentation/Dev Process/Enumeration Handling.md
@@ -0,0 +1,68 @@
+## Enumeration
+
+Enum or enumeration are used for data type consisting of named values like elements, status workflow, types, etc., that represent integral constants. Enums are non-transactional (so called static data) which can only get changed in a new application version. Changes in the operation mode of an application are not allowed since this will result into possible system breaks.
+
+List of used enums in the portal application
+
+* agreement_categories
+* application_checklist_statuses
+* application_checklist_types
+* audit_operation
+* bpdm_identifiers
+* company_application_statuses
+* company_service_account_statuses
+* company_service_account_types
+* company_statuses
+* company_user_statuses
+* connector_statuses
+* connector_types
+* consent_statuses
+* document_status
+* document_types
+* identity_provider_categories
+* invitation_statuses
+* notification_topic
+* notification_type
+* offer_statuses
+* offer_subscription_statuses
+* offer_types
+* privacy_policies
+* process_step_statuses
+* process_step_types
+* service_types
+* unique_identifiers
+
+
+
+
+### Add Enums
+
+New enums can get added easily be enhancing the enumeration table (via the seeding data). With the next deployment; the new enum is getting auto deployed to the respective env.
+Since enums have an enhanced impact on the system functionality; it is mandatorily needed to test (FE wise) the impacted screens / flows before releasing new enums. It is likely that the enum has an enhanced impact on the user journey / flow and break the system if not well tested.
+
+
+
+
+### Change Enums
+
+Change of enums (labels) is possible but need to be done carefully and only if necessarily needed.
+In the case a change is getting executed; the system configuration / appsettings / env. variables need to get checked to ensure that those dont refer to the enum which is getting changed/ updated.
+Same applies to frontend and backend logic. Both might refer to the enum label and will automatically fail when an enum value is getting changed.
+
+
+
+
+### Delete Enums
+
+Deletion of enums have following impacts
+
+* Seeding data update needed (likely data need to get deleted / changed)
+* Data inside the database in the different running environments need to get updated
+* User flow process impacted
+* Backend business logic impacted
+* Frontend business logic impacted
+
+It is not recommended to delete enums; instead .......... to be updated; we need to define how enums can / should get changed if needed
+
+
+
diff --git a/developer/Technical Documentation/Dev Process/Multi Language.md b/developer/Technical Documentation/Dev Process/Multi Language.md
new file mode 100644
index 000000000..45aafe4da
--- /dev/null
+++ b/developer/Technical Documentation/Dev Process/Multi Language.md
@@ -0,0 +1,47 @@
+# Multi Language
+
+## Summary
+Multi-Language support is planned for the Portal and Registration App in two languages
+
+* English
+* German
+
+
+The multi language function is mainly implemented on front-end side via i18next.
+
+I18next is an internationalization-framework for react and ideal to support multi language function in web applications.
+
+
+
+i18next provides following add-ons:
+* detect the user language
+* load the translations
+* optionally cache the translations
+* extension, by using post-processing - e.g. to enable sprintf support
+
+=> get more details (https://www.i18next.com/overview/plugins-and-utils)
+
+
+
+
+
+## Technical Implementation
+
+### Portal-Registration
+
+There is a locales folder in src which contains subfolders according to respective language codes as shown in the screenshot shared, like 'de'(German), 'en'(English). These folders contain the translation.json file used for translations.
+
+
+
+We can add additional translation files if needed for any additional language.
+
+
+
+### CX-Portal
+
+Inside the CX Portal, the locales are divided by pages.
+
+
+
+There is one main file holding the generic translation for often used items (e.g. "approval button", headlines,...) and a file for each specific page to translate not often used values.
+
diff --git a/developer/Technical Documentation/Identity & Access/01. Introduction.md b/developer/Technical Documentation/Identity & Access/01. Introduction.md
new file mode 100644
index 000000000..afbd01722
--- /dev/null
+++ b/developer/Technical Documentation/Identity & Access/01. Introduction.md
@@ -0,0 +1,27 @@
+## Identity & Access Management
+
+### As-Is Authentication Management
+
+
+
+Authentication Flow - User login to Catena-X
+
+
+
+
+
+
+*(Schatten-) User: The „Schatten-User“ is defined as an empty User frame holding limited information. The actual user is managed in the respective Identity Provider.
+The Schatten-User are always federated identities
+
+
+
+
+### Authentication Protocol - OpenID Connect (OIDC)
+
+
+
+
+
+
+
diff --git a/developer/Technical Documentation/Identity & Access/02. Generic Setup.md b/developer/Technical Documentation/Identity & Access/02. Generic Setup.md
new file mode 100644
index 000000000..b13177daf
--- /dev/null
+++ b/developer/Technical Documentation/Identity & Access/02. Generic Setup.md
@@ -0,0 +1,142 @@
+## Generic Setup
+
+### Identity Provider
+
+#### Requirement
+
+- [x] Identity Providers are configured on CX-Central Realm level only
+- [x] Identity Providers are Azure Active Directory, WebEAM, SAP, Amazon,...
+- [x] Default Protocol used is OIDC
+- [x] Users getting authenticated by an identity provider should only be able to login to the CX Services if a user in Keycloak is available
+- [ ] ...
+
+
+
+
+#### What's a Keycloak identity provider
+An Identity Broker is an intermediary service connecting service providers with identity providers. The identity broker creates a relationship with an external identity provider to use the provider’s identities to access the internal services the service provider exposes.
+
+From a user perspective, identity brokers provide a user-centric, centralized way to manage identities for security domains and realms. You can link an account with one or more identities from identity providers or create an account based on the identity information from them.
+
+An identity provider derives from a specific protocol used to authenticate and send authentication and authorization information to users. It can be:
+
+* A social provider such as Facebook, Google, or Twitter.
+* A business partner whose users need to access your services.
+* A cloud-based identity service you want to integrate.
+
+Typically, Keycloak bases identity providers on the following protocols:
+
+* SAML v2.0
+* OpenID Connect v1.0 ![Tag](https://img.shields.io/static/v1?label=&message=CATENA-X-Standard&color=green&style=flat)
+* OAuth v2.0
+
+
+
+
+
+
+#### Brokering overview
+When configuring Identity Providers in Keycloak, Keycloak does not force users to provide their credentials to authenticate in a specific realm.
+Keycloak displays a list of identity providers from which they can authenticate.
+
+
+
+If you configure a default identity provider, Keycloak redirects users to the default provider. For Catena-X, this is not necessary.
+
+
+
+
+#### (Change) Identity Provider Display Name
+The Identity Provider display name can geht changed by the operator without any negative impact.
+The change should still only get executed if necessarily needed. The change is resulting into a new IdP Button Name on the application login side.
+
+
+
+
+#### Delete Identity Provider
+There are a few different scenarios where the deletion of a identity provider within keycloak might be needed.
+
+* Company wants to move back to Shared CX IdP (currently not supported)
+* Company is off-boarding from Catena-X
+* Company is changing the company IdP internally (UI supported; no intervention by the platform operator needed)
+* Identity Provider link to Shared IdP is not needed anymore (UI supported; no intervention by the platform operator needed)
+
+
+
+More details regarding the function flow of deleting idp's can get found here: [Get there](/docs/02.%20Technical%20Integration/02.%20Identity%20Provider%20Management/04.%20Delete%20Identity%20Provider.md)
+
+
+
+
+### Realms
+
+> **Note**
+> Realms dont get much detailed explained; since it is not planned that they are manually created; all realm related services are automated.
+
+#### Requirement
+
+- [x] Realm is created for each registration company
+- [x] Realms are created inside the Shared IdP only; the Central IdP only holds the realms of the platform operator
+- [x] A realm hold the user data of a company (kind of tenant management)
+- [x] Roles and Groups are not managed on realm level
+- [ ] ...
+
+
+
+
+#### Realm Emails
+Keycloak can send emails to users for several different scenario
+
+* to verify the user email address
+* to recreate a password in case it was forgotten
+* or when an administrator needs to receive notifications about a server event
+
+
+To enable Keycloak to send emails, SMTP server settings need to get configured by following steps:
+* Login to the respective Keycloak instance and open the relevant realm
+* Click Realm Settings in the menu.
+* Click the Email tab.
+* Fill in the fields and toggle the switches as needed.
+
+
+
+> **Note**
+> The email realm config is automatically taking place when a realm is getting created; no manual adjustments needed. However the config of the email service attributes is needed via the env. var files.
+
+
+###### Host
+SMTP server hostname used for sending emails.
+
+
+###### Port
+SMTP server port.
+
+
+###### From
+Address used for the From SMTP-Header for the emails sent.
+
+
+###### From Display Name
+Allows to configure a user friendly email address aliases (optional). If not set the plain From email address will be displayed in email clients.
+
+
+###### Reply To
+Reply To denotes the address used for the Reply-To SMTP-Header for the mails sent (optional). If not set the plain From email address will be used.
+
+
+###### Reply To Display Name
+Reply To Display Name allows to configure a user friendly email address aliases (optional). If not set the plain Reply To email address will be displayed.
+
+
+###### Envelope From
+Envelope From denotes the Bounce Address used for the Return-Path SMTP-Header for the mails sent (optional).Enable SSL and Enable StartTSLToggle one of these switches to ON to support sending emails for recovering usernames and passwords, especially if the SMTP server is on an external network. You will most likely need to change the Port to 465, the default port for SSL/TLS.
+
+
+###### Enable Authentication
+Set this to ON if your SMTP server requires authentication. When prompted, supply the Username and Password.
+
+
+
+
+
+
diff --git a/developer/Technical Documentation/Identity & Access/03. Clients.md b/developer/Technical Documentation/Identity & Access/03. Clients.md
new file mode 100644
index 000000000..06dd05d0d
--- /dev/null
+++ b/developer/Technical Documentation/Identity & Access/03. Clients.md
@@ -0,0 +1,119 @@
+## Clients
+
+
+### Overview Clients
+Clients are entities that can request Keycloak to authenticate a user. Most often, clients are applications and services that want to use Keycloak to secure themselves and provide a single sign-on solution.
+
+Clients can have 3 different client types
+
+* public (For client-side clients that perform browser logins. As it is not possible to ensure that secrets can be kept safe with client-side clients, it is important to restrict access by configuring correct redirect URIs)
+* confidential (For server-side clients that perform browser logins and require client secrets when making an Access Token Request. This setting should be used for server-side applications)
+* bearer-only (The application allows only bearer token requests. When turned on, this application cannot participate in browser logins)
+
+
+
+
+### Client Creation
+
+clients are created with the portal & marketplace services:
+* App Services
+* Service Services
+
+Manual creation of clients is not expected/needed
+
+
+
+
+### Initial Client Load
+
+In the initial system deployment/data load provided by the catena-x migration script, the relevant core clients are included.
+
+
+
+
+
+
+
+### Client Authentication Concept
+
+** example DFT / SDE **
+
+The DFT (Data Format Transformer) is planned to get offered as a data provider essential services, hosted/operated by 3rd party service providers.
+
+In the design of the authentication flow, it was analyzed which authentication flows are available and how do they differ.
+
+
+
+Two main scenarios are possible and shown in the picture below
+
+* One Central DFT Client Registration for all costumer
+* Multiple Central DFT Client Registration, each customer one registration
+
+
+
+
+
+
+
+
+
+In the chapter/details both scenarios are detailed.
+
+##### Scenario 1 - Only one DFT Client - one for all customer
+
+
+In the example of one DFT registrations for all customer, following tasks are necessary.
+
+Whenever a new customer is approaching a service provider for a DFT instance, the service provider needs to request the enhancement of the allowed redirect URIs from the central portal instance.
+
+Additionally, no additional effort is needed on the portal side.
+
+
+
+For the authentication the result would look the following:
+
+Below a picture is added with the user JWT token (used for authentication). Green highlighted the identical section and yellow highlighted the difference
+
+
+
+
+
+
+
+
+
+Summary: in this scenario the difference of user of company 1 and user of company 2 is only the organisation and bpn tag. Everything else is identical and cant get used to ensure that users of company 1 are not able to access the dft instance of company 2.
+
+
+
+Security: MEDIUM
+
+
+
+
+##### Scenario 2 - Multiple DFT Clients - one for each customer
+
+Instead of Scenario 1 "one app registration for all tenants" - Scenario 2 is focusing on a tenant-specific authorization setup. With that, the operator of the app can distinguish the assigned roles on a tenant basis. In the following figure, you can see that there is a specific section of roles for each tenant. With this setup, a user can only access the tenant to which he actually has roles assigned. If the user gets a link to a tenant of a different customer he will get a not authorized error. There is no Catena-X specfic check based on the bpn necessary.
+
+
+
+
+
+
+
+
+
+Summary: the user of company 1 will only retrieve jwt token roles/client attributes for the DFT Instance 1. The user of company 2 only receives a JWT token roles/client attributes for DFT instance 2. In case the user is trying to login to another DFT Instance, a JWT token will get created, but the section
+
+
+
+..wont be existing
+
+
+
+Security: HIGH
+
+
+
+
+
diff --git a/developer/Technical Documentation/Identity & Access/03. User Management.md b/developer/Technical Documentation/Identity & Access/03. User Management.md
new file mode 100644
index 000000000..63c50f881
--- /dev/null
+++ b/developer/Technical Documentation/Identity & Access/03. User Management.md
@@ -0,0 +1,73 @@
+## User Management
+
+We differenciate between real users and technical users (aka service accounts).
+Both scenarios are completly automated / FE supported. There is no necessarity to setup/configure users in keycloak directly.
+
+Evenmore it should get prohibited to create users via the keycloak admin console; reason: those users would be missing in the portal db since there is no snychronization back to the portal db. This would result into an internal service issue.
+When using the available services for real and technical user creation; the issue wont appear since portal will create first of all the relevant user accounts in the portal db and afterwards create the same in keyloak.
+With help of the portal db table iam_users; the user id in keycloak central idp (user_entity_id) and the user id inside the portal (company_user_id) are linked.
+For service accounts the mapper is the service account clientId.
+
+
+
+
+
+
+### Technical User
+For the type of technical (non-human) users, service accounts are to be used.
+
+Service accounts differ from normal user accounts in multiple ways:
+
+* They don't have a password and can't be used for browser-based sign-in.
+* They're created and managed as a user that belongs to a client.
+* How to setup technical user authentication
+* The service account should have it's own client.
+
+Each OIDC client has a built-in service account which allows it to obtain an access token. This is covered in the OAuth 2.0 specifiation under Client Credentials Grant. To use this feature the Access Type of your client is set to confidential.
+
+
+
+
+#### Role Management
+The technical user relevant roles are managed within a shadow client called "technical-user-management".
+
+All composite roles available for technical user creation inside the portal are configured in this area.
+
+Additionally, the role need to be available inside the portal db - user_roles.
+
+
+
+
+### User Attributes
+
+All users can get specific user attributes added - currently the following attributes are supported / implemented
+
+* bpn-mapper
+* username-mapper
+
+
+
+
+#### bpn-mapper
+
+The Business Partner Number (BPN) is a verified company credential which is getting added as attribute to each user inside the network.
+
+The bpn provides an extended user authentication possibility.
+
+
+
+How is the attribute added to the user
+
+ * Option1: With the registration approval: with the registration, a user is invited without the company/bpn connection. The actual confirmation of user / BPN mapping will only take place with the registration approval => if the company registration is getting approved, a backend service is calling the function to add the company BPN to the respective user
+ * Option 2: Automatically added with the user invite/creation: the IT Administrator is adding one or multiple users to the CX network. By doing so, the user accounts get created => as part of this flow, the newly created user(s) should get a user attribute added which is the same as the Company BPN from the table "company"
+ * Option 3: Manual added, by permission (via the user management permission "add user"): by opening the user admin account inside the portal, the administrator can add another BPN to the user account. Currently without any limitations. However there is the plan to limit the functionality and to restrict the BPNs which can get selected / added by the admin
+
+
+#### username-mapper
+
+Is handling the username created for each user account inside the central idp.
+{idpalias}+uuid
+
+
+
+
diff --git a/developer/Technical Documentation/Identity & Access/04. Authentication Configuration.md b/developer/Technical Documentation/Identity & Access/04. Authentication Configuration.md
new file mode 100644
index 000000000..3baf9a446
--- /dev/null
+++ b/developer/Technical Documentation/Identity & Access/04. Authentication Configuration.md
@@ -0,0 +1,4 @@
+## Authentication Configuration
+
+---- will get added ----
+
diff --git a/developer/Technical Documentation/Identity & Access/05. Roles & Rights Concept.md b/developer/Technical Documentation/Identity & Access/05. Roles & Rights Concept.md
new file mode 100644
index 000000000..e88829204
--- /dev/null
+++ b/developer/Technical Documentation/Identity & Access/05. Roles & Rights Concept.md
@@ -0,0 +1,258 @@
+## 1. General details
+
+
+### 1.1 Scope and binding force of the document
+
+The Roles & Rights concept is part of the System Implementation for Catena-X. It specifies the roles, authorizations and controls which must be implemented in Catena-X.
+
+The Roles & Rights Concept aims at providing a high-level description with respect to the planning and implementation of roles and rights in the context of Catena-X. The Roles & Rights concept is supposed to define required functions, structures and basic principles. Therefore only an illustrative description of specific roles and associated rights is provided. This concept document is high level description of the implemented roles and rights. However, the included roles and rights give a sufficient representation of the relevant functions, structures and principles.
+
+
+### 1.2 Affected application
+
+Registration // Portal // Managed Wallet // DFT // BPDM
+
+
+
+
+### 1.3 Referenced documents
+
+n/a
+
+
+
+
+## 2. Authorization structure and role model
+This chapter explains the business, organizational, and technical principles of the role and authorization definition, thereby illustrating the relationship between business function and authorization structure. The objective is to make the actual authorizations and authorization assignments granted in the new Catena-X solution verifiable against the business, technical, and organizational specifications, specified in this document.
+
+
+
+### 2.1 Underlying business processes and roles:
+n/a
+
+
+
+
+### 2.2 Basic principles
+n/a
+
+
+
+
+### 2.3 Individual privileges and authorization framework
+n/a
+
+
+
+
+### 2.4 Role definition
+In the concept of the roles and rights management we are differentiating between roles and permissions.
+
+Permissions are the lowest level which a user can have. Several permissions are collected to a role.
+
+The assignment of rights to an actual user is happening on the role level itself.
+
+
+
+It is suggested to setup naming convention for roles and permissions to ensure that they can get clearly defined.
+
+On the CX Portal side the conventions are setup the following *please note that this is not mandatorily needed to be followed by 3rd Party Providers
+
+
+
+ Naming Convention:
+
+ - Permissions
+ - always lowercase
+ - no spaces, only use underscore
+ - task/role needs to be clearly understandable
+ - don't use any "Umlaute" (special character) such as: ä, ü, ö
+ - a permission can get assigned to several roles, but one is the minimum role to which it need to be assigned
+
+
+ Roles:
+
+ - capital letters to be used for 1st character
+ - spaces are allowed
+ - role should be identifiable
+ - don't use any "Umlaute" (special character) such as: ä, ü, ö
+ - a role needs as a minimum 1 permission assigned to it
+
+
+
+
+### 2.5 Role/Permission Matrix
+This role concept covers all roles related to
+
+- Registration/Onboarding Process Roles
+- Portal Roles
+
+
+
+
+
+
+
+
+
+#### 2.5.1 Technical User (portal internal)
+
+
+
+
+
+
+#### 2.5.2 Registration Application
+
+
+
+
+
+
+#### 2.5.3 Portal Application
+
+
+
+
+
+
+
+
+#### 2.5.3b Technical User Accounts
+
+
+
+
+
+
+#### 2.5.4 Managed Wallets
+
+
+
+
+
+*depending on the need, technical user will have a subset of the selected roles in the role table "Managed Wallets".
+
+For example:
+
+* SD Hub: view and update wallets
+* Portal: view and add wallets
+* EDC Extension: view and update wallet (technical user needs BPN as user attribute)
+
+
+
+
+#### 2.5.5 BPDM
+
+
+
+
+
+
+#### 2.5.6 BPDM Gate
+
+
+
+
+
+
+#### 2.5.7 BPDMShare
+no roles
+
+Note regarding the role setup in context of CPLP-121 - Registration App: Invite additional Registration Participants (FE/BE) CLOSED :
+
+* the inviting party needs to have the role "manage users" to be able to create users
+* the invited party needs to have the role "view users" to be able to see the own roles in the upper right corner of the registration portal
+Note regarding the role setup in context of CPLP-225 - Registration Service - Add Users: Roles to be fetched from Keycloak CLOSED :
+
+The user needs to have the role "view clients" to be able to see the available composite roles in the dropdown. Also, the user needs to have the role "view users" to be able to see the own composite roles in the upper right corner of the registration portal.
+
+Long term solution: a concept needs to be defined and implemented for technical identities (backend services which gather the composite roles should be executed with technical users, not require the user to have elevated rights).
+
+
+
+
+### 2.6 Segregation of duties
+Segregation of duties is the concept of having more than one person or role required to complete a task. Currently there is no such scenario inside the portal existing.
+
+
+
+
+## 3. Global subjects
+This chapter explains how the Catena-X Platform is embedded into the Business Partner application landscape and what infrastructure components are connected to it in terms of authorization management. Furthermore, technical restrictions, naming conventions, audit logging and the authentication mechanisms are outlined in more detail.
+
+
+
+
+### 3.1 Authorization management connections
+Authorization management is handled in CX central IdP.
+
+
+
+
+### 3.2 Used infrastructure components
+-
+
+
+
+
+### 3.3 Privileged and technical user accounts
+Technical users are used for backend to backend connections. Inside CX but also outbound between member companies and CX components.
+
+E.g. Central registry connection by a third party app.
+
+
+
+
+### 3.4 Technical restrictions
+For a detailed description of how the internal security system works please refer to Security Concept. In terms of the Catena-X Platform, this approach brings the following technical restrictions:
+
+A new login is required for user rights changes to take effect
+The fact that the rights for a particular user are only read at user login and then cached for the session implicates, that changes to rights can only take effect after a new user login.
+
+
+
+
+
+### 3.5 Logging the use
+Logging actions that can lead to granting or revocation of authorizations must observe the legal privacy specifications. Access to the logs is restricted. This is allowed only if there is legitimate interest and if it is according to the legal regulations for privacy.
+
+For the Catena-X Platform, there are three types of logging the use:
+
+System internal audit history
+
+System external monitoring system
+
+System technical server logs
+
+Internal audit history, an on screen audit record is available for key screens. This functionality is restricted to particular roles (see section 2.5). The following information can be viewed tabular within the System:
+
+..
+
+
+
+
+All internal audit and access logs are saved ???. The retention period for audit history is 7 years. After this period the audit history can be deleted, however this is not mandatory in legal terms.
+
+Finally, each infrastructure component and all surrounding systems have their own logging solutions in use. This includes the logging of grants and revoked of user access rights in the central BMW access management system. However, details on these technical logging solutions are out of scope for the Roles & Rights concept.
+
+
+
+
+## 4. Authorization procedure
+User permission / access withdrawal are possible via
+
+* Company IT Admin is able to withdraw user rights/permissions
+* Company IT Admin can delete company users under the same org
+* Company User can delete his/her own user account
+* App provider can withdraw app usage for a company, but not for a single user
+
+
+
+
+## 5. Appendix
+
+
+
+
+
diff --git a/developer/Technical Documentation/Identity & Access/06. Password Policy.md b/developer/Technical Documentation/Identity & Access/06. Password Policy.md
new file mode 100644
index 000000000..670291714
--- /dev/null
+++ b/developer/Technical Documentation/Identity & Access/06. Password Policy.md
@@ -0,0 +1,148 @@
+# Password Policy
+
+## Password Policy
+Password Policies are restrictions and/or requirements that a user must follow to ensure that their password is strong/secure.
+In Keycloak, password policies are set per realm.
+
+
+
+Requirement
+
+- [ ] Default Password Policies are needed for every realm - the policies are set by Catena-X and identical for all realms
+- [ ] Password refresh every 90 days
+- [ ] Password length 15+ digits
+- [ ] Password characters: letters + minimum 1 number is mandatory
+- [ ] Password shouldn't be the same as the username or email
+- [ ] If the Password is getting reset by the user and is not fitting the password policies, a error message with a detailed error code will get shown
+
+
+
+
+#### How to configure Password Policies
+
+Open Keycloak admin page, go to "Authentication" and open the "Password Policy" tab.
+Click on the Add policy … to see the list of available password policies.
+
+
+
+
+Select the relevant policy and set the policy value by adding the relevant number. Important: only numbers are to be added, no letters.
+After saving the policy, Keycloak login enforces the policy for new users. Existing users can still login with theire old password, but as soon as a password change request is getting triggered the new policies will take affect.
+
+Blacklisting passwords is possible via UTF-8 file, for Catena-X no blacklisting is planned so far.
+
+
+
+
+#### Implementation
+
+Password Policies are auto set (as per the definition mentioned above) for each company tenant.
+With the new creation of an company tenant; the password policies are automatically configured for the respective realm inside the sharedIdP.
+
+
+
+##Password Reset
+
+If Password reset is enabled, users are able to reset their credentials if they forget their password or lose their OTP generator.
+
+Requirement
+- [ ] Forgot Password option should be available for all users using Shared IdP
+- [ ] New Password needs to get validated against the configured Password Policies
+- [ ] Config needs to get automatically set whenever a new realm is getting created
+
+
+
+#### How to configure Password Recovery
+
+Go to the Realm Settings left menu item, and click on the Login tab. Switch on the Forgot Password switch.
+
+
+
+
+
+The new password will get send via email.
+
+The email text is fully configurable. How: extend or edit the theme associated with it.
+
+When the user clicks on the email link, they will be asked to update their password, and, if they have an OTP generator set up, they will also be asked to reconfigure this as well. Depending on the security requirements of your organization you may not want users to be able to reset their OTP generator through email. You can change this behavior by going to the Authentication left menu item, clicking on the Flows tab, and selecting the Reset Credentials flow.
+
+
+
+
+#### Implementation
+
+tbd
+
+
+
+
+## 2-Factor-Auth
+
+Levels of Authentication
+
+- Level 0: Authentication by username and password only. No 2-factor-auth.
+- Level 1: Authentication by username and password; plus additionally 2-factor-auth via Keycloak OTP
+- Level 2: Authentication by username and password; plus additionally 2-factor-auth via configured webauth method
+
+
+
+
+
+
+#### Setup for Catena-X
+
+Keycloak 2-Factor-Auth is suggested for all users/identities which are managed by Catena-X and not federated by any company identity management system.
+
+
+
+
+##### Config for the Master Realm
+
+The Master realm, holding the admin accounts, is configured to
+
+* Each User needs to mandatorily configure OTP
+* Each User needs to mandatorily update the password after the first login
+* Password policies as per chapter PasswordPolicies need to get followed
+
+
+
+
+##### Config for the Catena-X Realm
+
+tbd
+
+
+
+##### Config for the Company Spec. Realm
+
+The Shared Company realm, holding the user accounts for the company, is configured as following
+
+* Each User needs to mandatorily configure OTP
+* Each User needs to mandatorily update the password after the first login
+* Password policies as per chapter PasswordPolicies need to get followed
+
+
+
+
+#### How to Setup - Yubikey as 2-Fact-Auth
+
+The IdP, where the user is stored/created (for SharedIdP Companies its the SharedIdP; for CX Operators its the CentralIdP as well as the SharedIdP) an authentication flow need to get configured.
+
+
+
+##### #1 Create New Auth Flow as shown below
+
+
+
+
+
+##### #2 Set the Auth Flow as browser flow
+
+
+
+
+
+##### #3 Update the Required Actions
+
+
+
diff --git a/developer/Technical Documentation/Identity & Access/07. Email Configuration.md b/developer/Technical Documentation/Identity & Access/07. Email Configuration.md
new file mode 100644
index 000000000..06b9525ad
--- /dev/null
+++ b/developer/Technical Documentation/Identity & Access/07. Email Configuration.md
@@ -0,0 +1,74 @@
+# IdP Email Configuration
+
+## Requirement
+tbd - setup will be needed
+
+
+
+
+## How to configuring email for a realm
+Keycloak can send emails to users for several different scenario
+
+* to verify the user email address
+* to recreate a password in case it was forgotten
+* or when an administrator needs to receive notifications about a server event
+
+
+To enable Keycloak to send emails, SMTP server settings need to get configured by following steps:
+* Login to the respective Keycloak instance and open the relevant realm
+* Click Realm Settings in the menu.
+* Click the Email tab.
+* Fill in the fields and toggle the switches as needed.
+
+
+
+###### Host
+SMTP server hostname used for sending emails.
+
+
+###### Port
+SMTP server port.
+
+
+###### From
+Address used for the From SMTP-Header for the emails sent.
+
+
+###### From Display Name
+Allows to configure a user friendly email address aliases (optional). If not set the plain From email address will be displayed in email clients.
+
+
+###### Reply To
+Reply To denotes the address used for the Reply-To SMTP-Header for the mails sent (optional). If not set the plain From email address will be used.
+
+
+
+###### Reply To Display Name
+Reply To Display Name allows to configure a user friendly email address aliases (optional). If not set the plain Reply To email address will be displayed.
+
+
+
+###### Envelope From
+Envelope From denotes the Bounce Address used for the Return-Path SMTP-Header for the mails sent (optional).Enable SSL and Enable StartTSLToggle one of these switches to ON to support sending emails for recovering usernames and passwords, especially if the SMTP server is on an external network. You will most likely need to change the Port to 465, the default port for SSL/TLS.
+
+
+
+###### Enable Authentication
+Set this to ON if your SMTP server requires authentication. When prompted, supply the Username and Password.
+
+
+
+#### Catena-X Implementation
+
+smtp-host: smtp.office365.com
+smtp-port: 587
+Enable StartTLS
+Enable Authentication
+visible in https://catenaxdev003akssrv.germanywestcentral.cloudapp.azure.com/iamcentralidp/auth/admin/master/console/#/realms/CX-Central/smtp-settings
+
+
+it's mandatory the 'from' email-address and the smtp-username used to authenticate with the office365 mailing-service are identical. Therefor Notifications@catena-x.net is configured as email address.
+This can get changed (if necessary) if a new login/account with the respective email is created.
+
+
+
diff --git a/developer/Technical Documentation/Identity & Access/08. Event Logging.md b/developer/Technical Documentation/Identity & Access/08. Event Logging.md
new file mode 100644
index 000000000..dee4b7838
--- /dev/null
+++ b/developer/Technical Documentation/Identity & Access/08. Event Logging.md
@@ -0,0 +1,177 @@
+# Event Logging
+
+## Requirement
+
+- [ ] Keycloak needs to log for each realm the login calls, logout, unsuccessful logins, changes of keycloak configs
+- [ ] Date and time should get logged as well as the user which did the change
+- [ ] Logs should not show any passwords in clear text
+- [ ] Usernames should not show up in clear text, but need to be traceable
+- [ ] When a new realm gets created, the log configuration needs to get configured automatically as per the requirement
+- [ ] Log retention period 90days
+
+
+
+## Keycloak events
+Keycloak has two kinds of events:
+
+* login events and
+* admin events
+
+
+Login events are emitted every time a user-related action around authentication is executed, e.g. login, logout, code-to-token exchanges, registrations, etc. Also errors of these actions are emitted as an event. The event itself then contains some useful information about the action and the corresponding user and/or client. Admin events are emitted on every change of a resource via the Admin-API, no matter if via the web console, REST api, CLI, etc.
+
+
+It is possible to enable the Keycloak db to store the events. However this is not recommended, since the login events DB table is hardly indexed, the admin events table besides the PK not at all and querying lots of entries will likely slow down the system. Also an important information regarding that: login event retention time can get configured; admin events retention time can't.
+
+
+Keycloak has a default events listener (called jboss-logging) in each realm configured. When there is e.g. an error during a login attempt, this error event will be logged with log level WARN.
+
+
+Successful events will be logged with level DEBUG and the root log level of the whole Keycloak server is set to INFO. With this setting, the SUCCESS-events won’t occur in the logs, only the ERROR-events will.
+
+
+
+## Configure Logging
+##### Keycloak Admin UI/DB
+Login events occur for things like when a user logs in successfully, when somebody enters in a bad password, or when a user account is updated. Every single event that happens to a user can be recorded and viewed. By default, no events are stored or viewed in the Admin Console. Only error events are logged to the console and the server’s log file. To start persisting you’ll need to enable storage. Go to the Events left menu item and select the Config tab.
+
+
+###### Event Configuration
+
+
+
+
+
+To start storing events you’ll need to turn the Save Events switch to on under the Login Events Settings.
+
+
+
+###### Save Events
+
+
+
+
+
+The Saved Types field allows you to specify which event types you want to store in the event store. The Clear events button allows you to delete all the events in the database. The Expiration field allows you to specify how long you want to keep events stored. Once you’ve enabled storage of login events and decided on your settings, don’t forget to click the Save button on the bottom of this page.
+
+
+To view events, go to the Login Events tab.
+
+
+
+###### Login Events
+
+
+
+
+As you can see, there’s a lot of information stored and, if you are storing every event, there are a lot of events stored for each login action. The Filter button on this page allows you to filter which events you are actually interested in.
+
+
+
+###### Login Event Filter
+
+
+
+
+
+In this screenshot, we’re filtering only Login events. Clicking the Update button runs the filter.
+
+###### Event Types
+Login events:
+
+* Login - A user has logged in.
+* Register - A user has registered.
+* Logout - A user has logged out.
+* Code to Token - An application/client has exchanged a code for a token.
+* Refresh Token - An application/client has refreshed a token.
+
+
+
+Account events:
+
+* Social Link - An account has been linked to a social provider.
+* Remove Social Link - A social provider has been removed from an account.
+* Update Email - The email address for an account has changed.
+* Update Profile - The profile for an account has changed.
+* Send Password Reset - A password reset email has been sent.
+* Update Password - The password for an account has changed.
+* Update TOTP - The TOTP settings for an account have changed.
+* Remove TOTP - TOTP has been removed from an account.
+* Send Verify Email - An email verification email has been sent.
+* Verify Email - The email address for an account has been verified.
+
+For all events there is a corresponding error event.
+
+
+
+
+##### Log Files
+
+Per default keycloak logs are configured to only log on INFO level, to get a detailed logging, the log level need to get updated.
+
+2 options are available to adjust the logging level in the logs:
+
+ Option1: Change the log level of the org.keycloak.events category logger
+ With this approach, you add an entry in the logging subsystem of the underlying Wildfly configuration. The new entry tells the logging subsystem to print all log messages from the package org.keycloak.events with DEBUG level and above to the log output:
+
+ /subsystem=logging/logger=org.keycloak.events/:add(category=org.keycloak.events,level=DEBUG)
+
+
+ Option2: Configure the jboss-logging listener to log on other levels
+ As per default, there is no eventsListener SPI config in the Keycloak server configuration. The default behaviour for the jboss-logging events listener is the one which is implemented in the code. To be able to change the configuration of the jboss-logging listener, you’ll have to create the proper SPI node in the keycloak-server subsystem first, then add the desired log levels.
+
+ /subsystem=keycloak-server/spi=eventsListener:add
+ /subsystem=keycloak-server/spi=eventsListener/provider=jboss-logging:add(enabled=true)
+ /subsystem=keycloak-server/spi=eventsListener/provider=jboss-logging:write-attribute(name=properties.success-level,value=info)
+ /subsystem=keycloak-server/spi=eventsListener/provider=jboss-logging:write-attribute(name=properties.error-level,value=warn)
+ Now the SUCCESS-events will occur in the log output with level INFO, as soon as they are emitted by Keycloak.
+
+
+
+## Event Listener
+Event listeners listen for events and perform an action based on that event. There are two built-in listeners that come with Keycloak: Logging Event Listener and Email Event Listener.
+The Logging Event Listener writes to a log file whenever an error event occurs and is enabled by default. Here’s an example log message:
+
+
+11:36:09,965 WARN [org.keycloak.events] (default task-51) type=LOGIN_ERROR, realmId=master,
+ clientId=myapp,
+ userId=19aeb848-96fc-44f6-b0a3-59a17570d374, ipAddress=127.0.0.1,
+ error=invalid_user_credentials, auth_method=openid-connect, auth_type=code,
+ redirect_uri=http://localhost:8180/myapp,
+ code_id=b669da14-cdbb-41d0-b055-0810a0334607, username=admin
+
+
+This logging is very useful if you want to use a tool like Fail2Ban to detect if there is a hacker bot somewhere that is trying to guess user passwords. You can parse the log file for LOGIN_ERROR and pull out the IP Address. Then feed this information into Fail2Ban so that it can help prevent attacks.
+
+
+The Email Event Listener sends an email to the user’s account when an event occurs. The Email Event Listener only supports the following events at the moment:
+
+* Login Error
+* Update Password
+* Update TOTP
+* Remove TOTP
+
+
+
+
+
+To enable the Email Listener go to the Config tab and click on the Event Listeners field. This will show a drop down list box where you can select email.
+You can exclude one or more events by editing the standalone.xml, standalone-ha.xml, or domain.xml that comes with your distribution and adding for example:
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/developer/Technical Documentation/Identity & Access/09. Generic Security.md b/developer/Technical Documentation/Identity & Access/09. Generic Security.md
new file mode 100644
index 000000000..3f955c3f1
--- /dev/null
+++ b/developer/Technical Documentation/Identity & Access/09. Generic Security.md
@@ -0,0 +1,150 @@
+## Security Generic
+
+### Host
+Keycloak uses the public hostname in several ways, such as within token issuer fields and URLs in password reset emails.
+
+By default, the hostname derives from the request header. No validation exists to ensure a hostname is valid. Therefor its suggested to use a load balancer, or proxy, with Keycloak to prevent invalid host headers.
+
+The hostname’s Service Provider Interface (SPI) provides a way to configure the hostname for requests. You can use this built-in provider to set a fixed URL for frontend requests while allowing backend requests based on the request URI. If the built-in provider does not have the required capability, you can develop a customized provider.
+
+
+
+
+### Bruce Force Detection
+A brute force attack happens when an attacker is trying to guess a user’s password multiple times. Keycloak has some limited brute force detection capabilities. If turned on, a user account will be temporarily disabled if a threshold of login failures is reached. To enable this feature go to the Realm Settings left menu item, click on the Security Defenses tab, then additional go to the Brute Force Detection sub-tab.
+
+When an attack is detected, permanent or temporary lockout can get configured.
+
+Permanent lockout disables a user account until an administrator re-enables it. Temporary lockout disables a user account for a specific period of time. The time period that the account is disabled increases as the attack continues.
+
+When a user is temporarily locked and attempts to log in, {project_name} displays the default Invalid username or password error message. This message is the same error message as the message displayed for an invalid username or invalid password to ensure the attacker is unaware the account is disabled.
+
+Details: https://www.keycloak.org/docs/latest/server_admin/index.html#password-guess-brute-force-attacks
+
+
+
+Config:
+
+1. Click Realm Settings in the menu
+2. Click the Security Defenses tab.
+3. Click the Brute Force Detection tab.
+
+Brute force detection
+
+
+
+
+
+
+Common Parameters
+
+
+
+
+
+
+#### Catena-X configuration
+
+##### Preventing automated attacks
+* Lock after 10 subsequent login failures
+* 1 second between failures (too quick for a human)
+* Lock remains active for ~5 min
+
+##### Preventing manual attacks
+* Lock after 10 subsequent login failures
+* Sliding window of 12 hours
+* Lock remains active for ~ 45 min
+
+
+
+
+### Clickjacking
+Clickjacking is a technique of tricking users into clicking on a user interface element different from what users perceive. A malicious site loads the target site in a transparent iFrame, overlaid on top of a set of dummy buttons placed directly under important buttons on the target site. When a user clicks a visible button, they are clicking a button on the hidden page. An attacker can steal a user’s authentication credentials and access their resources by using this method.
+
+By default, every response by {project_name} sets some specific browser headers that can prevent this from happening. Specifically, it sets X-FRAME_OPTIONS and Content-Security-Policy. You should take a look at the definition of both of these headers as there is a lot of fine-grain browser access you can control.
+Procedure
+
+In the Admin Console, you can specify the values of the X-FRAME_OPTIONS and Content-Security-Policy headers.
+
+1. Click the Realm Settings menu item.
+2. Click the Security Defenses tab.
+Security Defenses
+
+By default, Keycloak sets up a same-origin policy for iframes.
+
+
+
+
+### Open redirections
+An open redirector is an endpoint using a parameter to automatically redirect a user agent to the location specified by the parameter value without validation. An attacker can use the end-user authorization endpoint and the redirect URI parameter to use the authorization server as an open redirector, using a user’s trust in an authorization server to launch a phishing attack.
+
+Keycloak requires that all registered applications and clients register at least one redirection URI pattern. When a client requests that Keycloak performs a redirect, Keycloak checks the redirect URI against the list of valid registered URI patterns. Clients and applications must register as specific a URI pattern as possible to mitigate open redirector attacks.
+
+
+
+
+
+
+### Compromised Authorization code
+For the OIDC Auth Code Flow, Keycloak generates a cryptographically strong random value for its authorization codes. An authorization code is used only once to obtain an access token.
+
+On the timeouts page in the Admin Console, you can specify the length of time an authorization code is valid. Its possible to configure the length of time for a client to request a token from the code.
+
+You can also defend against leaked authorization codes by applying Proof Key for Code Exchange (PKCE) to clients.
+
+-- not yet considered in CX --
+
+
+
+
+
+
+### Compromised access and refresh tokens
+Keycloak includes several actions to prevent malicious actors from stealing access tokens and refresh tokens. The crucial action is to enforce SSL/HTTPS communication between {project_name} and its clients and applications. {project_name} does not enable SSL by default.
+
+Another action to mitigate damage from leaked access tokens is to shorten the token’s lifespans. You can specify token lifespans within the Realm Setting → Token. Short lifespans for access tokens force clients and applications to refresh their access tokens after a short time. If an admin detects a leak, the admin can log out all user sessions to invalidate these refresh tokens or set up a revocation policy.
+
+
+In the current project phase, we will proceed with the default values for the token lifespans
+
+
+
+
+
+
+
+
+### CSRF attack
+A Cross-site request forgery (CSRF) attack uses HTTP requests from users that websites have already authenticated. Any site using cookie-based authentication is vulnerable to CSRF attacks. You can mitigate these attacks by matching a state cookie against a posted form or query parameter.
+
+The OAuth 2.0 login specification requires that a state cookie matches against a transmitted state parameter. {project_name} fully implements this part of the specification, so all logins are protected.
+
+The {project_name} Admin Console is a JavaScript/HTML5 application that makes REST calls to the backend {project_name} admin REST API. These calls all require bearer token authentication and consist of JavaScript Ajax calls, so CSRF is impossible. You can configure the admin REST API to validate the CORS origins.
+
+The user account management section in {project_name} can be vulnerable to CSRF. To prevent CSRF attacks, {project_name} sets a state cookie and embeds the value of this cookie in hidden form fields or query parameters within action links. {project_name} checks the query/form parameter against the state cookie to verify that the user makes the call.
+
+
+
+
+
+
+
+
+### Limiting Scope - Client Token
+By default, new client applications have unlimited role scope mappings. Every access token for that client contains all permissions that the user has. If an attacker compromises the client and obtains the client’s access tokens, each system that the user can access is compromised.
+
+Limit the roles of an access token by using the Scope menu for each client. Alternatively, you can set role scope mappings at the Client Scope level and assign Client Scopes to your client by using the Client Scope menu.
+
+For any clients in CX, the scope is limited to the client scope.
+
+
+
+
+
+
+### Client Policies
+tbd
+
+
+
+
diff --git a/developer/Technical Documentation/Identity & Access/10. FAQ.md b/developer/Technical Documentation/Identity & Access/10. FAQ.md
new file mode 100644
index 000000000..9094697af
--- /dev/null
+++ b/developer/Technical Documentation/Identity & Access/10. FAQ.md
@@ -0,0 +1,178 @@
+## FAQ
+
+### How to crete new roles
+
+Bevore creating new roles, check once for which level/purpose the role is needed
+
+1. Portal Role
+2. App Role
+3. Technical User Role
+
+
+
+##### Portal Role
+
+Portal roles can get added easily if following steps are considered/followed.
+
+1. Create the roles inside keycloak - central idp; realm: CX-Central inside the respective client
+ * open the client via the left side menu Clients
+ * select the resepctive client (Cl2-CX-Portal or Cl1-CX-Registration)
+ * Open the tab Roles
+ * And click "Add" on the right hand side
+ * Enter the respective role name (keep in mind the role naming conversation)
+ * Click "Save"
+
+
+
+ To transform the created "role" to an actual role, since currently its a single permission only; click on Composite Roles "ON".
+
+
+
+ Afterwards select the respective permissions which should get collected under the new created role/composite role by selecting the client in which the relevant permissions are located.
+ Note: permissions of multiple clients can get assigned to one composite role without any troubles/issues.
+
+
+
+
+
+2. Create the same role inside the portal db (either via a delta migration job) or via sql.
+
+ For the scenario of sql, the relevant sql can get found below:
+
+
+
+ 1st create the role
+
+ INSERT INTO portal.user_roles
+ (id, user_role, offer_id, last_editor_id)
+ VALUES ('{uuid}', '{user role name}', '{offer.id of portal or registration}', '{operator user uuid}');
+
+
+ 2nd add role description in german and english
+
+ INSERT INTO portal.user_role_descriptions
+ (user_role_id, language_short_name, description)
+ VALUES
+ ('(user_roles.id)', '{de}', '{description}'),
+ ('(user_roles.id)', '{en}', '{description}');
+
+
+ 3rd connect role with company role collection
+
+ INSERT INTO portal.user_role_assigned_collections
+ (user_role_id, user_role_collection_id)
+ VALUES ('{user_roles.id}', '{user_role_collections.id}');
+
+
+
+
+##### App Role
+
+App roles are managed by app provider by the portal user interface. It should be strightly forbidden to add / change any app roles in any other way. Reason: app roles are (beside that they are in the ownership of the app provider) impacting not only a keycloak client and portal db; additionally apps have app clients registered in keycloak and each client need to get enahnced with the new roles where human errors are very likely possible.
+
+
+
+
+##### Technical User Role
+
+Technical user roles are similar like portal user roles created/managed and enhanced by the platform owner.
+
+1. Create the roles inside keycloak - central idp; realm: CX-Central inside the client "technical_role_management"
+ * open the client via the left side menu Clients
+ * Open the tab Roles
+ * And click "Add" on the right hand side
+ * Enter the respective role name (keep in mind the role naming conversation)
+ * Click "Save"
+
+
+
+ To transform the created "role" to an actual role, since currently its a single permission only; click on Composite Roles "ON".
+
+
+
+ Afterwards select the respective permissions which should get collected under the new created role/composite role by selecting the client in which the relevant permissions are located.
+ Note: permissions of multiple clients can get assigned to one composite role without any troubles/issues.
+
+
+
+
+
+2. Create the same role inside the portal db (either via a delta migration job) or via sql.
+
+For the scenario of sql, the relevant sql can get found below:
+
+
+
+ 1st create the role
+
+ INSERT INTO portal.user_roles
+ (id, user_role, offer_id, last_editor_id)
+ VALUES ('{uuid}', '{user role name}', '{offer.id of technical_user_management}', '{operator user uuid}');
+
+
+ 2nd add role description in german and english
+
+ INSERT INTO portal.user_role_descriptions
+ (user_role_id, language_short_name, description)
+ VALUES
+ ('(user_roles.id)', '{de}', '{description}'),
+ ('(user_roles.id)', '{en}', '{description}');
+
+
+
+
+
+
+### What is the difference between roles & permission
+
+In the concept of the roles and rights management we are differentiating between roles and permissions.
+
+Permissions are the lowest level which a user can have. Several permissions are collected to a role.
+
+The assignment of rights to an actual user is happening on the role level itself.
+
+
+
+
+### How to setup technical user authentication
+
+Technical user/service accounts should get created as standalone client to clearly differenciate applications from technical users.
+Each OIDC client has a built-in service account which allows it to obtain an access token.
+This is covered in the OAuth 2.0 specifiation under Client Credentials Grant. To use this feature you must set the Access Type of your client to confidential. Make sure that you have configured your client credentials.
+
+In tab Service Account Roles you can configure the roles available to the service account retrieved on behalf of this client.
+
+https://github.com/keycloak/keycloak-documentation/blob/main/server_admin/topics/clients/oidc/service-accounts.adoc
+
+
+* Create the respective OIDC client, with respective setting
+ * Access Type: confidential
+ * Standard Flow: disabled
+ * Direct Access Grant: disabled
+ * Service Accounts: enabled
+ * Add Mapper "BPN" to the user
+
+
+
+ * Add a bpn into the user account 8when using the existing api endpoints; the bon is added automatically based on the company bpn of the acting user)
+
+After saving the config, the client gets automatically a service user account created which is used as "technical user"
+
+
+
+
+### Retrieve token for service account
+
+ curl --location --request POST '{keyloak URL}/auth/realms/{realm}/protocol/openid-connect/token' \
+ --header 'Content-Type: application/x-www-form-urlencoded' \
+ --data-urlencode 'client_secret={secret} \
+ --data-urlencode 'grant_type=client_credentials' \
+ --data-urlencode 'scope=openid' \
+ --data-urlencode 'client_id={clientId}'
+
+
+
+
+
+
+
diff --git a/developer/Technical Documentation/Interface Contracts/BPDM (2).md b/developer/Technical Documentation/Interface Contracts/BPDM (2).md
new file mode 100644
index 000000000..4fc767153
--- /dev/null
+++ b/developer/Technical Documentation/Interface Contracts/BPDM (2).md
@@ -0,0 +1,56 @@
+# Business Partner Data Management
+
+
+## Interface Summary
+
+Business Partner Data of all business partners stored inside the catena-x data pool get visually displayed inside the partner network.
+This document describes the details of the interface spec between BPDM and Portal product.
+
+
+
+## Architecture Overview
+
+
+
+
+
+## Description of the functional interface (WHAT)
+Display business partner data via the partner network.
+
+
+
+## Description of the physical interfaces (HOW)
+
+n/a
+
+
+
+### Get Business Partner data
+
+
+```diff
+! GET /api/catena/legal-entities/legal-addresses/search
+```
+
+#### Data Mapping for Company Data
+
+to be added
+
+
+
+
+#### Get Membership Flag
+The endpoint provides all business partner numbers of those comapny records; where the company status is "ACTIVE" (means: company is part of the catena-x network).
+Those bpns are mapped with the GET Business Partner Data response (see above) and a membership flag is added for matching companies inside the partner network user interface.
+
+
+```diff
+! GET /api/administration/partnernetwork/memberCompanies
+```
+
+#### Data Mapping for Company Data
+to be added
+
+
+
+
diff --git a/developer/Technical Documentation/Interface Contracts/BPDM.md b/developer/Technical Documentation/Interface Contracts/BPDM.md
new file mode 100644
index 000000000..164811071
--- /dev/null
+++ b/developer/Technical Documentation/Interface Contracts/BPDM.md
@@ -0,0 +1,73 @@
+# Business Partner Data Management
+
+
+## Interface Summary
+
+BPDM Data Pool provides an API (Reference Data API) to lookup business partner data via REST endpoint "Lookup Business Partner". This endpoint provides access to several external data sources (trade registers, open data repositories, etc.)
+
+API authentication is managed by API keys which is processed via HTTP header. This key manages also authorization, e.g., access to the CX data pool (instead of other community data).
+
+
+For the registration process we are using the BPDM data call to pull the company basic data.
+
+2 Options are available for the data pull
+
+* Via Company Name (Level 2 - not yet implemented)
+* Via BPN Number (BPN Generator: BPN Generator: Modes of Operation)
+
+
+
+## Architecture Overview
+To integrate the API into CX onboarding process, portal team just have to call the lookup REST endpoint and transform the response into a pick list for the portal user.
+
+
+
+
+
+## Description of the functional interface (WHAT)
+Retrieving company data from the CX mirror.
+
+
+
+## Description of the physical interfaces (HOW)
+
+
+
+
+
+### Service Call via BPN
+
+
+```diff
+! GET /api/catena/business-partner/{idValue}
+```
+
+
+ idValue: {BPN-Number},
+ idType: BPN
+
+
+
+#### Data Mapping for Company Data
+
+
+|Data Field Name Portal|Data Field on CX Data Pool|Example|
+|--------|--------|--------|
+|BPN|"bpn": (first response line)|BPNL0MVP000000Q7|
+|Organization Name|"names": [ { "value}]|German Car Factory|
+|Registered Name |"names": [ { "value}]|German Car Factory|
+|International Name |"names": [ { "value}]|German Car Factory|
+|Street & House Number|addresses "country": [ { "technicalKey":}]|DE|
+|Country|addresses "postCodes": [ { "value":}]|80809|
+|Postal Code|addresses "localities": [ { "value":}]|Munich|
+
+
+
+
+### Service Call via CompanyName
+
+currently not supported
+
+
+
+
diff --git a/developer/Technical Documentation/Interface Contracts/CX-Membership.md b/developer/Technical Documentation/Interface Contracts/CX-Membership.md
new file mode 100644
index 000000000..c06333f5f
--- /dev/null
+++ b/developer/Technical Documentation/Interface Contracts/CX-Membership.md
@@ -0,0 +1,45 @@
+# CX-Membership
+
+## Interface / API / Service Summary
+The membership discovery endpoint is used to display/retrieve all cx network members based on the bpn
+
+
+
+
+## Architecture Overview
+
+n/a
+
+
+
+
+## Implementation
+
+### #1 CX Membership Discovery
+The cx membership discovery endpoint can get triggered via technical as well as real users, if relevant roles are available.
+For technical user, a company can request the user creation via the link to technical user creation.
+For details, click following link:
+[Technical User Management](/docs/03.%20User%20Management/3%20Technical%20User/02.%20Create%20Technical%20User.md#create-a-new-technical-user)
+
+
+```diff
+! GET api/administration/partnernetwork/memberCompanies
+```
+
+###### Request Body
+
+n/a
+
+###### Response Body
+
+the string response includes all bpn's of active network members
+
+ [
+ "string"
+ ]
+
+
+the string response includes all bpn's of active network members
+
+
+
diff --git a/developer/Technical Documentation/Interface Contracts/Dataspace-Discovery.md b/developer/Technical Documentation/Interface Contracts/Dataspace-Discovery.md
new file mode 100644
index 000000000..8671131c9
--- /dev/null
+++ b/developer/Technical Documentation/Interface Contracts/Dataspace-Discovery.md
@@ -0,0 +1,53 @@
+# Dataspace Discovery
+
+## Interface / API / Service Summary
+The EDC / dataspace discovery interface is a CX network public available endpoint which can get used to retrieve edc endpoints and the related BPNs, as well as search for endpoints via the BPN
+
+
+
+
+## Architecture Overview
+
+n/a
+
+
+
+
+## Implementation
+
+### #1 EDC Discovery
+The edc discovery endpoint can get triggered via technical as well as real users, if relevant roles are available.
+For technical user, a company can request the user creation with the technical user creation feature inside the portal.
+For details, click following link:
+[Technical User Management](/docs/03.%20User%20Management/3%20Technical%20User/02.%20Create%20Technical%20User.md#create-a-new-technical-user)
+
+
+```diff
+! POST: /api/administration/connectors/discovery
+```
+
+###### Request Body
+The request body is expecting a list of BPNs for which the EDC endpoint should get be fetched. Please add minimum one BPN.
+
+
+ [
+ "string"
+ ]
+
+###### Response Body
+
+ [
+ {
+ "bpn": "string",
+ "connectorEndpoint": [
+ "string"
+ ]
+ }
+ ]
+
+
+
+In case of an empty response, no edc is found for the requested BPNs
+
+
+
diff --git a/developer/Technical Documentation/Interface Contracts/Managed Wallets.md b/developer/Technical Documentation/Interface Contracts/Managed Wallets.md
new file mode 100644
index 000000000..c3d66be57
--- /dev/null
+++ b/developer/Technical Documentation/Interface Contracts/Managed Wallets.md
@@ -0,0 +1,49 @@
+# Managed Wallets
+
+
+## Interface Summary
+
+Wallets are the touchpoint of company/participant to SSI as the digital identity. Companies can interact with other actors in the network using their own identity on their wallet.
+Since SSI Wallets are not yet common on company level, Catena-X decided to create CX managed wallets for membership companies. This wallets can be used to enable the benefits of SSI for a number of services.
+
+The Portal / Managed Service connection is implemented in 2 functions
+* Company Registration - initital wallet creation
+* EDC Registration - EDC Self-Description creation
+
+
+
+## Architecture Overview
+
+### #1 Company Registration
+
+
+
+
+
+### #2 Company Registration
+
+
+
+
+
+## Authentication Flow / Details
+
+
+
+
+
+
+## Description of the functional interface (WHAT)
+Creation of a managed wallet for the newly registered legal person / company.
+
+
+
+## Description of the physical interfaces (HOW)
+With the /approvalRequest api, the managed wallet logic is triggered to create for the new member (based on the bpn) a new managed wallet.
+
+
+
+## APIs
+
+Endpoint: no specific endpoint, part of the portal internal logic, which will call the /selfdescription factory endpoint
+
diff --git a/developer/Technical Documentation/Interface Contracts/Offer-Autosetup.md b/developer/Technical Documentation/Interface Contracts/Offer-Autosetup.md
new file mode 100644
index 000000000..69f222e68
--- /dev/null
+++ b/developer/Technical Documentation/Interface Contracts/Offer-Autosetup.md
@@ -0,0 +1,169 @@
+# Offer Autosetup
+
+## Interface / API / Service Summary
+For the case of a service setup / app, where an autosetup is available, CX will offer a standardized interface to push the relevant information to the service provider, which can trigger the service setup, if relevant.
+
+Following interfaces are relevant to enable the autosetup
+
+1. POST Service URL (Generic endpoint for service providers to store their autosetup - if available - url inside CX)
+2. POST Service Request (Specific endpoint to trigger customer subscription)
+3. POST Instance Details (Register service instance for customer inside CX)
+
+
+
+
+## Architecture Overview
+
+### #1 Highlevel Architecture picture
+
+
+
+
+
+
+### #2 Details
+
+
+
+
+## Implementation
+
+### #1 PUT Service URL
+The PUT service url is enabling the service / app provider to store/hold the service partner / app partner autosetup url.
+
+Logic: the service provider/app provider (must be an cx member) can trigger the endpoint to store the autosetup endpoint.
+
+
+
+
+
+
+```diff
+! PUT api/administration/serviceprovider/owncompany
+```
+
+With the first time calling the endpoint; the url will be set as app/service provider endpoint as a new data set.
+With any further endpoint triggers; the existing record will get overwritten. Means; the app/service provider can have only one endpoint configured.
+
+
+
+
+### #2 POST Service Request
+he service request (from the customer, to the provider) is getting stored and managed under this api.
+
+
+```diff
+! POST /api/services/{serviceId}/subscribe
+```
+
+
+This API will be used to trigger (if available) the service provider endpoint (stored under #1) with the following body
+
+
+
+ [
+ {
+ "customer" :
+ {
+ "organizationName": "companyName"[required] ,
+
+ "country": "company country alpha2code" [required],
+
+ "email": "user email address which triggered the service" [required]
+ }
+
+ "properties":
+ {
+ "bpnNumber": "bpn of the company" [required],
+
+ "subscriptionId": "" [required],
+
+ "serviceId": "" [required]
+ }
+ }
+ ]
+
+
+
+
+
+
+### #3 POST Service Instance
+Post service request is used to create the customer service/app instance inside the portal db.
+With the successful client/app instance creation on the portal side, the technical user for the AAS registry will get send within the response
+
+
+Request Body
+
+
+ [
+ {
+ requestId (service request id),
+ appUrl (service provider endpoint / client / app)
+ }
+ ]
+
+
+
+```diff
+! POST: /api/services/autosetup
+```
+
+API Endpoint Logic
+
+* Validate if requestId is existing in app_subscription table
+* Validate if user calling the endpoint is registered as service provider of the service/app
+* Validate if the subscription is in status "PENDING"
+ * if yes, proceed
+ * if no, error
+* Run client name creation (logic needed - similar like the service account logic implemented by Norbert; but in this case for the client itself) - ideally naming convention should be something like Cl-{AppName}-{CustomerName}
+* Add app instance and client for the customer and app id in following tables
+ * iam_client table
+ * app_instance table
+* Next, create the client in keycloak central IdP - setting
+ * Client ID: {client name defined by the service before}
+ * Access Type: {public, might get auto set, please check}
+ * Standard Flow Enabled: true
+ * Direct Access Grants Enabled: true
+ * Valid Redirect URIs: {url send via the request body, likely a "*" needs to get added}
+ * Web Origins: "+"
+ * Backchannel Logout Session Required: true
+ * Full Scope allowed: false
+
+
+* now add roles to the same client by using the roles stored inside user_roles in the portal db and linked to the respective app for which the instance got created
+* Create the technical user for the service, by creating another client with following settings
+ * Client ID: {ideally client name + prefix "sa-"}
+ * Access Type: {confidential}
+ * Standard Flow Enabled: false
+ * Direct Access Grants Enabled: false
+ * Service Accounts Enabled: true
+ * Backchannel Logout Session Required: true
+
+ * Full Scope allowed: true
+ * Service Account Roles: select the service account role "Digital Twin Management" of the client "technical_roles_management"
+
+* add to the technical user the bpn as attribute (bpn of the customer) and the bpn mapper inside the client. Config see attachment
+* store technical user data inside portal db => description "Technical User for app {app name} - {techUserRoleName}"
+* Technical user to be mapped to the customer company id
+* Back inside the portal db, update the service/app status in the app_subscription table from "PENDING" to "ACTIVE"
+* Create Notifications
+ * customer notification to inform the customer company about the technical user creation via the service provider. (receiver: customer IT admin)
+ * customer notification to inform the customer company about the activated app/service (receiver: customer app requester, customer IT admin)
+
+
+
+Response Body
+
+
+ {
+ technicalUserId,
+ technical user secret
+ }
+
+
+
+
+
+
+
diff --git a/developer/Technical Documentation/Interface Contracts/Self Description.md b/developer/Technical Documentation/Interface Contracts/Self Description.md
new file mode 100644
index 000000000..c1c79c15d
--- /dev/null
+++ b/developer/Technical Documentation/Interface Contracts/Self Description.md
@@ -0,0 +1,117 @@
+# Self Description
+
+
+## Interface Summary
+Gaia-X requires all providers to describe themselves and their service offerings using standardized, machine-readable metadata called Self-Descriptions. Such Self-Descriptions will for example include information like the address of a company, a specific service description or certificates and labels.
+In the Catena-X context, those self-descriptions are implemented between the product Portal and SD Factory.
+
+
+In the current implementation level, self-descriptions are considered in the following scenarios
+
+* Onboarding / Registration of a company
+* Registration of a connector
+* Registration / Release of a new app or service
+
+
+In the document details below, those interfaces are described / explained.
+
+
+
+## Architecture Overview
+
+
+
+
+
+## Description of the functional interface (WHAT)
+The Portal - SD Factory Interface is used to generate signed self descriptions which are stored in json ld files.
+The json ld file is supposed to get stored - for now normal db document storage linked to the self description owner (usually a company).
+
+
+
+## Description of the physical interfaces (HOW)
+Portal is pushing the self description via an REST API "POST" developed under the portal context.
+Factory will receive the information and create the self-description with signature (with help of the wallet).
+A response is getting send to the portal with an "content" section. The content section is getting stored as json file in the portal db.
+
+
+
+## 1. Self Description Creation
+For self descriptions, 2 different kinds of self descriptions are currently in scope.
+Participants and services. In the section below both are explained.
+
+### 1.1 Participant (Type of SD is "LegalPerson")
+The participant self description is getting auto triggered with the CX member approval.
+Following data are getting submitted to the factory to create the participant self description.
+
+ JSON Body
+
+ "type": "LegalPerson",
+
+ "registration_number": "application id of the company, in future unique identifier",
+
+ “headquarter_country”: "use the alpha2code of the company identity",
+
+ ”legal_country”: "use the alpha2code of the company identity",
+
+ “bpn”: "company bpn",
+
+ “issuer”: "Catena-X bpn",
+
+ “holder”: "Company bpn"
+
+
+
+Endpoint: no specific endpoint, part of the portal internal logic, which will call the /selfdescription factory endpoint
+
+
+
+### 1.2 Service (Type of SD is "ServiceOffering")
+The service self description is currently only triggered for edcs with a limited content scope.
+Following you can find the self description json. Same as for participant, there is no self-description endpoint available, the self description is triggered as part of an internal portal logic when registering the connector.
+
+ JSON Body
+
+ "type": "ServiceOffering",
+
+ "providedBy": "participant sd document url",
+
+ “aggregationOf”: "",
+
+ ”termsAndConditions”: "link to AGB of Catena-X"; → to be clarified with Felix Gerbig (Werner Jost will request this),
+
+ “policies”: "the policies declared in the EDC instance to be registered/onboarded" → to be clarified with Stefan Ettl (Werner Jost will request this),
+
+ “issuer”: "Catena-X bpn",
+
+ “holder”: "Company bpn"
+
+
+Result: self description of the connector connected to the participant SD via the "provided_by" link.
+The self description is stored inside the document table
+
+
+
+## 2. Self Description Storage
+Created self descriptions are stored against the company account inside the portal db "documents" with binary data.
+The self-description can get published again when transferring the binary data into a json ld.
+
+
+Storage logic:
+* Documents are stored under a own document type "Self-Subscription..."
+* With the storage of the document the status is set to "locked" => ensures that user can not easily delete it
+* Connector SDs are additional linked to the respective connector, since a company could have multiple connectors
+* User which triggered the SD creation is logged
+
+
+
+## 3. Self Description Deletion
+currently not supported
+
+
+
+## 4. Self Description Discovery
+currently not supported
+
+
+
diff --git a/developer/Technical Documentation/Operations/Auditing.md b/developer/Technical Documentation/Operations/Auditing.md
new file mode 100644
index 000000000..b7830b830
--- /dev/null
+++ b/developer/Technical Documentation/Operations/Auditing.md
@@ -0,0 +1,120 @@
+# Audit Logging
+
+For db audit logs, 2 generic approaches are used
+
+ * PostgreSQL Session Logging (pgAudit)
+ * Application Logging
+
+
+
+## PostgreSQL Session Logging (pgAudit)
+
+PgAudit module is enabled for the portal db via the Bitnami PostgreSQL Image:
+
+https://github.com/bitnami/bitnami-docker-postgresql#auditing
+
+
+
+Following operations are audited: WRITE, DDL
+WRITE: INSERT, UPDATE, DELETE, TRUNCATE, and COPY
+DDL: CREATE, ALTER, and DROP schema objects
+For a complete list of auditable operations see https://github.com/pgaudit/pgaudit#pgauditlog
+
+
+
+In addition the parameters time stamp with milliseconds, user name and database name are configured as log line prefixes.
+
+
+
+Future enhancements: Auditing logging on application side namely in the backend. The auditing on db level with pgAudit doesn't provide the information by which person specific user an operation was triggered because db operations are executed by our generic db users (for instance the 'portal').
+
+
+
+## Application Audit Logging
+
+Application Audit Logging is implemented to fulfill and enable extended audit log functionalities for the CX portal.
+
+In the implementation the possibility of pgAudit extension and db table logging inside the postgreSQL was validated.
+
+Due to the functional requirement to enable serach, quick validations and audit traceability, the in-DB audit implementation got preferred.
+
+
+
+Implementation Details
+
+What: for each audit relevant table, an audit_tablename_version table is created and storing any original table INSERT, DELETE or UPDATE records. Important, we always store:
+
+- Who changed
+- What
+- When
+
+
+
+ Why we use versioning for the audit tables?
+
+ To ensure that an audit table is never modified, but only entries are added, we have introduced versioning for audit table.
+
+ Each audit table has version suffix in the name, this corresponds to the name of the migration in which the audit table was added.
+
+ See the example below for further information:
+
+
+
+ How to enable an entity to be auditable in the code (Example: CompanyUser)
+
+1. The auditable entity needs to implement interface 'IAuditable'
+ public class CompanyUser : IAuditable
+
+2. Create Audit entity which should derive from the auditable entity and implement IAuditEntity
+
+ public class AuditCompanyUser : CompanyUser, IAuditEntity
+
+3. Add DbSet in PortalDbContext for the newly created Entity
+
+ public virtual DbSet AuditCompanyUsers { get; set; } = default!;
+
+4. Add .ToTable configuration to the OnModelCreating for the auditable entity
+
+ entity.ToTable("company_users")
+
+5. Add modelBuilder.Entity configuration to the OnModelCreating for the audit table ignore all virtual properties of the base entity. !IMPORTANT! -> The tablename of the audit table must exactly match the name of the migration in snakecase and beginn with audit_.
+
+ modelBuilder.Entity(x =>
+ {
+ x.HasBaseType((Type?)null);
+ x.Ignore(x => x.Company);
+ x.Ignore(x => x.IamUser);
+ x.Ignore(x => x.Consents);
+ x.Ignore(x => x.Documents);
+ x.Ignore(x => x.Invitations);
+ x.Ignore(x => x.Apps);
+ x.Ignore(x => x.UserRoles);
+ x.Ignore(x => x.CompanyUserAssignedRoles);
+ x.Ignore(x => x.CompanyUserAssignedBusinessPartners);
+ x.Ignore(x => x.Notifications);
+ x.Ignore(x => x.CreatedNotifications);
+ x.ToTable("audit_company_users_cplp_1254_db_audit");
+ });`
+
+6. Add Migration as described in the readme.md in CatenaX.NetworkServices.PortalBackend.Migrations the name must match the table name of the audit table
+
+ 20220802122302_CPLP-1254-db-audit
+
+7. Add the AuditTrigger to the created migration. Add migrationBuilder.AddAuditTrigger("versionName") at the end of the Up method and migrationBuilder.DropAuditTrigger() to the beginning of the Down method. T should be the Audit Entity and the version should equal the backpart of the name of the migration without timestamp as snakecase.
+
+
+
+Up:
+
+ migrationBuilder.AddAuditTrigger("cplp_1254_db_audit");
+
+Down:
+
+ migrationBuilder.DropAuditTrigger();
+
+
+
+Additional relevant information:
+
+ (warning) If not already existing in the original table, a uuid and last_editor_id attribute need to get added to the original id.
+ (warning) whenever the original table attributes are changed (e.g. adding an attribute or deleting and attribute) the already existing audit table will be set to frozen and a new audit table is getting created. All new audit relevant records will be stored in the new audit table
diff --git a/developer/Technical Documentation/Operations/Release-Process.md b/developer/Technical Documentation/Operations/Release-Process.md
new file mode 100644
index 000000000..71700be78
--- /dev/null
+++ b/developer/Technical Documentation/Operations/Release-Process.md
@@ -0,0 +1,96 @@
+# Release Process
+
+The release process for a new version can roughly be divided in the following steps:
+
+* Preparation
+* Build of a versioned image
+* Release of a new helm chart version
+* Merge upstream to eclipse-tractusx
+
+The process builds on the development flow which takes place within the forks from eclipse-tractusx, located in the catenax-ng organization.
+
+The relevant frontend repositories are the following:
+
+* https://github.com/catenax-ng/tx-portal-frontend
+* https://github.com/catenax-ng/tx-portal-frontend-registration
+* https://github.com/catenax-ng/tx-portal-assets
+
+The relevant backend repository is the following:
+* https://github.com/catenax-ng/tx-portal-backend
+
+## Preparation
+
+It's recommended to do step 1-3 in one preparatory pull request to main, or dev respectively.
+
+#### 1. Update changelog file
+
+The changelog file tracks all notable changes since the last released version.
+During development every developer should extend the changelog under the 'Unreleased' section when raising a pull request to main or dev.
+Once a new version is ready to be released, the changelog of the version gets finalized and the release version gets set for the, up to then, unreleased changes.
+In the released version, the changelog is structured as following:
+
+* Changes
+* Features
+* Technical Support
+* Bug Fixes
+
+In case of breaking change, the breaking change will get highlighted with a breaking change tag => ![Tag](https://img.shields.io/static/v1?label=&message=BreakingChange&color=yellow&style=flat)
+
+#### 2. Update dependencies file
+
+In order to have an up-to-date list, of the used third-party libraries, the dependencies file needs to be updated.
+
+For the frontend repositories this can be done by running the following statement:
+
+```bash
+yarn licenses list > DEPENDENCIES
+```
+
+For the backend repository the dependencies file can be updated by running the following statements:
+
+```bash
+dotnet list src package --include-transitive > DEPENDENCIES-PREP
+cat DEPENDENCIES-PREP | grep ">" | grep -Pv "\s(Org|Microsoft|NuGet|System|runtime|docker|Docker|NETStandard)" | sed -E -e "s/\s+> ([a-zA-Z\.\-]+).+\s([0-9]+\.[0-9]+\.[0-9]+)\s*/nuget\/nuget\/\-\/\1\/\2/g" > DEPENDENCIES
+awk -i inplace '!seen[$0]++' DEPENDENCIES
+```
+
+Only commit the updated dependencies file, not the 'DEPENDENCIES-PREP' file.
+
+#### 3. Version bump (frontend repos only)
+
+The version in the 'package.json' files needs to get bumped, the following statement can be used:
+
+```bash
+yarn version
+```
+
+#### 4. Merge from dev into main branch
+
+The merge from dev into main, via pull request, needs to happen before releasing.
+This is only necessary for repositories with a dev branch e.g., tx-portal-frontend and tx-portal-frontend-registration.
+
+## Build of a versioned image
+
+It's important to pull the latest state from main of every repository.
+Then a tag for the released version (e.g. v0.10.0) needs to be created and pushed.
+The push of the tag triggers the release workflow action (available in every repository) which creates the versioned image/s.
+
+## Release of a new helm chart version
+
+Once the versioned images are available, they can be referenced in the portal helm chart and a new version of the chart can be released.
+The consortia specific helm chart is released from the 'helm environments' branch available in the https://github.com/catenax-ng/tx-portal-cd fork.
+The official portal helm chart is released from the main branch of https://github.com/eclipse-tractusx/portal-cd.
+
+## Merge upstream to eclipse-tractusx
+
+Once a new version has been released, it should be merged upstream to eclipse-tractusx and tagged.
+
+The relevant frontend repositories are the following:
+
+* https://github.com/eclipse-tractusx/portal-frontend
+* https://github.com/eclipse-tractusx/portal-frontend-registration
+* https://github.com/eclipse-tractusx/portal-assets
+
+The relevant backend repository is the following:
+
+* https://github.com/eclipse-tractusx/portal-backend
diff --git a/developer/Technical Documentation/Operations/test.md b/developer/Technical Documentation/Operations/test.md
new file mode 100644
index 000000000..05a15c7b7
--- /dev/null
+++ b/developer/Technical Documentation/Operations/test.md
@@ -0,0 +1,27 @@
+## Summary
+
+
+
+
+
+## Unit Tests
+
+Unit tests are available for backend and frontend components and getting automatically executed as part of the code commits inside the CX NG.
+
+
+
+
+## Test Automation
+
+Test Automation as part of functional e2e tests are planned for upcomming releases.
+Currently all tests are manually handled.
+
+
+
+
+## Manual Tests
+
+Manual tests are executed and documented inside the Catena-X consortia. Currently, manual tests are not open source available.
+
+
+
diff --git a/developer/Technical Documentation/Others/Document Management.md b/developer/Technical Documentation/Others/Document Management.md
new file mode 100644
index 000000000..4c2f38ae2
--- /dev/null
+++ b/developer/Technical Documentation/Others/Document Management.md
@@ -0,0 +1,133 @@
+# Summary
+
+Inside the portal, we have a number of different places to
+
+* upload documents
+* view documents
+* delete documents
+
+
+Documents can be templates, but also signed contracts The uploaded documents must be .pdf documents.
+
+In the DB table we have differentiated between documents which are uploaded by a customer because the document is signed or used as legitimation and those kind of documents which are templates.
+
+
+Example User Flow which is supported by the document controller:
+
+
+
+
+
+
+# Solution Details
+
+## Database
+
+Documents are managed inside the postgresql db.
+
+Mainly 4 tables are used for the documents itself
+
+* documents
+* document_types
+* document_status
+* offer_assigned_documents
+* agreement_assigned_documents
+
+
+
+
+
+
+
+
+## Document Storage
+
+The uploaded documents are getting stored in the postgresql db.
+Its possible to change this in a later stage to another tool such as a document storage of any cloud provider or a network/local file store. Storing on dev and int the documents inside the db is providing the necessary flexibility by still considering document access limitations/security.
+
+
+
+
+## Document Deletion
+
+The document deletion is designed and implemented in a very limited functionality. The reason of the limitation is extremely relevant since the documents are mostly legal binding agreements, contracts or authentication certificates.
+The deletion of legal binding documents will lead to an immense issue on the audit area, if not done carefully.
+Based on the reasons above, the document deletion is handled in 2 different functions
+
+
+* Deletion triggered by the enduser
+ The deletion triggered by the enduser is possible as long as the document is in status "PENDING". As soon as any other state is reached the deletion wont be possible anymore.
+
+* Deletion triggered by an automatic job running at a specific time (batch job)
+ Specific configured batch job running nigthly to delete INACTIVE documents with a certain age.
+
+
+
+
+## Document Storage Size
+
+Uploading documents is limited to 8MB. The configuration for the maximum file size is set in ingress (nginx). See the last line in the screenshot below:
+
+
+
+
+Additionally document size validation on FE was implemented lately where the size depends on the process.
+Inside the registration sizes can be following:
+
+* Registration => up to 8MB
+* App Release Process => up to 1MB
+* etc.
+
+
+
+
+# Implementation Details
+
+## #1 Get Documents
+
+Documents can get retrieved in the registration and administration service backend for a specific application id.
+
+
+```diff
+! GET /api/registration/application/{applicationId}/documentType/{documentTypeId}/documents
+```
+
+
+
+
+## #2 POST Document
+
+Store documents inside the document table in portal.
+Document will get stored with linkage to the user and document type.
+
+
+```diff
+! POST /api/registration/application/{applicationId}/documentType/{documentTypeId}/documents
+```
+
+```diff
+! PUT: /api/apps/appreleaseprocess/updateappdoc/{appId}/documentType/{documentTypeId}/documents
+```
+
+
+
+
+## #3 Ad-Hoc Delete Documents
+
+As mentioned above, the deletion triggered by the enduser is possible as long as the document is in status "PENDING". As soon as any other state is reached the deletion wont be possible anymore.
+
+
+```diff
+! Delete: /api/registration/documents/{documentId}
+```
+
+
+
+
+## #4 Batch Delete Documents
+
+Scheduled deletion job, configurable to run overnight.
+
+
+
+
diff --git a/developer/Technical Documentation/Others/Email Templates.md b/developer/Technical Documentation/Others/Email Templates.md
new file mode 100644
index 000000000..f96811107
--- /dev/null
+++ b/developer/Technical Documentation/Others/Email Templates.md
@@ -0,0 +1,106 @@
+# Email Templates
+
+## Summary
+As part of the Catena-X shared services, a number of E-Mail messages are send to the customer / business partner.
+On this page a summary is provided on which Email Templates are available and used
+
+* Email Service
+* Email Templates
+* E-Mail Frame Template
+* E-Mail Invite for Registration
+* E-Mail Invite additional Users
+* E-Mail Submitted Registration & Next Steps
+* E-Mail Welcome to Catena-X - Join the Network
+* E-Mail Passwort Reset
+* E-Mail Invite New User to Portal
+* E-Mail Template implementations
+
+
+GitHub Email Template Storage: https://github.com/tractusx-team-portal-onboarding/tractusx/tree/feature/CAX-portal/portal/code/tractus-x-portal/Email%20Template
+
+
+
+## Email Service
+Email templates implemented at Portal Backend side. Templates are prepared as a HTML file and emails sent via API upon corresponding business logic steps.
+
+For development and test environments, a Catena-X email mailbox is available to send and receive emails.
+The mailbox is managed by the portal team. If you have questions or want to use the service, please contact the PO Julia Jeroch
+
+
+Currently the service is used by
+
+* Traceability (Markus Kreuz; Thomas Braun)
+* Portal
+
+
+
+## Email Templates
+
+### E-Mail Frame Template
+currently under change
+
+...
+
+
+
+
+### E-Mail Invite for Registration
+Email Trigger: Invite of a new Business Partner by the CX Admin
+
+
+
+
+
+
+
+### E-Mail Invite additional Users
+Email Trigger: Invite of a team member to the registration process by the company admin.
+
+...
+
+
+
+
+### E-Mail Submitted Registration & Next Steps
+Email Trigger: User clicked "Submit" button in the last step of the Registration Flow
+
+
+
+
+
+
+### E-Mail Welcome to Catena-X - Join the Network
+Email Trigger: CX Admin has approved Company Registration request.
+
+...
+
+
+
+
+### E-Mail Passwort Reset
+Email Trigger: Shared IdP User is selecting "Password reset" on the login screen
+
+...
+
+
+
+
+### E-Mail Invite New User to Portal
+Email Trigger: Admin User is inviting inside the Portal User Management a new user into Catena-X
+
+...
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
diff --git a/developer/Technical Documentation/Others/Notifications.md b/developer/Technical Documentation/Others/Notifications.md
new file mode 100644
index 000000000..0bdb7fcf0
--- /dev/null
+++ b/developer/Technical Documentation/Others/Notifications.md
@@ -0,0 +1,310 @@
+## Summary
+
+Notification Services are used to send messages to one or several users. Usually notification services are known as push services, where a system/application is pushing notifications to a mobile device of the user.
+In CX, the idea of push notification to a mobile device is something which is currently not in scope of the implementation, however the initial service of notifications inside the portal is planned as an mvp for Release 2/3.
+
+
+
+
+## Architecture
+
+
+
+
+
+
+## Design
+
+##### Elements
+
+
+
+++ highlight messages which have read status "false"
+++ enable urls inside the message
+++ user navigation count is red, if messages with needed actions are unread
+
+
+
+##### WebApplication User Interface
+
+###### User Navigation
+
+Scenario 1
+If unread messages are "0" the notification icon wont show up. Instead only the user icon will be displayed
+
+
+
+
+
+Scenario 2
+If unread messages are > 0 AND the actionRequired are = 0; the user icon with notification "false" state will get displayed. Inside the notification count bubble the number of "unread" messages will be shown.
+
+
+
+
+
+Scenario 3
+If unread messages are > 0 AND the actionRequired are > 0; the user icon with notification "true" state will get displayed. Inside the notification count bubble the number of "actionRequired" messages will be shown.
+
+
+
+
+
+###### Notification Screen
+
+
+
+
+
+###### Filtering
+
+
+
+
+
+###### Deletion Process for "Action Required" Notifications
+
+
+
+
+
+
+
+
+## Implementation Details
+
+### Database
+
+
+
+
+
+Important: the notification message is not available/stored inside the database; instead the db is only storing message metadata and the actual message text is handled inside the FE translation file located in the following repo structure.
+Front-End repo cx-portal/src/assets/locales/en/notification.json
+
+
+
+
+### #1 Get User Notification Count
+
+The get user notification count job is used to fetch the count of unread notifications, as soon as the user logs in to the CX Network.
+Via the user token, all relevant information will get fetched from the portal db and getting displayed in the user account.
+
+
+```diff
+! GET /api/notification/count-details
+```
+
+
+
+
+### #2 Get User Notification Count-Details
+
+With the user notification details, read and unread count per filter can get fetched.
+
+The endpoint is a pure calculation/counting of the different metadata found below:
+
+* read
+* unread
+* infoUnread
+* offerUnread
+* actionRequired
+
+
+```diff
+! GET /api/notification/count-details
+```
+
+
+
+
+### #3 Get User Notification Details
+
+The get user notification details is following the "get user notification count" job.
+The details job will only run when the user is clicking on the notification sub-menu.
+The endpoint supports pagination inside the metadata section.
+
+
+Additionally the endpoint supports to
+
+* only get read messages
+* only get unread messages
+* get only a specific notification type
+* get only due notifications
+* sorting by date and read status
+
+
+```diff
+! GET /api/notification
+```
+
+
+
+Response Body
+Please note, the "content" text is only an example, each service has its own content attributes defined. Details to the actual content can get found here: /notificationDetails
+
+ {
+ "meta": {
+ "totalElements": ##,
+ "totalPages": ##,
+ "page": ##,
+ "contentSize": ##
+ },
+ "content": [
+ {
+ "id": "uuid",
+ "created": "date",
+ "typeId": "label",
+ "notificationTopic": "label",
+ "isRead": false or true,
+ "content": "{\"OfferId\":\"uuid\",\"CompanyName\":\"string\",\"OfferName\":\"string\"}",
+ "dueDate": null or date
+ }
+ ]
+ }
+
+
+
+
+### #4 PUT User Notification "read" / "unread"
+
+The user can select a notification inside the notification screen and put that notification to "read" or "unread".
+This will impact the notification count of #1. Since #1 will only show those notification as "new" or "to be checked" notifications which are not set to "read"
+
+
+```diff
+! PUT /api/notification/read or /api/notification/read?notificationStatusId=UNREAD
+! PUT /api/notification/read or /api/notification/read?notificationStatusId=READ
+```
+
+
+
+
+### #5 POST User notification
+
+The post user notification API is a input api only. Means its used in the current project phase to validate the notification service/behavior.
+
+
+```diff
+! POST /api/notification/{companyUserId:guid}
+```
+
+
+
+
+### #6 DELETE User notification
+
+With the delete user notification, a notification can get deleted. The function is triggered by the user himself and will be executed without any chance for notification recovery.
+
+
+```diff
+! DELETE /api/notification/{notificationId:guid}
+```
+
+
+
+
+### #7 Implemented Sorting feature
+
+User can sort results based on given sorting possibilities. The sorting will act jointly with the view component.
+Means, if the user did selected the view "Info Only" and now wants to also sort the results; the sorting will get executed on the view "info only" and not on all notifications.
+Therefore following endpoints are implemented:
+
+
+###### VIEW ALL (inside the filter)
+Newest first: {hostname}/api/Notification?page=0&size=15&onlyDueDate=true&sorting=DateDesc
+Oldest first. {hostname}/api/Notification?page=0&size=15&sorting=DateAsc
+Unread first: {hostname}/api/Notification?page=0&size=15&sorting=ReadStatusAsc
+
+
+
+###### VIEW APP (inside the filter)
+Newest first: {hostname}/api/Notification?page=0&size=15¬ificationTopic=OFFER&sorting=DateDesc
+Oldest first. {hostname}/api/Notification?page=0&size=15¬ificationTopic=OFFER&sorting=DateAsc
+Unread first: {hostname}/api/Notification?page=0&size=15¬ificationTopic=OFFER&sorting=ReadStatusAsc
+
+
+
+###### VIEW Info (inside the filter)
+Newest first: {hostname}/api/Notification?page=0&size=15¬ificationTopic=INFO&sorting=DateDesc
+Oldest first. {hostname}/api/Notification?page=0&size=15¬ificationTopic=INFO&sorting=DateAsc
+Unread first: {hostname}/api/Notification?page=0&size=15¬ificationTopic=INFO&sorting=ReadStatusAsc
+
+
+
+###### View Action Required (inside the filter)
+Newest first: {hostname}/api/Notification?page=0&size=15 ¬ificationTopic=ACTION&sorting=DateDesc
+Oldest first. {hostname}/api/Notification?page=0&size=15& notificationTopic=ACTION&sorting=DateAsc
+Unread first: {hostname}/api/Notification?page=0&size=15& notificationTopic=ACTION&sorting=ReadStatusAsc
+
+
+
+
+### #8 Implemented Views
+
+....
+
+
+
+
+
+
+When the user is opening the page "All" is preselected and the notification as per the endpoint:
+https://portal-backend.dev.demo.catena-x.net/api/Notification?page=0&size=15&sorting=DateDesc
+
+
+When the user clicks on the view tag "app only" notification as per the endpoint are showing app:
+https://portal-backend.dev.demo.catena-x.net/api/Notification?page=0&size=15¬ificationTopic=OFFER&sorting=DateDesc
+
+
+When the user clicks on the view tag "info only" notification as per the endpoint are showing app:
+https://portal-backend.dev.demo.catena-x.net/api/Notification?page=0&size=15¬ificationTopic=INFO&sorting=DateDesc
+
+
+When the user clicks on the view tag "messaged with action required" notification as per the endpoint are showing app:
+https://portal-backend.dev.demo.catena-x.net/api/Notification?page=0&size=15&onlyDueDate=true&sorting=DateDesc
+
+
+
+
+## Configuration
+
+### Notification Types / Messages
+
+#### Welcome
+Welcome Messages, triggered by the api endpoint
+* PUT api/administration/registration/application/{applicationId}/approveRequest
+
+1 | 2 | 3 | 4 | 5
+-------- | -------- | -------- | -------- | --------
+INFO | WELCOME | n/a | Triggered from the FE locales file Welcome to the Catena-X Network. To easily get you onboarded, a number of notifications / onboarding steps have been defined. Please check your notifications and start the configuration of your company area inside the portal to have a network experience based on your need. | New Registered Company Admin
+INFO | WELCOME_USE_CASES | n/a | Triggered from the FE locales file The network is quite huge, we want to ensure that you can focus on your preferred use cases. Select your preferred use case from the table below. | New Registered Company Admin
+INFO | WELCOME_SERVICE_PROVIDER | n/a | Triggered from the FE locales file If you need a service provider to help you with setting up your dataspace or an EDC, just follow us to the Service Provider Marketplace LINK | New Registered Company Admin
+INFO | WELCOME_CONNECTOR_REGISTRATION | n/a | Triggered from the FE locales file You do not have any registered Connector so far – have a look at the connector offers and get your connector to participate. LINK | New Registered Company Admin
+INFO | WELCOME_APP_MARKETPLACE | n/a | Triggered from the FE locales file Get a first inside into available apps, just follow us to the marketplace for apps. LINK | New Registered Company Admin
+
+
+
+
+#### Offer Subscription
+Offer Subscription Messages, triggered by the api endpoint
+
+* POST api/apps/{appID}/subscribe
+* POST api/apps/{serviceID}/subscribe
+* PUT api/apps/{appID}/subscription/company/{companyId}/activate
+* ----autosetup----
+
+1 | 2 | 3 | 4 | 5
+-------- | -------- | -------- | -------- | --------
+OFFER | APP_SUBSCRIPTION_REQUEST | OfferId: {offer.id} CompanyName: {companies.name} OfferName: {offer.name} | Triggered from the FE locales file A new app subscription request was triggered by {requestorCompanyName}. Get in contact with {userEmail} to agree on the app usage and setup guidelines. As soon as this is done, you can activate the app for {requestorCompanyName} here: LINK | App Provider - User documented as "Sales Manager"
+OFFER | APP_SUBSCRIPTION_ACTIVATION | OfferId: {offer.id} | Triggered from the FE locales file App {AppName} go activated, you can now assign user permission to this app. LINK | App Subscription Requester
+OFFER | SERVICE_SUBSCRIPTION_REQUEST | OfferId: {offer.id} RequestorCompanyName: {companies.name} AppName: {offer.name} UserEmail: {company_user.mail} AutoSetupExecuted: {status} AutoSetupError: {status} | Triggered from the FE locales file A new app subscription request was triggered by {requestorCompanyName}. Get in contact with {userEmail} to agree on the app usage and setup guidelines. As soon as this is done, you can activate the service for {requestorCompanyName} here: LINK | Service Provider - User documented as "Sales Manager"
+?? | TECHNICAL_USER_CREATION | | Triggered from the FE locales file ??? | Service Subscription Requester
+OFFER | SERVICE_SUBSCRIPTION_ACTIVATION | OfferId: {offer.id} | Triggered from the FE locales file | Service {ServiceName} go activated. Manage your subscriptions via the following service management panel: LINK | Service Subscription Requester
+
+
+Missing inside the documentation:
+* CONNECTOR_REGISTERED
+* APP_RELEASE_REQUEST
+
+
diff --git a/docs/01. Onboarding/01. Registration Invite/01. Summary.md b/docs/01. Onboarding/01. Registration Invite/01. Summary.md
new file mode 100644
index 000000000..8375d2110
--- /dev/null
+++ b/docs/01. Onboarding/01. Registration Invite/01. Summary.md
@@ -0,0 +1,18 @@
+## Summary
+
+In the initial implementation of the reference implementation, possible network participants need to get actively invited by the CX Admin to register for the platform.
+If you want to invite one of your partners; please send an email to the Portal operator to request the company invite.
+To ensure that the operator can support with the invite; please share for the invitee following data
+
+- Company Name
+- Single Point of Contact (person who is taking over the registration of the company)
+ - First Name
+ - Last Name
+ - Email
+
+
+
+
+#### Operator Invite Flow
+
+
diff --git a/docs/01. Onboarding/01. Registration Invite/02. FAQ.md b/docs/01. Onboarding/01. Registration Invite/02. FAQ.md
new file mode 100644
index 000000000..f360d7ca5
--- /dev/null
+++ b/docs/01. Onboarding/01. Registration Invite/02. FAQ.md
@@ -0,0 +1,25 @@
+# FAQ
+
+
+
+## How can I invite a potential new Catena-X member?
+In the first implementation level, Catena-X members can get invited by the operator only.
+a potential new membership can get initiated by existing members by writing a email to the operator and request the invite. Please make sure that you mention the
+* Company Name
+* Contact Person
+ * Email
+ * First Name
+ * Last Name
+
+
+
+## Can I identify already invited members?
+Normal users can not identify companies which are currently in the registration process, but as soon as the registration is finished, the membership will be visible via the partner network.
+If you go to the partner network and search for a company, check out the membership icon. If the CX icon is displayed (example see screenshot below) the company is member of Catena-X.
+
+
+
+
+
+
+
diff --git a/docs/01. Onboarding/02. Registration/01. Login.md b/docs/01. Onboarding/02. Registration/01. Login.md
new file mode 100644
index 000000000..bc6b8ce8b
--- /dev/null
+++ b/docs/01. Onboarding/02. Registration/01. Login.md
@@ -0,0 +1,34 @@
+## Login Details
+
+
+The registration process includes the onboarding of an organization. A natural person does not need an onboarding in Catena-X.
+
+
+The registration process of an organization involves a person belonging to the organization and who is authorized acting on behalf of the organization.
+
+Pre-condition: The authorized organization onboarding party must have received a Catena-X invite and needs to have valid documents of the organization (e.g. commercial register excerpt, certifications).
+
+
+
+### Registration Login
+
+After receiving the CX invite email (incl. registration login URL and one-time-password), the user can directly start the login to the company registration.
+
+
+
+
+
+After selecting the company for login; the user can login via the email and password (first time; the one-time-password shared via email)
+
+
+
+
+After the successfull login; the user can directly start to proceed with the company registration form.
+
+
+
+
+### Portal Login
+
+no change / update; same design as used for the registration
+
diff --git a/docs/01. Onboarding/02. Registration/02. Add Company Data.md b/docs/01. Onboarding/02. Registration/02. Add Company Data.md
new file mode 100644
index 000000000..5d03f54a3
--- /dev/null
+++ b/docs/01. Onboarding/02. Registration/02. Add Company Data.md
@@ -0,0 +1,20 @@
+#### Add Company Data
+
+The first application form page is expecting the company data.
+Two options are available:
+- add company data manually
+- use your business partner number (if known) to auto fill the company data
+
+
+
+
+
+In case the manual data entering is used, the user will need to enter
+- Company Name
+- Legal Address
+ - Street
+ - House Number (if relevant)
+ - ZipCode
+ - City
+ - Country
+ - Country specific unique id (such as tax id or commercial register number)
diff --git a/docs/01. Onboarding/02. Registration/03. Add Additional User(s).md b/docs/01. Onboarding/02. Registration/03. Add Additional User(s).md
new file mode 100644
index 000000000..7a31d7f16
--- /dev/null
+++ b/docs/01. Onboarding/02. Registration/03. Add Additional User(s).md
@@ -0,0 +1,18 @@
+#### Invite additional users
+
+#optional step#
+
+The 2nd step inside the registration form is optional. Means, the user can invite additional company members if support in the registration is needed.
+Normally this should only be relevant if an user is not authorized to finish the registration in the name of the company. E.g. missing rights to agree to terms and conditions or similar scenarios.
+
+
+
+
+
+
+
diff --git a/docs/01. Onboarding/02. Registration/04. Company Role & Consent.md b/docs/01. Onboarding/02. Registration/04. Company Role & Consent.md
new file mode 100644
index 000000000..698676984
--- /dev/null
+++ b/docs/01. Onboarding/02. Registration/04. Company Role & Consent.md
@@ -0,0 +1,10 @@
+#### Company Role & Terms and Conditions
+
+Under step 3 "Company Roles & Agreements" the applicator is requested to select the company role with which the application company want to participate inside the network. Beside the "Active Participant", "App Provider" and "Service Provider" are available. Depending on the role, the network agreements/terms and conditions which the application company needs to agree on are getting displayed. Also, the role i relevant to manage the respective access rights/permissions which the application company will receive inside the Catena-X network.
+The role can get easily enhanced in future by enhancing or reducing the role inside the company configuration (available inside the CX Portal).
+
+
+
+
+
+
diff --git a/docs/01. Onboarding/02. Registration/05. Document Upload.md b/docs/01. Onboarding/02. Registration/05. Document Upload.md
new file mode 100644
index 000000000..0adb33617
--- /dev/null
+++ b/docs/01. Onboarding/02. Registration/05. Document Upload.md
@@ -0,0 +1,11 @@
+#### Document upload
+
+In Step 4, the users are asked to upload the company identification.
+
+All documents uploaded under the same application register form are shown. If a second user has already uploaded a doc, the user will be able to see as well as delete this document as weel; as long as the users belong to the same company application.
+
+
+
+
+
+
diff --git a/docs/01. Onboarding/02. Registration/06. Verify Registration Data.md b/docs/01. Onboarding/02. Registration/06. Verify Registration Data.md
new file mode 100644
index 000000000..5bcd2d58f
--- /dev/null
+++ b/docs/01. Onboarding/02. Registration/06. Verify Registration Data.md
@@ -0,0 +1,13 @@
+#### Submit company data
+
+The last step of the company application is the verification of the data.
+The user can revalidate if al data are correctly added. In case anything is wrong or missing, the "back" button will support to update any entered data.
+
+
+With the submit of the application, the application form is getting closed and the company application data are submitted for review to the platform operator. The application verification will run through a number of identification validations as well as technical setup to enable the company to participate inside the dataspace.
+
+
+
+
+
+
diff --git a/docs/01. Onboarding/02. Registration/07. FAQ.md b/docs/01. Onboarding/02. Registration/07. FAQ.md
new file mode 100644
index 000000000..5e9a6cd51
--- /dev/null
+++ b/docs/01. Onboarding/02. Registration/07. FAQ.md
@@ -0,0 +1,29 @@
+# FAQ
+
+
+## For what are the registration data used for?
+The company registration data are used to register the company in the network and to authenticate the legal company.
+
+
+
+## What will happen after the registration?
+As soon as the company registration got submitted, the Catena-X operator will validate the data for correctnes and start the automatic regisration process. This includes the legal validation, the Gaia-X compliance check as well as the creation of the company account.
+The process can take up to 48 hours. As soon as the process is successfully processed, the user will get informed and the access to the network will be given. All details are getting shared via email.
+
+
+
+## Do I need to do the registration in one flow or can i pause in between?
+You can pause with the company registration whenever you want. To proceed with the registration, just login with your own credentials and you will be able to proceed where you finished.
+
+
+
+## What can I do, if I dont have all necessary information available, which are needed to register my company?
+Whenever you want, you can pause the registration.
+If pausing the registration is not enough, you can also use the optional step #2 and invite another person to support the registration. E.g. a person with the necessary permission level to provide the necessary approvals or to upload the necessary documents.
+
+
+
+## Why do I always receive a message / warning screen when logging in to the registration form of my company.
+In case the registration is already submitted for validation; the company wont be able to change / adjust any company registration relevant data anymore. The registration form is officially closed and the user need to wait for the registration form validation to finish.
+
+
diff --git a/docs/01. Onboarding/03. Registration Approval/01. Summary .md b/docs/01. Onboarding/03. Registration Approval/01. Summary .md
new file mode 100644
index 000000000..45bb2b37f
--- /dev/null
+++ b/docs/01. Onboarding/03. Registration Approval/01. Summary .md
@@ -0,0 +1,11 @@
+## Summary
+
+The registration approval board is created for the CX Admin to managed registration applications to the Catena-X network.
+
+Acting user: CX Admin (Operator)
+
+
+The board supports filter, serach and the actual approval / validation function of new company registration requests.
+
+
+
diff --git a/docs/01. Onboarding/03. Registration Approval/02. View Company Application(s).md b/docs/01. Onboarding/03. Registration Approval/02. View Company Application(s).md
new file mode 100644
index 000000000..b60e0b983
--- /dev/null
+++ b/docs/01. Onboarding/03. Registration Approval/02. View Company Application(s).md
@@ -0,0 +1,34 @@
+## View Company Application (with Details)
+
+Inside the application request board, the operator / CX Admin can view "Closed" as well as "In Review" company applications.
+
+Inside the offered board; the user can
+* view application details
+* download identification document
+* view the application approval process status
+
+
+
+
+
+### Display Application Details
+
+With using the application details button, application details such as
+
+
+
+ * Company Data
+ * Company application role
+ * Documents, and
+ * Details to the approval flow status
+
+ are displayed.
+
+
+
+
+
+Additionally the user can easily download the document by clicking on the document title (inside the overlay or on the main page)
+
+
+
diff --git a/docs/01. Onboarding/03. Registration Approval/03. Registration Approval Process.md b/docs/01. Onboarding/03. Registration Approval/03. Registration Approval Process.md
new file mode 100644
index 000000000..fd4026a4d
--- /dev/null
+++ b/docs/01. Onboarding/03. Registration Approval/03. Registration Approval Process.md
@@ -0,0 +1,296 @@
+## Registration Approval Flow
+
+The company registration approval flow is covering the manual and automatic check of the company application including the setup of the company to participate inside the dataspace.
+
+The list below shows an overview of all application approval steps:
+
+
+
+
+
+
+
+
+
+As highlevel displayed above; the registration approval flow consist out of 6 steps. Which can partially run in parallel or must run in the predefined sequence.
+The six registration approval flow steps are implemented in a kind of an checklist worker which automatically triggers the relevant services as per the current state of the company application. To ensure that the operator knows the status of the company application, each step can be in the status
+
+ * Open
+ * In Progress
+ * Done
+ * Failed
+
+In case of an failed scenario; the error code (if available) is getting recorded for the registration application workflow step and can get viewed by the operator.
+
+
+
+##### Details "Manual Validation"
+
+The "manual validation" checklist item is covering the company application validation by the operator. In this step the application gets manually checked and 'approved' or 'declined'.
+Depending on the decision the checklist item "Registration_Verification" is set to DONE or FAILED.
+
+In the scenario of FAILED, a comment/message can get submitted by the operator and provided/send via email to the company application party.
+
+
+
+###### Scenario: Approve
+
+The endpoint "approve" sets the "Registration_Verification" checklist item to "DONE".
+The endpoint can only get triggered/executed if the application is in status "submitted" and the "Registration_Verification" in Status "TO_DO"
+
+
+```diff
+! PUT /api/administration/registration/application/{applicationId}/approve
+```
+
+
+
+
+###### Scenario: Decline
+
+
+
+
+
+The endpoint "decline" sets the "Registration_Verification" checklist item to "FAILED" incl. a time stamp, as well as the decline message added by the operator.
+The endpoint can only get triggered/executed if the application is in status "submitted" and the "Registration_Verification" in Status "TO_DO".
+
+
+```diff
+! PUT /api/administration/registration/application/{applicationId}/decline
+```
+
+Request Body:
+
+ {
+ "comment": "string"
+ }
+
+
+
+
+##### Details "Create Business Partner Number (if necessary)"
+
+The status "Business_Partner_Number" is getting updated based on the application registration content.
+
+
+
+
+###### Scenario 1 - Registration with BPN
+
+If the registration application is getting submitted by the registration party for approval with an BPN, the checklist item "Business Partner Number" is getting set to "DONE".
+In this case; nothing is needed anymore regarding the business partner number checklist item.
+
+
+
+###### Scenario 2 - Registration without BPN
+
+If the registration application is getting submitted by the registration party for approval without an BPN, the checklist item "Business Partner Number" is kept in status "TO_DO"
+
+In this case; the checklist item worker will fetch the application when running and submit the company data of the registration company to the business partner golden record gateway to validate the record and to generate a business partner number.
+
+
+```diff
+! POST /api/administration/registration/application/{applicationId}/trigger-bpn
+```
+
+the checklist item "Business Partner Number" is getting set to "IN_PROGRESS", till a BPN is received (currently not yet implemented)
+
+
+
+ Please note - in the current implementation the bpn gate response does mainly handle success scenarios. In the Scenario of an fail (due to incorrect/not matching company data) the failure response is not yet available and will be delivered by the bpdm product team asap.
+
+
+
+
+###### Scenario 3 - manually add BPN as operator (interim supported workflow)
+
+For the interim process of the need to add the BPN of the new CX participant manually, the operator can use the endpoint to add the business partner number to the application.
+This endpoint is an interim endpoint only and supposed to get disabled; as soon as the BPN Gateway is providing a stable feedback on provided company data.
+
+
+```diff
+! POST /api/administration/registration/application/{applicationId}/{bpn}/bpn
+```
+
+
+
+
+##### Details "Create Managed Identity Wallet"
+
+After the checklist item "Registration_Verification" status is set to "DONE", as well as the status of the "Business_Partner_Number" automatically the IF to the identity wallet is getting triggered to create the company identity wallet.
+Details to the company identity wallet can get found inside the identity wallet product description.
+
+With triggering the registration; the company name as well as the bpn are getting submitted and stored inside the company wallet.
+
+Depending on the API response, the system will behave in the following way:
+
+- Response "Fail" => store the error message in the checklist table under checklist.comment and set the status to "FAILED"
+- Response "Success" => set status to "DONE" and store the did provided by the response body inside the comment attribute inside the table checklist.comment
+
+
+ Please note: the scenario of "bring your own company wallet" is currently not supported and will get rechecked in H2 2023.
+
+
+
+
+##### Details "Clearinghouse Check"
+
+The "Clearinghouse Check" is getting automatically triggered when following pre-requisites are fullfilled:
+
+
+* application checklist status "Business_Partner_Number" = "DONE"
+* application checklist status "Registration_Verification" = "DONE"
+* application checklist status "Identity_Wallet" = "DONE"
+* application is in status "submitted"
+
+
+
+
+
+The interface is an asyncron interface - due to this; the interface is explained below in two steps
+
+
+
+
+###### Step 1 - manually add BPN as operator (interim supported workflow)
+
+```diff
+PUT /api/administration/registration/application/{applicationId}/trigger-clearinghouse
+```
+
+Submitted body to clearinghouse endpoint (content is created on backend side only; no FE interaction)
+
+ {
+ "participantDetails": {
+ "name": "string",
+ "city": "string",
+ "street": "string",
+ "bpn": "string",
+ "region": "string",
+ "zipCode": "string",
+ "country": "string",
+ "countryAlpha2Code": "string"
+ },
+ "identityDetails": {
+ "did": "string",
+ "uniqueIds": [
+ {
+ "type": "string",
+ "value": "string"
+ }
+ ]
+ }
+ }
+
+
+
+
+###### Step 2 - Clearinghouse response
+
+In the asyncron call of the clearinhouse check; the portal provices an POST endpoint, which can get triggered by the clearinghouse to update the checklist status.
+
+
+the clearinghouse need to be able to store an fail/success message. the message is supposed to get stored inside the checklist comment of the record attribute "clearing_house"
+
+
+```diff
+! PUT ????
+```
+
+ {
+ "bpn": "string",
+ "status": "string",
+ "message": "string"
+ }
+
+
+The bpn inside the request body is used to fetch the correct application Id. (application in status "submitted")
+The status can only get changed/updated; if the status of the application checklist attribute "clearing_house" is "IN_PROGRESS".
+
+
+
+
+##### Details "Self-Description Creation LegalPerson"
+
+The "Self_Description_Legal_Person" is getting automatically triggered when following pre-requisites are fullfilled:
+
+
+* application checklist status "Business_Partner_Number" = "DONE"
+* application checklist status "Registration_Verification" = "DONE"
+* application checklist status "Identity_Wallet" = "DONE"
+* application checklist status "Clearinghouse_Check" = "DONE"
+* application checklist status "Self_Description_LP" = "TO_DO"
+* application is in status "submitted"
+
+
+with the endpoint; the SD Factory is getting triggered and a self description of the legal person is getting submitted back. The portal backend is storing the self-description inside the portal db linked to the company.
+
+
+With triggering the endpoint, the status of the checklist item "Self_Description_LP" is set to "IN_PROGRESS"
+
+
+Response "Error" => store the error message in the checklist table under checklist.comment and set the status to "FAILED"
+Response "Success" => set status to "DONE"
+
+
+ "registratioNumber": [
+
+ {
+ "type":"technicalKey",
+ "value":"value from db"
+ }
+ ]
+
+
+
+###### DB Table Content
+
+ID | Portal DB Key | Interface Key for SD
+------------- | ------------- | -------------
+1 | COMMERCIAL_REG_NUMBER | local
+2 | VAT_ID | vatID
+3 | LEI_CODE | leiCode
+4 | VIES | EUID
+5 | EORI | EORI
+
+
+
+
+##### Details "Activation"
+
+The complete company account activation (as result of the successful application checklist finalization) is automatically executed when following pre-requisites are fullfilled:
+
+
+* application checklist status "Business_Partner_Number" = "DONE"
+* application checklist status "Registration_Verification" = "DONE"
+* application checklist status "Identity_Wallet" = "DONE"
+* application checklist status "Clearinghouse_Check" = "DONE"
+* application checklist status "Self_Description_LP" = "DONE"
+* application is in status "submitted"
+
+
+With the execution of the application activation, the system will:
+
+* set company status inside portal.companies to "ACTIVE"
+* set application status inside portal.company_application to"CONFIRMED"
+* set company_application time stamp
+* set invitation of all users to "CLOSED"
+* set invitation time stamp
+* update user roles (portal db and keycloak)
+* add bpn to user(s)
+* send welcome email
+
+
+
+
+### Add/Update BPN for the registration company
+
+The bpn can get manually added (as an workaround) if the registration company request doesnt have a business partner number added and the registration request is in status "submitted".
+
+
+
+BPNs can only get added by CX Admin's.
+As mentioned above, the implementation is a workaround only and will get replaced by the actual bpn connection as soon as the reference implementation is available.
+
+
diff --git a/docs/01. Onboarding/03. Registration Approval/04. Decline Application.md b/docs/01. Onboarding/03. Registration Approval/04. Decline Application.md
new file mode 100644
index 000000000..2e316452d
--- /dev/null
+++ b/docs/01. Onboarding/03. Registration Approval/04. Decline Application.md
@@ -0,0 +1,16 @@
+## Decline Company Application
+
+While the company application is processing the application validations; the administrator can decline the application whenever wanted.
+To decline the application the "Cancel Application" Button is enabled for all applications which did not reach the "CONFIRMED" / "DECLINED" status so far.
+
+
+
+
+
+
+> **Warning**
+> In the current state of implementation the checklist worker and manual process intervention such as the cancellation have no validation/check implemented where the services can validate if the other service might already run. Means; in the unlikely case that the cancellation is triggered while the activation is running in parallel; the activation might overrule the cancellation.
+> The scenario is very unlikely and will get handled in an upcomming release.
+
+
+
diff --git a/docs/01. Onboarding/03. Registration Approval/05. FAQ.md b/docs/01. Onboarding/03. Registration Approval/05. FAQ.md
new file mode 100644
index 000000000..ec6c1da5b
--- /dev/null
+++ b/docs/01. Onboarding/03. Registration Approval/05. FAQ.md
@@ -0,0 +1,17 @@
+## FAQ
+
+### What happens if I decline an application?
+
+In case of an application "decline", the user(s) registered under the registration account are getting informed about the rejection.
+Additionally an information of the reject reason (if available) is getting shared.
+
+
+
+
+### Can I as a registration company view my registration status?
+
+The registration status itself can not get checked. The only information available is the information displayed inside the registration form that the registration is under validation.
+As soon as the validation is finished you will get informed about the next possible steps via email.
+
+
+
diff --git a/docs/01. Onboarding/index.md b/docs/01. Onboarding/index.md
new file mode 100644
index 000000000..fb31f982a
--- /dev/null
+++ b/docs/01. Onboarding/index.md
@@ -0,0 +1,20 @@
+## Onboarding
+
+The Catena-X onbaording is splitted into two section:
+
+* Regsitration
+* Technical Onbaording
+
+In this section the registration process and approval is in focus.
+
+
+
+
+
+
+
+Read more details in the following sections:
+
+- [Registration Invite](./01.%20Registration%20Invite/)
+- [Registration](./02.%20Registration/)
+- [Registration Approval](./03.%20Registration%20Approval/)
diff --git a/docs/02. Technical Integration/01. Connector Registration/00. Summary.md b/docs/02. Technical Integration/01. Connector Registration/00. Summary.md
new file mode 100644
index 000000000..706d81d2d
--- /dev/null
+++ b/docs/02. Technical Integration/01. Connector Registration/00. Summary.md
@@ -0,0 +1,17 @@
+## Summary
+
+For a full technical onboarding and to enable the network to browse through and find available data connectors, each data provider or connector owner is in ownership to register their connectors in the network which will trigger on top a self description (GAIA-X).
+
+The details below show the user interface as well as the available endpoints to trigger the registration.
+
+
+In the technical integration / setup of the connector, 3 different scenarios are available
+
+connector as a service (request a service via a service provider)
+bring your own connector
+no connector required
+
+
+Connector stakeholders are mainly app providers and data provider (active CX participants along the automotive value chain).
+
+For the scenario "bring your own connector", the user will be able to register the connector by entering the relevant information. In the case of a "connector as a service" case, the relevant data fields need to get still defined by the Product Team CaaS (not in scope for release 1)
diff --git a/docs/02. Technical Integration/01. Connector Registration/01. Connector Overview.md b/docs/02. Technical Integration/01. Connector Registration/01. Connector Overview.md
new file mode 100644
index 000000000..abcd6aba0
--- /dev/null
+++ b/docs/02. Technical Integration/01. Connector Registration/01. Connector Overview.md
@@ -0,0 +1,32 @@
+## Connector Overview
+
+Via the User Navigation (top right) administrators and technical users can access the "Connector Registration".
+Inside the connector registration area; an overview of existing connectors (always owned connectors) with theire status are displayed.
+
+Additionally the user can register easily new connectors.
+
+
+
+
+
+
+
+
+#### DAPS Auth Status
+
+
+
+
+
+#### SelfDescription Status
+
+
+
+
+
+#### Connector Status
+
+
+
+
+
diff --git a/docs/02. Technical Integration/01. Connector Registration/02. Connector Registration.md b/docs/02. Technical Integration/01. Connector Registration/02. Connector Registration.md
new file mode 100644
index 000000000..055837e13
--- /dev/null
+++ b/docs/02. Technical Integration/01. Connector Registration/02. Connector Registration.md
@@ -0,0 +1,85 @@
+## Connector Registration
+
+### Create new Connector Registration - self-owned
+
+New connector registration can get triggered/created by using the "Register Connector" function.
+
+Select the option "Connect company connector"
+
+
+
+
+
+
+
+Click "Next" and enter the following data:
+* Connector Name (own defined and only used for own reference)
+* Connector URL (endpoint under which the connector can get reached)
+* Location (2digit country code - ISO)
+* Public Authentication Key Upload - [get help to generate the publik key](./07.%20FAQ.md)
+
+
+
+
+
+
+
+Click "Confirm" as soon as all data are added.
+
+
+
+The connector registration will automatically trigger the daps certificate via the public key which was uploaded by the user. Same applies for the Self-Description of the connector.
+
+
+
+In case the DAPS is failing, the connector will still get registered and DAPS registration will be hold on "PENDING". In the scenario of an PENDING connector; the user will be enabled to retrigger the missing service registration (in this case DAPS) to enable the usage of the connector inside the network fully.
+
+
+
+
+### Create new Connector Registration - managed
+
+In the scenario of a managed connector; the customer will order/purchase a managed connector via the service marketplace.
+The service provider will be able to register the connector in the name of the customer. In this scenario; the service provider might use the ui function offered by the portal or directly executes the registration via direct API call.
+
+[Connector Registration - API](./06.%20OpenAPI.md)
+
+
+
+Additionally the UI Flow is supported - see details below
+
+
+
+Initiate the connector registration by using the "Register Connector" function.
+
+Select the option "Connector-as-a-service"
+
+
+
+
+
+
+
+
+Click "Next" and enter the following data:
+* Connector Name (own defined and only used for own reference)
+* Connector URL (endpoint under which the connector can get reached)
+* Location (2digit country code - ISO)
+* Customer/Connector Owner BPNL
+* Public Authentication Key Upload - [get help to generate the publik key](./07.%20FAQ.md)
+
+
+
+
+
+
+
+Click "Confirm" as soon as all data are added.
+
+
+
+The connector registration will automatically trigger the daps certificate via the public key which was uploaded by the user. Same applies for the Self-Description of the connector.
+
+
+
+
diff --git a/docs/02. Technical Integration/01. Connector Registration/03. DAPS Registration.md b/docs/02. Technical Integration/01. Connector Registration/03. DAPS Registration.md
new file mode 100644
index 000000000..f82ef7e9f
--- /dev/null
+++ b/docs/02. Technical Integration/01. Connector Registration/03. DAPS Registration.md
@@ -0,0 +1,16 @@
+## 4 DAPS Registration
+
+In the normal connector registration flow; the daps registration is automatically triggered/executed.
+In case the DAPS registration failed (visible in the connector overview via greyed out lock icon), the user will be able to retrigger the endpoint directly.
+To retrigger daps; click on the grey lock icon to open up the overlay where the public key of the token can get uploaded.
+
+
+
+
+
+
+
+
+As soon as the user clicks confirm; the icon on the connector overview will get green and the daps auth is successfully configured for your connector.
+
+
diff --git a/docs/02. Technical Integration/01. Connector Registration/04. SelfDescription Retrigger.md b/docs/02. Technical Integration/01. Connector Registration/04. SelfDescription Retrigger.md
new file mode 100644
index 000000000..8b6ab9751
--- /dev/null
+++ b/docs/02. Technical Integration/01. Connector Registration/04. SelfDescription Retrigger.md
@@ -0,0 +1,3 @@
+#### Self Description Retrigger
+
+....under development....
diff --git a/docs/02. Technical Integration/01. Connector Registration/05. Delete Connector.md b/docs/02. Technical Integration/01. Connector Registration/05. Delete Connector.md
new file mode 100644
index 000000000..14c5e4869
--- /dev/null
+++ b/docs/02. Technical Integration/01. Connector Registration/05. Delete Connector.md
@@ -0,0 +1,16 @@
+## 5 Delete Connector
+
+Delete own connector. The deletion will disable the discovery service for the connector.
+
+
+
+
+
+
+
+
+
+Click on the delete icon to trigger the connector registration. An overlay will get displayed where the deletion need to get reconfirmed. As soon as this is done, the connector is not connected to the dataspace anymore.
+
+
+
diff --git a/docs/02. Technical Integration/01. Connector Registration/06. OpenAPI.md b/docs/02. Technical Integration/01. Connector Registration/06. OpenAPI.md
new file mode 100644
index 000000000..80248c008
--- /dev/null
+++ b/docs/02. Technical Integration/01. Connector Registration/06. OpenAPI.md
@@ -0,0 +1,53 @@
+## Open API - Create new Connector Registration - managed
+
+In the connector registration scenario OpenAPIs are offered for managed connector registration.
+To be able to run the interface, a technical user is needed which can get generated easily via the user management.
+
+[How to create a technical user](/docs/03.%20User%20Management/03.%20Technical%20User/02.%20Create%20Technical%20User.md)
+
+
+
+
+Service Provider can create a new registration for a company which subscribed for a service provider service
+
+Same as for self-owned connectors, the connector registration will automatically
+
+* register the connector in the daps authentication service (with the public key uploaded inside the connector registration UI / endpoint)
+* trigger the SD Factory to create the self-description of the connector
+
+
+
+If connector data have been successfully stored; DAPS auth has been successful and SD is created and stored; the connector record will receive the status "ACTIVE". Technical explanation: if the connector.daps_registration_successful is "true" and connector.self_description_document_id is != NULL; connector status is "ACTIVE"
+
+
+
+
+##### API Details
+
+```diff
+! POST /api/administration/connectors/managed
+```
+
+
+
+##### Request Body
+
+ {
+ "name": "string",
+ "connectorUrl": "string",
+ "location": "string",
+ "providerBpn": "string",
+ "certificate": "string"
+ }
+
+
+
+###### Provider BPN
+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
+
+###### Certificate
+only allowes .crt files
+
+
+
diff --git a/docs/02. Technical Integration/01. Connector Registration/07. FAQ.md b/docs/02. Technical Integration/01. Connector Registration/07. FAQ.md
new file mode 100644
index 000000000..08aea05a7
--- /dev/null
+++ b/docs/02. Technical Integration/01. Connector Registration/07. FAQ.md
@@ -0,0 +1,108 @@
+## FAQ
+
+### How to register a connector inside the network?
+A connector can get created via the user navigation "Connector Registration".
+
+The sub-menu is only available for company administrators.
+
+
+The connector registration will auto generate the connector self-description and the daps authentication.
+
+
+
+
+
+In the following window, select the connector type. Either "Company Connector" (own Connector) or "Connector-as-a-service" (managed Connector).
+
+
+
+
+
+After selecting the connector and pressing "confirm" the connector form gets displayed where connector details as well as the authentication key (public key) needs to get added.
+The public key is needed for the connector authentication inside the dataspace. Details to the connector authentication can get found HERE (to be added asap).
+
+
+With the successful registration, the connector is part of the dataspace. This means, the connector can get identified by other dataspace participants, as well as authentication is secured.
+
+
+
+### Whats the difference of a OWNED and a MANAGED connector?
+Owned connectors are company (own managed) connectors.
+Managed connectors are (3rd party managed) connectors, e.g. if a connector is managed by a service provider.
+
+
+
+### How can a connector get deleted?
+The deletion of a connector is similar as the registration only possible if the user has enough user permissions. Ideally the company administrator or IT admin.
+To delete a connector registered inside the network, get to the connector overview and trigger the deletion via the delete icon.
+
+
+With the successful deletion, the daps registration will get disabled and the connector wont be available in the dataspace anymore.
+
+
+
+### Why is my connector "PENDING"?
+A pending connector status shows, that the connector is not fully registered inside the dataspace yet. For example: the daps authentication might be missing or the connector provider still needs to configure the connector before the connector is fully usable.
+In case of a managed connector - please contact for any questions your service provider.
+
+
+
+### Why is my connector authentication icon green or grey?
+The connector authentication icon shows the authentication status. If the icon is grey, the authentication was unsuccessful; in this case a new authentication needs to get manually triggered. Otherwise the connector will be not useable inside the dataspace.
+A green connector icon shows the active authentication registration.
+
+
+
+
+### Whats a public key and how do I create the public key?
+Self-Signed certificates (with the public key) are relevant to crate a secure authentication between my connector and the catena-x dataspace.
+Therefore the own created public key needs to get created by the connector owner and shared with the CX dataspace authentication system.
+
+To create the public key, please follow the steps defined below:
+* Install OpenSSL or LibreSSL (509.X Zertifikat)
+* Create the keys with the following data
+ * Make sure you have your BPN and Legal Entity data of the connector owner (not the host) available
+ * URL of the connector
+
+
+
+#### Steps to install OpenSSL on mac with brew:
+
+ Step 1: Install brew
+
+ * Open terminal on your Mac
+ * Enter the command:
+ /bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"
+ * Reference link: https://brew.sh/
+
+
+
+
+
+ Step 2: Add Homebrew to your path and install openssl
+
+ Run these three commands in your terminal to add Homebrew to your PATH:
+ * echo '# Set PATH, MANPATH, etc., for Homebrew.' >> /Users/ $USER/.zprofile
+ * echo 'eval "$(/opt/homebrew/bin/brew shellenv)"' >> /Users/ $USER/.zprofile
+ * eval "$(/opt/homebrew/bin/brew shellenv)"
+
+
+
+
+
+ Then run brew update and install:
+ * brew update
+ * brew install openssl
+
+
+
+
+
+ Step 3: Navigate to the folder having openssl.cnf and run the command
+
+
+
+
+
+
+
diff --git a/docs/02. Technical Integration/02. Identity Provider Management/01. Summary.md b/docs/02. Technical Integration/02. Identity Provider Management/01. Summary.md
new file mode 100644
index 000000000..4d56cc74f
--- /dev/null
+++ b/docs/02. Technical Integration/02. Identity Provider Management/01. Summary.md
@@ -0,0 +1,13 @@
+# Summary
+
+The IdP Switch function is used to integrate / connect company idp's or switch back to catena-x shared idp usage.
+
+
+The integration of company idp's is suspected to be the most used scenario when considering the use of idp switch. Companies which want to use their own company authentication can connect their company idp with the catena-x shared idp by using user federation.
+
+
+In this scenario - authentication is delivered by the company idp and authorization is still managed inside keycloak.
+
+
+The biggest positive element on ownCompany idp usage is the comfort of the login, as well as the user credentials which are not shared with an operator.
+
diff --git a/docs/02. Technical Integration/02. Identity Provider Management/02. Configure Company IdP.md b/docs/02. Technical Integration/02. Identity Provider Management/02. Configure Company IdP.md
new file mode 100644
index 000000000..4d25b3d0a
--- /dev/null
+++ b/docs/02. Technical Integration/02. Identity Provider Management/02. Configure Company IdP.md
@@ -0,0 +1,97 @@
+# User Description
+
+How to connect the own idp:
+
+
+- Request a idp connection
+- Upload your company-idp metadata file (please note, CX will mainly support OIDC)
+- Manually add client-id and secret
+- Confirm the IdP config, we will share the authentication URL with you
+
+
+
+After successful setup, the user migration/invite need to take place, before the previous used idp is getting deactivated and deleted.
+
+
+
+Details regarding the IAM architecture (applies for shared as well as own IdP usage)
+
+
+
+
+
+
+
+
+
+
+
+### Register your company IdP
+
+To register your company idp, login with administration rights and open the "Identity Provider Config" via the top right user navigation.
+Inside the config, you will find your current registered (enabled and disabled) identity providers - quite oftne this will only be one identity provider. As well as the option to register a new identity provider (such as you company idp).
+
+
+
+
+
+
+
+
+
+
+
+ Please note - for the company identity provider conenction you will need to prepare certain information to be able to connect your company IdP. Please ansure that all necessary information are available.
+
+Currenly only the connection for OIDC idp's is supported.
+
+
+
+#### Create the new idp record
+
+Click on "Add Identity Provider" to start the registration.
+Inside the overlay a idp name will need to get added. This will be the display name of your IdP. Means users which try to login to CX will see this login option. Use a name which users can understand and know that this belongs to their company.
+
+
+
+
+
+
+
+
+By clicking on "Confirm".
+
+On the upcoming screen the idp relevant connection information need to get added.
+Those are
+- metadata url (available in your local/company IdP - ending with /.well-known/openid-configuration)
+- client ID (created in your company IdP)
+- client secret (created in your company IdP)
+
+
+
+
+
+
+
+
+if the config was sucessful, you will get asked to add your personal company idp unique identifier. In this step you will connect your exosting catena-x user account (with your already assigned roles and customized configurations) with your company IdP. To do this successfully, you need to add your company IdP unqiue ID.
+
+
+
+
+
+
+
+
+With the confirm/submit button the value will get stored successfully and you can now test the successful company IdP integration by doing a logout and trying to login with your company credentials and company IdP.
+Please note: in this moment, your user is connected with the Catena-X Shared IdP as well as your company IdP. This means, if after the logout and new login via your company IdP you might find out, that the login via the company IdP might not work (due to wrong configuration) you still can login to catena-X with the previous used IdP and correct the IdP config.
+
+
+As soon as you have successfully tested the login, please proceed with the user migration => see next chapter.
+
+
+
+PLEASE NOTE - THIS PAGE IS STILL UNDER REWORK AND WILL CHANGE IN THE UPCOMING WEEKS
+
+
+
diff --git a/docs/02. Technical Integration/02. Identity Provider Management/03. User Migration.md b/docs/02. Technical Integration/02. Identity Provider Management/03. User Migration.md
new file mode 100644
index 000000000..e8b5ed23d
--- /dev/null
+++ b/docs/02. Technical Integration/02. Identity Provider Management/03. User Migration.md
@@ -0,0 +1,39 @@
+#### Migrate existing user accounts to the new created IdP
+
+With the configuration of a new IdP, existing user accounts should not get lost. In the previous section "Create the new idp record" it was already described, how the admin user can connect his/her existing user account with the new company idp. In this section the user migration of additional available user accounts is handled.
+
+
+For the migration of additional existing user accounts, which have been created under the shared IdP previously, the administrator can call the user migration list via the IdP config page.
+
+
+
+
+
+
+
+
+By clicking on the "Users" sub-navigation icon, a overlay with the user migration list as json or csv file is getting displayed.
+
+
+
+
+
+
+
+
+Download the list and add for each user, which is supposed to get migrated, the company idp unique identifier into the list as ProviderUserID upload the list again by placing in inside the upload area and wait for the success message that all the users have been migrated / added.
+
+
+
+
+
+
+
+
+With that, the user migration is successfully done - you can validate the user list again by re-opening the users list of the IdP.
+After the successful config, the new IdP can get enabled and the old IdP can get disabled.
+
+
+
+
+PLEASE NOTE - THIS PAGE IS STILL UNDER REWORK AND WILL CHANGE IN THE UPCOMING WEEKS
diff --git a/docs/02. Technical Integration/02. Identity Provider Management/04. FAQ.md b/docs/02. Technical Integration/02. Identity Provider Management/04. FAQ.md
new file mode 100644
index 000000000..74bb7c0be
--- /dev/null
+++ b/docs/02. Technical Integration/02. Identity Provider Management/04. FAQ.md
@@ -0,0 +1,17 @@
+### FAQ
+
+
+####
+
+
+
+####
+
+
+
+####
+
+
diff --git a/docs/02. Technical Integration/03. CX Membership/01. Open API.md b/docs/02. Technical Integration/03. CX Membership/01. Open API.md
new file mode 100644
index 000000000..5abe8fe3d
--- /dev/null
+++ b/docs/02. Technical Integration/03. CX Membership/01. Open API.md
@@ -0,0 +1,38 @@
+## Open API - CX-Membership
+
+The membership discovery endpoint is used to display/retrieve all cx network members based on the bpn.
+The cx membership discovery endpoint can get triggered via technical as well as real users, if relevant roles are available.
+Technical users can get generated easily via the user management:
+
+[How to create a technical user](/docs/03.%20User%20Management/03.%20Technical%20User/02.%20Create%20Technical%20User.md)
+
+
+
+
+### Architecture Overview
+
+n/a
+
+
+
+
+### #1 application programming interface (API)
+
+```diff
+! GET api/administration/partnernetwork/memberCompanies
+```
+
+###### Request Body
+
+n/a
+
+###### Response Body
+
+the string response includes all bpn's of active network members
+
+ [
+ "string"
+ ]
+
+
+
diff --git a/docs/02. Technical Integration/04. Dataspace Discovery/01. Open API.md b/docs/02. Technical Integration/04. Dataspace Discovery/01. Open API.md
new file mode 100644
index 000000000..6e99cbf1e
--- /dev/null
+++ b/docs/02. Technical Integration/04. Dataspace Discovery/01. Open API.md
@@ -0,0 +1,58 @@
+## Open API - Connector Discovery
+
+The connector discovery endpoint can get triggered via technical as well as real users, if relevant roles are available.
+For technical user, a company can request the user creation with the technical user creation feature inside the portal.
+For details, click following link:
+
+[How to create a technical user](/docs/03.%20User%20Management/03.%20Technical%20User/02.%20Create%20Technical%20User.md)
+
+
+
+
+## Interface/API/Service Summary
+The EDC/dataspace discovery interface is a CX network public available endpoint which can get used to retrieve edc endpoints and the related BPNs, as well as search for endpoints via the BPN
+
+
+
+
+### Architecture Overview
+
+n/a
+
+
+
+
+### EDC Discovery - application programming interface (API)
+
+
+```diff
+! POST: /api/administration/connectors/discovery
+```
+
+###### Request Body
+The request body is expecting a list of BPNs for which the EDC endpoint should get be fetched. Please add minimum one BPN.
+
+
+ [
+ "string"
+ ]
+
+
+
+###### Response Body
+
+ [
+ {
+ "bpn": "string",
+ "connectorEndpoint": [
+ "string"
+ ]
+ }
+ ]
+
+
+
+In case of an empty response, no edc is found for the requested BPNs
+
+
+
diff --git a/docs/02. Technical Integration/index.md b/docs/02. Technical Integration/index.md
new file mode 100644
index 000000000..219b103ea
--- /dev/null
+++ b/docs/02. Technical Integration/index.md
@@ -0,0 +1,8 @@
+# Technical Integration
+
+The technical integration covers functionalities such as the connector registration of an company, as well as identity provider connections. Mainly those functionalities are managed by IT Managers of an company.
+Learn how to configure the technical integration items in the Catena-X Portal.
+Read more details in the following sections:
+
+- [Connector Registration](./01.%20Connector%20Registration/)
+- [Identity Provider Management](./02.%20Identity%20Provider%20Management/)
diff --git a/docs/03. User Management/01. User Account/01. Summary.md b/docs/03. User Management/01. User Account/01. Summary.md
new file mode 100644
index 000000000..f744c36da
--- /dev/null
+++ b/docs/03. User Management/01. User Account/01. Summary.md
@@ -0,0 +1,8 @@
+# Summary
+
+Company Administrators as well as IT Administrators of the company can create new user accounts.
+With the Catena-X user account, the user can access the Catena-X Portal including the apps marketspace, direct access to subscribed company apps, semantic data models, digital twins, service offers, etc.
+
+
+
+
diff --git a/docs/03. User Management/01. User Account/02. User Account.md b/docs/03. User Management/01. User Account/02. User Account.md
new file mode 100644
index 000000000..61dbac3e3
--- /dev/null
+++ b/docs/03. User Management/01. User Account/02. User Account.md
@@ -0,0 +1,12 @@
+## View company user accounts
+
+Within the user management, the Company Admin/IT Admin will be able to see a list of all org/company related users.
+Only those users created under the same company account can get viewed. Users created under a different company account are not accessible, neither viewable.
+
+
+
+
+
+
+
+
diff --git a/docs/03. User Management/01. User Account/03. Create new user account (single).md b/docs/03. User Management/01. User Account/03. Create new user account (single).md
new file mode 100644
index 000000000..a969fdc94
--- /dev/null
+++ b/docs/03. User Management/01. User Account/03. Create new user account (single).md
@@ -0,0 +1,20 @@
+## Create a new user account (single)
+
+User with the respective user management rights can access the user management via the top right user navigation.
+As soon as the user management is displayed, the user can direct via the button "Identity User Management" or scroll down the page to get to the Identity User Management section where new user accounts can get created.
+
+Select the "Add User" Button to trigger the new user account creation dialog.
+Inside the dialog, add the users first name, last name and email. Additionally to the user information, a network role need to get selected. Based on the network role, the user will be able to have a certain permissions inside the portal.
+
+
+
+
+
+
+
+
+As soon as the confirm button is selected, an invite email is send to the user including a one-time-password (otp) for login.
+With the first login, the user will be asked to set a own password, password policies are to be followed.
+
+
+
diff --git a/docs/03. User Management/01. User Account/04. Create new user account (bulk).md b/docs/03. User Management/01. User Account/04. Create new user account (bulk).md
new file mode 100644
index 000000000..cd11e220c
--- /dev/null
+++ b/docs/03. User Management/01. User Account/04. Create new user account (bulk).md
@@ -0,0 +1,3 @@
+## Create a new user account (bulk)
+
+Currently not supported
diff --git a/docs/03. User Management/01. User Account/05. FAQ.md b/docs/03. User Management/01. User Account/05. FAQ.md
new file mode 100644
index 000000000..ed932a1eb
--- /dev/null
+++ b/docs/03. User Management/01. User Account/05. FAQ.md
@@ -0,0 +1,26 @@
+# FAQ
+
+#### Can I delete an user of another company?
+
+No, it is not possible to delete an user which is assigned to another company account.
+
+The person which is triggering the deletion needs to belong to the same company or it has to be the user itself which triggers the deletion for the own account.
+
+
+
+#### How can I delete an user account which is company IdP federated?
+
+In the scenario of federated company IdP user accounts, the user deletion will only be effective inside the Catena-X idp. The company IdP wont be effective on the company IdP; only the shadow user with the assigned roles inside Catena-X will get deleted.
+
+
+
+#### Can I revert a user deletion?
+
+No, user deletions can't get reverted.
+
+
+
+#### If my/a user has 2 idp connections, will the user deletion delete both idp connections?
+
+Yes, even with multiple idp connections, the user deletion will work as planned. The user access will get reverted and the user account details will get deleted.
+
diff --git a/docs/03. User Management/01. User Account/index.md b/docs/03. User Management/01. User Account/index.md
new file mode 100644
index 000000000..b7c1f3eb8
--- /dev/null
+++ b/docs/03. User Management/01. User Account/index.md
@@ -0,0 +1,9 @@
+# User Account
+
+User accounts are accounts for real persons - your company employees.
+Read more details in the following sections:
+
+- [FAQ](./1%20FAQ.md)
+- [HowTo](./2%20HowTo.md)
+- [Implementation](./3%20Implementation.md)
+- [Summary](./4%20Summary.md)
diff --git a/docs/03. User Management/02. Modify User Account/01. Summary.md b/docs/03. User Management/02. Modify User Account/01. Summary.md
new file mode 100644
index 000000000..c087c48ac
--- /dev/null
+++ b/docs/03. User Management/02. Modify User Account/01. Summary.md
@@ -0,0 +1,14 @@
+# User Account Details
+
+
+The "User Account Details" function is a detailed view of one user, which the company administrator can open by clicking on "details" of any users under his organization.
+
+
+
+
+# My CX Account
+
+
+The "My User Account Details" function is a detailed view of your own user account and can get viewed by the user owner only.
+
+
diff --git a/docs/03. User Management/02. Modify User Account/02. Password Reset.md b/docs/03. User Management/02. Modify User Account/02. Password Reset.md
new file mode 100644
index 000000000..e6d720329
--- /dev/null
+++ b/docs/03. User Management/02. Modify User Account/02. Password Reset.md
@@ -0,0 +1,25 @@
+## Password Reset
+
+The "Reset password" button is available in the user account detail page and can get triggered by the administrator with the respective (modify_user_account) right.
+The picture below includes the service details
+
+
+
+
+
+### Error message handling for password reset
+
+* If the reset is triggered 10 times already, the next time an error will get submitted with which the FE can submit the message "You have triggered the maximum time of password resets, please try it later again". For that, the backend need to respond with an error that FE can display the right error message
+* For any other errors, the error message will be "The password reset was unsuccessful. We phased an issue, please try It later again"
+* If policy is failing (company is using ownIdP), the backend service will enable the FE to submit a scenario specific error message
+
+
+
+### Password reset policy
+
+* User for whom password reset is triggered needs to be under the same org/tenant => to be checked as part of the service
+* Before triggering the password reset, check the company id => password reset is only valid for SharedIdP customers. Check in table identity_providers if the identity_provider_category_id for the company is Shared IdP (value: '1')
+* SharedIdP user id need to get retrieved via the user token and transferred to the sharedIdP user ID
+ * take user id handed over by FE
+ * transfer the user id to the centralIdP user id (via iam_user) table
+ * transfer centralIdP user id to sharedIdP user id
diff --git a/docs/03. User Management/02. Modify User Account/03. User Permissions - UPDATE NEEDED.md b/docs/03. User Management/02. Modify User Account/03. User Permissions - UPDATE NEEDED.md
new file mode 100644
index 000000000..0e4baa794
--- /dev/null
+++ b/docs/03. User Management/02. Modify User Account/03. User Permissions - UPDATE NEEDED.md
@@ -0,0 +1,10 @@
+## User Permissions
+
+In the view "my user account" and "user account" the user assigned app permissions are displayed.
+
+As administrator (e.g. company administrator; IT Admin, etc.) company user details can get viewed.
+Normal users can only view their own user account via "my user account".
+
+
+
+
diff --git a/docs/03. User Management/02. Modify User Account/04. Manage user assigned BPN.md b/docs/03. User Management/02. Modify User Account/04. Manage user assigned BPN.md
new file mode 100644
index 000000000..9516921d0
--- /dev/null
+++ b/docs/03. User Management/02. Modify User Account/04. Manage user assigned BPN.md
@@ -0,0 +1,21 @@
+## Add BPN
+
+
+To add a business partner number to an existing user; open the user details page (via the user management) and edit the bpn field.
+
+
+
+
+
+
+
+# Delete BPN
+
+
+To delete a business partner number to an existing user; open the user details page (via the user management) and edit the bpn field.
+Inside the overlay the "delete" icon can get used to delete an assigned bpn.
+
+
+
+
+
diff --git a/docs/03. User Management/02. Modify User Account/05. Suspend User.md b/docs/03. User Management/02. Modify User Account/05. Suspend User.md
new file mode 100644
index 000000000..69f15e3cb
--- /dev/null
+++ b/docs/03. User Management/02. Modify User Account/05. Suspend User.md
@@ -0,0 +1,3 @@
+# Suspend User
+
+currently not supported
diff --git a/docs/03. User Management/02. Modify User Account/06. Delete User.md b/docs/03. User Management/02. Modify User Account/06. Delete User.md
new file mode 100644
index 000000000..fa70d2a16
--- /dev/null
+++ b/docs/03. User Management/02. Modify User Account/06. Delete User.md
@@ -0,0 +1,30 @@
+## Delete User
+
+Inside the portal, a user will be able to delete an user - the function is differentiated into 2 functions
+
+* Delete your own user account
+* Delete an user account of a user inside your organization (only available for the IT Administrator)
+
+
+
+User accounts might be companyIdP federated or CX user accounts. In both scenarios the user deletion is implemented and will effect the user account itself, the user favorites, user roles as well as user attributes.
+
+The deletion of users is audit relevant and will be audit logged inside the db.
+
+More details to the audit logging can get found here: https://github.com/catenax-ng/tx-portal-assets/blob/945546d91065b8870aa8f69ce94b48eac7a5ade2/docs/Technical%20Details/Auditing.md
+
+
+
+### Own User Deletion Flow
+
+
+
+
+
+
+### Company User Deletion Flow
+
+
+
+
+
diff --git a/docs/03. User Management/02. Modify User Account/index.md b/docs/03. User Management/02. Modify User Account/index.md
new file mode 100644
index 000000000..e1bbc4840
--- /dev/null
+++ b/docs/03. User Management/02. Modify User Account/index.md
@@ -0,0 +1,17 @@
+# Summary
+
+User Account, or My User Account is implemented to retrieve details of the current user or an user of the company (for admins only).
+
+Inside the user account page, a number of services/actions can get triggered.
+
+
+
+* Add BPN
+* Delete BPN
+* Delete User
+* Password Reset
+* Suspend User
+* Change User Roles
+
+
+
diff --git a/docs/03. User Management/03. Technical User/01. Technical User Overview.md b/docs/03. User Management/03. Technical User/01. Technical User Overview.md
new file mode 100644
index 000000000..d9481999d
--- /dev/null
+++ b/docs/03. User Management/03. Technical User/01. Technical User Overview.md
@@ -0,0 +1,18 @@
+## Technical User Overview
+User with the respective user management rights can access the user management via the top right user navigation.
+
+Inside the Technical User Management page administrator users can
+
+* create technical users in the name of their company
+* get an overview of the existing, company owned technical users
+* look-up technical user details
+* delete technical user
+
+
+
+
+
+
+
+
+
diff --git a/docs/03. User Management/03. Technical User/02. Create Technical User.md b/docs/03. User Management/03. Technical User/02. Create Technical User.md
new file mode 100644
index 000000000..13b7b8472
--- /dev/null
+++ b/docs/03. User Management/03. Technical User/02. Create Technical User.md
@@ -0,0 +1,58 @@
+## Introduction
+
+The technical user creation process involves creating a specific user account with limited access to a system or network. This user account is typically used for backend to backend service/application connections.
+It is important to ensure that the technical user has the necessary privileges and access rights to carry out the tasks required; but also to limit the access rights to those specific services only. This will help to protect the system or network from unauthorized access.
+
+In the Catena-X dataspace, following technical users are provided to all members:
+
+
+
+#### Available technical user roles
+* Connector User (technical user for data connector to connect to the digital twin registry)
+* Identity Wallet Management (technical user to reach out the the company owned managed identity wallet)
+* BPDM Pool (technical user to connect to the BPDM Data Pool)
+* Dataspace Discvoery (technical user to call the Connector Discovery service)
+* App Tech User (technical user for app tenants - user is usually auto created as part of a app tenant activation - includes digital twin access and bpdm lookup)
+* Service Management (technical user for service and app providers to create connector registration, store autosetup url and use the portal opneAPI for autosetup)
+
+
+
+
+## Create a new technical user
+
+User with the respective user management rights can access the user management via the top right user navigation.
+As soon as the user management is displayed, a button "Technical User Management" shows up to switch from real users to technical users.
+
+
+
+Click on the action button "Create Technical User" to initiate the process.
+
+
+
+Enter the relevant information in the displayed overlay
+
+* Username (username to be added for own verification)
+* Description (description of the technical user, will be useful in case several technical users are existing)
+* Service / Permission (which user rights/roles are needed
+
+
+
+
+
+
+
+
+As soon as the user is selecting the "Confirm" button, the user is getting created as service account / technical user.
+Each technical user will have the relevant permission assigned and a user attribute "bpn" is getting added based on the requesting users bpn.
+
+
+
+
+
+
+
+
+With the shared user_id and secret, the technical user can get used to authenticate for the respective service.
+
+
+
diff --git a/docs/03. User Management/03. Technical User/03. Delete Technical User.md b/docs/03. User Management/03. Technical User/03. Delete Technical User.md
new file mode 100644
index 000000000..f6d644391
--- /dev/null
+++ b/docs/03. User Management/03. Technical User/03. Delete Technical User.md
@@ -0,0 +1,22 @@
+## Delete an user
+
+Technical users created under the same company id can get deleted by user administrators.
+To delete an user, just open up the user details and click the "delete" button.
+
+
+
+
+
+
+
+
+
+
+The technical user deletion will immediately get active. Please ensure that you inform the relevant user about the deletion.
+
+
+
+
+#### Currently not supported:
+
+update technical user secret
diff --git a/docs/03. User Management/03. Technical User/04. FAQ.md b/docs/03. User Management/03. Technical User/04. FAQ.md
new file mode 100644
index 000000000..8b1378917
--- /dev/null
+++ b/docs/03. User Management/03. Technical User/04. FAQ.md
@@ -0,0 +1 @@
+
diff --git a/docs/03. User Management/03. Technical User/index.md b/docs/03. User Management/03. Technical User/index.md
new file mode 100644
index 000000000..b3260d6da
--- /dev/null
+++ b/docs/03. User Management/03. Technical User/index.md
@@ -0,0 +1,18 @@
+# Summary
+
+The technical user management which is used to manage technical users for a company. Technical users are relevant for backend to backend service connections.
+
+CX Member companies can create technical users on their need(s) and map them to the pre-defined roles.
+
+
+
+### Customer Functionalities covered in the function
+* Create new technical user under my org
+* View all my technical users (including technical user details)
+* Delete a technical user
+
+
+
+
+
+
diff --git a/docs/03. User Management/04. Assign App Roles/01. App Access Management Overview.md b/docs/03. User Management/04. Assign App Roles/01. App Access Management Overview.md
new file mode 100644
index 000000000..f1ba926cf
--- /dev/null
+++ b/docs/03. User Management/04. Assign App Roles/01. App Access Management Overview.md
@@ -0,0 +1,12 @@
+## App Access Management Overview
+
+Via the User Management section "App Access Management" company administrators can assign app roles of the active subscribed apps to their users.
+The assigned role enables the user to access the application.
+
+
+
+
+
+
+
+
diff --git a/docs/03. User Management/04. Assign App Roles/02. Assign User App Role(s).md b/docs/03. User Management/04. Assign App Roles/02. Assign User App Role(s).md
new file mode 100644
index 000000000..c858bc78a
--- /dev/null
+++ b/docs/03. User Management/04. Assign App Roles/02. Assign User App Role(s).md
@@ -0,0 +1,17 @@
+## Assign User App Role
+
+To enable users to access an application, minimum one application app need to get assigned to the respective user(s).
+
+1. Click on the "Add Role" Button.
+2. Select respective app role(s) & users to which those roles should get assigned.
+3. Confirm your selection via the "Confirm" Button
+4. The user role got successfully assigned and the respective users are visible in the App Access user list.
+
+
+
+
+
+
+
+
+
diff --git a/docs/03. User Management/04. Assign App Roles/03. Update Users Assigned App Role(s).md b/docs/03. User Management/04. Assign App Roles/03. Update Users Assigned App Role(s).md
new file mode 100644
index 000000000..edfba94c9
--- /dev/null
+++ b/docs/03. User Management/04. Assign App Roles/03. Update Users Assigned App Role(s).md
@@ -0,0 +1,11 @@
+## Update User Assigned App Role
+
+User assigned app roless can get easily modified via the user role edit button.
+
+
+
+Click on the edit button and select or unselect the respective user role.
+With the confirmation the user role change is taking place.
+
+
+
diff --git a/docs/03. User Management/04. Assign App Roles/04. FAQ.md b/docs/03. User Management/04. Assign App Roles/04. FAQ.md
new file mode 100644
index 000000000..8b1378917
--- /dev/null
+++ b/docs/03. User Management/04. Assign App Roles/04. FAQ.md
@@ -0,0 +1 @@
+
diff --git a/docs/03. User Management/04. Assign App Roles/index.md b/docs/03. User Management/04. Assign App Roles/index.md
new file mode 100644
index 000000000..c47389052
--- /dev/null
+++ b/docs/03. User Management/04. Assign App Roles/index.md
@@ -0,0 +1,10 @@
+# Summary
+
+The app access management allows admins to assign app roles to company users. This enables the respective user to access the application.
+
+The App Access Management page include information about
+
+* Available App Roles
+* Users which have access to this app and their related role
+* option to add a user with a role to the app
+* option to add a to an existing app user another role or switch the role
diff --git a/docs/03. User Management/index.md b/docs/03. User Management/index.md
new file mode 100644
index 000000000..a29f30901
--- /dev/null
+++ b/docs/03. User Management/index.md
@@ -0,0 +1,10 @@
+# User Management
+
+User accounts are the basic entities to access resources in Catena-X.
+Learn how to manage different kinds of user accounts in the Catena-X Portal.
+Read more details in the following sections:
+
+- [User Account](./1%20User%20Account/)
+- [Edit User Account](./2%20Edit%20User%20Account/)
+- [Technical User](./3%20Technical%20User/)
+- [App Access Management](./4%20App%20Access%20Management/)
diff --git a/docs/04. App(s)/01. Marketplace/01. App Overview.md b/docs/04. App(s)/01. Marketplace/01. App Overview.md
new file mode 100644
index 000000000..7806841d0
--- /dev/null
+++ b/docs/04. App(s)/01. Marketplace/01. App Overview.md
@@ -0,0 +1,17 @@
+## App Overview
+
+The app marketplace is providing a list of software applications of catena-x approved app providers.
+
+Beside the generic list, apps can get viewed in specific pre-configured views
+* List View
+* Category (Use Case) View
+additionally user can select app details to display additional information for a specific selected app and mark apps as favorite (Details about Favorites)
+
+
+
+
+
+
+
+
+
diff --git a/docs/04. App(s)/01. Marketplace/02. App Details.md b/docs/04. App(s)/01. Marketplace/02. App Details.md
new file mode 100644
index 000000000..2dd428d0c
--- /dev/null
+++ b/docs/04. App(s)/01. Marketplace/02. App Details.md
@@ -0,0 +1,19 @@
+## App Details
+
+The app details page is getting triggered/open from the app marketplace. When the user is clicking on the "Details" button of an app, the app details will get displayed.
+
+Inside the app details following information will be stored
+
+* app provider & name
+* app supported language
+* app description
+* app images
+* app documents
+* subscription status
+
+
+
+
+
+
+
diff --git a/docs/04. App(s)/01. Marketplace/03. App Favorites.md b/docs/04. App(s)/01. Marketplace/03. App Favorites.md
new file mode 100644
index 000000000..5d1aab568
--- /dev/null
+++ b/docs/04. App(s)/01. Marketplace/03. App Favorites.md
@@ -0,0 +1,13 @@
+## App Favorites
+
+
+
+
+
+
+
+
+Via a click on the plus button, the plus button changes to a checkmark button and the app is added to the user own favorites. If the user clicks on the checkmark button again, the app is deleted from the favorites and the plus button appears again.
+
+
+
diff --git a/docs/04. App(s)/01. Marketplace/04. My Business Apps.md b/docs/04. App(s)/01. Marketplace/04. My Business Apps.md
new file mode 100644
index 000000000..5a4a69ce5
--- /dev/null
+++ b/docs/04. App(s)/01. Marketplace/04. My Business Apps.md
@@ -0,0 +1,35 @@
+## My Business Applications
+
+My Business Applications is a component inside the portal which shows the current logged in user which business applications the user can actively used.
+The logic is implemented based on
+
+* company subscribed apps
+* user roles
+
+The component can hold up to 4 apps in one page, in case the user has more apps assigned, the component will turn to a carousel with the option to scroll through the pages.
+
+
+
+
+
+
+
+
+
+
+With a click on the business app tile, the user gets automatically redirected to the respective app and via SSO, the user can work inside the app.
+
+
+
+
+
+
+
+
+
+The idp of the business application will check the user token. If the user token is valid, the user gets access to the respective tenant. If not, a permission / access error page is getting displayed.
+Important: to enable the functionality, an idp connection must be existing between the business app and catena-x.
+This connection is a user federation which establishes trust between the app idp and catena-x idp and enabled users with a valid key to access there subscribed app tenant.
+
+
+
diff --git a/docs/04. App(s)/01. Marketplace/05. FAQ.md b/docs/04. App(s)/01. Marketplace/05. FAQ.md
new file mode 100644
index 000000000..1537d0b2a
--- /dev/null
+++ b/docs/04. App(s)/01. Marketplace/05. FAQ.md
@@ -0,0 +1,17 @@
+### FAQ
+
+
+#### How can I release my app on the app marketplace.
+To release your app on the app marketplace, you just need to have the company role "App Provider" assigned as well as the user role "App Manager". If thats the case - just follow the description under following link [App Release Process](/docs/04.%20App(s)/Release-Process/App%20Release%20Workflow.md)
+
+
+
+####
+
+
+
+####
+
+
diff --git a/docs/04. App(s)/02. App Release Process/01. App Release Intro.md b/docs/04. App(s)/02. App Release Process/01. App Release Intro.md
new file mode 100644
index 000000000..9cb170277
--- /dev/null
+++ b/docs/04. App(s)/02. App Release Process/01. App Release Intro.md
@@ -0,0 +1,39 @@
+# Summary
+
+The Page "App Release Process" is accessible via the top main menu.
+
+Main focus is the transparent overview of the app process steps, but also the option to directly start the app release process or to get back to the "App Overview".
+
+The main interest group of this page are app provider companies.
+
+Companies which are service provider or data offer/consumer, are not able to access this page.
+
+
+
+
+# Design
+
+
+
+
+
+
+# Functions
+
+#### "Publish Company App"
+Start the app publishing process or jump into your own app overview.
+
+
+
+
+#### "Process Guide"
+A vertical screen process panel is used to show transparently the app release process steps which need to get processed to publish a app inside the marketplace.
+
+
+
+
+#### "Outlook: Marketplace Requirements"
+Soon upcoming new requirements are getting published here. This enables companies to prepare for future app release requirements.
+
+
+
diff --git a/docs/04. App(s)/02. App Release Process/02. App Release Process.md b/docs/04. App(s)/02. App Release Process/02. App Release Process.md
new file mode 100644
index 000000000..085f572e0
--- /dev/null
+++ b/docs/04. App(s)/02. App Release Process/02. App Release Process.md
@@ -0,0 +1,159 @@
+## App Release Process
+
+The "App Release Publishing Process" is accessible via the "App Release Process" as well as the "App Management".
+
+The App Provider has access to both of the start screens to trigger a new app for marketplace publishing.
+
+The app publishing process includes the submission of relevant app details, adding app images, documents as well as testing and technical connection (where suitable).
+
+
+
+
+
+
+
+
+
+#### Trigger the Publishing Process
+
+ Option 1: Via the app management page
+
+Access the "App Overview" page via the top navigation "App Management"
+
+
+
+
+
+
+
+
+ Option 2: Via the App Release Process
+
+Access the "App Overview" page on the "App Release Process"
+and click on
+
+
+
+
+
+
+
+
+#### Step 1 - App Card Details
+
+In the Step 1 of the publishing process, the app card details are getting filled first
+
+* app name
+* provider
+* app lead picture
+* language support
+* pricing information
+* etc.
+
+
+
+
+
+
+The input fields for language, sales manager as well as the use case selection supports the user with pre-selectable values.
+
+###### App language
+The app language need to get set to ensure that customers can identifier the app supported language. Select all supported app language tags inside the dropdown by scrolling through all the available language tags or add the language inside the input field to activate the auto complete search.
+
+
+
+
+
+
+
+
+
+###### Use Case
+The use case selection provides the possibility to specify the app supported use cases.
+Customers will have the chance to look up use case specific apps. Select app covered use cases by scrolling through all the available dropdown records or add the use case inside the input field to activate the auto complete search.
+
+
+
+
+
+
+
+
+
+###### Sales Manager
+The sales manager is a field which enables the user to select the app sales manager. The sales manager will get informed if an app is retrieving an purchase request. Please note that only users inside the company tenant with the role "Sales Manager" will display in this dropdown.
+
+In case there is no Sales Manager available or in case the app provider doesnt wanna use the option, "none" can get selected.
+
+
+
+
+
+
+
+
+
+
+#### Step 2 - App Page Details
+
+In the Step 2 of the publishing process, the app detail page is getting filled
+
+* app description
+* app images
+* documents/contract information
+* etc.
+
+
+
+
+
+
+
+
+
+
+#### Step 3 - Terms & Conditions / Consent
+
+Under Step 3 - the user needs to agree to the terms and conditions of the app publish rules before getting on the marketplace. This section is mandatory and displays areement documents; if any documents are linked to the relevant agreement types
+
+
+
+
+
+
+
+
+
+
+#### Step 4 - Technical Integration
+
+For technical integration, the app roles get loaded inside the step 4. Those roles are necessary to enable in the customer subscription scenario the possible user federation including assigned user roles.
+With the technical integration feature, the user can
+
+* upload those app user roles via csv file
+* preview uploadable roles
+* trigger the role creation for the app (roles can get later updated again via the app change process)
+* delete uploaded roles
+
+
+
+
+
+
+
+
+
+
+#### Step 5 - Beta Test Runs
+
+
+
+
+
+
+#### Step 6 - Validate & Submit for Publishing check
+
+
+
+
+
diff --git a/docs/04. App(s)/02. App Release Process/App-Design_guidelines.md b/docs/04. App(s)/02. App Release Process/App-Design_guidelines.md
new file mode 100644
index 000000000..65e0bbf64
--- /dev/null
+++ b/docs/04. App(s)/02. App Release Process/App-Design_guidelines.md
@@ -0,0 +1,99 @@
+## App Design Guidelines
+
+### The App Picture
+
+The App Picture / Image for the app card logo is one of the most important elements since it will ensure that customers can recognize the app quickly.
+
+
+The app card should be
+
+* unique
+* colors should be selected carefully (not too much and not too less)
+* reduce characters since people wont be able to read the text => icons are rather small inside the marketplace
+* size: 200x200 pixel
+* full-bleed square
+* dont use ui pictures or screenshots, take a graphic/design a graphic
+
+
+
+
+### Support Information
+
+#### App Picture Layout Template
+
+
+
+
+
+
+#### App Color Guidelines
+
+App Images should support to be published on black and white backgrounds. To ensure that the App Image is not giving any troubles, stronger colors are
+
+
+
+All images used for any user interaction will receive a frame. White as well as dark image backgrounds / icon backgrounds are supported through a standard frame which is getting set around the image/icon when publishing the same in an user interface.
+
+
+
+###### Do's
+
+* Colorful, white and black background
+
+
+
+###### Dont's
+
+* pastel colors (always difficult as soon as the background is white)
+
+
+
+
+#### App Picture Icon Template
+
+
+
+
+
+
+#### In-App Design (Catena-X Apps)
+
+##### App Typography
+
+App Images should support to be published on black and white backgrounds. To ensure that the App Image is not giving any troubles, stronger colors are
+
+
+
+
+All images used for any user interaction will receive a frame. White as well as dark image backgrounds / icon backgrounds are supported through a standard frame which is getting set around the image/icon when publishing the same in an user interface.
+
+
+
+Do's
+
+* Colorful, white and black background
+
+Don'ts
+
+* pastel colors (always difficult as soon as the background is white)
+
+
+
+
+##### Language Support
+
+Multi Language Support is necessary for Catena-X owned apps
+
+
+Mandatory language support
+
+* German
+* English
+
+
+Technical solution proposal
+* i18n
+
+
+
+
diff --git a/docs/04. App(s)/02. App Release Process/App-Release_guidelines.md b/docs/04. App(s)/02. App Release Process/App-Release_guidelines.md
new file mode 100644
index 000000000..0ead4b343
--- /dev/null
+++ b/docs/04. App(s)/02. App Release Process/App-Release_guidelines.md
@@ -0,0 +1,40 @@
+# App Release Guidelines
+
+## Summary
+
+App Release Guidelines are defined to ensure that app providers follow
+
+* CX Standardization Rules
+* Apps are user friendly and in a certain percentage user friendly
+* Apps are marketplace ready
+* Gaia-X compliance is ensured
+
+## Technical Guidelines
+ - DRAFT -
+
+to be added
+
+#### #1 Authentication
+
+- [ ] CX Portal Authentication enabled => SSO with CX IdP connection
+- [ ] Logout Function implemented
+
+
+#### #2 User Error Handling
+
+- [ ] user error handling is implemented
+- [ ] user service/contact is available for all app costumers
+- [ ] ...
+
+
+## Functional Guidelines
+ - DRAFT -
+
+to be added
+
+- [ ] App Lead Picture Guidelines - [App Design Guidelines](./App-Design_guidelines.md/)
+- [ ] CX IP App Guidelines - [App Design Guidelines](./App-Design_guidelines.md/)
+- [ ] CX IP App Language Support - [App Design Guidelines](./App-Design_guidelines.md/)
+- [ ] ...
+- [ ] ...
+
diff --git a/docs/04. App(s)/03. App Release Approval/01. App Approval Board.md b/docs/04. App(s)/03. App Release Approval/01. App Approval Board.md
new file mode 100644
index 000000000..bb425c7e3
--- /dev/null
+++ b/docs/04. App(s)/03. App Release Approval/01. App Approval Board.md
@@ -0,0 +1,27 @@
+## Summary
+
+The Page "App Approval Board" is accessible via the top main menu for CX Admins.
+
+The main focus / scope of the page is to enable the operator to manage apps releases for the CX marketplace.
+
+The page includes following functions
+
+* search
+* filter
+* approve a app release
+* decline a app release (with message)
+* look up app details
+
+
+
+
+### Page Design
+
+
+
+
+With the initial page load, all apps waiting for a review are displayed.
+The user can get to the app details or approve / decline the app release.
+
+
+
diff --git a/docs/04. App(s)/03. App Release Approval/02. App Details.md b/docs/04. App(s)/03. App Release Approval/02. App Details.md
new file mode 100644
index 000000000..ab1dddd7e
--- /dev/null
+++ b/docs/04. App(s)/03. App Release Approval/02. App Details.md
@@ -0,0 +1,12 @@
+## App details
+
+For apps under release process and ready to get validated by the marketplace operator; the app details may get displayed to verify all details.
+To display the details the app data get displayed by clicking on the app card on the administrator board.
+
+
+
+
+
+
+
+
diff --git a/docs/04. App(s)/03. App Release Approval/03. Approve App Release.md b/docs/04. App(s)/03. App Release Approval/03. Approve App Release.md
new file mode 100644
index 000000000..713597131
--- /dev/null
+++ b/docs/04. App(s)/03. App Release Approval/03. Approve App Release.md
@@ -0,0 +1,10 @@
+## Approve App Release
+
+With the app release approval, the app is getting activated for the app marketplace.
+The approval is triggered by clicking on the approval icon inside the app card:
+
+
+
+
+
+
diff --git a/docs/04. App(s)/03. App Release Approval/04. Decline App Release.md b/docs/04. App(s)/03. App Release Approval/04. Decline App Release.md
new file mode 100644
index 000000000..d875b98bd
--- /dev/null
+++ b/docs/04. App(s)/03. App Release Approval/04. Decline App Release.md
@@ -0,0 +1,12 @@
+## Decline App Release
+
+The app release decline icon can get triggered by clicking on the decline icon inside the app card. Additionally to the cancellation, a message can get added which will get provided to the app manager(s) of the respective company.
+
+
+
+
+
+
+
+
+
diff --git a/docs/04. App(s)/04. App Provider Management Board(s)/01. App Board.md b/docs/04. App(s)/04. App Provider Management Board(s)/01. App Board.md
new file mode 100644
index 000000000..f475fab7e
--- /dev/null
+++ b/docs/04. App(s)/04. App Provider Management Board(s)/01. App Board.md
@@ -0,0 +1,44 @@
+## App Board
+
+The Page "App Overview" is accessible via the top main menu for app providers.
+
+The main focus / scope of the page is to enable app providers to manage their apps under the release process, inside the marketplace or inactive apps, as well as starting the release process for a complete new app.
+
+The page includes following functions
+
+* search
+* filter
+* trigger app registration (link to be added)
+
+
+
+
+### Details
+
+
+
+
+
+
+"Active" App
+All apps in status "Active" are published on the marketplace and can get subscribed by an customer.
+
+
+"In Progress" App
+Apps currently in progress can get opened inside the app release process and further edited there. If you are happy with the app content; submit your app to get it published on the marketplace.
+
+
+
+"In Review" App
+Apps which are in "In Review" are logged; please wait until the review is finished.
+
+
+
+"Inactive" App
+Apps which are in "Inactive" have been deactivated by the app owner and are not available anymore on the marketplace
+
+
+
+Additionally the "App Change Process" can get triggered from the app overview page. Details to the app change process are documented under following page App Marketplace - App Change Process
+
+
diff --git a/docs/04. App(s)/05. App-Subscription/01. Subscription Request (Customer).md b/docs/04. App(s)/05. App-Subscription/01. Subscription Request (Customer).md
new file mode 100644
index 000000000..a81c60d8d
--- /dev/null
+++ b/docs/04. App(s)/05. App-Subscription/01. Subscription Request (Customer).md
@@ -0,0 +1,27 @@
+# Summary
+
+The app subscription process is essential for the usage of an business application, no matter if an app is right away usable or any pre-requisites are given, the app subscription process will manage the relationship between interested app user and app provider.
+
+In the drawing below, the initial process is drafted. Important: this is a draft only and relevant for the initial implementation. As soon as this process is enabled an enhancement is planned which should enable to whole app provider / customer communication on the CX platform.
+
+
+
+
+
+
+
+
+
+Important flow chart details: the app subscription process does not handle the contract workflow inside the portal, instead the contract agreement is planned to take place outside the marketplace/portal
+
+After the successful subscription (request by customer and activation by provider) the user management will get enabled for the respective customer company.
+
+With that, the customer can manage user roles for their own users (pre-requisite: those users need to have an active cx account)
+
+
+
+
+
+
+
+
diff --git a/docs/04. App(s)/05. App-Subscription/02. Overview Company Subscription (Customer).md b/docs/04. App(s)/05. App-Subscription/02. Overview Company Subscription (Customer).md
new file mode 100644
index 000000000..4d2e5f2b8
--- /dev/null
+++ b/docs/04. App(s)/05. App-Subscription/02. Overview Company Subscription (Customer).md
@@ -0,0 +1,5 @@
+# Summary
+
+Available subscriptions or outstanding/pending subscriptions are available under "My Organisation"
+
+
diff --git a/docs/04. App(s)/05. App-Subscription/03. Subscription Overview (App Provider).md b/docs/04. App(s)/05. App-Subscription/03. Subscription Overview (App Provider).md
new file mode 100644
index 000000000..e279bcc1f
--- /dev/null
+++ b/docs/04. App(s)/05. App-Subscription/03. Subscription Overview (App Provider).md
@@ -0,0 +1,21 @@
+## Summary
+
+The Page "App Subscription Management" is accessible via the top main menu for app providers.
+
+The main focus / scope of the page is to enable app providers to manage their app subscriptions (active as well as requests)
+
+The page includes following functions
+
+* search
+* filter
+* trigger subscription activation
+
+
+
+
+
+### Management Board
+
+
+
+
diff --git a/docs/04. App(s)/05. App-Subscription/04. Subscription Activation (App Provider).md b/docs/04. App(s)/05. App-Subscription/04. Subscription Activation (App Provider).md
new file mode 100644
index 000000000..7ee11efc8
--- /dev/null
+++ b/docs/04. App(s)/05. App-Subscription/04. Subscription Activation (App Provider).md
@@ -0,0 +1,7 @@
+## Activate Subscription Request
+
+......
+
+
+
+
diff --git a/docs/04. App(s)/05. App-Subscription/05. FAQ.md b/docs/04. App(s)/05. App-Subscription/05. FAQ.md
new file mode 100644
index 000000000..7db6d6d0d
--- /dev/null
+++ b/docs/04. App(s)/05. App-Subscription/05. FAQ.md
@@ -0,0 +1,25 @@
+### FAQ
+
+
+#### I dont have subscription rights - how can I receive the necessary rights?
+Subscription rights can get shared / assigned by the company admin / company IT admin.
+Please contact your admin if additional rights are needed. Subscriptions can get triggered by all administrators as well as the "Purchaser" role.
+
+
+
+
+#### I triggered an app subscription request what do I need to do now?
+After the app subscription request got triggered, please wait for the app provider to get in contact with you. This can take up to 48 hours, but is usually much quicker. An technical trigger will have a look at the status and re-inform the app provider if needed.
+
+
+
+
+#### Where can I see my company subscriptions?
+Company subscription can get viewed via the company details page => /organization
+
+
+
+#### ?
+
+
+
diff --git a/docs/04. App(s)/06. App Change Process/01. Summary.md b/docs/04. App(s)/06. App Change Process/01. Summary.md
new file mode 100644
index 000000000..d84ac93dd
--- /dev/null
+++ b/docs/04. App(s)/06. App Change Process/01. Summary.md
@@ -0,0 +1,53 @@
+## Summary
+
+
+The app change process is implemented to support app providers to change apps which are active.
+
+
+There is a number of change scenarios, in the first implementation round the following change scenarios are considered
+
+
+* App Deactivation
+* Add Role - not yet supported
+* Change Documents - not yet supported
+* Change Description - not yet supported
+* Change Image - not yet supported
+
+
+
+On purpose, the change scenarios are kept limited for the first release of "app change" to ensure that the implementation is supporting a number of key scenarios within the given / available implementation slot.
+
+
+
+
+## Function
+
+Inside the App Overview (see following page for details: ) the app change process start got implemented:
+
+
+
+
+
+
+Inactive State (in case the app is not yet "active" - in this case, the change can not get triggered)
+
+
+
+
+
+
+SubMenu Disabled and enabled
+
+
+
+
+
+
+Open up the sub-menu
+
+
+
+
+
+
+
diff --git a/docs/04. App(s)/06. App Change Process/02. App Deactivation.md b/docs/04. App(s)/06. App Change Process/02. App Deactivation.md
new file mode 100644
index 000000000..aa217f324
--- /dev/null
+++ b/docs/04. App(s)/06. App Change Process/02. App Deactivation.md
@@ -0,0 +1,25 @@
+## Summary
+
+
+The app deactivation function allows users to easily and conveniently deactivate their app from the app marketplace. This feature gives users the power to control their own offers and allows them to easily stop or start offer whenever they like.
+
+
+
+To deactivate an app, select "Deactivate" via the app management app card sub-menu
+
+
+
+
+the app provider can deactivate the app provided inside the marketplace.
+Important; the process is currently not reversable. The app is getting deactivated in the marketplace, but ecisting acces of subscription companies does still work.
+
+
+
+
+