# Device & FHIR-endpoint identity

**Give a medical device or a FHIR endpoint a routable IPv6 `/128` derived from the public key it already holds, named by its `Endpoint.identifier` or its FDA UDI. The address _is_ the endpoint: forge-proof, tenant-private, DNSSEC-anchored, DANE-EE pinned, and revocable worldwide in one call.**

This is the spine of the health vertical, and it is **shipped and live**. Everything else (the device/API-abuse cure, the FHIR·UDAP·TEFCA·UDI integration guides, the FDA §524B and HIPAA evidence) builds on the one idea below: an endpoint's network address stops being a label a directory publishes on faith and a proxy can rotate, and becomes a cryptographic fact only that endpoint's key can stand behind. It **complements** UDAP, SMART, and TEFCA; it never replaces them.

> **Shipped & live.** Deriving a device or endpoint `/128` from the public key it already holds (with the `Endpoint.identifier` or the UDI as the domain separator) is in production today. Provision one with the control-plane call below and verify it from the DNSSEC root with tools already on your machine. A first-class typed `--endpoint` / `--udi` flag is **on the roadmap**; the generic `device_id` path is live now.

> **Two tiers, per Postel's Law.** With **no API key** anyone (a QHIN allow-listing a peer, an auditor, a suspicious relying party) can _verify_ an endpoint's identity from stock tools (`dig`, `curl`, RDAP), because the identity half is public by design. With **your key** you _provision_ and _govern_: mint the `/128`, DANE-pin the endpoint cert, source-bind egress, pull the logs, see who checked it, and revoke it. Verification never needs an account; the control plane does.

## The address is the endpoint

Every layer of the health stack already carries an _identifier_, and most now carry a _key_. What none of them carry is a binding of **identifier ↔ key ↔ routable address** that anyone can verify at the address itself. The binding always lives somewhere private.

- **FHIR `Endpoint`.** The resource already names itself: `Endpoint.address` (datatype `url`, `1..1`) is "the technical base address for connecting to this endpoint" (a real URL, DNS-addressable by construction), and `Endpoint.identifier` (`0..*`) is its stable business id. Its `connectionType` spans `hl7-fhir-rest`, `hl7-fhir-msg`, `dicom-wado-rs`/`qido-rs`/`stow-rs`, `direct-project`, and the IHE `xcpd`/`xca`/`xds` profiles, so one `Endpoint` can front FHIR, imaging, and document exchange at once. But the resource itself carries **no signature, no key, no cert**. Its FHIR Security Category is "Business," and trust is delegated entirely to TLS plus out-of-band UDAP.
- **UDAP.** The closest thing the ecosystem has to endpoint-trust. UDAP (HL7 SSRAA / FAST Security IG) binds the FHIR base URL to an X.509 certificate: the identifying URI _is_ the base URL, and it "SHALL match a `uniformResourceIdentifier` entry in the `SubjectAltName` of the server's certificate" and "SHALL equal the server's `{baseURL}`," with `/.well-known/udap` returning `signed_metadata`: a JWT signed by the server key, the chain in the JWS `x5c`. That is a genuinely good, key-bound name. Its limit is _scope_: UDAP trust is rooted in a **private, community-scoped trust anchor**, and you trust whichever anchor you were configured with (a TEFCA anchor, a state-HIE anchor). Cross-community trust needs federation, revocation is a **community-scoped CRL/OCSP**, and nothing anchors the base-URL↔cert binding in public DNS: there is no DANE/TLSA, no DNSSEC. A relying party outside your community, with no anchor pre-provisioned, cannot verify it at all.
- **FDA UDI & `Device.url`.** The UDI (a Device Identifier plus Production Identifier, held in GUDID) names the _physical_ device, and FHIR R5's `Device.url` ("a network address on which the device may be contacted directly") plus `Device.endpoint` model it as network-addressable. But the UDI is a barcode string (not IP/DNS-addressable, trivially copyable), and **nothing binds it to the address**: `Device.url` can point anywhere, and no key ties the UDI to the machine that answers there.

