### Problem An `audit_trail_tsa_provider` carries two identities, and one of them is hand-rolled next to one the framework already provides. - `tsa_id`, an integer assigned at save from a counter, is what a `tsa_timestamp` row names inside its signed `context_permanent` bucket. - `id`, the config entity machine name, is derived from it as `tsa_<n>`, so the operator never chooses it. - `uuid`, which Drupal generates for every config entity, writes into the config file and preserves across export and import, is already there and unused. ### What the counter is for An id must never be handed out twice, because a stored row names it and `ChainTimestamper::verifyRow()` resolves the provider from it to get the CA chain the RFC 3161 response is checked against. Reissue an id and old timestamps verify against another authority's chain, silently. `AuditTrailTsaProvider::getNextTsaId()` therefore asks three sources and takes the maximum plus one: the surviving provider entities, the stamped rows (an unindexed scan of `context_permanent` JSON, because nothing indexes a value inside it), and `audit_trail_tsa.highest_assigned_tsa_id` in state, which `audit_trail_tsa_uninstall()` deliberately does not delete. That machinery exists because integers are ordered. One number vouches for every number below it, including ids this site has never seen, which is what a disaster-recovery import produces. ### Why a uuid removes the need for all of it A uuid does not need a floor, a scan or a mark, because it does not collide. Nothing has to know what any other site ever used. Deletes: - `AuditTrailTsaProvider::getNextTsaId()` and the three-source maximum; - `AuditTrailTsaProvider::STATE_HIGHEST_ASSIGNED_TSA_ID` and the preservation of it in `audit_trail_tsa_uninstall()`; - `TsaProviderUsage::getHighestUsedTsaId()` and the unindexed JSON scan it runs once per provider an operator adds; - the re-ask-at-submit dance in `AuditTrailTsaProviderForm`, which is why the add form asked for a machine name and then discarded the answer (#3620411); - `getTsaId()`, the `tsa_id` config key and its schema entry, and the id column on the providers listing. And the machine name becomes an ordinary one the operator picks, like every other config entity in Drupal, because nothing derives it any more. ### The behaviour this changes, on purpose Today, a provider that disappears and a new one that takes its number are indistinguishable to a stored row: the row resolves to the new provider and is verified against the wrong certificate chain, with nothing said. A recreated provider gets a new uuid, so those rows resolve to nothing and say so. An honest failure replaces a silent wrong answer, which is the behaviour this module exists to provide. ### Cost Readability. `Provider %label (#@id)` in the activate, deactivate and delete confirmations, and in `ChainTimestamper`'s exceptions, cannot carry 36 characters of hex. Those messages should name the label alone, which reads better than the number did. The listing drops its id column, which is redundant beside the label. Row size: a uuid in `context_permanent` instead of a small integer, on `tsa_timestamp` rows only, which are written per chain head rather than per audit row. ### No upgrade path Pre-beta, so no update hook: reinstall is the answer. Rows written under the old scheme name an integer that no provider will carry, and there is no rewriting them in place because the bucket is signed. ### Disclosure Written by an AI assistant (Claude Code) during an audit of this module requested by the maintainer. The uuid was confirmed present on a live provider before this was filed. Any merge request is reviewed by the maintainer.