# Attestations — spoke context

The user wants to see what identity attributes Whoois holds about them — verified email, address, age, KYC status, etc.

If you haven't already, fetch `https://poc.whoois.app/whoois-context.md` for the root primer.

---

## What's an attestation?

A verifiable claim about the user, issued by a trusted provider. Examples:

- **"Email verified"** — Whoois sent a verification email and the user clicked the link
- **"Over 18"** — provided by a KYC partner; the user proved their age
- **"Address verified (US)"** — the user's mailing address has been confirmed by a real-estate or USPS-tier partner
- **"KYC complete (basic)"** — passed a basic Know-Your-Customer flow
- **"KYC complete (enhanced)"** — passed an enhanced KYC flow (typically required for higher-value transactions)

The user gathers attestations over time (often passively — verification flows are inline during onboarding or first-time merchant interaction). Once collected, attestations are reusable across merchants — the user releases the relevant attestations during a grant (see `https://poc.whoois.app/context/grants.md`).

---

## Trigger phrases

- "What does Whoois know about me?"
- "Show my attestations"
- "What's verified on my Mi?"
- "Show my identity proofs"
- "Am I KYC-verified?"
- "Show what I've proven to Whoois"

---

## Tool to call

**`itsmi_attestations_view`** — LLM-visible. Renders the attestations iframe. Shows each attestation as a card:

- Label (e.g., "Over 18")
- Provider (who issued — KYC partner, internal verification, etc.)
- Issued timestamp
- Expiry (some attestations have validity windows)
- Verification level (basic / enhanced)
- "Re-verify" button (for attestations approaching expiry)

The iframe also shows attestations the user could acquire but hasn't yet — e.g., "Get KYC enhanced (required for crypto withdrawal)."

---

## Mi-has-limits (architectural context)

Per Decision #49 (Mi-has-limits): the Mi holds personal-identity attestations, not domain-specific persona data. Things that belong on the Mi:

- Identity proofs (KYC, address, age)
- Verified contact info (email, phone)
- Trust score (Miclock)
- Cross-cutting credentials (driver's license, passport — when supported)

Things that do NOT belong on the Mi (they live in Miapp boundaries instead):

- Shopping preferences (mishopping.app holds these)
- Medical history (mitbp.app would hold these)
- Sports fandom (a sports Miapp would hold this)

If the user asks "does Whoois know what I shop for?" — the answer is no: shopping data lives in the mishopping Miapp boundary, not in their core Mi. This is intentional privacy design.

---

## Cross-references

- See `https://poc.whoois.app/context/grants.md` for the recipient-side view (which merchants have received the user's attestations)
- See `https://poc.whoois.app/context/kyc.md` for the KYC submission flow (preview-only in POC)
- See `https://poc.whoois.app/context/credentials.md` for credential storage (preview-only in POC)

---

## Tone notes

Attestations are personal — the user is checking what's verified about them. Be respectful, factual, no editorializing. If the user has few attestations (new Mi), don't shame them — just note what's there and offer "want to add more?"

---

*This spoke is fetched from `https://poc.whoois.app/context/attestations.md`. Pair with `https://poc.whoois.app/whoois-context.md` for the root primer.*
