gizmoduck: T3 federation design r4.1 for #414: privilege path table with closed and accepted forms (mos-1009), issuer and TLS front end (B8), key procedure (N13), R3 consumes row 196 (N14), DNS (N15), grants name bus project ids with one covers (morgana-0005)

This commit is contained in:
2026-10-20 14:12:55 -05:00
parent a659e41f30
commit 73677b87d5
2 changed files with 86 additions and 19 deletions
+85 -19
View File
@@ -1,9 +1,9 @@
# T3 federation design: factory and hub (Vikunja #414, G3, G4, C1.1)
Author Gizmoduck (Opus 5.5), 2026-10-20, r4. Design only, no product code. Reviewer Duckworth (Opus 5.5,
Author Gizmoduck (Opus 5.5), 2026-10-20, r4.1. Design only, no product code. Reviewer Duckworth (Opus 5.5,
mos-0978), r1 verdict changes B1-B5 (duckworth-0001, REVIEW.md at b402197ff), r2 verdict changes B6 (duckworth-0002,
REVIEW-r2.md at 03a663cd7), r3 verdict changes B7 (duckworth-0003, REVIEW-r3.md at 45cbe5896). R1, R2 and R5
go to Sage's
REVIEW-r2.md at 03a663cd7), r3 verdict changes B7 (duckworth-0003, REVIEW-r3.md at 45cbe5896), r4 verdict changes B8 (duckworth-0005, REVIEW-r4.md at
4966136d4). R1, R2 and R5 go to Sage's
queue once Duckworth approves, and Sage assigns owners. Code lines are at origin/refactor 9ae8c73ac. The
Q175 SSO design is cited at Sage's local commit 817e8f51b (agents/sage/work/q175-sso/DESIGN.md), which was
not on origin when this was written.
@@ -40,6 +40,19 @@ PLAN.md T3 (all in jason-master-restart).
#419, section 8). N11, `#waiting` returns null for `to` `user` (3.6 item 7, R3).
N12, R3 assumes nothing about how shares end (section 9 Q2). Row 196 (#1694, Gander) owns the shared
principal verifier before R3 (section 5).
- r4.1 (mos-1006, gander-0007, morgana-0005): R8's gate adds the identity provider path. A factory
credential that can administer the issuer the hub trusts gets in without the host (the B8 bullet below
has the rule). Mos accepted the sudo deviation (root ssh
and the `authorized_keys` check). Row 196's interface is settled: one verify per one-request
connection, `s.user` for that request only, and the walk mutants move to row 196. morgana-0005: grants
name bus project ids, and one pure `covers` in R1 matches a grant to a thread (3.5). R4's loss
predicate counts only collaborator grants, so a downgrade to viewer ends the run.
- r4.1 (duckworth-0005): B8, the hub's issuer and TLS front end are in its trust base. The hub trusts
only an issuer no factory credential can administer, and TLS ends where the factory can't reach
(3.4, R8). A brand, tenant or application in the factory's Authentik doesn't count. N13, the key check
is a procedure. N14, R3 consumes row 196's verifier and depends on it. N15, DNS control. mos-1009:
section 8 has a table of every privilege path (hypervisor, backups, sign-in provider, TLS front end,
certificate authority, DNS, network), each closed by a check or accepted by Jason with set wording.
- r2.1 (mos-0988): the separate uid is row 190b. R8's gate points at 190b, R7 at row 190 (one uid,
scratch). P19 333 is on the 10-27 path (section 8).
- Mos's rulings in mos-0978 and mos-0984 replace the r1 questions (section 9). The push credential note is
@@ -156,9 +169,13 @@ to each other (W1).
### 3.4 Remote user identity
A user is `(provider, sub)` where `provider` is an id from that instance's `console.sso.providers`. Q175
already verifies signature, issuer, audience, expiry and nonce, and allows several providers. If the hub
and the factory use the same Authentik, Jason's `sub` is the same on both. If Melanie's hub uses Pocket
ID, the hub lists both providers. Either way the receiving instance checks the token. It never takes the
already verifies signature, issuer, audience, expiry and nonce, and allows several providers. The hub
trusts only an issuer that no factory credential can administer (B8, duckworth-0005), for example a
Pocket ID on the hub's side. Jason then has his own account at that issuer, with a `sub` of its own. A
separate brand, tenant or application in the factory's Authentik doesn't count: factory agents hold an
Authentik API token, and whoever administers the issuer can impersonate any user, reset a login or
repoint a redirect. If Jason wants the hub on the factory's Authentik anyway, that is his decision, of
the same kind as #419 (section 8). Either way the receiving instance checks the token. It never takes the
home instance's word for who the user is.
The owner path stays as Sage designed it: `console.sso` subjects sign in as the business human. Everyone
@@ -202,13 +219,29 @@ provider ids, peer ids and declared businesses as arguments, so it stays pure:
- `subjects[].provider` names a given provider. A `(provider, sub)` pair appears once in the file and
never in `console.sso.subjects`.
- `home` names a given peer, or is `local` for a non-federated extra user.
- A grant names a declared business. `projects` is `["*"]` or declared project ids. `instances` is
- A grant names a declared business. `projects` is `["*"]` or bus project ids, the UUIDs
`project.create` makes (broker.mjs:2306). `instances` is
`["*"]` or declared instances. `level` is `collaborator`, the only level in 10-27. `expires` is optional
ISO time.
- The loader checks a project entry's shape only (a UUID). It can't see the bus, so an id with no bus
project covers nothing.
- A grant past `expires` is treated as absent.
- A file that fails any rule leaves every user with no grant, which revokes everything. That is the safe
direction.
Matching a grant to a thread (morgana-0005). A thread's `project` is a bus project id
(`threads.project REFERENCES projects(id)`, packages/bus/schema.sql:245), set by `thread.create`
(broker.mjs:2329-2345). A bus project may have no repo in the business file, so grants can't name
business-file projects. They name bus project ids, not names. A name could be taken later: the tester,
which runs from an agent, can call `project.create` (:2300), and nothing renames or deletes a project
today. R1 exports one pure function, `covers(grant, { business, project, instance }, now, { level })`.
It is true when the grant is unexpired, the business matches, `projects` is `["*"]` or holds the
project id, `instances` is `["*"]` or holds the instance, and the grant's level is the one asked for,
when one is asked for. The broker passes the thread row. `["*"]` also covers projects made after the
grant, and the R5 help text says so. R5's `grant --project <name>` resolves the name to the id through
`project.list` at grant time and writes the id. `mosaic access list` shows both. Row 193 uses the same
`covers`.
The collaborator level is an exact verb list. Every other verb fails `access-refused` before the verb's own
checks. That covers all owner verbs (W3), every board read (F9), `message.*`, `decision.*`, project files,
`spec.read`, `assistant.stop`, `launch.*`, `name.set` and `usage.*`.
@@ -243,7 +276,8 @@ The bar (B1, mos-0984 point 1): a bus user principal comes only from something t
that is the Console's verified OIDC session, reached through a proof the bus checks itself. The calling
process's claim alone isn't enough, and neither is a proof that admits agent ancestry.
The proof. A new path-bound CLI, `packages/bus/src/user-cli.mjs`, with its own nonce variable
The proof. Row 196 (#1694, Gander) builds this check as the `user` kind of its shared `verifyPrincipal`,
and R3 consumes it (section 5). The checks are the ones below. A new path-bound CLI, `packages/bus/src/user-cli.mjs`, with its own nonce variable
(`MOSAIC_BUS_USER_NONCE`), so neither of the other CLIs' nonces proves it. The bus checks it with a
`verifyUser` that:
@@ -323,14 +357,15 @@ find the loss:
3. `access.reload`, a new human-only verb. `mosaic access grant` and `revoke` (R5) call it after the
write, so CLI changes act at once.
On a loss, in one transaction, the broker ends the claims of every `user:<id>` thread that is no longer
covered (via `#threadHolders(business, instance, 'user:<id>')`, F5, and `#claimEnd`). The run's next bus
On a loss, in one transaction, the broker ends the claims of every `user:<id>` thread that no live collaborator
grant covers any more (via `#threadHolders(business, instance, 'user:<id>')`, F5, and `#claimEnd`). The run's next bus
call is then refused (F10).
The launcher side, so a pending message can't start a new run:
- `threadsState` (broker.mjs:390-393) adds `revoked: true` to any thread owned by `user:<id>` that no live
grant covers. The broker computes this from the file on each call, so it survives a launcher restart,
collaborator grant covers (`covers` with `level: 'collaborator'`, morgana-0005). A downgrade to viewer
ends the run. The broker computes this from the file on each call, so it survives a launcher restart,
unlike `startedFor`.
- The launcher's thread pass (launcher.mjs:510-553) never starts a revoked thread.
- For a revoked thread that is still running, the launcher SIGTERMs the runner at once, as the idle stop
@@ -359,8 +394,9 @@ assumes nothing about sharing a host:
peer link is a plain link. Section 6 does need each Console's origin reachable from the other host, so
R8 checks that now and the later rows add no infra.
- Each instance has its own OIDC client with its own redirect URI on its own origin (3.3). Each Console
must reach its provider's issuer and JWKS from its own host. If the hub uses the factory's Authentik
across hosts, that means over Authentik's public URL.
must reach its provider's issuer and JWKS from its own host. The issuer is a privilege path too. Whoever administers it can mint a hub user, so
the hub's issuer is one the factory can't administer (3.4, R8). The factory's Console reaches its own
Authentik, and the hub's reaches its own issuer.
- Q175 checks token expiry, and section 6 has a 60 s window on signed requests, so both hosts need a synced
clock.
@@ -408,7 +444,10 @@ The only one-host piece is R7, which is scratch on one host by design (row 190).
`verifyPrincipal(request, connection)` returning `{kind, business, id}`, with `SO_PEERCRED` binding
`proof.pid` to the connection. R3 consumes it for the `user` kind instead of writing its own
`verifyUser`, with the same checks as 3.6 (human walk, direct parent the bus tree's Console `serve`,
own nonce variable). R3 keeps the grant check and its mutants as consumer tests.
own nonce variable). It runs once for each one-request connection, and `s.user` holds for that
request only, with no role or grant cached (gander-0007). R3 owns every live grant check, the
`(provider, sub)` to user mapping and the user-name policy. Row 196 kills the agent-parent,
non-Console-parent and kind-confusion mutants. R3 keeps the reserved user-name mutant.
- T1.1 live also needs two Consoles, two public origins, two reverse-proxy routes and two provider
clients, which are Jason-gated infra.
- T1.2, #412 SSO. Hard dependency. Row R6 builds on Sage's phase 1 candidate (Q177 merge-chaining) and
@@ -442,14 +481,14 @@ gate. Chains follow Q177: a dependent row builds on its parent's candidate.
| Row | Work | Owner model | Depends on | Test gate |
|---|---|---|---|---|
| R1 | `packages/business/src/access.mjs`: access.json loader and validator. Providers, peers and businesses come in as arguments. One read plus the file checks | Codex Sol | none | business tests: every rule in 3.5 refuses with the key path named, symlink, non-regular file, other owner, group or other write, expiry, `*`, disjoint from the given subjects, `human`/`tester` ids, a level other than `collaborator` |
| R1 | `packages/business/src/access.mjs`: access.json loader and validator. Providers, peers and businesses come in as arguments. One read plus the file checks | Codex Sol | none | business tests: every rule in 3.5 refuses with the key path named, symlink, non-regular file, other owner, group or other write, expiry, `*`, disjoint from the given subjects, `human`/`tester` ids, a level other than `collaborator`, a project entry that isn't a UUID. `covers`: `*` and listed ids match, an unlisted project, instance or business doesn't, an expired grant doesn't, a level filter rejects another level |
| R2 | `federation` key in scripts/mosaic-config.mjs | Haiku 5.5 high | Sage #412 phase 1 candidate | test-config.sh: valid key loads, unknown sub-key and bad origin refuse, config without it loads |
| R5 | `mosaic access list, grant, revoke`: human proof, atomic write, revision bump, receipt line. Help text states the `instances` limit and the provider-removal order | Haiku 5.5 high | R1 | cli tests: tester and agent callers refused, concurrent write refuses on revision conflict, receipt appended, bad grant refused before write |
| R3 | Broker user principal: `verifyUser` and `user-cli.mjs`, `bindUser`, the 3.6 changes, the collaborator verb list and its filters, per-request grant read, audit lines for every `s.human`/`s.tester` branch | Opus 5.5 | R1 | bus tests: each listed verb allowed, every other verb refused, a leak test per listed read (other projects, other instances, other users' threads), a reply-chain `message.send` into another user's thread refused, `thread.send` writes no `human.input`, the run's reply to a user's message reaches that user's `thread.messages`, a reply `to: 'user'` without a matching `in_reply_to` refused, a user-thread run sending `to: 'human'` refused, a reply to a user returns `waiting` null and posts no notice message, revoked and expired grant refused on next request, refusals recorded. Mutants: the user CLI accepted under an agent-marked parent, accepted with a parent that isn't the Console, the grant read skipped, a read filter dropped, `#threadFor`'s user refusal removed, the reply-to check dropped (a run answers another user's message or one outside its thread), a user named like the human accepted |
| R4 | Revocation: 30 s timer, `access.reload` verb, claim end on loss, `threadsState` `revoked`, launcher skip and SIGTERM, launch check refusal, R5 calls `access.reload` | Codex Sol | R3, R5 | bus and launcher tests, each with a mutant: a hand edit removing the grant ends the run within one timer period, an expiry with no request ends it, a pending message followed by a launcher restart starts no run, a running revoked thread gets SIGTERM, another user's runs stay |
| R3 | Broker user principal: consumes row 196's `verifyPrincipal` (`user` kind, `user-cli.mjs`), `bindUser`, the 3.6 changes, the collaborator verb list and its filters, per-request grant read, audit lines for every `s.human`/`s.tester` branch | Opus 5.5 | R1, row 196 | bus tests: each listed verb allowed, every other verb refused, a leak test per listed read (other projects, other instances, other users' threads), a reply-chain `message.send` into another user's thread refused, `thread.send` writes no `human.input`, the run's reply to a user's message reaches that user's `thread.messages`, a reply `to: 'user'` without a matching `in_reply_to` refused, a user-thread run sending `to: 'human'` refused, a reply to a user returns `waiting` null and posts no notice message, revoked and expired grant refused on next request, refusals recorded. Mutants (the agent-parent, non-Console-parent and kind-confusion mutants are row 196's): the grant read skipped, a read filter dropped, `#threadFor`'s user refusal removed, the reply-to check dropped (a run answers another user's message or one outside its thread), a user named like the human accepted |
| R4 | Revocation: 30 s timer, `access.reload` verb, claim end on loss, `threadsState` `revoked`, launcher skip and SIGTERM, launch check refusal, R5 calls `access.reload` | Codex Sol | R3, R5 | bus and launcher tests, each with a mutant: a hand edit removing the grant ends the run within one timer period, an expiry with no request ends it, a pending message followed by a launcher restart starts no run, a running revoked thread gets SIGTERM, a grant left at a level other than collaborator counts as a loss, another user's runs stay |
| R6 | Console: granted-user sign-in, `user-cli` transport per session, per-request grant re-read, owner-only controls hidden, peer links | Opus 5.5 | Sage #412 phase 1, R1, R2, R3 | webui tests on Sage's fake OP: granted user signs in, ungranted `sub` refused, revoked mid-session gets 401 on next call, a granted user's owner-verb call refused by the bus even with the UI check removed (mutant) |
| R7 | Scratch two-instance acceptance: two configs, two data roots, two Consoles, one fake OP. The Consoles start outside agent ancestry (a transient user unit), as the user proof requires. They never use the live stack's units or ports | Haiku 5.5 high | R1-R6, row 190 (several instances on one uid) | script test: Jason granted collaborator on one hub project signs in to the hub, makes a thread, sends to the granted instance, gets the instance's reply in the thread, is refused on another project and on board reads, is revoked and gets refused with the run ended. The factory shows nothing of the hub |
| R8 | Live window, not a code row: hub provider client, hub proxy route, access.json written by Jason, re-pins | Jason, Mos | the hub host live (Vikunja #418), Jason's #419 answer, #412 phase 2, R7 | Entry gate, host form only for 10-27 (mos-0996): the hub runs on its own host (#418), not on dragon-lin or Melanie's server. R8 refuses to start unless every check passes. The privilege checks run on the factory host as the factory uid under `env -i`, and each passes only when the call fails: `sudo -n true`, `doas -n true`, and `ssh -o BatchMode=yes <hub-host> true` as the hub user, as Jason's user and as root, each with and without the session's `SSH_AUTH_SOCK`. If `sudo -n` succeeds, as it does for jwoltje on dragon-lin (mos-0996 point 1), the ssh checks also run as root through it and must fail, and the hub host's `authorized_keys` files hold no key whose private half is on the factory host. The hub host's bus socket, data root and config dir don't exist on the factory host, the factory host mounts nothing of the hub's, and the hub host runs no other instance or agent. Also: the two provider client ids differ, each origin answers over HTTPS from the other host, each Console reaches its issuer's discovery URL, and both clocks are synced. Jason's attestation confirms no factory agent holds a login or key for the hub host, but the failed calls are the gate. Open gate item (Vikunja #419, Jason's decision): factory agents hold root ssh to the PVE nodes (Q172), and root on a node defeats the host form (duckworth-0004). R8 doesn't start until Jason picks one of O1 to O3 (section 8). The uid form (row 190b) is a later option, outside this gate. Then Jason signs in to the hub from his account and sends one message, Melanie revokes, and his next request is refused |
| R8 | Live window, not a code row: hub provider client, hub proxy route, access.json written by Jason, re-pins | Jason, Mos | the hub host live (Vikunja #418), Jason's #419 answer, #412 phase 2, R7 | Entry gate, host form only for 10-27 (mos-0996): the hub runs on its own host (#418), not on dragon-lin or Melanie's server. R8 refuses to start unless every check passes. The privilege checks run on the factory host as the factory uid under `env -i`, and each passes only when the call fails: `sudo -n true`, `doas -n true`, and `ssh -o BatchMode=yes <hub-host> true` as the hub user, as Jason's user and as root, each with and without the session's `SSH_AUTH_SOCK`. If `sudo -n` succeeds, as it does for jwoltje on dragon-lin (mos-0996 point 1), the factory counts as root on its own host. Then, as root through `sudo -n`: fingerprint every private key under every home and `/root`, and every key loaded in any agent socket found on the host (`ssh-add -l` per socket). Compare them with `ssh-keygen -lf` over every `authorized_keys` on the hub host, root's included, and no fingerprint matches. Run the ssh checks as root, once with no agent socket and once with each socket found, and each fails (N13). Every other privilege path is a named item in section 8's table (mos-1009): hypervisor, backups, sign-in provider, TLS front end, certificate authority, DNS and network. R8 refuses to start until each one is either closed, with its check passing, or accepted by Jason in writing with the table's wording, which also goes to Melanie (#419). The hub host's bus socket, data root and config dir don't exist on the factory host, the factory host mounts nothing of the hub's, and the hub host runs no other instance or agent. Also: the two provider client ids differ, each origin answers over HTTPS from the other host, each Console reaches its issuer's discovery URL, and both clocks are synced. Jason's attestation confirms no factory agent holds a login or key for the hub host, but the failed calls are the gate. The uid form (row 190b) is a later option, outside this gate. Then Jason signs in to the hub from his account and sends one message, Melanie revokes, and his next request is refused |
R1, R2 and R5 can start now and run in parallel. R3 starts when R1 has a candidate, R4 when R3 and R5 do.
R6 waits on Sage's phase 1 candidate.
@@ -478,7 +517,34 @@ which the node can read, and a node that can change the boot can capture the pas
Mos adds Jason's answer. Until then R8 doesn't start.
## 9. Rulings (mos-0978, mos-0984, mos-0991, mos-0996, mos-1004)
### R8 privilege paths (mos-1009, duckworth-0005, Vikunja #419)
ops-01 measured the estate read-only at 19:10Z (relayed in mos-1009). There is one PVE node, `pve`,
standalone, and its root `authorized_keys` holds the factory's key, so the factory has root on the
hypervisor without any API token. The only PBS is VM 1021 on that node, the factory has root on it, and
its backups are unencrypted. The LAN is flat (10.1.0.0/16) with dragon-lin on it and no internal VLAN.
The factory has used the jarvis Authentik token for admin changes. No hardware outside PVE without
factory root has been confirmed. So today the factory administers every path below.
Each path is a gate item. Jason decides each one (#419): closed, when its check passes, or accepted,
when the accepted wording goes into his attestation and to Melanie. Every check runs from the factory
host, as root through `sudo -n` where the factory has it, and passes only when the call fails.
| Path | Closed: the check | Accepted: the wording | Hub-local option |
|---|---|---|---|
| Host access | The R8 sudo, doas, ssh and key checks (section 7, N13) | "Factory agents can log in to the hub host." | none needed, the checks can pass today |
| Hypervisor | O1 or O2 above: no factory key in any PVE node's root `authorized_keys`, and a PVE API call on the hub VM fails with each token the factory holds | "Factory agents have root on the machine the hub runs on and can read its memory and disk." | O1, hardware outside PVE |
| Backups | The hub's backups are encrypted with a key only Jason or Melanie holds: the PBS datastore shows the hub's snapshots encrypted, and the key's fingerprint matches no file on the factory host | "Factory agents can read the hub's backups in full." | client-side encrypted backups, key held by Jason or Melanie |
| Sign-in provider (B8, mos-1006) | The hub's `console.sso` trusts only an issuer no factory credential administers, never a brand, tenant or application in the factory's Authentik. An admin API call on it fails with each identity provider token found on the factory host, and the issuer's list of admin tokens and service accounts (names only, never values) shows none held on the factory | "Anyone with admin on the factory's sign-in provider can sign in to the hub as any user, Melanie included." | an issuer on the hub host, such as Pocket ID (Q175 supports several providers) |
| TLS front end (B8) | TLS for the hub's origin ends on the hub host: the certificate the origin serves matches the key on the hub host, and no factory proxy, tunnel or overlay route names the hub's origin | "The factory's proxy sees every hub sign-in, cookie and message in clear." | TLS ending on the hub host |
| Certificate authority (mos-1009) | The hub's certificate comes from a public CA through an ACME account whose key is only on the hub host, and the zone's CAA record names only that CA | "The factory can get a valid certificate for the hub's name." | ACME run on the hub host |
| DNS (N15) | A zone edit for the hub's name fails with each DNS credential found on the factory host, and the zone's owner account is one the factory can't sign in to | "The factory can point the hub's name at a host it runs." | a zone or registrar account only Jason or Melanie holds |
| Network | From the factory host, the hub host answers only on the ports R8 needs (HTTPS, and ssh where it is used), and nothing else is open to the LAN | "The hub host sits on the same flat LAN as the factory, and only its logins protect it." | a host firewall on the hub, a separate VLAN |
Some paths depend on others. Closing TLS doesn't help while the hypervisor is open, because root on the
node reads the certificate key. The attestation names every path that stays accepted.
## 9. Rulings (mos-0978, mos-0984, mos-0991, mos-0996, mos-1004, mos-1006, mos-1009)
1. Q1: human cross-access is the 10-27 slice (mos-0978). Duckworth's N8 put agent-to-agent's timing to
Jason through Mos. Jason answered "P2P federation is acceptable for 10-27" (mos-0991). Mos is checking
+1
View File
@@ -1364,3 +1364,4 @@ are never rewritten or removed; corrections are new entries.
2026-10-20T19:01:43Z | Gizmoduck (Opus 5.5) | T3 federation design r3.1 for Vikunja #414, mos-0991 (R8 gate accepts a separate host or uid, one-host audit 3.8, Q1 answer) and morgana-0002 (Q2 settled, access.json is the human store) | committed and pushed on gizmoduck/federation-design; sent to Duckworth with r3
2026-10-20T19:04:18Z | Gizmoduck (Opus 5.5) | T3 federation design r4 for Vikunja #414, answering duckworth-0003 B7 (privilege paths in R8's gate), N11 (#waiting for user replies), N12 | committed and pushed on gizmoduck/federation-design; sent to Duckworth
2026-10-20T19:08:20Z | Gizmoduck (Opus 5.5) | Correction to the 19:04:18Z line: commit 04a6112be carried only that SESSIONS line, because the DESIGN.md edit script failed on an anchor and the chain still committed and pushed, and nothing went to Duckworth then. r4 proper: B7 per mos-0996 and mos-1004 (host form only, sudo, doas and ssh checks, hypervisor path an open R8 item with O1 to O3 on Vikunja #419), N11, N12, row 196 verifier noted per gander-0006 | committed and pushed on gizmoduck/federation-design; sent to Duckworth and Mos, reply to Gander
2026-10-20T19:12:55Z | Gizmoduck (Opus 5.5) | T3 federation design r4.1 for Vikunja #414: B8 (duckworth-0005, issuer and TLS front end), N13 key procedure, N14 R3 on row 196, N15 DNS; mos-1006 (identity provider path, sudo deviation accepted); mos-1009 (privilege path table, each closed or accepted per #419); gander-0007 (verifier interface); morgana-0005 (grants name bus project ids, one covers in R1, R4 counts collaborator grants only) | committed and pushed on gizmoduck/federation-design; sent to Duckworth, copies to Mos, Morgana and Gander