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:
@@ -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.
|
||||
|
||||
Reference in New Issue
Block a user