Privacy Policy

1. Overview

HIPVerify is a Tier 1 pathway provider for the Human Integrity Protocol (HIP). This privacy policy describes what data HIPVerify — the verification service operated at hipverify.org — collects, processes, and retains during the issuance of a Tier 1 credential. It is separate from the protocol-layer privacy posture documented at hipprotocol.org and from the HIPKit commercial product (hipkit.net Privacy Policy) which has its own privacy policy.

HIPVerify is designed around minimal data collection. We verify that you are a living human with a valid government ID, then we forget who you are. Your identity documents and biometric data flow directly to our verification provider (Didit) and are never stored by HIPVerify. Your payment data flows directly to Stripe and is never stored by HIPVerify. What HIPVerify holds, after a successful verification, is a one-way deduplication hash, a pseudonymous credential ID mapping, and short-lived session metadata.

HIPVerify is operated by Peter Rieveschl as an individual at the time of this update. See § 13 (Operator and Successor Entity) for how this policy continues to apply if HIPVerify's operations are transferred to a successor entity. For the contractual side of your relationship with HIPVerify (separate from this privacy policy), see the HIPVerify Terms of Service.

2. Data We Collect

Data we process but do NOT store

• Identity documents: Your government ID images are sent directly to our verification provider (Didit) for processing. HIPVerify never receives, stores, or has access to your document images.
• Biometric data: Your selfie and liveness check data are processed by Didit. HIPVerify never receives, stores, or has access to your biometric data.
• Personal information: Your name, date of birth, document number, and other identity fields extracted from your ID are processed by Didit during verification. HIPVerify receives a verification result (approved/declined) but does not receive or store your personal information in readable form.

Data we DO store (HIPVerify infrastructure)

• Deduplication hash: A one-way HMAC-SHA-256 hash computed from your document number, date of birth, and issuing state. This hash is stored permanently in Cloudflare KV to prevent the same person from creating multiple credentials. It is computationally infeasible to reverse this hash to recover your identity.
• Verification session metadata: A temporary record of your verification session (session ID, status, timestamp, non-identifying verification scores). This is stored in Cloudflare KV with a 1-hour expiration and is automatically deleted.
• Credential ID mapping: Your deduplication hash is mapped to your credential ID (a pseudonymous identifier). This mapping is stored permanently to enable duplicate detection across re-verification attempts.
• Stripe customer reference: Stripe issues a customer ID for the $1 verification charge. Stripe holds the payment instrument and the email you provide at checkout; HIPVerify retains the Stripe customer ID associated with the issued credential for receipt reconciliation.

Data stored only in YOUR browser (localStorage)

• Your credential: Your cryptographic key pair (Ed25519 private + public key), credential ID, tier, issuance metadata, and pathway provenance. The private key is generated and held entirely in your browser. HIPVerify never sees, receives, or stores your private key.
• Session state: UI preferences and ephemeral state for in-progress flows.

3. Analytics

HIPVerify uses Cloudflare Web Analytics, a privacy-respecting analytics service. Cloudflare Web Analytics:

• Does not use cookies or local storage to identify visitors.
• Does not perform browser fingerprinting.
• Does not track users across websites or sessions.
• Aggregates page views, referrers, anonymized device categories, and country-level geographic data.
• Does not collect IP addresses for analytics purposes (Cloudflare derives country from the IP at the edge and discards the address).

This analytics data is used solely to understand which pages get visited and where traffic comes from, in aggregate, to improve the Service. It is not joined with your credential, your verification record, your deduplication hash, or any other identifier.

4. Payment Data

The $1 Tier 1 verification fee is processed entirely by Stripe. HIPVerify does not receive, process, or store your credit card number, billing address, or other payment details. HIPVerify receives from Stripe only:

• A confirmation that the $1 charge succeeded.
• Your Stripe customer ID (a pseudonymous identifier internal to Stripe).
• The email address you provided at checkout (used to issue receipts and confirmations).

Stripe's privacy policy governs their handling of your payment data. See stripe.com/privacy.

5. Third-Party Data Processing

