# Indbakke

Et begrundet forslag ind. Et bekræftet svar tilbage. Indbakken samler henvendelser til én person på tværs af systemer. Arbejdspladsen viser i dag organisationens egne henvendelser med sagens kontekst; den selvstændige native app kommer senere.

## Bliv afsender

I I1 optager operatøren dit systems id, titel, offentlige Ed25519-nøgle, nøgle-id og godkendte HTTPS-origin. Organisationens titel følger henvendelsen. Der er ingen offentlig selvregistrering eller domæneopdagelse endnu.

Læs [protokollen](protocol.md), vælg en konkret beslutnings svarform i JSON Schema 2020-12 og send det almindelige OKF-dokument som `text/markdown` til `POST /v1/requests?organization=<id>`. Dokumentet har `type: request`, `title`, `description`, Markdown-prosa og felter i `okf.graph.fields`. Samme `requestId` og samme parsede indhold kan sendes igen; andet indhold under idet får `idempotency_conflict`.

Signér hvert kald med RFC 9421 og Ed25519. Profilen dækker `@method`, `@target-uri` (inklusive query) og `content-digest` (RFC 9530), i den rækkefølge. Parametrene er `created`, `keyid` og `alg="ed25519"`. Brug RFC 8941 Structured Fields til signaturfelterne. Fem minutters urforskel accepteres. Genlevering signeres på ny.

`replyTo` (valgfri) er en HTTPS-adresse på din godkendte origin. Modtag `POST application/json`, efterprøv RFC 9421-signaturen mod indbakkens på forhånd bundne origin og [dens JWKS](/.well-known/inbox-keys.json), og kvittér med 2xx efter holdbar modtagelse. Leveringen er mindst én gang og idempotent på `answerId`. Efter nedetid henter du svar med `GET /v1/requests?organization=<id>&answeredAfter=<after>`. GET-svaret er signeret over `@status`, `content-digest`, `"@method";req` og `"@target-uri";req`; fortsæt med svarets `after`.

`correlationId` er dit uigennemsigtige tråd-id. Det kommer uændret tilbage og giver ingen adgang. `viewHints` er ordnede forslag til en konkret visning; modtageren vælger den første, som forstås og er betroet, ellers teksten. Parametre er beslutningens data, aldrig et formularsprog. Et fast bekræftelseslag gentager svar og ordrette blokke.

Fristen `respondBy` er krævet og kan flyttes med `POST /v1/requests/{requestId}/respond-by`, mens henvendelsen er åben. Uden `replyTo` hentes svar i `GET /v1/requests?answeredAfter=`. `workplaceUrl` er et valgfrit HTTPS-link, som bruges i notifikationen; uden det linker mailen til indbakken.

Indbakken afslutter med `outcome: none`, `actingVia: inbox` og årsagen `expired`, `withdrawn`, `rejected` eller `unreachable`. Det er ingen personverifikation og har derfor intet `assurance`. Tilstanden er `unanswered`, når alle er afsluttet uden svar; et `cannot` giver `declined`. Signerede GET-svar dækker `@status`, `content-digest`, `"@method";req` og `"@target-uri";req` efter RFC 9421 §2.4.


## Verifikation

Udelad `assurance`, eller brug `{level: session}` for en verificeret session. `{level: recent, maxAge: 300}` kræver verifikation højst 300 sekunder før svaret. Begge kortlægges til OpenID `acr: "0"`; nylighed udtrykkes med `auth_time` og OpenID `max_age`, ikke som en påstået MFA-klasse. Personens svar har altid `assurance: {level, acr, verifiedAt}`. `per-answer` med WebAuthn kommer i I2 og afvises nu med `assurance_unsupported`. Der sendes aldrig et svagere `answered`; personen kan svare `cannot` med begrundelse under sin verificerede session.

Klienten bruger et OAuth-adgangstoken til indbakkens origin som `resource` og scopet `inbox`. IdP skal signere `email`, `email_verified: true` og det faktiske `auth_time` i adgangstokenet. Et nyt token eller tokenets `iat` tæller ikke som ny verifikation. En session accepteres i højst 12 timer fra verifikation; adgangstokenet udløber tidligere. Ved `verification_required` gennemføres nyt login med henvendelsens `max_age`, og samme submission kan prøves igen. Klienten beder også om ny verifikation ved genåbning efter inaktivitet. Arbejdspladsen signerer sin organisation oven i personens token; databasen afgrænser til netop den organisation. Der er ingen login-sider eller indbakkebrugerflade her.

## Agentflader

[OpenAPI](/openapi.json) og [værktøjsreferencen](tools.md) genereres fra samme operationer som MCP-serveren på `/mcp`. MCP bruger Streamable HTTP. Offentlig læsning kræver ingen identitet. Beskyttede operationer har præcis samme identitet og databaseadgang som HTTP-API'et: afsendere signerer det ydre `/mcp?organization=<id>`-kald og dets JSON-RPC-bytes, og klienter vedlægger personens bearer-token. Værktøjets organization skal svare til den signerede query; det kan aldrig udvide adgangen. Resultatet er et værktøjsresultat over den samme operation, ikke en ny vej til at spørge mennesker.

Forsiden tilbyder kun de offentlige værktøjer gennem `document.modelContext.registerTool`, når browseren understøtter WebMCP. Ingen polyfill eller loginværktøjer. Nøglehentning, protokol og denne vejledning kan altid læses over almindelig HTTP.