2026-09-05 01:02:34 +00:00
2 changed files with 17 additions and 7 deletions
@@ -1,5 +1,5 @@
 ---
-status: proposed
+status: accepted
 date: 2026-09-05
 deciders: jochen
 reconstructed: false
@@ -1,9 +1,9 @@
 ---
-status: open
+status: resolved
 opened: 2026-09-05
 located-in: [mesh-control, mesh-catalog]
-fixed-by:
+fixed-by: ADR 0054 (a slug for the login) + a shorter minted secret (mesh-control)
-amended-design:
+amended-design: 0054-a-consumers-identity-fits-the-tightest-backend.md
 ---
 # The mesh's derived login does not fit every backend's identity rules — S3 rejects it
@@ -62,6 +62,16 @@ and those are not always the same string.
  permissive? If nothing needs it long, the cheap fix is to cap it.
 - Does this fold into the same decision as the data-provision return path, or is it separate?
-The options are sketched in **ADR 0054 (proposed)** — bound the identity by the true minimum and
+## Resolution
-refuse early (recommended), a compact fallback for overflow, per-interface bounds, or a
+
-provider-generated identity (rejected). Awaiting ratification.
+Accepted **ADR 0054** (option E): a module declares an optional short `slug`, and the mesh derives
 `mesh_<node>_<slug|name>`, bounded by the tightest backend (an S3 access key's 20) and refused at
 assignment — naming the slug as the remedy — when it still would not fit. The minio grant e2e proved
 it: `bucketuser` declares `slug: bkt`, so its access key `mesh_anchor_bkt` (15) is accepted where
 `mesh_anchor_bucketuser` (22) was refused.
 Proving that surfaced a **second S3 length constraint on the same credential** — the secret. The
 mesh minted a 43-character password (32 random bytes, base64url), and an S3 secret key is 8–40. Fixed
 in `mesh-control` `internal/secrets/seal.go` by minting 30 bytes → exactly 40 characters (240 bits,
 ample), which fits S3 and every other backend. Both halves of an S3 credential — the access key
 (login) and the secret key (password) — now fit the tightest backend, by the same rule.