Security & compliance

Integrating with LifeCare.ID means inheriting — and upholding — a small set of hard guarantees. This page states what the platform guarantees you, and what you must guarantee in return.

The zero-PHI invariant (the one rule above all)

For any data value d held by a resource holder R and delivered to a requester Q, the transfer R → Q is direct. No LifeCare.ID component is an intermediary, cache, proxy, or co-processor of d. LifeCare.ID participates only in {DID, public key, token, scope, consent receipt, revocation status}.

This is architectural, not a policy toggle. What it means for you:

• Never send a health value to a LifeCare.ID endpoint. Not in a scope, not in a purpose, not in an accessor, not in any free-text field. Scopes name categories; purposes are short declared strings; descriptions are plain-language and value-free.
• Data flows directly between the data source and the requesting app. If your design routes data through LifeCare.ID, it's wrong — redesign it.
• A full compromise of LifeCare.ID must yield only metadata. Keep it that way by never putting a value where one doesn't belong.

A data source must additionally be able to demonstrate direct transfer (this is part of future conformance). An app accepts the obligation as part of the Network Developer Agreement (🛣️).

Identity & key custody

• The user's private key never leaves their device (Secure Enclave / Android Keystore, via WebAuthn). You never see, store, or transmit it.
• LifeCare.ID is the DID authority, not the key holder — it cannot sign as the user, and neither can you.
• Recovery is human-anchored (email magic link / trust partner), never a password reset. Key rotation (/v1/identity/rotate) is fail-secure: with no trust-partner approval configured, it is refused.
• Because keys can rotate, always resolve the DID document fresh when you need the user's current verification key.

Token handling

The lcs_ session token doubles as the user token: when a resource server introspects it, it carries subject_did — proof the caller is that user, required for user-self actions (e.g. in-app consent). A lc_ access token never carries a subject; it names the data it unlocks via resource_owner. See Authorization & tokens.

• Tokens are bearer credentials — possession is authorization. Treat them like secrets.
• Tokens are stored hashed at rest by the AS; you should not need to persist raw lc_ tokens beyond their short lifetime.
• Minimum scope, minimum lifetime. Request a single scope, only when needed.

Consent & revocation discipline

• Purpose binding is enforced. A token issues only against a grant whose declared purpose matches — don't reuse one purpose to back unrelated processing.
• Design for revocation. A grant can be revoked at any instant; dependent tokens die in < 500 ms. A 403 / active:false is a normal state, not an error to retry-storm. Degrade gracefully and stop using the data.
• Record accesses (data sources) so the user's ledger is a true audit trail.
• The ledger is tamper-evident (chain_valid). If it ever reads false, treat it as a security incident.

Transport & storage

• TLS 1.3 in transit (LifeCare.ID runs behind the node's ingress).
• AES-256 at rest for tokens on the platform side.
• No third-party analytics in privileged surfaces (the consent panel, the identity web pages) — don't add tracking there.
• GDPR Art. 25 privacy-by-design is a prerequisite of integration; SOC 2 / BAA targets return at commercialization.

Your integration checklist

Apps - [ ] Token exchange runs server-side; client_secret never reaches a client. - [ ] PKCE S256 with a fresh per-attempt code_verifier; state validated. - [ ] HTTPS redirect URIs, exact-match registered. - [ ] Session + access tokens stored server-side, never logged or URL-borne. - [ ] No health value in any field sent to LifeCare.ID. - [ ] Graceful handling of revoked / expired grants and tokens.

Data sources - [ ] Introspect every request; enforce active + scope, and bind the request to the introspected resource_owner. (For a user-self action, require a user token whose subject_did matches the acting user instead.) - [ ] Serve data directly to the requester — never via LifeCare.ID. - [ ] Record each access (/v1/access/record). - [ ] Honor revocation within targets; don't over-cache active results. - [ ] Hold upstream provider credentials yourself, under an active grant; never send them (or any value) to LifeCare.ID. - [ ] Source has its own DID and signs its requests.

Node transparency — verify what you integrate with

A node publishes a public, CORS-open attestation at GET {node}/v1/attestation: the code commit, AI models (with licenses), and parameter version it is running, over a measurement it signs with its own key (ECDSA P-256). It carries no PHI.

LifeCare.ID hosts a public verifier — https://lifecare.id/verify — that confirms a node's attestation in the browser, without trusting the operator: it recomputes the measurement from the published fields and verifies the signature. It works for any node — pass the address (?node=<url>) for a one-click "verify the node you're talking to" link you can surface to your users.

• What a pass proves: the claim is internally consistent and cryptographically signed by the node's key — recomputable and tamper-evident.
• What it does not yet prove: this is the software floor, not hardware-rooted attestation; the node's key is self-asserted today (anchoring it as a resolvable node DID via LifeCare.ID is specified and trigger-gated). The page states this boundary plainly.

Verifying the node you integrate with is good hygiene; for high-assurance flows, treat the hardware-rooted attestation (roadmap) as the bar.

Reporting & contacts

Security issues with the platform should be reported to the network operator through the channel they provide at onboarding. 🛣️ A formal vulnerability disclosure policy and a status/changelog page are planned with the developer portal.

References

• The published, drift-tested API contract — the authoritative integration surface: openapi.json.
• This page summarizes the platform's security posture and the zero-PHI invariant; the underlying PRD and design-decision records sit alongside it in the project repository.