Providers no longer return a `Response`. Each one says what it needs from
the person — an address, a pin, a yes-or-no — as a `Screen`, and a single
`Renderer` decides how that is drawn.
The old arrangement made every provider a small web framework. It had to
know about markup, about the stylesheet's attribute names, about how a page
is assembled, so each grew its own callback signature and its own copy of
`new Response(jsx.toString())`. Three consequences, all of them visible in
the tree before this change:
- The device flow never got a design at all. Its two pages were built by
concatenating HTML strings, with an inline `style` on the user code, and
six of its replies were `text/plain` — unstyled black-on-white in the
middle of signing in, which is also what a person got when their sign-in
cookie expired.
- The password screens were drifting. They were written against attribute
names the stylesheet no longer had, and nobody noticed because password
sign-in is not switched on. They are deleted here rather than repaired;
the flow is now six screen descriptions and no markup.
- A provider could not be named or marked without editing the library. The
brand marks and display names were two hardcoded records inside the code
that drew the chooser, so anything missing from them rendered as its own
lowercase identifier with no icon. Providers now declare `display`
themselves, and the chooser is built from what they say.
Also removes the theme global. It was `globalThis`, with a comment
conceding as much, which made every component depend on something invisible
at the call site — untestable in isolation, and shared mutable state on a
runtime that keeps one module instance across requests. The theme is now a
closure argument, and the same change shrinks `Theme` to the handful of
values a deployment sets that the stylesheet cannot.
Adding a screen now touches no CSS, and swapping the presentation layer
means implementing one method. The code flow's tests demonstrate the
second: they render screens as JSON.
Behaviour is unchanged. Status codes, cookies and the confirmation step are
the same, which the device tests cover unmodified.
A program with no browser — the desktop app — had a client for RFC 8628 and
nothing to point it at. This serves the other half: a device authorization
request that hands back a code, a page a person enters that code on, and a
token endpoint that answers the poll.
Both of the paths the client already implements are now reachable. Polling
faster than the advertised interval gets slow_down, and each warning widens
the interval so ignoring one costs more than the last; refusing gets
access_denied, so a request nobody started stops instead of being polled until
it ages out. The interval is capped, because it only ever grows and a code has
to stay pollable for the whole of its life.
The codes live in the same storage as the other short-lived grants rather than
in a table, since that is what they are. User codes are drawn from an alphabet
with no vowels and no look-alike pairs, and are accepted back in whatever case
and spacing a person retyped them in.
