You can't be deplatformed — a developer's bill of rights ✅

The short version. On a Web2 platform, the platform owns your users and can cut you off. On LifeCare.ID, nobody owns the user — the user owns themselves. Your relationship with them is direct and consent-mediated, and most of the ways a platform could hurt you are structurally impossible here — not promised, impossible. The few operational levers that remain are narrow, disclosed, and on a roadmap to remove. You can't be cut off on a whim or have your users seized — the one way off the network is breaking clearly-defined rules, through a transparent conformance process. And you can verify all of it yourself.

The fear, named

If you've built on someone else's platform, you know the trauma: you grow on top of an API, and one day the platform changes the rules, raises the rent, or deplatforms you — and your users were never yours to keep. So when you read that the LifeCare.ID is the account, the natural reaction is: great, so LifeCare owns my users and can do the same to me.

It can't. Here's why — and how to check.

The reframe

LifeCare.ID is not a platform that owns your users. It's a protocol where:

the user holds their own identity (a key on their device),
their consent to your app is theirs to grant and revoke — not ours,
and the data flows directly between you and the source — we are never in the middle.

So there is no "pile of your users" for anyone to seize, and no pipe of your data for anyone to pinch off. The thing a platform would use against you doesn't exist in this architecture. That makes your user relationship more durable than anything a platform can offer — because it doesn't depend on us staying friendly.

Your bill of rights

Each right below is backed by how the system is built, not by a promise we make. ✅ = enforced today; 🛣️ = the end-state we're building toward, tagged honestly.

1. We can never hold your users' keys, or act as them ✅

The user's root key lives on their device (a passkey); we derive their DID from the public key and never see the private one. By rule, there is "no code path where an origin holds something the user cannot revoke or carry" — we are a coordinator, never a custodian. We cannot sign as, impersonate, or log in as your user.

2. We are never in your data path ✅

By invariant, no LifeCare.ID component is ever an intermediary, cache, or proxy of a health value. Data goes directly from the source to you. We hold only {DID, public key, token, scope, consent receipt, revocation status}. This is enforced in code — scopes are a fixed list of category names, never values, and a test fails if any endpoint carries a reading. We cannot withhold, throttle, inspect, or monetize your users' data, because it never touches us.

A grant binding a user to your app can only be created by that user's authenticated session — an app token or an operator cannot mint one (the endpoint returns 403). And there is no operator path to revoke a user's grant; only the user can. Every grant and revocation lands in a hash-chained, tamper-evident ledger, and revocations are published to a public, unauthenticated registry anyone can poll. We can't fake a revocation to cut you off, and we can't quietly erase one — the chain would break, visibly.

4. We cannot cut you off on a whim ✅

There is no arbitrary kill switch over your user relationships, and no way for us to seize the users themselves. Even deregistering your app's client only blocks new sign-ins — existing consents and sessions survive (the ledger never deletes), so users who already granted you access keep working. The only way an app leaves the network is removal for cause through a transparent, rules-based conformance process — not operator discretion. See Removal for cause.

5. You are not locked in ✅

The whole stack is open standards: DIDs, WebAuthn/passkeys, OAuth 2.0 + PKCE, UMA 2.0, ISO-27560 consent receipts, FHIR / Open mHealth. Our authorization server is a standards-shaped service, not a black box — a decision on record keeps it swappable for another certified UMA server behind the same published contract. Your app can integrate other identity providers alongside us. Nothing here is a proprietary lock-in or a token you're forced to hold.

6. You don't have to trust us — you can verify ✅ (software floor; hardware-rooted 🛣️)

Every node publishes a signed, unauthenticated attestation of exactly what code and models it runs. Anyone — you, your user, an auditor — can recompute the measurement and check the signature without trusting the operator, including in a browser verifier. Today this is a recomputable software-floor measurement (a malicious operator could spoof it, and we say so plainly); the hardware-rooted version that defeats even that is designed-in and trigger-gated. "Don't trust, verify" is the wedge — and the verifiable part is live.

