registrystack / registrystack/registry-stack

Revisit parked registry-platform-sts when a consumer is promoted

Open
#298 1 comment 0 reactions 0 assignees View on GitHub
area:platform post-1.0 triage:roadmap
Dominant language
Rust
Stars
2
Forks
0
Avg merge
2h 57m
Merged PRs (30d)
128

Description

## Context

Issue #246 parked `crates/registry-platform-sts` instead of deleting it. The source remains in git, but the crate is excluded from the active workspace because the intended Assisted Access caller did not enter the `registry-stack` release surface.

The STS bridge was originally built to exchange raw eSignet subject token material for narrow Notary-bound transaction tokens. That remains useful, but it should not become a 1.0 support or audit surface without a real promoted consumer.

## Revisit when

Pick this back up when one of these is true:

- Assisted Access is promoted into the source/release surface and needs the STS endpoint.
- The Notary delegation-profile work (#44 / #49) needs an RFC 8693 token-exchange bridge.
- Another release-surface product needs Notary-bound transaction tokens from verified subject tokens.

## Acceptance criteria

- Restore `crates/registry-platform-sts` as an active workspace member only with a named consumer.
- Add end-to-end tests proving the consumer calls STS and Notary receives only the Notary-bound token.
- Document the deployment contract: routes, env vars, trust anchors, audit sink, rate-limit store, and signing-key custody posture.
- Re-run adversarial review for token minting, session binding, audit redaction, rate limiting, and signer custody.
- Update release readiness and platform docs so STS is represented as active only after the consumer path is covered.

## Non-goal

Do not delete the parked STS source just to close this issue; it is intentionally retained for future reactivation.

Contributor guide

Open the contributing guide

Research direction

Start with the parked crate at crates/registry-platform-sts and review issue #246, then check the consumer conditions in Assisted Access and the Notary delegation-profile work (#44 / #49). Work should begin only after a named release-surface consumer is promoted. Done means the consumer path, end-to-end tests, deployment contract, adversarial review, and release/platform documentation are all covered.

Written by the indexing model from the issue text.

Assessment

Tech stack
rust
Domain
api, authentication, release, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.