0.2.0-alpha.5 — owner decisions (day 0)#
Recorded: 2026-10-17. These decisions were taken by the project owner at the start of the alpha.5 phase, on the recommendations of the 2026-10-17 workspace assessment. Each one names the work it unblocks. Later phases record their own decisions in this directory.
| # | Question | Decision | Unblocks |
|---|---|---|---|
| 1 | Under the phishing-resistant administrator profile, how does an administrator who holds only TOTP enrol a passkey, and does the operator floor fail closed when passkeys are disabled? | Upgrade proof. Proving the existing factor inside the transaction unlocks passkey registration but never satisfies MFA on its own; totp/enroll and totp/activate are refused under the profile. The floor fails closed: CheckMFAFloor refuses realm policies that leave passkeys disabled, production startup refuses the floor without WebAuthn configured, and identity-cli doctor warns about realms already in that state. | evaluate() change (MFA-006) |
| 2 | May organization administrators enable JIT provisioning on their own connections, and when is Google's email_verified trusted? | Bounded JIT. Organization-scoped connections may enable JIT only when allowed_email_domains is non-empty and a subset of the organization's verified domains. The google adapter keeps email_verified only for gmail.com, googlemail.com, or when the hd claim equals the e-mail domain. | Federated e-mail verification fix |
| 3 | Is the realm signing algorithm stored on the realm or derived from the active key? | Derived from the active key in alpha.5 (no migration). A stored default algorithm plus an enabled-algorithm set arrives in 0.3.0 together with one active key per algorithm, so that work stays additive. | Scheduled-rotation fix; 0.3.0 multi-algorithm signing |
| 4 | Which releases receive security fixes, and is PostgreSQL 17 supported? | Latest prerelease only until 0.2.0, then the latest minor release. PostgreSQL 18.x only, matching CI. | SECURITY.md and release-state consistency pass |
| 5 | How are registry names reserved, and what versioning and runtime floors apply to the SDKs? | Apply for the ProudAuth.* ID prefix on NuGet now; submit proudauth-sdk-php to Packagist under the proudauth vendor now; accept the pub.dev squat risk until the beta.2 release. Independent SemVer per SDK: Go v0.2.0 now, v0.3.0-alpha.1 in alpha.7 for the typed interaction client, Go and Node 0.3.0 from CI at beta.1, Dart/PHP/.NET 0.3.0-alpha.1 in beta.2. Floors: Go 1.25 (tested on 1.26 and 1.27), Node 22, .NET net8.0 + net10.0 until net8 is dropped. | Go SDK tag; SDK release workflows |
| 6 | Where do the 2026-10-13 migration artifacts at the workspace root go? | Archive under _archive/2026-10-13-migration/ in the workspace with historical headers; delete .migration-legacy-go after confirming it matches proudauth-sdk-go history. | Workspace archive task |
| 7 | Does the Docker Hub mirror carry the GHCR signatures and attestations, or is it retired? | Retire unless a consumer is known; installation.md states that GHCR is the only published registry. | Release dry run and its exit gate |
| 8 | Is a GitHub security advisory warranted for the published @proudauth/sdk 0.2.0, which keeps a compromised retiring key trusted until the process restarts? | Yes. A repository security advisory on proudauth-sdk-node (no CVE requested) that states the restart workaround now and names 0.3.0 as the fixed version once it ships, alongside the Known-limitations notes in both SDKs. | SDK Known-limitations and advisory task |
No tag is created without the owner's explicit instruction.