Sign in through a server that delegates to an identity provider

[iderex]

Some servers hand sign-in to an external identity provider. From the core's side
this is a third acquisition route with its own shape: the core is told to send a
person somewhere, and the answer comes back afterwards.

The core does not embed a browser and does not draw anything, so the part where a
person interacts with the provider belongs to the client. What the core owns is
knowing that this is the route, producing what the client needs to start it, and
turning the result back into an ordinary session.

What this produces

Detecting that a server delegates, so a client can offer the right thing rather
than a password box that will never work.

Producing what the client needs to hand to the platform's own browser, and
consuming what comes back.

The security properties stated and tested: the value that ties a started attempt
to its answer is generated by the core, is unpredictable, and an answer that does
not match a started attempt is refused rather than accepted.

A refusal from the provider surfaced as a distinct named error, since it means
something different from a rejected password.

Done when

The three properties above have a test each against the fake server, including
one that feeds back a mismatched answer and proves it is refused. The route ends
in the same session type as the other two. Blocked on #5, #4, #21.

[iderex]

The route landed as docs/decisions/0032-a-server-that-delegates-sign-in.md, on ba11f25.

It answers the four things this issue asks for, and one of them by writing the record for both of #10's possible answers rather than waiting for one.

Detecting that a server delegates comes from the configured server itself and never from a failure. Where the server states its routes, a client offers what will work; where it states nothing, the route is capability-absent from 0004 carrying the name from #10's set, rather than being offered and failing at the moment somebody presses it. Where #10 answers that capability is probed per call, the probe is this call and nothing else in the record moves. Reading a rejected password as evidence that a different route was wanted is refused by name, because it sends a person with a typing mistake to a provider they have no account with.

What the client gets is one address, and it is the configured server's own. 0069 already states that the identity provider is a second host outside the destination set because the core never contacts it, and this record is where that is spent rather than restated: every request on this route goes to the origin 0028 resolved. Where the route needs a return address, the client supplies it at the time of the call, because only the client knows what its platform can receive, and it is part of what the attempt is tied to.

The three security properties are stated with their reasons. The value tying an attempt to its answer is generated in the core from the runtime's unpredictable bytes, never from a clock, a counter, or anything derived from the session, at least 128 bits, compared over its whole length. An answer is matched against a started attempt before it is used and not after, which reads the same written either way and is only safe in one of them: a core that exchanged first has already sent an attacker's value to the operator's server. An attempt is accepted at most once, so a second answer naming the same value finds nothing started.

An attempt is the caller's call and ends when it is answered, cancelled, or the core stops under 0115. There is no expiry number here, which is 0005's treatment of the wait in #31 arriving unchanged: a person authenticating somewhere else is doing something the core cannot see and has no business timing.

An answer matching no attempt is not-authenticated with nothing presented, which is what a refused password also reaches under 0030, and the sameness is deliberate. A client that lost its own attempt and an answer somebody injected produce the same failure, and separating them in the answer would be telling the second one which it was. The vocabulary does not grow a kind for it, on 0069's own argument for the same shape. What does get a distinct kind, which is what this issue asks for, is a refusal from the provider: request-refused, carrying the provider's identifier as the opaque string 0004 already fixes for that payload and never the sentence the provider wrote.

Both conditions here are untouched. A test per property, including one that feeds back a mismatched answer, is a statement about running code, and the route ending in the same session type as the other two is 0005's rule rather than something a run here asserts. There is no language chosen, no build and no test command in this tree, and the fake server those tests run against is #21.

One requirement in the record reaches past this tree deliberately. Where the means chosen in #11 offers no source of unpredictable bytes, the record makes that a fourth seam a client supplies on the shape 0033 and 0040 already use, rather than a weaker value drawn from what is to hand. That is a decision about a language nobody has chosen, written now so it is not settled by whichever call site needs bytes first.

[iderex]