This verifiability runs both ways, and that's a feature for you: the same machinery that lets you check a node is how the network checks that every participant — apps included — honors the rules. It's what keeps a bad actor from poisoning the network you build on (and it's the basis of removal for cause, below).

7. Your users are portable ✅ / 🛣️

A user's DID is stable and theirs; their identity, consent, and data move with them, not with us. They can recover onto a new device and keep the same DID, so your relationship survives a lost phone. The end-state where the key is fully user-held with no shared origin is the locked target (A3) we're building toward.

What we can do today — and why it isn't seizure

We won't pretend the levers don't exist; a serious developer will find them, so here they are, with what they actually mean and how we're removing them.

Lever (today)	What it is — and isn't	Where it's going
Token introspection	If our service is down or refuses, tokens can't be validated and reads fail. That's a denial of service, not a seizure — your users' consent still exists in the ledger, and attestation lets you prove we didn't fake a revocation.	🛣️ Offline-validatable tokens (UMA / JWT) so reads don't depend on us being up.
Production client registration	The operator provisions production clients today (the sandbox is self-serve now ✅). In principle the operator could decline to register a new app.	🛣️ Self-service production registration + secret rotation in the developer portal.
Recovery (the honest one)	Recovery is email-based in the MVP, and we run the email path — so today an operator could, in principle, intercept a time-limited recovery link. Even then the DID survives (only the device key rotates) and the user knows recovery happened.	🛣️ Recovery moves to provider-approved key rotation — a medical practice the user chose, not us.

None of these let us take your users, reach your data, or forge consent. They are operational, disclosed, and detectable, and each is on the roadmap to disappear.

Removal for cause — rules, not whim 🛣️

We're not going to promise "you'll never be removed," because that would mean a bad actor — an app that exfiltrates data, ignores revocation, or sends PHI where it must never go — gets to stay and poison the network you depend on. You don't want that, and neither do your users.

So there is one way off the network, and it's the opposite of arbitrary: removal for cause through a transparent conformance process. The same attestation/verification machinery that lets you check a node becomes, for apps, a conformance regime — an app is verified to honor the network's rules, and that conformance can be withheld or revoked for a clearly-defined violation, which removes the app.

The point is which kind of lever this is. It is not operator discretion, a business-terms dispute, or "we changed our mind about you." It is rules-based, with the violation defined in advance and the process transparent — closer to losing a safety certification than to being deplatformed on a whim.

This is roadmap governance, stated honestly: today only nodes self-attest; an app conformance/attestation regime is future work. When it lands, the rules, the evidence, and a due-process / appeal path will be defined in the developer terms and the conformance spec — not left to discretion. We'd rather tell you the lever exists, and that it's bounded by rules, than pretend the network has no immune system.

The trust anchor, stated precisely

This is the crux of "who's actually in control," so let's be exact:

The root of trust is the user's own key (ruling A3) — not LifeCare, and not the provider. That is the non-negotiable target.
A medical provider becomes the recovery partner — the human who approves a key rotation if a user loses their device — replacing the operator/email anchor. A recovery partner is not a custodian of the root; it cannot act as the user day to day.
The network is built to go multi-operator / mesh, so no single LifeCare entity is a permanent chokepoint. (Live today is a single shared identity origin — an explicitly accepted interim with a documented retirement trigger, not a hidden dependency.)

So "provider-based" describes recovery, not ownership. Ownership stays with the user, by construction.

Verify any of this yourself

What a node runs: fetch GET {base}/v1/attestation (no auth) or use the verifier. See Security & compliance.
Whether a consent is revoked: poll the public GET {base}/v1/revocation/{user_id} — no auth, no trusting our word. See Authorization & tokens.
That we hold no data: read the invariant and the zero-PHI procurement pack; the contract has no endpoint that carries a value.
The model and the plan: Concepts and the Roadmap.

Bottom line. Building on LifeCare.ID isn't renting your users from a landlord who can evict you on a whim. It's plugging into users who own themselves, over a connection we can't stand in — where the only way off the network is breaking rules you can read in advance. That's the most durable foundation you can build a health app on.