Didit (identity verification provider) processes your identity documents and biometric data under their own privacy policy. HIPVerify has a data processing relationship with Didit in which:

• Didit receives your ID images and selfie for verification.
• Didit sends verification results (approved/declined, document type, non-identifying verification scores) to HIPVerify via a secure webhook.
• Didit's own data retention policies govern how long they retain your identity documents and biometric data. See didit.me/privacy.

Stripe (payment processor) handles all payment data under their own privacy policy. HIPVerify has a data processing relationship with Stripe limited to the customer-reference and receipt fields described in § 4.

Cloudflare hosts the HIPVerify infrastructure: the static frontend, the verification Worker, KV storage (deduplication hashes, session data, credential ID mappings), and Email Routing. Cloudflare's privacy policy applies to their infrastructure services. See cloudflare.com/privacypolicy.

HIPVerify does not share data with any other third party except as required by law or to operate the Service.

6. Data Retention

• Deduplication hashes: Stored permanently. Required to enforce one-credential-per-human across the Tier 1 pathway.
• Credential ID mappings: Stored permanently alongside the deduplication hash to support duplicate detection on re-verification attempts.
• Verification session data: Automatically deleted after 1 hour.
• QR transfer relay data: Encrypted blobs are deleted after first retrieval or automatically after 5 minutes, whichever comes first.
• Audit records (institutional verifications): Retained for 1 year, containing only operator ID, credential ID, and timestamp — no personal information.
• Stripe customer reference and receipt email: Retained while you have an active credential issued through HIPVerify.
• Cloudflare Web Analytics data: Retention is governed by Cloudflare's own retention policy.
• Email Routing logs: Cloudflare's Email Routing Activity Log shows forwarded messages; retention governed by Cloudflare.

7. What We Do NOT Do

