> For the complete documentation index, see [llms.txt](https://docs.legal-data-analytics.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.legal-data-analytics.com/legal-data-analytics-v1/integration/ldh-readiness/technical-guideline-key-management-for-ldh-compatible-applications.md).

# Technical Guideline: Key Management for LDH-Compatible Applications

## Purpose and Scope

This document provides implementation guidance for platform providers building LDH-compatible applications. It describes how to securely handle the Client ID and Secret provided by customers ("Bring Your LDH Key") and how to integrate with the Legal Data Hub (LDH) APIs.

## Core Principles

* Customer ownership: The Client ID and Secret are owned and provided by the customer (which could be the platform provider or the end-customer).
* Secure storage: Credentials must never be exposed or stored in plain text.
* Tenant isolation: Each customer environment must be separated.
* Backend usage only: Keys must only be used on server-side components.
* End-customer attribution: All requests must be traceable to end-customers.

## System Architecture

LDH-compatible applications act as intermediaries between end-users and LDH APIs. The application securely stores the Client ID and Secret and uses them to perform authenticated API calls. End-users interact with the application, not directly with LDH.

## Key Management Process

### Issuing

The LDH Key (consisting of Client ID and Secret) are issued by Otto-Schmidt or LDA and provided via a secure way to the customer.

### Provisioning

Customers administer the Client ID and Secret in a secure administration area. The application validates and stores the credentials in a protected environment. The Key is used to retrieve an access token, which allows accessing the LDH. The access token is validated while accessing the LDH API. It contains information about the customer, which can be used for access control, authorization, and billing.

### Runtime Usage

For each user request (e.g., Semantic Search, Q\&A), the application uses the LDH Key to perform an authenticated LDH API call (request). Responses include content, references, and links to the publisher’s content.

### End-customer Attribution

Ensure that users are authenticated and known. Integration with identity systems should enable end-customer tracking and seamless transitions to OSO for further research and avoidance / detection of misuse.

### Multi-Tenant Support

Support multiple customers with strict separation. Allow multiple credential sets for different departments if required.

## Security Requirements

* No exposure of secrets in frontend code or logs.
* Use a secure secrets vault.
* Implement credential rotation support.
* Monitor and audit all access to credentials.\
  \ <br>