2026.09.1
The first published release. Until now StubID could only be run from a clone, and the guides told readers to pull an image that did not exist.
What is published
Three packages a test suite references directly:
| Package | For |
|---|---|
StubId.Testing |
running StubID in a container for the length of a test run |
StubId.InProcess |
running it inside the test process, with no Docker at all |
StubId.Client |
the control API on its own, against an instance already running somewhere |
StubId.Server, StubId.Wire, StubId.Abstractions and StubId.Profiles.Abstractions are
published too, because the three above depend on them. They are substrate: they carry no
package tags and no readme, and nothing needs to reference them directly.
StubId.Profiles.Idura is deliberately not published. It declares Idura's route table and
answers 501 to every route but one, because no Idura login has been recorded. It exists to
prove the profile seam can express a second broker.
The container image is ghcr.io/benne/stubid, built for linux/amd64 and linux/arm64 on
runners of each architecture rather than one emulating the other, and carrying a provenance
attestation that gh attestation verify checks.
Three tags point at this release:
| Tag | Moves |
|---|---|
2026.09.1 |
never |
2026.09 |
to the next release recorded in the same month |
latest |
to every release |
Pin 2026.09.1 in anything that asserts on bytes.
The version is a date
What this emulator changes is bytes. A fidelity correction — StubID emitting what the broker actually sends, where it previously did not — is a breaking change for anyone asserting on the bytes it corrects, and it is not a distinction a semantic minor can carry. A date says which recording of the broker you are running, which is the question that actually matters.
The same release is therefore spelled two ways. The container tag keeps its padding, because
tags sort as text and 2026.09 precedes 2026.10 where 2026.9 would not. NuGet reads a
version as numbers and drops the leading zero, so the package version is 2026.9.1. Both
spellings resolve: dotnet add package StubId.Testing --version 2026.09.1 works and is written
into the project file as typed, while a bare dotnet add package writes 2026.9.1.
What this release reproduces
A login, end to end, against the recorded surface of Signaturgruppen Broker ("Nets eID
Broker") pre-production: discovery, the key set, authorization in all four arrival shapes,
the token exchange, userinfo, logout, and transaction signing including the transaction token
and its OCSP response. A stock ASP.NET Core application signs in, and so do Node's
openid-client and Spring Security, over TLS as well as plain HTTP with nothing relaxed on
either side. So does a real browser in Chromium, Firefox and WebKit.
Where StubID knowingly differs from the broker it says so, and a running instance lists
every divergence at GET /_stubid/v1/fidelity.
What is not in it
The admin interface is not built. Three behaviours are implemented from vendor documentation
rather than from a recording, because reaching them needs a completed login the capture harness
cannot drive; each is marked in the fidelity ledger and listed in the divergences. The address
members under ssn.details_* have never been observed, because the test identity has no
register entry behind it.
Claim composition, error envelopes, the key roster and the request grammar are engine code rather than profile code, and stay that way until a second broker is recorded.