amadan
Require explicit future-time refusal in fresh authentication
1 file changed,
+1
−1
implementation/fresh-assertion.md+1 −1
CI passed — run details
diff --git a/implementation/fresh-assertion.md b/implementation/fresh-assertion.md| index 73ee4df..a6d398b 100644 |
| --- a/implementation/fresh-assertion.md |
| +++ b/implementation/fresh-assertion.md |
| @@ -8,7 +8,7 @@ Include MaxAge (0 or 300) and optional original Subject in the sealed ten-minute |
| For this bounded step-up, a valid fresh-intent cookie causes handleSigninBegin to select signin.MethodMagicLink. This uses the existing email confirmation and optional passkey/recovery factor. It avoids accepting a standing upstream Keymail inbox session as a new gesture. The decision must be server-side: the existing form action does not retain query flags, so a force=1 query alone is insufficient. Invalid/expired/duplicate intent cannot request or satisfy freshness. No new copy or inline scripts are needed. This extra mail ceremony applies only when the user reaches sign-in during an explicit fresh flow; ordinary SSO and ordinary Keymail sign-in are unchanged. |
| -Do not advance AuthTime while issuing an assertion. A freshly minted session whose original AuthTime is old remains stale. Time checks use sessions.Fresh, including its future-time handling. On successful reauthentication, the new assertion carries the actual verified identity's AuthTime, falling back to the session At only when AuthTime is absent, as in the approved existing implementation. |
| +Do not advance AuthTime while issuing an assertion. A freshly minted session whose original AuthTime is old remains stale. Time checks use sessions.Fresh plus an explicit verified-time <= now check. Source inspection of Rastrillo0.23 sessions.Fresh found that it only checks now.Sub(verified) <= maxAge, so it accepts future times by itself. The issuer must not credit them. On successful reauthentication, the new assertion carries the actual verified identity's AuthTime, falling back to the session At only when AuthTime is absent, as in the approved existing implementation. |
| No consumer authorization is inferred from max_age. It is a request to the issuer, not a proof for the receiver. A sensitive consumer must independently reject an assertion or session whose actual AuthTime exceeds its five-minute window; an attacker removing max_age must not make account linking or roster writes accept stale authentication. Shared consumer query forwarding and its consumer-side freshness enforcement will be a separate implementation stage, followed by Docs account linking. Do not claim this issuer-only stage enables those actions. |