Procurement & compliance pack ✅

For security reviewers, privacy officers, and procurement teams evaluating an integration that uses LifeCare.ID. The goal of this page is to let you clear review before your engineers write code. Share it freely.

The one-sentence version. LifeCare.ID is a consent and authorization layer that never receives, stores, caches, relays, or logs health data — it handles only DIDs, public keys, tokens, scope strings, consent metadata/receipts, and revocation state. A full compromise of LifeCare.ID yields metadata, not patient data.

1. What LifeCare.ID is — and is not

Raw health data flows directly between the data source and the requesting app. LifeCare.ID is never on that path.

        ┌────────────────────────────────────────────────┐
        │                  LifeCare.ID                     │
        │  DIDs · consent receipts/ledger · tokens · revocation
        └──────▲───────────────▲───────────────▲──────────┘
               │ sign-in/token  │ grant/revoke  │ token validation
   ┌───────────┴───┐   ┌────────┴───────┐   ┌───┴──────────────┐
   │  App          │   │   The person    │   │  Data source     │
   │ (requester)   │   │  (device key)   │   │ (holds the data) │
   └───────┬───────┘   └─────────────────┘   └────────┬─────────┘
           │            raw data, app ↔ source         │
           └──────────────────────────────────────────-┘
                 (LifeCare.ID is NEVER in this path)

2. The zero-PHI invariant (the basis of every claim below)

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 an architectural invariant, not a policy setting — there is no configuration that routes PHI through LifeCare.ID, because no endpoint accepts a health value. Every request and response field carries identity, scope, consent, or token metadata only.

Why this matters for your review: the blast radius of LifeCare.ID is bounded to metadata by construction, so it can be assessed independently of — and far more quickly than — a system that custodies PHI.

3. Does LifeCare.ID need a BAA? (US/HIPAA)

LifeCare.ID does not create, receive, maintain, or transmit Protected Health Information on your behalf, so it does not act as a HIPAA Business Associate with respect to PHI. It handles only de-identified identifiers and consent/authorization metadata. Your data source and your app remain responsible for PHI they hold and exchange directly, and for any BAAs between them.

This is informational, not legal advice. Confirm against your own counsel and your specific data flows — but the architecture is deliberately shaped so LifeCare.ID is out of the PHI path, which is the fact most reviews turn on.

4. GDPR / privacy-by-design (EU/UK)

• Data minimization & privacy-by-design (Art. 25): LifeCare.ID processes the minimum needed to express and enforce consent — identifiers, scopes, and receipts — and nothing about the content of health data.
• Consent is explicit, purpose-bound, and revocable: every grant names a scope and a declared purpose; a token issues only against a grant whose purpose matches; the user can revoke at any time and dependent access dies in < 500 ms.
• Auditable lawful basis: each grant produces a machine-readable consent receipt (ISO/IEC 27560-style) and an immutable ledger entry (below), so the lawful basis and its lifecycle are demonstrable.
• No tracking in privileged surfaces: the consent panel and identity pages carry no third-party analytics.

5. The audit trail you can show a regulator

• Consent receipts. Every grant returns a structured receipt (who, what scope, what purpose, when, for how long) — a portable record of consent.
• Hash-chained, tamper-evident ledger. Grants, revocations, token issuance, and recorded data accesses are appended to a per-user ledger whose entries are hash-chained. A chain_valid flag lets anyone detect tampering; if it ever reads false, treat it as an incident.
• Recorded accesses. Data sources record each access, so the user's ledger is a true end-to-end audit trail of who read what, when, for what purpose — without any health value appearing in it.

6. Identity & key custody

• The user's private signing key never leaves their device (Secure Enclave / Android Keystore, via WebAuthn/passkeys). LifeCare.ID is the DID authority, not the key holder — it cannot sign as the user, and neither can an integrator.
• Recovery is human-anchored (email magic-link / trust partner), never a password reset; key rotation is fail-secure (refused without trust-partner approval).
• Standards-based throughout: OAuth 2.0 + PKCE, WebAuthn, did:web/JWK, UMA-pattern tokens, TLS 1.3 in transit, tokens hashed at rest.

7. Verify the node you integrate with — yourself

Beyond trusting our description, a node's deployment is independently verifiable: it publishes a signed attestation of the exact code, AI models, and parameters it runs, and anyone can confirm it in a browser at lifecare.id/verify (recompute + signature check, no trust in the operator required). This is the software floor today; hardware-rooted attestation is on the roadmap. See Security & compliance → Node transparency.

8. Security-reviewer checklist

Use this to scope your review quickly:

• [ ] PHI boundary: confirm your integration sends LifeCare.ID only {DID, scope, purpose, accessor, token} — never a health value. (No endpoint accepts one.)
• [ ] Direct data path: raw data flows app ↔ data source; LifeCare.ID is not an intermediary.
• [ ] Consent lifecycle: grants are purpose-bound, receipted, and revocable; your app degrades gracefully on 403 / active:false.
• [ ] Token hygiene: bearer tokens are stored server-side, never logged or URL-borne; client_secret never reaches a browser.
• [ ] Audit: data accesses are recorded; the ledger's chain_valid is monitored.
• [ ] Identity: you resolve the user's DID document fresh (keys can rotate).
• [ ] Node transparency: you can independently verify the node's attestation.

9. Roadmap items relevant to procurement 🛣️

• SOC 2 / formal BAA posture and a vulnerability-disclosure policy return at commercialization.
• A self-service conformance kit for data sources (proves direct-serve, correct introspection, revocation timeliness).
• Hardware-rooted node attestation and resolvable node DIDs (strengthening §7).

For the engineering view of the same guarantees, see Security & compliance. The authoritative integration surface is the drift-tested API contract.