# Oversight Inspector for Outlook

Read-mode Outlook task pane that verifies and decrypts `.sealed` attachments
using the same parse/verify/decrypt pipeline as the public web inspector at
<https://oversightprotocol.dev/viewer/>. No second crypto stack, no second
container parser, no telemetry.

Status: **hosted pilot scaffold**. The manifest, task pane HTML, JS, icons,
and pilot landing page are live under
<https://oversightprotocol.dev/integrations/outlook/>. The remaining gate is
an Outlook tenant load-test against classic and hybrid sealed attachments. The
architecture decisions are recorded in [`docs/OUTLOOK.md`](../../docs/OUTLOOK.md).

## Files

| File | Purpose |
|---|---|
| `index.html` | Hosted pilot page with sideload links, scope, and next checks |
| `manifest.xml` | Office add-in 1.1 manifest, `MailApp` type, read-mode task pane |
| `taskpane.html` | UI shell: status badge, attachment picker, manifest summary, decrypt panel |
| `taskpane.js` | Office.js + viewer-module integration; reuses `parseSealed`, `verifyManifestSignature`, `decryptSealed` |
| `assets/` | Icons referenced by `manifest.xml` (64 px, 128 px). Placeholders pending design. |

## Hosting

The task pane and its imports are served over HTTPS from the URL declared in
`manifest.xml` (`SourceLocation`). Production target is
`https://oversightprotocol.dev/integrations/outlook/`, which lives under
`gh-pages` next to `viewer/`.

To deploy: copy this directory's contents into the public site tree at
`integrations/outlook/` and push `gh-pages` (the standard site deploy step).
Same-origin imports of `/viewer/viewer.js` and the vendored noble bundles work
automatically once both paths are on the same host.

## Sideload (developer)

1. For the hosted pilot, use
   `https://oversightprotocol.dev/integrations/outlook/manifest.xml` directly.
2. For local development, build a local manifest with `SourceLocation` pointing at your dev URL
   (e.g., `https://localhost:3000/integrations/outlook/taskpane.html` if you
   are serving locally). Outlook requires HTTPS even for localhost; use
   `office-addin-dev-certs` or your own self-signed pair.
3. **Outlook on the web**: open any message > the More (`...`) menu >
   `Get Add-ins` > `My add-ins` > `Add a custom add-in` > `Add from file...`
   and pick your local `manifest.xml`.
4. **Outlook desktop**: Home tab > `Get Add-ins` > same path.
5. Open a message that has a `.sealed` or `.oversight` attachment. The task
   pane will offer to load and verify it.

## Tenant install

For a pilot deployment a Microsoft 365 admin uploads `manifest.xml` in the
admin centre under `Integrated apps > Upload custom apps > Office Add-in >
Provide link to the manifest file` (or by uploading the XML directly). The
admin assigns the add-in to a user group and Outlook surfaces it on the
ribbon for those users.

## Permissions

`ReadItem` is the only requested scope. The add-in does not modify the
message, send anything from the user's mailbox, or access any folders other
than the open message. Decryption keys come from the user's pasted
`identity.json` and stay in task-pane memory for the lifetime of that
message view.

## What's missing for a real pilot

- [x] Hosted pilot page and manifest URL under `oversightprotocol.dev`.
- [ ] Replace placeholder icons in `assets/` before AppSource review.
- [ ] A short demo video or screenshots for the AppSource listing once we
      decide AppSource is in scope.
- [ ] End-to-end test inside an Outlook dev tenant against a hybrid `.sealed`
      attachment.
- [ ] Decision: do we accept the `.oversight` extension Codex is shipping on
      the mobile side as a synonym for `.sealed`? The activation rule already
      covers any attachment, so this only affects the task pane's filename
      filter.
- [ ] Localization beyond `en-US` once a customer asks.

Sealing-from-Outlook (compose mode) is intentionally out of scope for v1; see
`docs/OUTLOOK.md` for the rationale.