The reason recorded here for why nothing refuses 0032 no longer reproduces, and one clause of the record's security property is refused today

The comment above ends by saying there is no language chosen, no build and no test
command in this tree, and it treats 0032's requirement about unpredictable bytes
as a decision about a language nobody has chosen. Both of those have moved. Read
at 598cf87361c79d32fa3716cbcbc7b354b6ae2aed, which is one merge behind
origin/main at 4ab60e1fcd309992319d17c8ddd91d04a089ee1d.

The language, the build and the suite are here:

git ls-tree --name-only origin/main | grep -E 'Cargo.toml|rust-toolchain.toml'
Cargo.toml
rust-toolchain.toml

cargo test --locked 2>&1 | grep -c '^test result: ok\.'
6

The record's conditional about the seam has resolved, and it resolved to the
seam rather than around it. 0032 writes the requirement with a fallback:

git show origin/main:docs/decisions/0032-a-server-that-delegates-sign-in.md | sed -n '74,78p'
It is drawn from the runtime's source of unpredictable bytes, and never from a
clock, a counter, an identifier the core already holds, or anything derived from
the session being established. It is at least 128 bits. Where the means chosen in
#11 offers no such source, it is a fourth seam the client supplies, on the shape
0033 and 0040 already use, rather than a weaker value drawn from what is to hand.

and the answer #11 recorded is that there is no such source:

git show origin/main:docs/decisions/0011-the-language-the-toolchain-and-the-binding-layer.md | sed -n '296,299p'
**0032 and 0036, a source of unpredictable bytes of at least 128 bits.** Measured
above: the standard library's source is unstable on the stable compiler. **Not met
on the toolchain as chosen**, so the seam 0032 already named is what is used, the
client supplies the bytes, and 0036 pays for it a second time on the device

So the fallback is the ordinary case here rather than the exception, and this
record is where that seam is defined. The reversal condition this record wrote
against the same question is not met, because it needs both halves and only one
of them happened:

git show origin/main:docs/decisions/0032-a-server-that-delegates-sign-in.md | sed -n '246,249p'
The means chosen in #11 turns out to have no source of unpredictable bytes and no
client on any platform can supply one. The seam named above is then a seam nobody
can fill, and the honest replacement says the route cannot offer the property
rather than offering a value that does not have it.

Nothing says a client cannot supply the bytes, so the record stands and what it
owes is the seam itself.

One clause of the security property is refused today, by a rule written for
another record. .github/invariants/rules holds rules as data over tracked
lines, each naming the landed record it comes from, and one of them takes the
clock out of src/ entirely:

git show origin/main:.github/invariants/rules | awk '/^id: no-platform-clock/,/^$/' | sed -n '1,4p'
id: no-platform-clock
pattern: (^|[^A-Za-z_])(SystemTime::now|Instant::now)
paths: src/
grounds: docs/decisions/0102-the-clocks-every-deadline-is-measured-against.md

So never from a clock has a machine behind it here, for 0102's reason rather
than for this record's, and a value drawn that way reddens the invariants check
before any of this issue's tests exist. That is one clause of one of the three
properties.

The rest of the property has no shape that register can hold, and this comment
does not claim it does. At least 128 bits, drawn from a source rather than from
an identifier the core already holds, matched against a started attempt before it
is used rather than after, and accepted at most once are statements about what a
value is and when it is compared. A line pattern over tracked files cannot ask any
of them. 0032 is grounds for no rule in that register today:

git show origin/main:.github/invariants/rules | grep -c 'docs/decisions/0032'
0

No condition and no scope on this issue changes.

CORRECTED BY RE-RUNNING IT. The first command above read sed -n '73,77p', and
line 73 of that record is blank, so the range as first written returns a blank
line and the first four of the five underneath it. The five lines are what the
record holds; the range is what was wrong. It was found by running the commands
again after posting rather than by anything reporting it, and nothing in this
repository reads a paste in an issue.