The seam is identical at every layer: a stable identifier, increasingly a key, but a binding to a routable address that is _private, out-of-band, and not self-verifying at the address_. Whisper closes it by making the **network address itself the credential**. The endpoint gets a real, routable `/128` out of `2a04:2a01::/32` (announced by **AS219419**) that is a deterministic function of the key it already holds and its `Endpoint.identifier` or UDI. Because the address is _derived from_ a key only that endpoint holds, you cannot present an endpoint identity whose key you don't have: a spoofed `Device.url`, a rogue aggregator replaying a token, or one IP claiming to be a thousand devices each becomes a DNSSEC/DANE inconsistency any verifier catches for free.

```
already at the endpoint                              public · verifiable · revocable: what Whisper adds
         │                                                                  │
┌────────────────────┐  public SPKI   ┌──────────┐  DNSSEC +    ┌─────────────────────────────┐
│ Endpoint / device  │  + Endpoint.id  │  /128    │  DANE-EE     │  A name anyone can verify   │
│ key                │  | UDI          │ 2a04:    │  3 1 1       │  whisper verify --trustless │
│ SPKI · UDAP cert / │ ───────────────▶│ 2a01:…:  │ ────────────▶│  RDAP-registered · DNSSEC   │
│ 802.1AR / TPM / SE │                 │ 71b2     │              │  to the IANA root           │
│ Endpoint.id | UDI  │                 │ routable │              │  our API is NOT in the      │
│ private key sealed │                 │ tenant-  │              │  trust path                 │
└────────────────────┘                 │ bound    │              └──────────────┬──────────────┘
                                        └──────────┘                             │
                                                        op:'revoke' ──▶ gone worldwide at DNS-TTL
```

## How the derivation works

The `/128` is not drawn from a pool and written into a database. It is _computed_, the same way on every node, from inputs the endpoint already has. Three things go in:

| Input | What it is | Where it lives |
|---|---|---|
| **Device / endpoint public key** | the `SubjectPublicKeyInfo` (SPKI) of the key the endpoint holds: the UDAP server cert's key, an [802.1AR IDevID](https://1.ieee802.org/security/802-1ar/), a TPM, or a secure-element key | the **public** half is submitted; the private key **never leaves the device** |
| **Endpoint.identifier** _(or UDI DI)_ | the FHIR `Endpoint.identifier` / UDAP base URL for an endpoint, or the FDA UDI Device Identifier for a physical device (the native, stable id) | submitted with the request; the public index (`device_id`) |
| **Component serial** _(optional)_ | a per-component domain separator, so one machine can hold several addressable identities (e.g. a modality and its DICOM AE, or a gateway and the legacy devices behind it) | optional; omit it for a single per-endpoint address |

Those inputs are combined by a one-way derivation (with a Whisper-held secret mixed in) into a stable, unguessable interface identifier scoped to your organization:

```
# inputs -> a stable, forge-proof interface identifier
derive( endpoint public key,  Endpoint.identifier | UDI [, serial],  your org )  -->  64 uniform bits

# the /64 prefix is your tenant block; the low 64 bits are the derived id
/128 = < your tenant /64 prefix > : < derived interface id >
```

Four properties fall straight out of that derivation, and each one is load-bearing:

- **Deterministic.** The same `(key, identifier[, serial])` yields a byte-identical `/128` every time, on every server: exactly one candidate, never a random retry. A reconnecting device re-derives its own address; both authoritative nodes mint the identical identity with zero replication between them.
- **Forge-proof.** The address is a function of a key only the endpoint holds. An attacker with the `Endpoint.identifier` and even the endpoint's _public_ key still cannot become that endpoint: the server-side secret and the DANE pin (below) are the parts they can never produce.
- **Tenant-bound & fleet-unlinkable.** Your organization's own `/64` is folded into the derivation. The same key + identifier under a _different_ organization produces a _different_ address, so an outsider cannot derive or enumerate a device's address in a fleet they don't control, and the identifier alone yields nothing. The classic scrape (walk the identifiers, hit the addresses) is a dead end, and a device is not linkable across organizations by address suffix.
- **Liberal in, strict out.** The identifier is accepted generously (whitespace stripped, case-folded where the id scheme allows), then validated to its scheme before anything is minted. A malformed identifier fails closed with a clear message, never a silent wrong address, never an opaque `500`.

