ADR 0114: a two-party credential rotates over two logins

Graduates research 016. Retiring a login is separated from removing a
consumer, which closes a data-loss path in five providers; single-party
secrets rotate in place; the number of parties decides, not the provider.
This commit is contained in:
jochen
2026-09-26 00:22:21 +02:00
parent 942ebe350f
commit 43f63ed41c
5 changed files with 234 additions and 20 deletions
@@ -6,6 +6,7 @@ updated: 2026-09-26
decisions:
- 02-DECISIONS/0112-a-module-definition-names-no-node-mesh-or-path.md
- 02-DECISIONS/0113-the-vault-makes-every-secret.md
- 02-DECISIONS/0114-a-shared-credential-rotates-over-two-logins.md
- 02-DECISIONS/0110-a-seat-is-a-module-assignment-from-a-closed-set.md
- 02-DECISIONS/0111-a-build-source-is-on-the-git-seat-or-external.md
- 02-DECISIONS/0084-which-provider-serves-a-consumer.md
@@ -248,12 +249,23 @@ process, or a file in a mounted directory. A secret a service takes only at firs
applied by its provisioner or marked not rotatable by the mesh, and a rotation of it is refused rather
than reported done.
**How old and new change over is not settled.** Until it is, rotation stays as the controller does it
today: in place, both ends sent in one push, with a stated window in which a consumer cannot
authenticate. [Research 016](../../01-RESEARCH/016-how-a-credential-can-be-rotated/00-overview.md)
measured three mechanisms against every provider. One constraint holds whichever is chosen: **retiring a
credential must never remove a consumer's resource.** Today's adapters remove both in one call, and in
five providers that deletes the consumer's data.
**How old and new change over depends on how many parties hold the credential**
([ADR 0114](../../02-DECISIONS/0114-a-shared-credential-rotates-over-two-logins.md), on
[research 016](../../01-RESEARCH/016-how-a-credential-can-be-rotated/00-overview.md)):
- **Two parties**, a consumer and its provider, or a module and the broker: each consumer has two logins
derived by the mesh, both with its rights over one resource, named after the consumer. The vault makes
the new value; each applier ensures the unused login with it and confirms both authenticate; only then
are readers given it and recreated; once every reader has confirmed, the old login is retired. Nobody
is left without a credential that works, and `status` shows who a rotation waits on.
- **One party**, a provider's administrative credential or a module's own secret: in place. Its own
provisioner applies it with the old value, or the host recreates it.
**Retiring a login never removes what it reached.** An adapter keeps *retire a login* and *remove the
consumer* apart. Only unassigning removes the resource, and never a rotation. Today the two are one
call, and in five providers it deletes the consumer's data, so this separation comes first. An adapter
that cannot yet ensure a second login rotates in place, with its window stated, and is listed until it
can.
## Refusing
@@ -302,8 +314,8 @@ Each phase ends at a check that holds, so none of them leaves a mechanism half-r
mesh carries providers' data back.
[Issue 103](../../04-ISSUES/103-a-container-is-not-recreated-when-a-file-it-reads-changes/00-report.md)
is fixed in the host already. *Ends when* nothing outside the vault generates a shared secret after
genesis, a lab consumer of analytics receives its site id, and a database credential rotates, the
vault making the value, the consumer recreated by derivation, and its data intact.
genesis, a lab consumer of analytics receives its site id, and a database credential rotates over its two
logins, the consumer recreated by derivation, never without a working login, and its data intact.
3. **Definitions move, and seats move to assignments.** Every catalogue definition is rewritten, adopted
and running assignments placed where their data already is, and each claim becomes a seat the
module can hold, held by the assignment that holds it today. *Ends when* the list of definitions
@@ -329,15 +341,13 @@ Each phase ends at a check that holds, so none of them leaves a mechanism half-r
| Only the vault generates a shared secret after genesis | A controller test: no code path generates one. An installer test: genesis generates exactly the foundation's first secrets and delivers them to the vault. |
| Only the vault provides `secret` | The parser refuses another provider of it, and resolution refuses a pin on a `secret` requirement. |
| A provider's per-consumer secret comes from the vault | A resolution test: requiring a database expands to a secret requirement named for the consumer, answered by the vault and delivered to both recipients. |
| Restarts are derived, and rotation keeps data | The tests of [ADR 0113](../../02-DECISIONS/0113-the-vault-makes-every-secret.md): an applied secret restarts nothing, one read at start recreates its reader without a declared restart, and rotating a consumer's credential leaves its resource and data intact. |
| Restarts are derived | The tests of [ADR 0113](../../02-DECISIONS/0113-the-vault-makes-every-secret.md): an applied secret restarts nothing, and one read at start recreates its reader without a declared restart. |
| A two-party credential rotates over two logins | The rotation tests of [ADR 0114](../../02-DECISIONS/0114-a-shared-credential-rotates-over-two-logins.md): retiring a login leaves the resource intact; readers move only after the applier confirms; an unreachable reader keeps its old login until it returns; a single-party secret rotates in place. |
| Refusal names everything at once | A resolution test with three unresolved requirements of different kinds: one refusal naming all three. |
| The old forms retire | The catalogue test listing definitions still using one. It must be empty before a form is removed. |
## Not settled here
- How old and new credentials change over on rotation: in place, as today, or two logins over one
resource, as [research 016](../../01-RESEARCH/016-how-a-credential-can-be-rotated/03-the-options.md)
recommends for credentials with two parties. It is decided in its own record.
- The exact spelling of the one form. It must name a requirement and a field and nothing else.
- The layout a node's default root uses beneath it, beyond one directory per assignment.