oficina / suite Public

Constrain external launch to provider privacy and mailbox proof

Paul Campbell pushed by paul@keymail.dev 1 month ago e75206a9a7fe34e1792eaa548ea45eda72027513 parent 7c23220

1 file changed, +20 −12

implementation/external-home-launch.json +20 −12

CI log

=== gate ===
ok  	amadan.net/oficina/suite	0.007s
ok  	amadan.net/oficina/suite/conformance	0.004s

diff --git a/implementation/external-home-launch.json b/implementation/external-home-launch.json

index ad245b2..2bd3d22 100644

--- a/implementation/external-home-launch.json

+++ b/implementation/external-home-launch.json

@@ -4,7 +4,7 @@

"state": "proposed",

"author": "this session, Codex suite coordinator subagent",

"date": "2026-09-10",

- "reviewer": null,

+ "reviewer": "claude-fable-5-1; R1 REQUEST CHANGES; revised boundary awaiting R2",

"runtime_activation": false

"citations": [

@@ -13,7 +13,7 @@

"commit": "1ac4323a7317a2bf4def3829896d9895a6ddc464",

"path": "docs/superpowers/specs/2026-09-05-suite-sharing-doctrine.md",

"sections": [

- "ruling 10",

+ "rulings 5, 8, 10 and 13",

"mail and files wrapper trigger"

]

@@ -41,7 +41,7 @@

}

"decision": {

- "proposed_boundary": "Oficina Home can identify the person requesting a launch. The provider must independently prove the existing local account/device and retain its current client unlock ceremony. The provider remains the data and decryption authority.",

+ "proposed_boundary": "Oficina Home can identify the person requesting a launch. The provider must independently prove the existing local account/device and retain its current client unlock ceremony. The provider remains the data and decryption authority. Providers remain lone-shape with an explicit person link; this proposal is not the roster/S1-S3 suite-shape wrapper described by ruling 5. It consumes person-proof boundary ruling 8.",

"shipping_order": [

"Complete native Oficina SSO rollout first.",

"Expose explicit launch navigation to existing provider front doors, with existing sign-in/unlock requirements visible.",

@@ -55,18 +55,21 @@

"email-based account matching",

"copying provider bearer credentials into Home",

"claiming an unopened vault is ready",

- "reusing generic connect session hooks without a provider-specific proof adapter"

+ "reusing generic connect session hooks without a provider-specific proof adapter",

+ "storing any server-side mapping from Keymail anonymous identity user handle or passkey credential to a mailbox",

+ "treating long-lived Keymail identity link tokens as fresh or revocable mailbox-device proof"

]

"provider_seams": {

"mail": {

- "local_authority": "Existing verified Keymail owner/device proof, not OAuth app grants. Existing consent scopes identify/send/newsletter do not authorize inbox reading.",

+ "local_authority": "Existing verified mailbox-scoped owner/device proof. Never an anonymous identity user handle, identity-service passkey credential, identity link token or OAuth app grant. Exact immutable mailbox incarnation and revocation API must be established from provider registry/device code before implementation.",

"unlock": "Existing same-origin WebAuthn PRF or established local device key state opens the mailbox vault client-side.",

"integration_owner": "keymail/keymail",

- "new_entry": "Proposed provider-owned /oficina/launch and /oficina/connect endpoints; route names require provider review before implementation."

+ "new_entry": "Proposed provider-owned /oficina/launch and /oficina/connect endpoints; route names require provider review before implementation.",

+ "pending_state": "Relay-held, mailbox-keyed, sealed short-lived pending state, reached using existing mailbox-scoped authenticated routing before redirect. The Home auto-POST has no provider bearer; it addresses a random single-use browser-bound rendezvous. No identity-service user/passkey identifier enters pending state or the mailbox relation. Exact proxy/header stripping and routing evidence is an implementation prerequisite."

"files": {

- "local_authority": "Existing Slopbox Home credential/device proof chooses the encrypted directory; existing instance membership proof authorizes files. These are distinct authorities.",

+ "local_authority": "Existing Slopbox Home credential/device proof chooses the encrypted directory; existing instance membership proof authorizes files. These are distinct authorities. Proposed relation binds Slopbox Home users.id (AUTOINCREMENT), never an instance member ID in the Home relation. Fresh proof requires a new local passkey sign-in within the specified window; existing session created_at alone is not proof of a recent ceremony.",

"unlock": "Existing browser passkey PRF opens the encrypted Home directory and instance file keys; the browser chooses the already-authorized instance.",

"integration_owner": "slopboxcloud/slopbox",

"new_entry": "Proposed provider-owned /oficina/launch and /oficina/connect endpoints at Slopbox Home; instance APIs remain unchanged."

@@ -81,7 +84,7 @@

{

"step": 2,

"actor": "provider",

- "action": "Require a fresh existing local owner/device proof using the provider ceremony. Bind the pending link to the exact local principal ID, current credential/device identifier and a rotating session/device proof. An OAuth identify grant cannot substitute."

+ "action": "Require a fresh existing provider proof. Keymail uses mailbox-scoped owner/device proof and a non-reusable mailbox incarnation, never identity-service user or passkey IDs. Slopbox Home uses its existing users.id and a fresh passkey sign-in; no instance membership is inferred. Bind pending state to this exact principal and rotating/revocable proof. The provider must first expose or establish the reviewed freshness/revocation API."

{

"step": 3,

@@ -96,7 +99,7 @@

{

"step": 5,

"actor": "person",

- "action": "Explicitly confirm the connection after both independent proofs. Show provider account context only inside its already-unlocked client UI; never send inbox names, file paths or vault plaintext to Home."

+ "action": "Explicitly confirm after both proofs. Show mailbox/file account context only inside its already-unlocked client UI. The launch path discloses no new inbox names, file paths or vault plaintext to Oficina Home; it does not claim Home lacks an email already supplied during independent Keymail OAuth sign-in."

{

"step": 6,

@@ -114,7 +117,7 @@

"storage_and_revocation": {

"home": "No provider bearer token, device secret, private key, vault plaintext, inbox name or file path.",

- "provider": "Provider-specific reviewed relation schema; HMAC or sealed opaque Home subject binding under a dedicated provider key, bound to issuer/consumer/local immutable principal/revocation generation. Exact schema and key lifecycle are implementation-review prerequisites.",

+ "provider": "Provider-specific relation schema, requiring separate owner privacy approval. Keymail: HMAC/sealed Home binding may map only to a mailbox-scoped non-reusable incarnation and revocation generation; no identity-user/passkey-to-mailbox join anywhere. Slopbox Home: a stable keyed Home-subject binding on users.id is a new opaque correlation column, not part of its current anonymous schema. This privacy addition requires explicit provider approval before implementation, plus raw-DB grep and correlation tests. If refused, retain launch-only navigation with local unlock and no durable relation. Dedicated key lifecycle and exact schema remain prerequisites.",

"deletion": "Remove relation in the same transaction as local principal deletion; never reuse principal IDs. Revoked provider devices cannot satisfy pending or future local proof.",

"unlink": "Own confirm screen behind fresh provider proof. Delete relation and pending flows atomically, preserving mailbox/files and existing independent credentials.",

"logout": "Provider sign-out retains its existing vault-lock/device semantics and must not instantly restart Home sign-in. Home sign-out grants no authority to erase provider keys or data.",

@@ -128,12 +131,17 @@

"CSP tests compare provider baseline and permit only the fixed validated Home issuer when needed; unrelated destinations and form chains remain blocked.",

"Existing raw-database/blob ciphertext invariants and recovery/device-link suites remain green.",

"No tests send human mail, authorize real OAuth accounts, expose keys or mutate customer files.",

- "Deploy isolated provider canaries after independent whole-delta review, then verify live versions and local unlock behavior; no shared production instance overwrite."

+ "Deploy isolated provider canaries after independent whole-delta review, then verify live versions and local unlock behavior; no shared production instance overwrite.",

+ "Keymail tests prove no persistent or pending-state relation contains both an anonymous identity-service user/passkey identifier and a mailbox identifier. Freeze and review registry, device-token, reauth and relay header-stripping code before choosing the principal.",

+ "Slopbox Home relation participates in existing raw-DB/ciphertext privacy tests (including home_test.go); tests cover absence of raw Home subject, address, file path and instance location. Document the deliberate opaque per-user correlation change and require provider approval.",

+ "Slopbox fresh-proof API must require a new verified sign-in; replaying an old session created_at cannot satisfy the window. Keymail identity link tokens cannot satisfy freshness or revocation."

"unresolved_before_implementation": [

"Exact provider owner/device freshness APIs and whether they rotate/revoke proof on account switch.",

"Private relation schema, account deletion hooks, and provider key rotation/recovery mechanics.",

"Which provider origins and customer mappings Home may list without disclosing information the current provider Home deliberately keeps encrypted.",

- "Whether an already unlocked browser can complete the intended launch without an extra passkey gesture; no guarantee until browser/device proof is tested."

+ "Whether an already unlocked browser can complete the intended launch without an extra passkey gesture; no guarantee until browser/device proof is tested.",

+ "Keymail non-reusable mailbox-scoped principal/registry lifecycle and device-proof freshness/revocation: review exact registry.go, relay.go, handlers.go, reauth.go and tests before any schema/API implementation.",

+ "Provider decision on adding a keyed Oficina relation to Slopbox Home anonymous storage; absence of approval means launch-only navigation remains the limit."

]

}