The moment the address is derived it is published as a full identity, atomically: an `AAAA`, a forward-confirmed `PTR`, and a **DANE-EE `TLSA 3 1 1`** record that pins the endpoint's leaf key directly, all DNSSEC-signed to the IANA root and registered in [RDAP](/docs/rdap). That TLSA pin is what turns "the address is derived from a key" into "the address is _provable_ against that key by anyone." See [DANE & TLSA](/docs/dane) for the byte-for-byte record and [DNSSEC](/docs/dnssec) for the chain it hangs from.

> **The private key never moves.** The endpoint submits only its public SPKI: the same public half of the UDAP / 802.1AR / TPM / secure-element key it already holds. The server derives a public _address_ from public inputs plus a server-side secret; it never sees, holds, or derives the endpoint's private key. The device proves ownership later by presenting its own key against the DANE pin.

## Provision a device or endpoint identity

Provisioning is one control-plane call: `whisper.agents` with `op:'connect'`, `tier:'wireguard'`, the endpoint's public SPKI, and its identifier as `device_id`. It returns the deterministic `/128` and a ready WireGuard configuration so the endpoint's traffic sources _from_ its own identity. The endpoint is `POST https://graph.whisper.security/api/query`, authed with an `X-API-Key` header. No key ever travels in the body.

```
CALL whisper.agents({op:'connect', args:{
  tier:                'wireguard',
  identity_public_key: '<base64 SubjectPublicKeyInfo of the endpoint key>',
  device_id:           'https://fhir.example-hdo.org/r4'   // the Endpoint.identifier / UDAP base URL
  // device_id: '00860001234567890'   // …or a physical device's FDA UDI (DI)
  // serial: 'AE-CT01'                 // optional: a distinct /128 per component
}}) YIELD op, ok, status, result, error
   RETURN op, ok, status, result, error
```

**With stock tools**: just `curl`, no Whisper software. A quoted heredoc keeps the Cypher single-quotes intact so it pastes and runs as-is:

```
curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d @- <<'JSON' | jq .
{"query":"CALL whisper.agents({op:'connect', args:{tier:'wireguard', identity_public_key:'MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...<SPKI>...', device_id:'https://fhir.example-hdo.org/r4'}}) YIELD op, ok, status, result, error RETURN op, ok, status, result, error"}
JSON
```

The response is the standard envelope; `result` carries the derived address and the transport. Because the endpoint holds its own key, no private key is ever returned, only the public identity and the config that binds egress to it:

```
{
  "op": "connect", "ok": true, "status": 200,
  "result": {
    "tier":               "wireguard",
    "address":            "2a04:2a01:f8e7:ca11:c0de:f41d:9a3d:71b2",   // the deterministic /128
    "fqdn":               "ep-c0def41d.fhir.<tenant>.agents.whisper.online",
    "server_public_key":  "…",
    "endpoint":           "…:51820",
    "dns":                "2a04:2a01:0:53::53",
    "wireguard_config":   "[Interface]\nAddress = 2a04:2a01:f8e7:ca11:c0de:f41d:9a3d:71b2/128\n…"
  },
  "error": null
}
```

Drop the returned `wireguard_config` onto the device's gateway or the endpoint host (or feed it to `wireproxy` for a no-root, userspace tunnel) and every packet it sends now sources from its own `/128`. The backend authorizes on that address (a forge-proof, attributable, revocable network identity) instead of a token anyone could carry. For the full transport mechanics and the SOCKS5 / AnyIP alternatives, see [Connect & egress](/docs/connect); for every other op on this same endpoint, the [Control plane](/docs/control-plane) reference. Point the FHIR `Endpoint.address` (or `Device.url`) at the `/128`'s name and the directory entry is now cross-checkable against the address itself: the self-verifying discovery ONC FAST and the NDH IG describe as missing today.

> The `whisper` CLI ships `create --register`, `verify --trustless`, `policy`, `logs`, and `kill --revoke`. A dedicated `--endpoint` / `--udi` flag is **on the roadmap, not shipped**. Provision devices and endpoints today via the control-plane call above, which is live. When the flag lands it will be a thin wrapper over exactly this call.

## DANE-pin the same UDAP endpoint cert, publicly