• We do not sell, share, or rent your data to any third party for marketing or advertising.
• We do not use your data to train AI models or any other unrelated downstream system.
• We do not track you across websites.
• We do not use cookies for analytics or advertising. The Service uses localStorage only for the operational credential storage described above.
• We do not collect IP addresses for analytics purposes (beyond what Cloudflare's edge infrastructure observes for routing and abuse mitigation).
• We do not store your name, date of birth, document number, or any personally identifiable information in readable form.

8. Data Security

All data in transit is encrypted via HTTPS/TLS. Deduplication hashes are computed using HMAC-SHA-256 with a server-side secret key. The QR credential transfer system uses AES-256-GCM end-to-end encryption where the encryption key never touches the server. Your credential's private key is generated and stored entirely in your browser's localStorage and is never transmitted to any server.

9. Your Rights

Because HIPVerify stores only irreversible hashes and pseudonymous identifiers rather than personal information, traditional data subject rights apply in a narrow but real way:

• Access: You can confirm whether a deduplication hash exists for your identity by contacting us. There is no readable personal data to enumerate.
• Deletion: You can request deletion of your deduplication hash and credential ID mapping. Be aware that this would allow re-verification with the same ID, which conflicts with the one-credential-per-human principle and may not be granted in all circumstances. To request removal of your Stripe customer reference and receipt email, contact us through the channels in § 16.
• Credential retirement: You can retire your credential at the protocol layer, which marks it as superseded and prevents further use under that credential. Retirement is recorded; the deduplication hash remains so a new credential can be issued through the same pathway when re-verification is attempted.

10. Young Users

The Service is available to users aged 13 and older who possess a valid government-issued ID. We do not knowingly process data from children under 13. The HIP protocol itself has no age restriction — minors can also obtain credentials through Peer Vouch (Tier 2) or Biometric Presence (Tier 3) on hipprotocol.org at no cost and with no age requirement.

11. International Users

The Service is operated from the United States. Data is processed through Cloudflare's global network, Didit's verification infrastructure, and Stripe's payment infrastructure. By using the Service, you consent to the processing of your data in these systems. Where applicable law requires additional protections (GDPR, CCPA, etc.), HIPVerify operates in good-faith compliance with the data-handling principles described in this policy: minimal collection, narrow third-party processing, no sale of data, and transparency about retention.

12. Protocol vs HIPVerify (Pathway Provider Boundary)

This privacy policy applies to HIPVerify, a Tier 1 pathway provider operating under the Human Integrity Protocol (HIP) Charter. It is important to distinguish HIPVerify (the operator) from the HIP protocol itself.

The HIP protocol layer — the public ledger, the worker that registers attestations, the verifier that validates them — does not see, store, or transmit identity data. The protocol receives only a one-way deduplication hash, a tier label (1, 2, or 3), and a pathway identifier. No documents, no biometric data, no personally identifiable information ever reaches protocol-layer code or ledger entries.

HIPVerify, as a pathway provider, is the institutional operator that handles the Tier 1 identity verification step. Identity documents and biometric data flow to our sub-processor Didit; payment data flows to our sub-processor Stripe; only the resulting deduplication hash, tier label, and pathway identifier reach the protocol. Operator-level access to Didit's verification dashboard is retained for support and audit purposes; HIPVerify does not retain copies of your identity documents or biometric data outside of Didit's systems.

Under Charter Deployment Principle 5 (Permissionless Proliferation), anyone may build alternative Tier 1 pathway providers. HIPVerify is the first; it is not the only one. Under Charter Deployment Principle 8 (Protocol, Not Entity), HIPVerify is an institutional participant in the HIP ecosystem, not the protocol itself. The data-handling described in this policy is governed by HIPVerify's own institutional policy and applicable regulation, not by the HIP protocol specification. If HIPVerify's pathway operations are ever Suspended or Declassified per PATHWAY-SPEC-v1, alternative Tier 1 pathways operating under DP-5 may be established by other operators with their own data policies.

13. Operator and Successor Entity

HIPVerify is operated by Peter Rieveschl as an individual at the time of this update. The HIPVerify name, brand, and pathway-operator code are owned by the operator personally; the protocol-layer code at github.com/human-integrity-protocol/hip-protocol is published openly under its repository licenses.

If HIPVerify's pathway operations are assigned to a limited-liability company or other successor entity formed to hold them — for example, a U.S.-formed LLC at the time of public launch — the successor will be bound by this policy with respect to data already collected under it, and any change in the operator entity will be noted with an updated effective date at the top of this page. The successor entity name, when formed, will appear in this section. A superseding privacy policy, if any, will be published here before any new collection practices begin.

14. Sunset and Continuity

If HIPVerify's pathway operations are wound down or its operations are sunset, the data described in § 6 (Data Retention) will be handled as follows:

• Deduplication hashes and credential ID mappings. The HIP protocol's verification surface is designed to outlast any single pathway operator. Once the protocol's Steward Node tier is activated, deduplication hashes and credential ID mappings necessary for ongoing protocol-layer verification can be migrated to Steward Nodes for continued public verification. Until that tier is activated, HIPVerify will publish a final read-only snapshot of the necessary protocol-facing fields (deduplication hashes, credential IDs, tier labels, issuance timestamps) to a public archive (such as a GitHub release or an Internet Archive snapshot) before any wind-down completes.
• Stripe customer references, receipt emails, audit records. These will be deleted no earlier than thirty (30) days after wind-down notice and after a final accounting period sufficient to satisfy any refund obligations under the HIPVerify Terms of Service.
• Notice. A wind-down or operator-transfer notice will appear at hipverify.org and on the HIP Protocol GitHub repository at least thirty (30) days before any non-reversible step is taken. Any updated privacy policy that applies under a successor operator will be published here.

Note that deduplication hashes are inherent to the one-credential-per-human guarantee of the Tier 1 pathway. Continuity of the pathway across an operator transition or sunset event is therefore distinct from the right-to-deletion handling discussed in § 9 (Your Rights); a sunset cannot retroactively withdraw a credential previously issued under the pathway.

15. Changes to This Policy

We may update this policy from time to time. Material changes will be noted with an updated date at the top of this page.

16. Contact

For privacy-related questions or data deletion requests, contact us through the HIP Protocol GitHub repository.