registrystack / registrystack/registry-stack
Decide whether BReg event destinations may carry a static authorization header
- 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
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