This is the highest-leverage move for anyone already speaking UDAP, and the strongest claim on this page. UDAP already asserts the binding you care about (_this base URL is served by the holder of this certificate_), but it asserts it **only inside your community**: the proof rests on a private trust anchor, and a relying party who never joined your community cannot check it.

Because the identity's DANE-EE `TLSA 3 1 1` record pins the endpoint's _leaf key_, and the endpoint presents its **UDAP server certificate** on the `/128`, the very same base-URL↔cert binding UDAP asserts privately is now published in **public, DNSSEC-signed DNS**. Any relying party (inside your community or not, with no pre-provisioned anchor) validates it against the DNS chain to the IANA root:

```
# 1. the UDAP endpoint's base URL now resolves to a DNSSEC-signed, DANE-pinned /128
dig +dnssec TLSA _443._tcp.ep-c0def41d.fhir.<tenant>.agents.whisper.online +short
3 1 1 b653a4ef2c...c9f0d1  ; pins the SAME cert /.well-known/udap presents

# 2. pull the UDAP server cert and confirm the pin matches: no community anchor needed
openssl s_client -connect [2a04:2a01:f8e7:ca11:c0de:f41d:9a3d:71b2]:443 </dev/null 2>/dev/null \
  | openssl x509 -pubkey -noout | openssl pkey -pubin -outform DER | openssl dgst -sha256
# -> matches the TLSA 3 1 1 digest above == the base-URL↔cert binding, verified in public DNS
```

It is a **second, orthogonal proof** that complements, never replaces, your UDAP cert chain: the community anchor still governs who may register and exchange; DANE adds a publicly verifiable, DNS-rooted attestation of the exact SAN/base-URL binding UDAP defines, closing the base-URL↔cert-spoofing gap for parties outside the community, and it revokes at DNS-TTL (drop the TLSA and the endpoint stops verifying at the network layer immediately, publicly) rather than waiting on a community CRL/OCSP. For the record format, see [DANE & TLSA](/docs/dane); for keying a per-endpoint leaf, [Per-agent CA](/docs/per-agent-ca).

## A legacy HL7v2 or DICOM device, verifiable for the first time

The hardest devices in a hospital are the ones that will never speak modern crypto: an HL7v2 feed, a DICOM node whose AE-Title→IP:port mapping is "set at install by installation personnel," unauthenticated and not globally unique (internet scans find thousands of open DICOM servers accepting connections without AE-Title validation, exposing well over a billion images with under 1% on TLS). These devices can't hold their own key or take an agent, but the **gateway in front of them** can.

Provision one `/128` per legacy device on that gateway (the `serial` separator gives each its own address), and the device it fronts now has, for the first time, a **verifiable network identity**: an `AAAA`, a forward-confirmed `PTR`, a DANE pin, and an RDAP record. A DICOM AE-Title→IP mapping that was manual and unauthenticated becomes DNSSEC/DANE-checkable; an HL7v2 interface behind a converged VLAN gets a name a peer can prove and an owner can revoke, without re-flashing a 15-year-old machine or bricking the clinical workflow.

> **Honest scope.** This gives the legacy device a verifiable _network_ identity and a governed egress path. It does **not** authenticate the clinical protocol itself. Two same-segment nodes trading an unauthenticated DICOM `C-STORE` or an injected HL7v2 message is a _segmentation and protocol-auth_ problem, and stays one; Whisper anchors identity and reachability at the IP/DNS boundary, complementing microsegmentation and protocol-level auth, never standing in for them.

## Idempotent, with honest errors

Because the address is _derived_, provisioning is naturally idempotent, and the failure modes are clear rather than surprising, Postel all the way down:

| You send | You get |
|---|---|
| the **same** key + identifier again (same tenant) | the **same** `/128` (a re-derivation, not a new allocation) |
| the same key with a **different** identifier (same tenant) | `409`: the reused identity is never silently re-pinned to a mismatched address |
| a **non-string** `device_id` (or `serial`) | `400` with a helpful `detail`, never an opaque `500` |
| `device_id` without `identity_public_key` | `400`: an endpoint derives its address from its _own_ key |

## Verify: keyless, no account

The identity half is public on purpose: anyone (a QHIN allow-listing a peer endpoint, an auditor, a suspicious relying party) can prove an endpoint's `/128` without a Whisper account and without trusting Whisper's word. Four independent checks, all from tools already on the machine:

