Skip to content

Build mock-plane example (L1 HTTP service receiving + verifying) #3

Description

@Faux16

Context

The examples README lists this as coming:

mock-plane/ — Minimal HTTP service receiving and verifying events (L1)

Symmetric counterpart to mock-vendor.

Goal

A self-contained example under examples/mock-plane/ that:

  1. Runs as a FastAPI HTTP service.
  2. Exposes a POST /events endpoint accepting signed AGP events.
  3. Resolves the signing key (config-driven trust store for now; registry-driven once the resolver ships).
  4. Verifies signature, validates schema, stores the event in an append-only in-memory ledger.
  5. Exposes GET /events for the operator to inspect what's been received.

Acceptance

  • make demo from examples/mock-plane/ boots the service.
  • Pointing mock-vendor at it produces verifiable events on the plane side.
  • agp-cts validate-plane --endpoint http://localhost:PORT (once that command lands — tracked in cts) returns "conformant L1".
  • Smoke test in tests/ posts a well-formed event (accepted) and a tampered event (rejected with a clear error).
  • README states: L1 only, no policy delivery / no Flow C.

Scope

  • Built on the Python SDK HTTP scaffold (related issue).
  • In-memory storage only; persistence is out of scope.
  • Replay-cache integration (once that ships — tracked in sdk-python) — wire the hook even if cache is a no-op stub for now.

🚀 Start here

What: a minimal HTTP service that receives AGP events and verifies their signatures (L1). The counterpart to mock-vendor (#2).

Files: examples/mock-plane/README.md, Makefile (demo target), the service.

How to build it:

from openagp.events import verify          # pip install openagp
# on POST /agp/v0/events: verify(event, public_key_b64=...) ; 202 on success, 400 on bad signature

Acceptance criteria:

  • Accepts events, verifies signatures, rejects tampered ones (flip a byte → rejected).
  • make demo shows a good event accepted and a bad one rejected.
  • README explains verification + key resolution; use the SDK.
  • DCO sign-off.

Metadata

Metadata

Assignees

No one assigned

    Labels

    good first issueGood entry point for a new contributorstatus:needs-triageNewly opened, not yet assessed by a maintainertype:featureAdditive change — new functionality

    Type

    No type

    Fields

    No fields configured for issues without a type.

    Projects

    No projects

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions