[antoinetoussaint-byte]

What we are trying to do

This is step 2c of the solution-principal work (spec #11, #14). The core's state layer merged in #19. This PR adds the core's issuance over it, so that the local authority, and later saas accounts, issue through one host-independent core. It also carries the r137 issuance findings and every r143 fix. Those must land before any host wires Uninstall, the role calls or WithdrawModule. saas is untouched. The local authority moves onto this core in the next PR.

The change

libraries/authority-core/go/authority:

• issue.go: IssueForPerson, IssueForWorkload, IssueForInstallation and IssueChild (rule A).
  • Through a solution, a person holds only their roles' scopes, owned by the principal.
  • The installation acting for itself is the principal, holding its agent role.
  • Owner-selected scopes go only to an audience that declares owner_aware.
  • A workload naming an undeclared binding is refused by name.
• delegation.go: Delegate, RevokeDelegation, Delegation and IssueForDelegation.
• check.go: Check and ListResources (grants carry their owner).
• transfer.go: AuthorizeTransfer.

r137, carried here

• B1: person, installation, child and delegation issuance each read the organization's revision and the owner's seal and epoch inside the decision's own snapshot. The seal and epoch come from sealIn and epochIn, the tx-scoped derivations the seal sources use, as r143 recommended. A minted capability is refused unless it carries those values, so a revoke, a team leave or an uninstall committed in between yields no capability. race_test.go covers this: a racing store applies the change right after the decision read, for a revoked role and a team leave, through each path.
• m1: an installation issue for another organization's installation gets the same answer as for an absent one.
• m4: Check verifies first. Only a capability that verified up to its revocation has an owner-aware withdrawal named from the store.
• Token-level B2 and M1:
  • a hop the installation made for itself stays dead after uninstall and a reinstall with a narrower role;
  • a person's hop through the solution, sealed elsewhere, ends with the uninstall.

r143

• M-a: Uninstall and every role call answer a caller of another organization with the foreign answer before any installation is read. principal_test.go's "another organization's administrator" case now expects that answer.
• M-b: a withdrawn module that is delivered again reactivates its module installations, each at a higher revision.
• m-a: a withdrawn module leaves a tombstone. A redelivery can neither rename it nor rewind its generation, so the seal never goes back and a generation never rewinds. The invariant is documented on the sources.
• m-b: an operation binding's incarnation adds the acting installation's revision, so a binding revoked by an uninstall is never revived.
• m-c: memstore.Write rolls back a transaction that panics.
• m-d: ApplyModule starts over when its transaction is retried.
• m-e: the same install asked again while pending resumes it. Another install of a pending target is refused naming the pending state.
• m-f: Install refuses a principal that names a module, a person or another installation.
• m-g: a store failure under a seal is reported as itself.

The Store contract gains Tombstone and PutTombstone. No host implements the contract yet besides memstore.

Size

1,375 hand-written non-test lines and 910 test lines, under the ~2,000 budget.

Reuse and classification

• Every decision is decide's (feat: the authority core's decisions, and readers that honour resource owners #18).
• Every seal, epoch and revision is the state layer's (feat: the authority core's state layer: Store, in-memory store, seal sources, roles and lifecycle #19), read through the same tx-scoped derivation the verifier's sources use. There is no second calculation.
• Signing and verification are core's workcontext.Authority and Verifier.
• This is a fix at the owner.

Tests

• go vet and go test -race -count=1 ./... with GOWORK=off pass in libraries/authority-core/go, libraries/hop/go and modules/authority/services/local/code.
• Each r143 test was run against the core as it was before these fixes, and failed: M-a, M-b, m-a, m-b, m-c, m-d, m-e, m-f, m-g.
• With the B1 fence disabled, the person and delegation races mint a capability that passes Check. The child race also fails closed without the fence, through core's recheck of the parent.
• Spec suites:
  • principal_test.go: confinement, owner-aware audiences, owner-aware withdrawal, roles by scope, children that never widen, and other installations and organizations;
  • revocation_test.go: revoking on A leaves the capability through B valid, team grants, uninstall, transfers;
  • child_intersection_test.go (r122);
  • r124_test.go;
  • race_test.go;
  • r143_test.go.

Fleet consumers

None change here. The owner-blind readers named in #18 still have to move before any host mints owner-selected scopes:

• module-annotations authority.go:307
• module-evaluation identity.go:337/528
• module-record-store operations.go:188
• cli executionrecorder

🤖 Generated with Claude Code