From 2e2eb7630115f8a24658c02abfb3c040c25ae678 Mon Sep 17 00:00:00 2001 From: John Coffey Date: Fri, 18 Sep 2026 12:31:18 -0700 Subject: [PATCH] Contract: C-7 matches C-5 (third-party OAuth apps are admin-registered unless open registration is chosen) --- docs/spec/contract.md | 12 ++++++++---- 1 file changed, 8 insertions(+), 4 deletions(-) diff --git a/docs/spec/contract.md b/docs/spec/contract.md index edeb8c7..bb926cd 100644 --- a/docs/spec/contract.md +++ b/docs/spec/contract.md @@ -98,10 +98,14 @@ Each has an ID, and tests name the IDs they check. INBUXA Admin's `` is set to `inbuxa-admin`. Until then it keeps upstream's `stalwart-webui`, which only works while registration isn't required. -- **C-7.** Third-party mail clients (Thunderbird, mobile apps) keep working - through dynamic registration (`/auth/register`), whose stateless client ids - carry their own redirect URIs. That's upstream's mechanism and is left as it - is. +- **C-7.** Third-party apps that want OAuth (Thunderbird, mobile apps) get a + client in one of two ways: an administrator registers it (`x:OAuthClient`, + in INBUXA Admin), or the operator turns anonymous dynamic registration back + on (`/auth/register`, whose stateless client ids carry their own redirect + URIs), accepting that anyone can then register. Either way, C-9's consent + page names the app and its redirect host. Mail apps that sign in with a + password or app password are unaffected, and that's everything INBUXA's + users were observed doing (see "Security note"). - **C-8.** People sign in on **the server's own sign-in page** (`/login`, already INBUXA-branded), never on a front end's form. Two-factor happens there, on the page's existing one-time-code step. Front ends never see a