Trust centre
What TDACorp Identity is, who runs it, what it protects, what it does with your data, and where every claim can be checked. It is pre-production, and every page says so.
On this page
Draft
About this trust centre
This is the index of the public trust documents for TDACorp Identity. Each document is written against the code that runs, not against a policy kept separately from it, and each one ends with a list of what it does not claim.
Note
TDACorp Identity is in pre-production. It is not yet serving the general public. Every statement in these documents describes behaviour that exists today, and anything planned or unbuilt is labelled as such. Nothing here is a roadmap.
Note
Every trust page currently carries a draft banner in the product: "This page is pending owner review. TDACorp has not approved it, and it is not yet a statement of TDACorp policy." The banner stays until the owner approves each page. Read the pages as an accurate description of the code, not as approved policy.
Last reviewed 5 October 2026.
What TDACorp Identity is
TDACorp Identity is the shared authentication and authorization platform behind TDACorp products. It does four jobs.
| Job | What it means in practice |
|---|---|
| Prove who you are | Sign-in with a passkey, a password, a one-time email link, or a second factor (authenticator app or recovery code). |
| Keep you signed in | Server-side sessions, held in the database, that can be listed and revoked by you. |
| Tell applications who you are | An OAuth 2.0 and OpenID Connect provider that issues short-lived tokens to registered applications. |
| Decide what you may do | An authorization service that applications ask for permission decisions, so each product does not build its own. |
It is a platform, not a product you use on its own. A product built on it decides why an account exists and what it does with the account beyond signing in. That product is responsible for its own data and its own notice.
What it does not do
| Not in scope | Why it matters |
|---|---|
| Sell, share or monetise account data | There is no advertising, analytics or behavioural-profiling feature to opt out of. |
| Sign you in with Google, GitHub or another social provider | Not offered today, so no such vendor is involved. |
| Cover tdacorp.in, the marketing website | The website has its own policy and terms. |
| Cover other TDACorp products beyond sign-in and permissions | Each product has its own terms and notice that apply in addition. |
Who operates it
| Fact | Value | Where it comes from |
|---|---|---|
| Operator | TDACorp Private Limited | Platform deployment configuration |
| Country of operation | India | Privacy policy |
| Incorporated | 17 July 2026 | The only date this centre asserts about the company |
| Governing law for TDACorp's own processing | Laws of India, including the Digital Personal Data Protection Act, 2023 | Privacy policy and terms |
| Hosting | Vercel | Subprocessors page |
| Primary database | Neon (Postgres) | Subprocessors page |
| Transactional email | Resend | Subprocessors page |
| Security contact | security@tdacorp.in | /.well-known/security.txt |
The platform is written and maintained by the same small team that publishes these pages. No outside party has verified the statements here.
Status: pre-production
Pre-production is a specific condition, not a polite word. It changes what you can rely on.
| Area | Pre-production fact |
|---|---|
| Users | The platform is not yet serving the general public. |
| Service level | No uptime guarantee and no service level agreement exists. The terms say the service is provided as-is and may change or be reset. |
| Key management | Encryption and token-signing keys are held by a software key provider, not a cloud key-management service or a hardware module. See security practices. |
| Data placement | The primary database is not in India. The specification places it there and the database provider has no Indian region, so the owner waived the placement for pre-production, to be revisited before launch. The function runs in Vercel region iad1 (US East, N. Virginia) and the database is in Neon on AWS US East 1 (N. Virginia). |
| Background jobs | Exports, erasure, key rotation and webhook delivery are driven by a daily scheduled job and by ordinary traffic on the current hosting plan, so they can run up to about a day late. |
| Approval | The trust pages are drafts pending owner review. |
| Certifications | None held. See the certifications table below. |
| Observability | Service level objectives are written down in the repository, but only part of the metric set they depend on is emitted. They are internal targets and not a commitment to you. |
Documents index
| Document | What it covers | Link |
|---|---|---|
| Overview (this page) | What the platform is, status, at-a-glance tables, how to verify claims, contacts | You are here |
| Security practices | Passwords, breached-password checks, sessions, refresh tokens, passkeys, second factors, step-up, secrets at rest, abuse limits, page hardening, audit log, alerts | Security |
| Vulnerability disclosure | How to report, scope, testing rules, response intentions, safe harbour, credit | Disclosure |
| Privacy policy | What is collected, why, who else touches it, cookies, retention, your rights | Privacy |
| Cookies | The cookies the platform sets and what each does | Cookies |
| Data retention | How long each category of data is kept | Retention |
| Terms of service | Your account, acceptable use, termination, availability, liability, governing law | Terms |
| Data processing addendum | Roles, what is processed, retention, rights, written in the shape of a DPA | Data processing |
| Subprocessors | Every third party that receives or stores data | Subprocessors |
| Incident response | How a security incident is handled | Incident response |
| Accessibility | Scope, what is tested, keyboard and focus behaviour, known limitations | Accessibility |
Note
The in-product trust navigation lists every page in this set: overview, security, disclosure, privacy, cookies, retention, terms, data processing, subprocessors, incident response and accessibility.
Security at a glance
Every number below is pinned in the platform's own code, and a test fails the build if the copy on the trust pages stops matching the source. The full description is in security practices.
| Control | What it is | Where detailed |
|---|---|---|
| Password hashing | Argon2id at 64 MiB memory, 3 passes, 4 lanes, random salt per hash, parameters recorded with each hash and upgraded at next successful sign-in | Security |
| Breached-password check | Have I Been Pwned range API: only the first five hex characters of a SHA-1 digest leave the system, padded responses. Each successful password sign-in rechecks the password in the background | Security |
| Passkeys | WebAuthn with user verification required, single-use short-lived challenges, signature counter comparison to detect cloned authenticators | Security |
| Authenticator codes | Time-based, single-use (matched time step recorded), secret stored encrypted | Security |
| Recovery codes | Batches of 10, single-use, stored only as keyed hashes (HMAC-SHA256) | Security |
| Step-up | Sensitive actions ask for a passkey or authenticator code again; proof is good for 10 minutes | Security |
| Sessions | Cookie __Host-tdaid_sid: HttpOnly, Secure, SameSite=Lax, no Domain attribute; only a SHA-256 digest is stored; ends after 12 hours idle or 14 days in total | Security |
| Access tokens | At most 15 minutes, a single audience, sender-constrained to a key the client holds unless the client is a first-party web application | Security |
| Refresh tokens | Rotate on every use; replay after a 10-second retry window revokes the whole family and its session | Security |
| Secrets at rest | Recoverable secrets sealed with AES-256-GCM under wrapped data keys; passwords, session secrets and tokens kept only as one-way hashes | Security |
| Rate limiting | Rate limits on sign-in, recovery, token and API endpoints; a refused request receives HTTP 429 with a Retry-After header | Security |
| Page hardening | Content security policy with per-response script nonce, no framing, no referrer, no sniffing, same-origin check on state-changing requests, no third-party scripts, fonts or images | Security |
| Audit log | Append-only, each row chained to the previous by a hash | Security |
| Account alerts | Email on password, passkey, authenticator, recovery-code, token, email, device-trust, session sign-out, export, deactivation and recovery events, on detected refresh-token reuse, on a blocked risky sign-in and on a burst of failed sign-in attempts. The last two are throttled per account | Security |
| Disclosure | Reports to security@tdacorp.in, published per RFC 9116 | Disclosure |
Security gaps stated openly
| Gap | Current state |
|---|---|
| Key management | Software provider in pre-production. Anyone who obtained both the database and the master key could forge tokens and read wrapped secrets until keys were rotated. Replacing the master key and the data keys is an operator command (idctl deks), not a scheduled job, and rotating a data key rewrites no stored secrets, so authenticator secrets stay under the old data key until they are re-enrolled. |
| Alerts for events you did not cause | The alerts for a blocked risky sign-in and for a burst of failed attempts are rate limited per account, so a repeated event may send no further email for a while. |
| Failed-attempt lockout | Repeated failures are throttled, with no permanent lockout. |
| Breached-password recheck | The recheck runs only when you sign in with the password, in the background. A password nobody signs in with again is not rechecked, and a breach found is shown in Activity, not emailed. |
| Audit anchoring | A scheduled anchoring job and an offline verification command (idctl anchor verify) are built. The scheduled job is off by default and is not enabled in the production configuration, so anchors are currently published by an operator command. |
| Audit pruning | Compaction is built but switched off by default and not enabled in the production configuration, so audit records are currently retained indefinitely. |
| Configurable session and step-up windows | Settings exist in the directory model but no runtime path reads them yet, so the defaults above apply to every session. |
Data handling at a glance
The full picture is in the privacy policy, the retention page and the data processing addendum.
| Data | How it is stored | Retention |
|---|---|---|
| Email addresses and display name | In the primary database. Each address is verified before use | Until the account is erased |
| Profile picture (optional) | PNG, JPEG or WebP as a database row, served from a public address keyed to your account identifier | Until the account is erased |
| Password | Salted Argon2id hash only | Until the account is erased or the password is replaced |
| Passkey | Public key only. The private key never leaves your device | Until you remove it or the account is erased |
| Authenticator secret | Encrypted | Until you remove it or the account is erased |
| Recovery codes | Keyed hashes only | Until used, regenerated or the account is erased |
| Sessions | Network address, hash of the browser user-agent, a label parsed from it, country of the address, how you signed in, times active | Session ends after 12 hours idle or 14 days in total. The network address is cleared 90 days after the session starts, and an ended session is deleted 90 days after it ends unless another record still refers to it |
| Devices | Name and trust level you can change, linked to the __Host-device_id cookie | The cookie lasts 400 days. Removing a device stops the account recognising it |
| Sign-in alert records | Label, country, address and method of a sign-in from a new browser | Deleted when used or after 7 days |
| Magic sign-in links | One-time links | Valid for 15 minutes |
| Personal access tokens | Stored as a hash. The raw token is shown once | Until revoked |
| Consent records and organization memberships | In the primary database | Until revoked or the account is erased |
| Audit log | Chained rows referencing identifiers and hashes | 8 years (2,920 days) by default, 365 to 3,650 days configurable for other organizations. Pruning is built but off by default and not enabled in production, so nothing is pruned today |
| Personal-data export | Signed JSON (authoritative) and CSV, stored in the primary database encrypted with AES-256-GCM under a per-file key wrapped by the key provider | Downloadable for 7 days, then deleted by a background job |
| Account deletion | Deactivated at once: every session and token revoked | Personal data erased 30 days after deactivation by a background job |
Note
Erasure is not total. The user-agent hash of past sessions (and their network address until it is cleared 90 days after the session starts), and the address an invitation was sent to, are kept because the records they sit in cannot be edited after the fact. The audit log keeps the account identifier and events so its integrity chain stays intact. Whether to change this is an open owner decision.
Cookies
| Cookie | Purpose | Lifetime |
|---|---|---|
__Host-tdaid_sid | Keeps you signed in | Ends with the session: 12 hours idle or 14 days in total |
__Host-tdaid_ltx | Tracks a sign-in in progress | At most 10 minutes |
__Host-tdaid_rdev | Set only when you start account recovery, so a recovery link works only in the browser that asked for it | 30 days |
__Host-device_id | Lets the account tell a seen browser from a new one and show your devices. Holds a random value | 400 days |
__Host-tdaid_regb and __Host-tdaid_regv | Set only during self-registration, which is off unless configured: they tie the emailed code or link to the browser that registered | 30 minutes and the remaining life of the link |
__Host-tdaid_pk_offer | Set only when the optional passkey offer is switched on, so the offer is made at most once every 7 days per browser | 7 days |
There are no tracking, advertising or analytics cookies, and no analytics or third-party script is loaded on any page the platform serves.
Certifications and audits
TDACorp holds no security or privacy certification and has not commissioned an outside audit. The table is explicit so that nothing is implied by silence.
| Assurance | Status | What is done instead |
|---|---|---|
| SOC 2 report | Not held | Behaviour is described against the source, and a repository test fails the build when numbers on the trust pages drift from the code |
| ISO 27001 certificate | Not held | The platform specification, a threat model and a final security audit are kept in the repository as working documents |
| Independent penetration test | Not held, none commissioned | An automated end-to-end suite, a security-test register gate, and an internal security audit by the team that maintains the code |
| Third-party security audit | Not held | The vulnerability disclosure channel is open to outside researchers |
| Privacy certification | Not held | The privacy policy and addendum describe current practice |
| Uptime guarantee or SLA | None offered | Internal service level objectives exist in the repository, but they are not a commitment and not all of their metrics are emitted yet |
| Bug bounty | None. No reward budget exists | Credit is offered if you ask for it, never by default |
| Signed data processing agreement | Not published | The addendum describes current practice. A signed agreement is a conversation with TDACorp directly |
How to verify these claims
You do not need to take this page on trust. These are the ways to check it.
| What to check | How |
|---|---|
| Who to report a security problem to | Open /.well-known/security.txt. It is served unauthenticated in the RFC 9116 format, lists the contact, the canonical address, the policy URL and an expiry, and deliberately lists no encryption key because TDACorp publishes none |
| That a number on a trust page matches the code | The trust pages quote one facts module, and a test reads each source file and fails when a value there stops matching. The facts are Argon2id parameters, session lifetimes, step-up window, recovery code count, refresh grace, access-token lifetime, cookie lifetimes, export window, erasure delay and audit retention |
| What happened on your account | Open Activity in your account. It lists security events from the last 90 days, newest first, each marked Routine, Review or Review now |
| What is signed in as you | Open Sessions in your account to see every session and device, and revoke any or all |
| Which applications can act for you | Open Connected apps to review and revoke each |
| What data is held about you | Request an export from Privacy and data. You receive a signed JSON file of your profile, email addresses, credential metadata (never secrets), sessions, consents, memberships and your own audit events, plus a CSV whose hash is signed in the JSON |
| What the page hardening actually does | Inspect the response headers of any page in your browser developer tools. The content security policy is delivered with the response |
| That nobody is tracking you | Inspect the network panel. No analytics or third-party script is requested |
| That email alerts really arrive | Perform a change such as renaming a passkey and watch for the alert email |
Note
The signed export lets you check that a file was produced by this platform. If the signing key rotates before you download, the file would not verify, so the page says so and asks you to request a new export.
Responsibilities
Security here is shared. Neither side can do the other's part.
| What we do | What you do |
|---|---|
| Store passwords only as Argon2id hashes and secrets only encrypted or hashed | Choose a password that is not reused elsewhere, and keep it private |
| Check new passwords against a breach corpus without sending the password | Add a passkey or an authenticator app, and keep your recovery codes somewhere safe |
| Rate limit sign-in and recovery | Do not share your credentials or your account with anyone else |
| Revoke sessions and tokens when you ask, or when token theft is detected | Review Sessions, Connected apps and Activity from time to time |
| Email you about the account changes listed in the security practices | Keep your email address current, and keep your mailbox secure. If an attacker reads your email, they can start account recovery by design |
| Keep an append-only audit log | Report anything suspicious to security@tdacorp.in |
| Acknowledge good-faith research under the disclosure policy | Test only against accounts you created yourself |
| State plainly what is not claimed | Read the terms. You are responsible for activity under your account |
Frequently asked questions
Where is my data?
In a Postgres database run by Neon, behind an application hosted by Vercel. The primary database is not in India during pre-production. The specification places it there, but the provider has no Indian region, so the owner waived the placement for this period. The function runs in Vercel region iad1 (US East, N. Virginia) and the database is in Neon on AWS US East 1 (N. Virginia).
Can you read my password?
No. A password is stored only as a salted Argon2id hash, with the parameters recorded alongside. The sign-in flow does not reveal whether an address has an account, and a password is never stored in a form anyone can reverse. A person with access to the database could still try to guess passwords against a hash, which is why the hash is deliberately costly (64 MiB, 3 passes, 4 lanes) and why a strong, unique password still matters.
Do you check my password against breaches? Does that leak it?
Yes, when you register, set or change a password, accept an invitation or finish recovery. Only the first five hexadecimal characters of a SHA-1 digest of the password leave the system, with a padded response, and no email address or account identifier is sent.
How do I delete my account?
Go to Privacy and data in your account and use Deactivate your account. You type "delete my account" to confirm, and the action needs a recent second-factor check. Deactivation is immediate and permanent: every session, token and personal access token is revoked and you cannot sign in again. Your personal data is erased by a background job 30 days after deactivation, and that job can run up to about a day late.
Is deletion complete?
Not entirely. Session user-agent hashes (and network addresses until they are cleared 90 days after the session starts), the address an invitation was sent to, and the audit log's identifiers and events remain, because those records cannot be edited without breaking their integrity. The audit log is designed to reference identifiers and hashes rather than names or email addresses, but not every event kind has been audited for that. Changing this is an open owner decision.
What happens if I lose my passkey?
If you have another passkey, use it. If you have an authenticator app or recovery codes, use those. Recovery codes come in batches of 10 and each works once. If you have none of them, start account recovery from the sign-in page. The recovery link is emailed to you and works only in the browser that asked for it, because a short-lived recovery cookie ties the two together. A cancel link is also sent, so a recovery you did not ask for can be stopped, and alerts are sent when recovery starts, is cancelled or finishes.
Can I sign in without a password?
Yes. Passkeys, and one-time email links valid for 15 minutes, are both supported. A passkey sign-in requires user verification on your authenticator, so it is multi-factor and phishing-resistant by itself.
Do you sell my data?
No. The data is held to deliver the service (signing you in, keeping your session, enforcing permissions) and for security (recognising a suspicious sign-in, rate limiting abuse, investigating a recovery request). It is not used for advertising or behavioural profiling, and there is no such feature to opt out of. The only third parties involved are the three infrastructure vendors on the subprocessors page.
Which apps can access my account?
Open Connected apps in your account. It lists the applications you have consented to and lets you revoke each, which revokes its access. A third-party application's refresh tokens also carry an absolute lifetime of at most 30 days.
Who else sees my data?
Vercel runs the application, so every request passes through it. Neon holds every persistent record. Resend receives the recipient address and the text of each email the platform sends. Nothing else receives personal data. The breach-check service receives a five-character hash prefix, which identifies no one. No cloud key-management vendor is involved, and no social sign-in or bot-detection vendor.
How long are my sessions?
A session ends after 12 hours idle or 14 days in total, whichever comes first. These are fixed defaults. An organization-level setting exists in the model but no runtime path reads it yet.
Can I see where I am signed in?
Yes. Sessions lists each session and device, with a label parsed from the browser (for example "Firefox on Linux"), the country of the network address and how you signed in. You can revoke one or all. Revocation takes effect on the next request, because every account request looks the session up in the database.
Will you tell me if someone signs in from a new device?
Yes. Signing in from a browser the account has not seen queues an email to your verified addresses with the label, country, network address and method. Alerts for events you did not cause yourself are also sent: detected token reuse, a blocked risky sign-in and a burst of failed attempts. The last two are rate limited per account.
Can I download my data?
Yes. Request a data export from Privacy and data. It is prepared automatically, normally within 24 hours, you are emailed when it is ready, and it can be downloaded for 7 days. Requesting and downloading need a recent second factor. The export is stored in the platform database encrypted with AES-256-GCM, under a per-file key wrapped by the key provider, and is decrypted when you download it.
Do you use tracking or analytics?
No. There are no tracking, advertising or analytics cookies, and no analytics or third-party script, font or image is loaded on any page the platform serves. The content security policy only permits the site's own scripts and styles.
Is the platform certified or audited?
No. There is no SOC 2 report, no ISO 27001 certificate, no independent penetration test and no third-party audit. See the certifications table above for what is done instead.
Is there an uptime guarantee?
No. The terms state the service is provided as-is, and no service level agreement exists.
I found a security problem. What do I do?
Email security@tdacorp.in with the URL, the steps, what an attacker gains, the time in UTC and anything you captured. The disclosure policy sets out scope, testing rules and safe harbour. TDACorp pays no bounty, publishes no PGP key and asks for ninety days before any public write-up.
Is the site accessible?
The sign-in, registration, recovery, account and trust pages are scanned with an automated accessibility checker against WCAG 2.2 AA in an end-to-end suite. Automated checks do not cover everything, and some manual checks are still owed. The accessibility statement lists them.
Is it safe to build my product on this?
That is a decision for you, not a claim these pages make. Read the security practices, the gaps stated above, the subprocessor list and the addendum. Note that a product built on the platform enforces its own authorization in its own database, and that pre-production means no uptime guarantee and a software key provider.
Contacts
| For | Contact | Notes |
|---|---|---|
| Report a vulnerability | security@tdacorp.in | Published in security.txt. Intentions, not contractual response times. Preferred language English |
| Privacy questions, or a request you cannot make while signed in | security@tdacorp.in | The same address is the published contact for the privacy policy, terms and addendum |
| A suspected compromise of your own account | Your account first, then security@tdacorp.in | Revoke sessions, check Activity and change credentials yourself, then write if something cannot be undone |
| A signed data processing agreement | security@tdacorp.in | A conversation with TDACorp directly |
| Accessibility problems | security@tdacorp.in | See the accessibility statement |
Note
The platform currently publishes a single contact address for every purpose. There is no separate privacy, legal or support mailbox, and no postal address is published on these pages.
Changelog
| Date | Document | Change |
|---|---|---|
| 5 October 2026 | All documents | Initial publication of this set, reconciled against the code. Last reviewed 5 October 2026 |
The review date is updated when the copy is reviewed, not when a fact changes silently. Because every figure is quoted from one facts module guarded by a test, a figure that changes in code fails the build until the copy is reconciled.
What this page does not claim
| Not claimed | Detail |
|---|---|
| Certification | No SOC 2, ISO 27001 or privacy certification, and no third-party audit |
| Approval | These pages are drafts pending owner review and are not yet a statement of TDACorp policy |
| External verification | No outside party has verified any statement. They are written by the team that maintains the code |
| Availability | No uptime guarantee and no service level agreement |
| Legal advice | None of this is legal advice or a contract. A specific agreement is a conversation with TDACorp |
| Data location | No region is declared for the vendors other than hosting and database, and the primary database is not in India during pre-production |
| Strength of key management | A software key provider is weaker than the production design, which calls for a real key-management service |
| Completeness of erasure | Some records survive erasure by design, as described above |
| Breach notification | No commitment beyond what applicable law requires |
| Invulnerability | This is not a threat model or a penetration test report, and it is not a claim that the platform is unbreakable |
| Other products | It does not cover tdacorp.in or any product built on the platform beyond sign-in and permissions |
| Future features | Anything unbuilt or switched off, such as audit pruning or the scheduled audit anchoring job, is stated as such |
The disclosure policy exists because we expect to be wrong somewhere. If you have found where, tell us at security@tdacorp.in.