```
# 1. Forward-confirmed reverse DNS: the address names the endpoint, the name resolves back
dig -x 2a04:2a01:f8e7:ca11:c0de:f41d:9a3d:71b2 +short
ep-c0def41d.fhir.<tenant>.agents.whisper.online.

# 2. The keyless verdict endpoint (takes an address or an FQDN; ?ip=<target> also accepted)
curl -s https://whisper.online/verify-identity/2a04:2a01:f8e7:ca11:c0de:f41d:9a3d:71b2 | jq .
{
  "is_whisper_agent": true,
  "dane_ok": true,
  "jws_ok": true,
  "evidence": { "aaaa": "...", "ptr": "...", "tlsa": "3 1 1 b653a4ef…fcb82d1d" }
}

# 3. The registry record: RDAP, IP-anchored to the /128
curl -s https://whisper.online/ip/2a04:2a01:f8e7:ca11:c0de:f41d:9a3d:71b2 | jq '.handle, .parentHandle'

# 4. The full chain re-derived on YOUR machine, against the IANA root: Whisper NOT in the trust path
whisper verify --trustless ep-c0def41d.fhir.<tenant>.agents.whisper.online
```

A target that isn't a Whisper identity gets a clean `200 {"is_whisper_agent": false}`: a negative verdict is a successful answer, not an error; only genuinely malformed input draws a `400`, never a `500`. `--trustless` is the strong form: it validates DNSSEC from the root _in-process_, on your resolver, so the proof holds even for a party that won't take Whisper's word for anything, precisely the relying party UDAP's private anchor can't serve. The full keyless walk lives in [Verify an agent](/docs/verify).

## See who checked your endpoint: a recon tripwire

An identity you can prove is also an identity you can _watch_. Because every endpoint's name resolves through Whisper's own authoritative DNS and RDAP, the owner can ask **who looked**: `op:'lookups'` returns the PTR/`AAAA`/TLSA resolutions and RDAP accesses against a device's identity. That is an early-warning tripwire the community directory never gave you: someone enumerating your endpoints, or verifying a device before they reach for it, shows up _before_ the connection lands, not in a post-mortem after exfil.

```
curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" -H "content-type: application/json" \
  -d '{"query":"CALL whisper.agents({op:\"lookups\", args:{agent:\"2a04:2a01:f8e7:ca11:c0de:f41d:9a3d:71b2\"}})"}' | jq .
# -> who resolved / RDAP-queried this endpoint's identity, and when
```

