> For the complete documentation index, see [llms.txt](https://docs.openg2p.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openg2p.org/platform/platform-services/partner-management.md).

# Partner Management

OpenG2P's central registry of partners, their public keys and their access policies, read by other modules over an internal API.

The **Partner Management** service is OpenG2P's central registry of **partners**, their **public keys** and their **access policies** (what each partner may ask for). Every OpenG2P module that needs to verify a partner's signature (g2p-bridge, consent-manager, …) fetches that partner's public key from this service, and modules that enforce access (the Consent Manager, an Exchange's Composite) fetch its policies, instead of maintaining their own partner tables.

## Why it exists

Before Partner Management, partner keys lived in two disconnected places:

* **g2p-bridge / openg2p-fastapi-common** kept a local `partner_keys` table seeded from Helm config, with no runtime admin API.
* **consent-manager** kept its own richer `Partner` + key model with an approval flow and a JWKS endpoint.

Partner Management consolidates these into one system of record. Modules stop managing partners locally and simply **read keys and policies from a shared API**. Access policies, formerly kept in the Consent Manager, are also held and approved here.

{% hint style="info" %}
Partner Management is installed **as part of `openg2p-commons-services`** (the shared platform-services layer), deployed as `commons-services-pm-*`. See [Deployment](/platform/platform-services/partner-management/deployment.md).
{% endhint %}

## What it does (v1)

* **Onboarding** — an admin registers a partner (`partner_id`, name, free-text description) and its initial public key(s). Keys may be pasted (PEM, X.509 certificate, or JWK) or imported once from the partner's `jwks_url`.
* **Approval** — a partner moves through `created` → `active` → `disabled`. Keys are served only while the partner is `active`.
* **Key rotation** — a partner (via the admin, in v1) files an *update* request that adds new keys and/or revokes old ones. New and old keys can be active at once for zero-downtime rotation.
* **Access policies** — per partner, a scope policy for each registry (data controller) and a policy for each Exchange use case, each versioned and changed through approved onboarding or policy requests. See [Access policies](/platform/platform-services/partner-management/functional-specifications.md#access-policies).
* **Policy choices** — optionally, the policy form offers registries' data scope catalogues and an Exchange's use cases ([catalogue sources](/platform/platform-services/partner-management/functional-specifications.md#catalogue-sources)), and purposes and subject ID types from the Master Data code lists `CONSENT_PURPOSE` and `SUBJECT_ID_TYPE` ([Master Data code lists](/platform/platform-services/partner-management/functional-specifications.md#master-data-code-lists)), and checks requests against them.
* **Key and policy fetch** — unauthenticated internal APIs return a partner's active public keys by `partner_id` (and optionally `kid`), plus a per-partner JWKS view, and its active access policies.

## Scope of the first version

* The portal is **admin-run**, not partner self-service. The admin both files requests and approves them.
* Approval is a **simple built-in step** (`created` → approved/`active`); there is no Approval Workflow Engine (AWE) integration yet. The data model reserves an `awe_request_id` for a later AWE integration.
* The key- and policy-fetch APIs require **no caller signature** — they return only non-secret material and are exposed on the cluster-internal gateway.

## Built on

The two backend services are built on [**`openg2p-fastapi-common`**](https://github.com/OpenG2P/openg2p-fastapi-common) (with `openg2p-fastapi-auth` for staff-realm JWT validation), tracked at the `develop` ref. See [Technical Architecture → Framework](/platform/platform-services/partner-management/technical-architecture.md#framework).

## Pages

* [Versions](/platform/platform-services/partner-management/versions.md)
* [Functional Specifications](/platform/platform-services/partner-management/functional-specifications.md)
* [Creating and Changing Policies](/platform/platform-services/partner-management/creating-and-changing-policies.md)
* [API Reference](/platform/platform-services/partner-management/api-reference.md)
* [Technical Architecture](/platform/platform-services/partner-management/technical-architecture.md)
* [Integration — consuming partner keys and policies](/platform/platform-services/partner-management/integration.md)
* [Deployment](/platform/platform-services/partner-management/deployment.md)
* [Testing](/platform/platform-services/partner-management/testing.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

```
GET https://docs.openg2p.org/platform/platform-services/partner-management.md?ask=<question>&goal=<user_goal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.