# Registry

The Registry is the optional enterprise layer that turns AIEP adoption into a higher-trust ecosystem without blocking open use.

AIEP remains open: anyone may publish AIEP Mirror endpoints. The Registry exists only to provide a place where certain claims can be anchored, verified, and referenced in a consistent way when organisations need higher assurance.

In practice, the Registry is where you would publish:

- approved issuers (who is allowed to issue certificates)
- certificate policies (what “AIEP Certified” means at a given version)
- revocation information (if a certificate is withdrawn)
- public keys or verification material for issuers

## Why a registry is optional

Many deployments only need AIEP as a publishing and retrieval protocol. Others—especially enterprise or regulated contexts—need a way to answer “who issued this certificate?” and “is it still valid?” without relying on a private email chain.

That is what a registry provides.

## Suggested publication pattern

A minimal registry can be published as static artefacts:

- `/.well-known/aiep/registry/index.json`
- `/.well-known/aiep/registry/issuers/*.json`
- `/.well-known/aiep/registry/policies/*.json`

A more advanced registry can be served via a Worker with audit logging, rate limiting, and key rotation, while still keeping public surfaces cacheable.

## Relationship to compliance

Compliance verifies certification claims. The Registry provides the public verification material that makes those checks deterministic.


---

# Certificate Issuance

Certificate issuance is the mechanism that makes the phrase **“AIEP Certified”** truthful and machine-verifiable.

AIEP does not require certification. Certification exists to protect users from false claims. When a system claims to be certified, it should be able to point to a certificate artefact and the verification material required to validate it.

## The issuance lifecycle

A practical issuance process has four stages:

1. **Application** — the operator requests certification and supplies the required artefacts.
2. **Assessment** — the issuer validates the implementation against a published policy and schema set.
3. **Issuance** — a certificate artefact is created, signed, and published.
4. **Ongoing validity** — revocation or expiry is recorded if required.

## Where certificates live

Certificates can be published by:

- the certified system (recommended: stable URL under its own AIEP surface)
- the issuer registry (optional mirror record)
- both (best practice for resilience)

## What a certificate contains

A minimal certificate includes:

- certificate id
- issuer identity
- issuance timestamp
- policy version
- subject (the certified domain/system)
- signature and public key reference

## Verification

Verification should be deterministic:

- retrieve the certificate artefact
- retrieve issuer verification material from the registry
- validate structure via schema
- verify signature
- check revocation/expiry status

This repo ships the public *interfaces* and schemas for that flow. The operational issuance services are implemented via Worker/registry infrastructure when you are ready.