registrystack / registrystack/registry-stack

Decide whether BReg event destinations may carry a static authorization header

Open
#1,019 1 comment 0 reactions 0 assignees View on GitHub
area:breg criticality:p3 enhancement needs-jeremi-decision
Dominant language
Rust
Stars
2
Forks
0
Avg merge
2h 57m
Merged PRs (30d)
128

Description

## Decision needed

BReg event deliveries carry `X-Registry-Signature` and nothing else for authentication: `EventDestinationRequestTemplate::event_delivery` in `registry-platform-httputil` hard-codes `DestinationAuthorizationTemplate::Forbidden`, while a `Bearer` variant already exists and is used by other destination kinds.

Receivers that cannot run a verifier, such as OpenFn's API-key webhook trigger, cannot be addressed directly today. The OpenFn pilot put a bridge in front that verifies the signature and forwards with `x-api-key`.

## Options

1. Keep `Forbidden`. Receivers that cannot verify use a bridge. The signature remains the only trust anchor for event egress. Recommended default.
2. Add an optional static header slot (bearer or named header, secret reference) to event destinations, in addition to the signature. Lets BReg post straight to API-key receivers, but those receivers then trust transport and TLS instead of the signature. Should be an explicit, documented downgrade with a runtime config flag and a compile-time warning in `bregctl explain events`.
3. Add the slot but require the receiver to also publish a verification endpoint. Over-engineered; listed only to reject it.

## Notes

If option 2 is chosen the change is small: wire the existing `Bearer` template into `event_delivery`, extend the destination runtime schema, and exclude the header from the signed fields (it is transport auth, not payload). Shipping the verifier in the Node client makes option 1 cheaper for receivers and is tracked separately.

Triage: decision only.

Contributor guide

Open the contributing guide

Research direction

Start by reviewing EventDestinationRequestTemplate::event_delivery in registry-platform-httputil and the existing Bearer variant, then inspect the destination runtime schema and the bregctl explain events entry point. The decision must establish whether static transport authorization is allowed, and option 2 would require the header to stay outside signed fields and be documented as a downgrade.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
authentication, backend-api-design, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.