A grant has no expiry and cannot be revoked short of rotating the server secret

Type: Bug — a credential with no lifecycle
Found while: SAPE-21
Triage: Fix in 1.0.0
Status: Open
Severity: High — the fix is a compatibility break the day after the tag

Description

A grant is a bearer credential: a list of scopes plus an HMAC over account_id ":" dbname ":" scope[,scope...], signed with a key derived from the server secret under signing.GrantLabel (internal/signing/signing.go:228, 331).

There is nothing else in the message. No expiry, no serial number, no issued-at. Verification (Server.granted, internal/server/server.go:833-841) checks the signature and the account/database binding and nothing more. So a grant is good forever, and the only way to withdraw one is to change s.options.Secret — which is the same secret that signs connection strings, so rotating it invalidates every connection string on the server at the same time.

Evidence

signing.Held carries AccountID, DBName and Scopes. There is no time field anywhere in the signed message, and Grants takes no clock.
server.go:833-841: granted is signature-check plus binding-check. There is no revocation list, no issuance record, and no state on the server that a grant is checked against — deliberately, since the whole design is offline issuance.
The limit is already documented rather than hidden. The CHANGELOG entry for scopes says: "a grant has no expiry and no serial number, so it is good until the secret changes, and withdrawing one scope from one account today means reissuing every connection string on that server. Adding an expiry changes the signed message, which is a change this side and the TypeScript signer make together — so it is not being done halfway now."
That last clause is what makes this a 1.0.0 item rather than a documented limitation: the signed message is the thing that freezes.

Triage

Does it lose data, break a promise on a public surface, or stop somebody installing and running? Yes — the middle one, and by the second-order reading rather than the first.

Say it straight, because this is the deferral-or-not that most deserves an argument. A grant that never expires does not, by itself, break a promise: the CHANGELOG says up front that it does not expire, so nobody is misled. By the narrow reading of the triage question this is Defer.

It is Fix in 1.0.0 because the surface that has to change is the signed message, and the signed message is the public surface. Adding exp means adding a field to the bytes that go into the HMAC, in the Go signer, in the Go verifier, and in the TypeScript signer, all together. Before the tag that is an edit. After the tag it is a break: every grant minted by 1.0.0 fails verification on 1.1.0, or 1.1.0 has to accept both message shapes forever, which is a permanent branch in a security check — the worst place in a codebase to keep two answers.

There is a second reason, weaker but real: the only revocation available today is rotating a secret that also invalidates every connection string. That is not a revocation mechanism, it is an outage. An operator who needs to withdraw one scope from one account has no proportionate action, which makes scopes hard to recommend for the case they exist for.

If deferred, what it costs to wait

This is the item whose cost of waiting is the whole argument. Today the change is three coordinated edits and a fixture update. After 1.0.0 it is either a breaking change to a security credential or a permanent dual-format verifier.
A dual-format verifier is worse than it sounds: "accept a message with no expiry" is exactly the downgrade an attacker would pick, so the compatibility branch would have to be disabled by configuration, which means shipping an insecure default or breaking people anyway.
Scope of the minimum fix: put an expiry in the signed message and verify it; decide now whether the message also gains a serial so a revocation list is possible later without another break. The revocation list itself can wait — the field cannot.
Sequence it with ISS-12. That issue adds a grant signer to the TypeScript client (and should add one to PHP); writing those against a message shape that is about to gain exp means writing them twice. Decide the message first, then write every signer once.
The offline-issuance property must survive. This is not an argument for a nonce or a challenge–response: SAPE-21 rejected those on the grounds that they turn an offline control plane into a request path, and an expiry does not.