Its outbound companion is `op:'logs'` (the endpoint's _own_ DNS and connection activity), the audit trail HIPAA §164.312(b) asks for. Non-repudiable, keyed to a forge-proof address rather than a spoofable last IP.

## Govern what a device may reach: egress governance

The same address that proves a device is also the handle you govern it by. A graph-first resolver and source-bound egress enforce **default-deny per device**: a control-plane way to segment the machine that can't take a NAC agent, at Layer 3, by name:

```
# default-deny; allow only the clinical systems this device must reach
whisper policy set --agent 2a04:2a01:f8e7:ca11:c0de:f41d:9a3d:71b2 \
  --default deny --allow fhir.example-hdo.org,pacs.example-hdo.org

# per-device firewall by host / cidr / port; a spend + traffic cap with a kill-switch
CALL whisper.agents({op:'firewall', args:{agent:'2a04:2a01:f8e7:ca11:c0de:f41d:9a3d:71b2',
    allow:['pacs.example-hdo.org:11112'], deny:['0.0.0.0/0']}})
CALL whisper.agents({op:'budget', args:{agent:'2a04:2a01:f8e7:ca11:c0de:f41d:9a3d:71b2', max_mb_per_day:200}})
```

`op:'policy'`, `op:'firewall'`, and `op:'budget'` are shipped: allow/deny by category, geography, name, subdomain, host, CIDR, or port, and cap a device's traffic, so a compromised monitor that starts beaconing to C2 is choked at the egress before it exfiltrates, and one `op:'revoke'` (below) cuts it off worldwide. This is the network-segmentation control the HIPAA Security Rule NPRM and the HHS CPGs put front and center, delivered for devices that can't host an agent. Full surface in [Egress governance](/docs/egress-governance).

## Revoke: worldwide, in one call

A compromised, decommissioned, or resold device is one `revoke` away from having no network identity anywhere. The call tears down the `/128`, its `PTR`, and its DANE pin across both authoritative servers, and the change propagates at DNS-TTL speed. That's the cross-organization kill-switch UDAP's in-community CRL/OCSP can't give you:

```
CALL whisper.agents({op:'revoke', args:{agent:'2a04:2a01:f8e7:ca11:c0de:f41d:9a3d:71b2'}})

# prove it (zero Whisper software): the same stock tools that proved it existed:
dig -x 2a04:2a01:f8e7:ca11:c0de:f41d:9a3d:71b2 +short           # -> nothing
curl -s https://whisper.online/verify-identity/2a04:2a01:f8e7:ca11:c0de:f41d:9a3d:71b2
# -> {"is_whisper_agent": false, ...}
```

Revocation isn't a database flag you have to trust; it's provable the same way the identity was: the reverse lookup goes empty and the keyless verdict flips to `false` for everyone, everywhere, at once. Contrast a credential burned at organization A but still valid against organization B, or a CRL you hope every relying party fetched. This is the **substance behind FDA §524B(b)(1)** postmarket containment: demonstrate you can revoke a single unit's identity in one call.

## Nothing issued in the dark: the transparency log

Every identity mint and every revoke lands in a public, append-only **RFC 6962 `tlog-tiles` Merkle log**, with Ed25519-signed C2SP `signed-note` checkpoints, each root anchored to Bitcoin via OpenTimestamps. For a regulated device fleet that is an auditable, non-repudiable issuance-and-revocation trail. It's evidence you can hand an auditor for FDA §524B postmarket monitoring or a HIPAA asset-inventory review, cross-checkable without trusting Whisper's database:

```
curl -s https://whisper.online/checkpoint            # signed Merkle root + tree size
curl -s https://whisper.online/ip/2a04:2a01:f8e7:ca11:c0de:f41d:9a3d:71b2/transparency | jq .
# -> this endpoint's ordered lifecycle: mint, DANE pin, revoke, each a log leaf
```

> **Honest status.** The log is tamper-evident, Ed25519-signed, and Bitcoin-anchored today, but it is **not yet independently witnessed** (ns1/ns2 co-signing is availability, not third-party independence). It already speaks the C2SP `tlog-witness` protocol, so an external witness can co-sign; until one does, treat it as strong tamper-evidence, not third-party attestation. It is also GDPR-compatible: leaves are salted opaque commitments, and `op:'erase'` destroys the salt so a leaf's meaning is unrecoverable while the proofs stay valid. More in [Transparency log](/docs/transparency) and [OpenTimestamps](/docs/opentimestamps).

## Attribution: name whoever already scraped you

Identity stops the _next_ forgery. To name whoever _already_ scraped an endpoint or a fleet, across rotating clouds and residential proxies, and critically **across organizations** (41% of 2024 healthcare breaches originated with a third-party vendor), the same API key opens the read-only attribution graph on the same endpoint. `whisper.identify` takes an address and returns the operator behind it, stitched across Amazon → Google → Azure hops that a raw last-IP loses:

```
curl -s https://graph.whisper.security/api/query \
  -H "X-API-Key: whisper_live_xxx" \
  -H "content-type: application/json" \
  -d '{"query":"CALL whisper.identify(\"203.0.113.45\")"}' | jq .
# operator fingerprinted across clouds; residential swarm collapsed by JA4: one operator, not a last IP
```

The read-only Cypher surface (`identify`, `origins`, `walk`, `variants`, `history`) runs over the same `POST https://graph.whisper.security/api/query` with your key, each returning a reproducible, replayable JSON evidence chain your SOC, your privacy office, and OCR can replay: the cross-organization vantage inventory tools structurally can't reach, since theirs stops at one hospital's edge. There is no `whisper identify` CLI subcommand. This is the API call, and it is live. Full verbs and shapes in [Graph & cognition](/docs/graph-api).

## Lifecycle, end to end

The whole thing reads as one arc, and every stage is a single call against the address:

```
  provision                 in-life                    incident / EOL
  ─────────                 ───────                    ──────────────
  op:'connect'    ──▶   op:'policy' · op:'firewall'   ──▶   op:'revoke'
  key + Endpoint.id     op:'budget'  · op:'lookups'         gone worldwide
  ─▶ /128 · DANE        op:'logs'    (who reached it,        at DNS-TTL
     · PTR · RDAP        who checked it)                  ─▶ op:'erase' (GDPR)

  every mint · every revoke ──▶ the public Merkle transparency log
                                (Ed25519-signed · Bitcoin-anchored)
```

A board swap or a re-key mints a new `/128` and revokes the old one; a resale or a change of custodian is one `revoke` and a re-register to the new owner; a decommission is one `revoke` and, if you must erase, one `op:'erase'`. Compromise one device and you've compromised _that device_, not the fleet: the "a stolen secret is the whole fleet" failure mode is structurally removed. Nothing is issued, and nothing is torn down, in the dark.

## Where this fits, and where it doesn't

Whisper anchors identity at the **device/endpoint ↔ network IP boundary**: the endpoint your backend authorizes and your directory publishes. It is additive: it complements the roots of trust you already run and does not try to replace them, and it deliberately stops at the transport edge.

- **UDAP / SMART / TEFCA.** The community anchor still governs registration and exchange; Whisper adds a second, DNS-rooted proof of the same base-URL↔cert binding that any relying party verifies without joining, plus DNS-TTL revocation. It complements the UDAP cert chain; it does not replace it. SMART authenticates the _caller_, not the endpoint (orthogonal).
- **802.1AR IDevID / TPM / secure element / Medcrypt-issued leaf.** The device's birth key is the _input_ to the derivation: Whisper publicly anchors an OEM-issued or silicon-rooted identity in open DNS/DANE, so the operating hospital or HIE can verify and revoke it. It complements that root; it does not replace it.
- **IoMT visibility & segmentation (Claroty, Armis, Ordr, Forescout, Palo Alto).** They discover devices and infer identity from behavior inside one org's console; Whisper consumes their UDI/inventory as `device_id` and gives each device a portable, forge-proof, publicly verifiable `/128` with cross-org attribution and one-call revocation. Additive: it plugs in, it doesn't rip and replace.
- **Where Whisper does _not_ go.** Not the unauthenticated clinical protocol on the LAN (an HL7v2 injection or a DICOM `C-STORE` between two same-segment nodes is a segmentation + protocol-auth problem, and stays one); not an insider abusing a valid, authenticated session; not ransomware already executing locally (it chokes C2/exfil and speeds cross-org revocation, but doesn't govern what an already-trusted process does on-box); not the unpatchable CVE itself (URGENT-11 / Ripple20 stay exploitable on-path; Whisper reduces _who_ can reach the device and attributes them, it doesn't patch the stack); and identity is only as forge-proof as the device's key storage: an EOL device with no TPM or secure element inherits weaker custody, and we say so.

For mapping these identities to **FDA §524B(b)(1)/(2)** authentication and postmarket containment, the **HIPAA Security Rule**'s asset-inventory / network-map / segmentation and `§164.312(a)/(b)/(d)` controls, **EU MDR** Annex I §17.4, and **IEC 62443** FR1 (IAC), see [FDA 524B · HIPAA · MDR](/docs/health-compliance). The **Splunk** connector is shipped; a Microsoft Sentinel connector, OpenCTI, and STIX 2.1 / TAXII export are on the roadmap and labelled as such there. No specific device maker, hospital, health system, or clearinghouse is named, endorsed, or implicated as a breach victim anywhere in these docs; the abuse patterns cited are the public, cross-industry ones.

## Next

- [Device/API-abuse cure](/docs/device-api-abuse-cure): this identity, applied to the exact FHIR BOLA / stolen-credential / unauth-DICOM problem it was built for
- [FHIR · UDAP · TEFCA · UDI](/docs/health-integrations): dropping the `/128` into the `Endpoint` resource, UDAP discovery, the RCE/NDH directory, and GUDID
- [DANE & TLSA](/docs/dane): the byte-for-byte record that makes the address, and your UDAP cert, provable in public DNS