AL2 Issuer Onboarding Process

Administrative document. No marketing. No sales engagement.

0. Normative Documents

• /v1/trust-store.json — authoritative issuer status and PX‑TL log keys
• /v1/policy.json — portability, non‑discrimination, data minimization, transparency
• /v1/fee-schedule.json — micro‑levy tiers and price constitution (including billing state)

Registry documents are published as layered JSON ({payload, signature}) and are authoritative only when the Root signature verifies.

1. Scope

This process applies to independent audit firms and institutional entities seeking permission to issue AL2 receipts and to obtain registry stamps (SCT) from PX‑TL.

This process is procedural and administrative by design. Individual technical consulting, custom integration support, private interpretations of specifications, and advisory services are out of scope. Implementers must rely on published registry documents.

2. Eligibility (minimum)

• Legal entity registration in an acceptable jurisdiction.
• Professional indemnity coverage appropriate for compliance attestation activities.
• Documented incident response, key compromise, and key rotation procedure.
• Evidence retention policy appropriate for external reliance workflows.

3. Cryptographic Custody (minimum)

• Issuer signing keys MUST be held in approved HSM / enclave boundaries (see Schedule 6/8 in licensing package where applicable).
• Issuer MUST support Ed25519 signing and verification operations without key export.

4. Verification Duty (liability boundary)

• Issuer MUST NOT rely on self‑reported CI metadata. Prior to issuing AL2, issuer MUST perform independent recomputation via the CI/CD platform official API (or equivalent immutable evidence source) and match deterministic binding outputs.
• AL2 issuance MUST be automated and reproducible; manual per‑receipt verification is discouraged.

5. PX‑TL SCT Stamp Request

PX‑TL does not accept raw telemetry. SCT requests register only a deterministic hash.

POST /v1/px-tl/sct
Content-Type: application/json

{
  "issuer_id": "<assigned issuer_id>",
  "canonical_hash": "<64-hex>",
  "log_id": "<optional; defaults to primary log>",
  "issuer_signature_b64u": "<ed25519 signature>"
}

issuer_signature message (bytes):
  "PXTL-REQ1." + canonical_hash + "." + log_id

Idempotency: canonical_hash is treated as the idempotency key. Repeat submissions for the same canonical_hash MUST return the same SCT without duplicate billing.

Billing state: Administrative micro-levy billing is governed by /v1/fee-schedule.json and is subject to the notice constraints stated therein.

HTTP semantics: 200 (SCT issued or replayed), 401/403 (unauthorized), 402 (payment required), 409 (conflict), 429 (rate limited).

6. Application Package (submission)

• Requested issuer display name and compliance contact.
• Issuer public key (Ed25519 raw 32 bytes, base64url).
• Evidence of custody controls (HSM/enclave boundary).
• Evidence of verification duty implementation (independent recomputation workflow).

Submission channel is provided via the Ticket Desk. The Ticket Desk is procedural only.

7. Outcome

• APPROVED: issuer is published as ACTIVE in the Trust Store.
• REJECTED: no issuer record is created.

8. Revocation

• Registry may set issuer status to REVOKED immediately.
• Once Trust Store reflects revocation, strict verification MUST fail external reliance.
• Appeals are procedural only (see /support/tickets).

9. Administrative Notice

This domain is operated by an independent registry operator for administrative and standard‑maintenance purposes. No governmental endorsement is implied.