Until now one authority answered for everything a deployed specdossierd did: the deployer declares it in service.ncl (`authority { url, ca, pins, project, client, actions }`), and every login and every Authorize decision is checked against it. A dossier belongs to a project, and a project that uses signatio declares its own authority where ontoref publishes it: the `signauthz` section of .ontoref/config.ncl (ClientConfig: endpoint, ca, clients) and its registered level (`.governance/authority/pins.json`: the authority's project id and keys; ontoref migrations 0104, 0105).
On 2026-09-29 the principal set the direction: landing and signing an agreed document is the project's responsibility and decision; SpecDossier knows and manages no signing key, and at most asks for a signature's verification or its attestation; the dossier carries where to reach the authority, and SpecDossier asks it directly rather than trusting what the project says. signatio already offers the act (VerifySignature, answered by an attestation the authority signs, verifiable offline with its pinned key), to a client the project registered with `authority.verify-signature` among its allowed actions.
A DOSSIER ANSWERS TO THE AUTHORITY ITS PROJECT DECLARES. For a project governed by ontoref it is the one its `signauthz` section and its registered level declare — endpoint, CA, the authority's project id and pinned keys — read as ontoref publishes them; a project without ontoref declares the same in its `.governance/dossiers.ncl`. A dossier's closing may name another when its signature is another's to give.
SPECDOSSIER LEARNS IT FROM THE ROUND. The person's CLI reads the declaration in their copy and puts it with the round (adr-003: the service never reads the project). Guests log in, and each act's Authorize decision is checked, against the authority the round names, under its pinned keys; a session is that authority's.
THE SERVICE IS THAT AUTHORITY'S CLIENT ONLY WHERE THE PROJECT GRANTED IT. The deployment declares the authorities it is a client of, with its own client credentials there — the only secret material it keeps, its own. A project grants the channel by registering SpecDossier's client in its project at its authority, with the actions it allows. A round naming an authority the service is not a client of, or pins that do not match what that authority answers with, is refused saying why.
IT ASKS THE AUTHORITY TO VERIFY AND ATTEST, NEVER HOLDING A KEY. When a dossier's closing asks for a signature, whoever signs does it on their own machine, as the project decides; SpecDossier sends the signature and the agreed bytes to the authority's VerifySignature as the project's granted client and shows the attestation it answers, verifiable offline by anyone with the authority's key. It never asks anyone to sign, and never decides who must.
WHAT THIS DOES NOT DECIDE: where the attestation persists (landing's, dossier-walk agreed → landed); the browser face of a person's proof (signatio's adr-005, proposed).
Logins and decisions for a round are checked against the authority the round names, and a round naming one the service is not a client of is refused
A signature on an agreed version is shown only as the authority's attestation, verified offline with its pinned key
One authority, the deployment's (as built until 2026-09-29)
Rejected: It makes every project answer to the deployer's authority; the principal set that the dossier carries where to reach its own.
Trust the project's word that a signature verifies
Rejected: An assertion, not evidence; the principal asked SpecDossier to ask the authority directly.
The service reads the project's signauthz itself
Rejected: adr-003: the service never reads the project; the person's CLI puts the declaration with the round.