Privacy policy
What TDACorp Identity collects about you, why it holds it, who else touches it, how long it is kept, and how to see, correct, export or remove it. Written against the code that runs rather than a policy kept separately from it.
On this page
Draft
Who we are
TDACorp Identity is operated by TDACorp Private Limited, a company incorporated in India on 17 July 2026. It is the shared sign-in, session, token and access-control service that TDACorp products use. TDACorp Private Limited decides why and how the personal data described on this page is processed, so for this platform it is the party responsible for that data. Where an organization invites you to an account, that organization has its own reasons for the invitation, and this page says so in the sections on lawful basis and organizations.
| Item | Statement |
|---|---|
| Operator | TDACorp Private Limited |
| Incorporation | 17 July 2026 |
| Last reviewed | 5 October 2026 |
| Lifecycle | Pre-production. Where a statement describes today only and not a launch commitment, it says so |
| Contact for privacy questions | security@tdacorp.in |
| Named data protection officer, grievance officer or representative | None is named in the repository, so none is named here |
Note
This is a plain-language notice written from the code. It is not legal advice, and the legal text of related pages is flagged as pending review by the owner.
What this notice covers
This notice covers your account, sessions and credentials on TDACorp Identity, and the same data processed on behalf of any TDACorp product that uses this platform to sign you in and enforce your permissions. It describes data the platform itself holds.
| In scope | Out of scope |
|---|---|
| Your account, profile, email addresses and credentials | tdacorp.in, TDACorp's marketing website, which has its own policy |
| Your sessions, devices and sign-in history | What a TDACorp product does with your data beyond authentication and permissions; that product has its own notice |
| Applications you connect through this platform, as to the consent and tokens held here | The vendors' own handling of data, which is described by those vendors; see the subprocessor list |
| Organization memberships and roles held here | Another organization's own records about you |
| Records of requests you make (export, deactivation) | Anything outside this platform |
Data inventory
The table lists every category of personal data the platform holds, what it is used for, where it sits, how long it stays and who else receives it. "Recipients" means parties beyond the operator: infrastructure vendors are named on the subprocessor page, and applications you sign in to receive only the claims in the scopes they request, and third-party applications only with your consent.
| Category | What it contains | Why we hold it | Where it is stored | Retention | Recipients |
|---|---|---|---|---|---|
| Identity and contact | One or more email addresses (each verified before use), display name, optional username, optional short bio, optional locale and time zone | To create and identify your account, to send security mail, to show your name in apps you authorize | Primary database | While the account exists; erased 30 days after deactivation | Database host; email provider receives the address when a message is sent; an application you sign in to receives the profile claims in the scopes it requests, and a third-party one only with your consent |
| Profile picture | An image (PNG, JPEG or WebP, at most 128 KiB) that you upload, or the picture a sign-in provider supplies when it creates your account | So an application you sign in to can show it | Primary database, served from a public address keyed to your account identifier | Until you remove it; erased at erasure | Anyone who has the address, which includes applications you sign in to |
| Password | A salted Argon2id hash, never the password | To check your sign-in | Primary database | While the credential exists; deleted at erasure | None |
| Passkey | The public key, a label, a signature counter and backup flags | To check your sign-in | Primary database | While the credential exists; deleted at erasure | None. The private key stays on your device |
| Authenticator and recovery codes | An encrypted authenticator secret; keyed hashes of recovery codes | Second factor and recovery | Primary database | While enrolled; deleted at erasure | None |
| Linked accounts | An issuer and subject pair and the email at link time, if you link Google or GitHub; when a provider creates your account it also supplies your display name and picture | To let you sign in through that provider | Primary database | While linked; deleted at erasure | The provider, as part of the sign-in you start |
| Session | Session identifier, the network address it started from, a hash of the browser user-agent, sign-in method, assurance level, timestamps, device reference | To keep you signed in and show you your sessions | Primary database | Network address set to empty after 90 days; the ended session row is deleted after 90 days | None |
| Session context | A label parsed from the user-agent (for example "Firefox on Linux"), country and city of the first request, and, only when an operator switches on an optional coarse-location setting (off in the production configuration), a coarse location grid cell of about 111 km | To show you where a session started and, when switched on, to recognise an unusual place | Primary database | While the account exists; deleted at erasure | None |
| Device | A random device key (in a cookie), a name you may set, a trust level | To recognise a browser and show your devices | Primary database | While the device is on your account; name emptied at erasure | None |
| Sign-in alert | Browser label, country, network address and method of a new sign-in, with a single-use token hash | To email you about a sign-in from a browser we have not seen or do not currently trust, or one admitted with less proof than normal | Primary database and the email in transit | Deleted when used or after 7 days | Email provider |
| Login and recovery transactions | Transaction state, identifier hash, risk score and signals, hashes of links | To complete a sign-in or recovery safely | Primary database | Login transaction 10 minutes; recovery link 15 minutes; completed or cancelled recovery rows deleted after 14 days | None |
| Audit log | Time, event kind, actor, target, organization, a hash and mask of any email, network address on some events | Security, investigation and integrity | Primary database | 8 years by default; no automatic pruning today | None |
| Consent records | Which third-party application you authorized and for which scopes | To remember your consent and let you revoke it | Primary database | Until revoked or erased | The application you authorized |
| Organization membership and roles | Which organizations you belong to, status and role bindings | To enforce what you may do in products | Primary database | While the membership exists | Products and organization administrators |
| Personal access tokens | A name, scopes, expiry, optional IP allowlist and a hash of the token | To authenticate scripts you create | Primary database | Up to 90 days; deleted at erasure | None |
| Applications you register | Client name, redirect addresses, key metadata | If you use developer features, which are off unless an operator enables them | Primary database | While the client exists | None |
| Notification preferences | Two settings, product updates and marketing email | To record your choice | Primary database | While the account exists; deleted at erasure | None |
| Requests you make | A record that you asked for an export or deactivation, and the export itself | To fulfil the request | Primary database | Export downloadable for 7 days, then deleted; the request record stays in the audit log | None |
| Outbound email | The recipient address and message text, sealed while queued, for link and recovery mail; a hash of the address stays on the finished row until it is purged | To deliver security and sign-in mail | Primary database, then the email provider | Finished queue rows are purged after 7 days | Email provider |
| Request log | Route pattern, method, status, duration, organization, client, a keyed hash of the caller, error class | Operations and abuse handling | Application log stream of the hosting platform | Governed by the hosting platform's log retention; the repository's plan notes record 1 hour on the current plan | Hosting provider |
| Browser crash reports | Error reports from your browser | Only when an operator turns the feature on, which is off by default | Not stored unless enabled | Not applicable while off | None |
Data we do not collect
| We do not | Detail |
|---|---|
| Use advertising or analytics cookies | None are set |
| Load third-party scripts, fonts or images | The pages are served with a policy that permits only this site's own scripts and styles |
| Profile you for advertising or behaviour | There is no such feature to opt out of |
| Collect your plaintext password | Only an Argon2id hash is stored |
| Send your password to a breach service | Only a five-character prefix of a SHA-1 digest of it leaves the system, never an account identifier or email address |
| Use SMS or phone numbers | No phone number is collected or used as a factor |
| Collect government identifiers, payment details or biometrics | None. A passkey biometric check happens on your device and is never sent to us |
| Collect your precise location | The platform stores country and city of a session's first request address, plus a roughly 111 km grid cell only when an operator switches on an optional coarse-location setting; only coarse values are kept |
| Use a third-party fraud-scoring service | None |
| Sell your data | The platform has no mechanism for it |
| Collect a date of birth | None is asked for |
| Store the raw user-agent text | A hash and a parsed label are stored |
Sources of data
| Source | What it supplies |
|---|---|
| You | Email, display name, optional profile fields, password, authenticator enrolment, passkeys, uploads, settings, requests |
| Your browser and network connection | Network address, user-agent, device cookie, country and city derived from the address, timestamps |
| An organization that invites you | Your email address and an optional role; the invitation is single use and valid 7 days |
| A sign-in provider you link | An issuer and subject, a verified email and, when the provider supplies them at sign-up, your display name and picture, if you use Google or GitHub, which is offered only when an operator registers a provider |
| An application you sign in to | The client identifier, requested scopes and redirect |
| Administrators of your organization or of the platform | Status changes, role bindings and support actions, each recorded in the audit log |
| A breach corpus | Only a yes or no on a hashed prefix lookup; no data about you is received |
| Earlier TDACorp identity platform | Accounts and credentials imported from the earlier generation, where an operator ran an import; imported password hashes of a weaker algorithm are never verified |
How we use data
| Use | Data involved | Notes |
|---|---|---|
| Authenticate you | Credentials, sessions, tokens | Server-side session lookup on every request |
| Keep you safe | Network address, device, attempt counters, risk score | See the section on automated decision making |
| Tell you about changes | Verified email addresses | Security alerts go to every verified address and cannot be turned off. They are best effort: a few kinds (blocked risky sign-ins, bursts of failed sign-ins) are rate-limited, and delivery depends on the email provider |
| Apply limits | Network address, identifier hash, device | Rate limits |
| Let you see and control your account | Sessions, devices, activity, connected apps, tokens | Account pages |
| Investigate a report or recovery request | Audit log, session records | By operators, recorded |
| Meet legal and integrity needs | Audit log and its chain | See retention |
| Run the service | Request log | Without credentials or addresses in the clear |
| Notify you of a breach if one occurs | Your email address | Workflow documented in the incident runbook |
We do not use your data for advertising or behavioural profiling. The platform stores two notification preferences, product updates and marketing email (marketing off by default); nothing in the platform sends product-update or marketing email today, and the preferences are stored, shown on your notifications page and included in your export.
Lawful basis and governing law
TDACorp Private Limited is an Indian company, and its own processing of your data is governed by Indian law, including the Digital Personal Data Protection Act, 2023. The repository documents the following basis for each way an account comes to exist; it documents no other.
| How the account was created | Documented basis |
|---|---|
| Self-registration | The agreement and acknowledgement shown beneath the registration form (no separate consent record is stored) |
| Invitation by an organization | The inviting organization's own basis for inviting you, recorded in the membership |
| Security logging | Operating the service and its integrity, with the audit log kept for the period in the retention schedule |
The repository's specification also names obligations such as reporting of cyber incidents to the national CERT within 6 hours and to the Data Protection Board within 72 hours for the classes it lists, and honouring erasure on withdrawal of consent. It tracks the phased dates of the 2025 rules as targets and does not treat their enforcement dates as a trigger. This page does not otherwise assert how any statute applies to TDACorp.
Sharing and subprocessors
Three infrastructure vendors are involved in running this platform: hosting, the primary database and transactional email. The subprocessor page is the single place to check them.
| Recipient | Role | What it sees |
|---|---|---|
| Vercel | Hosting and application infrastructure | Every request to this platform passes through it, and application logs go to it |
| Neon | Primary Postgres database | Every persistent record: accounts, credential hashes and sealed secrets, sessions, avatars, the audit log, exports while they exist |
| Resend | Transactional and security email | The recipient address and the text of each message: verification, sign-in and recovery links, the security alerts and other account notices |
| Applications you sign in to | Relying parties | The identifiers and profile claims in the scopes requested; third-party applications also need your consent, TDACorp's own products are not shown a consent screen |
| Organizations you belong to | Tenant administrators | Membership, role and status; support access windows are emailed to you |
| Have I Been Pwned | Breach corpus | A five-character hash prefix only; not a subprocessor because no personal data is sent |
| Law enforcement or regulators | On lawful demand | Not described anywhere in the repository, so no practice is claimed |
A disclosure to a third-party application you sign in to follows your consent, which you can review and revoke on the Connected apps page. Not on this list on purpose: cloud key management, a storage vendor, social sign-in vendors, analytics and advertising. This list changes when any of them is added.
International transfers
The platform specification places the primary database in India. The database provider has no Indian region, so for the pre-production period the owner has waived that placement, to be revisited before launch. The primary database is therefore not in India. The function runs in Vercel region iad1 (US East, N. Virginia) and the database is in Neon on AWS US East 1 (N. Virginia). This page makes no claim about where a vendor's staff or backups sit. Anchors of the audit chain, which contain only hashes, may be stored abroad according to the specification; none is published to an outside location in the committed configuration.
| Item | State |
|---|---|
| Primary database location | Neon, AWS US East 1 (N. Virginia). Not in India during pre-production; waived by the owner, to be revisited before launch |
| Backups | A nightly encrypted dump workflow is written and has not been run; the specification places backups in a second Indian region, which is not a claim about today |
| Email delivery | By the email provider; no region is declared in the repository |
| Hosting | By Vercel, function region iad1 (US East, N. Virginia), no failover |
| Transfer safeguards | None are described in the repository, so none are claimed |
Cookies and storage
Every cookie set by the platform is strictly part of signing you in or protecting the sign-in. There are no tracking, advertising or analytics cookies, and no analytics or third-party script is loaded. All cookies on the identity host carry the __Host- prefix, so they are Secure, have path / and have no Domain attribute, and all are HttpOnly with SameSite=Lax. The separate administrative console sets two cookies of its own, listed in the last rows.
| Name | Purpose | Lifetime | Holds personal data |
|---|---|---|---|
__Host-tdaid_sid | Keeps you signed in | Ends with the session: 12 hours idle or 14 days in total | A random secret; only its digest is stored |
__Host-tdaid_ltx | Tracks a sign-in in progress | At most 10 minutes | A transaction identifier |
__Host-tdaid_rdev | Set only when you start recovery, so a link works only in the browser that asked | 30 days | A random value |
__Host-device_id | Lets the account tell a browser it has seen from a new one | 400 days | A random value, not personal data |
__Host-tdaid_regb and __Host-tdaid_regv | Bind a registration code and verified link to the registering browser | 30 minutes for the binding cookie, 15 minutes for the verified-link cookie | Random values |
__Host-tdaid_fed | State of a federated sign-in in progress | 10 minutes | A signed state value |
__Host-tdaid_pk_offer | Remembers a passkey offer so it is not repeated | 7 days | A flag |
| Admin console session cookie | The separate administrative console | Up to 7 days, encrypted | Administrator sessions only |
| Admin console sign-in attempt cookie | State of an administrator sign-in in progress, cleared once used | 10 minutes, encrypted | Administrator sign-ins only |
SameSite=Lax is one layer of this platform's protection against cross-site request forgery; the other is a same-origin check on every request that changes state. Removing a device from your account page stops the account recognising its device cookie. The platform does not use local storage or session storage to hold personal data as part of its sign-in; clearing browser storage does not affect your account.
Retention schedule
The table gives the retention of each kind of record as the code enforces it. Background jobs run from a daily scheduled job and from ordinary traffic on the current hosting plan, so a deletion can run up to about a day later than its nominal time.
| Record | Nominal retention | Mechanism |
|---|---|---|
| Session cookie and session | 12 hours idle, 14 days absolute | Server-side expiry and revocation |
| Session network address | Set to empty after 90 days | Housekeeping job; the period is a setting with a default of 90 days |
| Ended session row | Deleted 90 days after it ended; the database refuses deletion sooner than 30 days after end or while an address remains | Housekeeping job |
| Ended OAuth token families and refresh tokens | Deleted after 90 days | Housekeeping job |
| Relying-party session records for logout | Deleted on the same 90-day cutoff as ended token families | Housekeeping job |
| Login transaction | 10 minutes of life, then swept | Expiry and sweep |
| Passkey challenge | 5 minutes | Expiry and sweep |
| Magic sign-in link | 15 minutes | Expiry and sweep |
| Email verification link and unverified address | 24 hours | Expiry and sweep |
| Unverified account created by registering | 24-hour claim; the empty account is swept after 48 hours | Housekeeping job |
| Recovery link | 15 minutes; held recovery can be re-opened for 7 days | Expiry and sweep |
| Completed or cancelled recovery request | Deleted after 14 days | Housekeeping job |
| Sign-in alert | Deleted when used or after 7 days | Expiry |
| Invitation | Valid 7 days, single use | The invited address is kept in the record afterwards; see below |
| Personal data export | Downloadable for 7 days, then deleted | Export worker |
| Queued outbound email | Finished rows purged after 7 days | Email queue |
| Settled event outbox rows | Kept 30 days for operator inspection | Housekeeping job |
| Rate-limit counters | Deleted after 7 days idle | Housekeeping job |
| Audit log | 2,920 days (8 years) by default, within a configurable range of 365 to 3,650 days with a floor of 2,920 days for TDACorp's own organization | Compaction exists but is off unless an operator enables it, so records are currently retained without automatic pruning |
| Activity page window | The most recent 90 days of your own events | Display window only |
| Deactivated account | Personal data erased 30 days after deactivation | Hourly worker, subject to scheduling lateness |
| Account that remains active | No automatic deletion timer applies to your own profile, credentials and consents; they persist as long as the account | Not applicable |
What erasure removes and what it keeps
Deleting your account deactivates it at once: every session, token and personal access token is revoked and you cannot sign in again. Thirty days later a background job erases your personal data.
| Erased | Kept, and why |
|---|---|
| Profile (name, username, bio, locale, time zone) | The account identifier, an opaque value, so the audit chain stays intact |
| Email addresses | The audit log's events about the account, which reference identifiers and hashes rather than names or addresses; not every event kind has been audited for this |
| Credentials: password, passkeys, authenticator, recovery codes, linked accounts | The network address and user-agent hash of past sessions: the record they sit in cannot be edited after the fact. The address is set to empty by the retention job after 90 days; the user-agent hash is kept until that session row is deleted |
| Stored exports | The address an invitation was sent to: that table refuses edits and deletes, so it remains. This is recorded as a gap needing an owner decision |
| Profile picture and notification preferences | Consent and membership records, which reference your opaque identifier and not your name |
| Session context labels (browser label, country, city, grid cell) and sign-in alert records | Device rows, with the name and device reference emptied, because past sessions refer to them |
| Personal access tokens | A break-glass credential row, only if one was ever referenced by an activation record, which is kept with its label emptied and its status revoked |
Erasure is not total, and this page states that rather than hiding it. Whether to change any of these retentions is an open owner decision.
Your rights and how to exercise them
You can see, correct, export and remove most of your data yourself, signed in. Each of these acts on the requester's own account only, which is why they require being signed in. If you cannot sign in, or need something these pages do not cover, email security@tdacorp.in; the response time for such a request is not promised here.
| Right | What you can do | Where in the product | Notes |
|---|---|---|---|
| Access and export | Request a copy of your account data; download JSON, CSV and a signature | Account, Privacy and data | Needs a fresh second factor. The export covers principal, profile, notification preferences, emails, credential metadata, linked accounts, devices, sessions, active consents, memberships and your own audit events. Each list is capped and a "truncated" section says which. Downloadable 7 days; sealed with a per-file key while stored |
| Correction | Edit display name, username, bio, locale, time zone, profile picture and email addresses; make an address primary, verify it, remove it | Account, Profile | Changing the primary address needs a fresh second factor; the old address is emailed a 24-hour link that reverts the change |
| Deletion | Deactivate the account, then personal data is erased after 30 days | Account, Privacy and data | A typed phrase and a fresh second factor are required; you cannot reactivate it yourself. Erasure is not total, as set out above |
| Withdraw consent or object to an application | Review and revoke a connected third-party application | Account, Connected apps | Revoking ends the consent and the tokens for that application |
| Objection to marketing | Turn off product updates and marketing email | Account, Notifications | Marketing is off by default and nothing sends it today |
| Control of sessions and devices | Review and revoke sessions, sign out everywhere, trust or remove devices | Account, Sessions | |
| Visibility of events | See your own security events for the last 90 days | Account, Activity | |
| Personal access tokens | List, create, rename and revoke | Account, Access tokens | Step-up required to create or revoke |
| Organizations | See memberships and leave an organization | Account, Organizations | |
| Portability | The JSON and CSV export | Account, Privacy and data | Machine-readable; the signature lets you verify the file offline |
| Restriction | No self-service control. Deactivate the account, or write to the contact address | Not a built feature | |
| Complaint | The repository names no complaint channel beyond the contact address and does not state a regulator process | Not described, so not claimed |
Children
TDACorp Identity is not designed for children. No date of birth is collected, and the repository documents no age check and no parental consent flow. If you believe a child has registered, contact security@tdacorp.in. The platform specification tracks the children's-data provisions of the 2023 Act as not expected to apply to an enterprise identity service; that is a design note, not a legal conclusion.
Security of data
The security practices page is the full account. In summary:
| Measure | Detail |
|---|---|
| Passwords | Argon2id at 64 MiB, 3 passes and 4 lanes |
| Secrets that must be recoverable | Sealed with AES-256-GCM under purpose-specific data keys |
| Session, token and code secrets | Stored as digests |
| Transport | HTTPS with HSTS (two years); application cookies are Secure and host-locked |
| Access | Row-level security on organization data; a fenced platform role with an audit row for every use |
| Logging | A closed list of non-personal fields; no credentials, cookies or raw addresses |
| Keys in pre-production | A software provider rather than a cloud KMS; database plus master key could open sealed secrets, as the security page states |
| Breach handling | An incident runbook with notification steps; no certified process |
No system is unbreakable, and this page does not claim one is.
Automated decision making
At the end of every sign-in a risk engine assesses the attempt and decides to allow it, to ask for a stronger factor, or to refuse it. It is a rule-based score, not a machine-learning model.
| Item | Detail |
|---|---|
| Inputs | Signals about the sign-in attempt, such as whether the browser is familiar, where it comes from and how it compares with recent attempts |
| Outcomes | A sign-in is allowed, asked for a stronger factor, or refused |
| Effect on you | A sign-in can be refused or made to ask for more proof. It does not set prices, rank you or affect anything outside signing in |
| Record | The score and signals are stored with the sign-in transaction and audited |
| Human review | There is no formal appeal process described in the repository. If a sign-in is refused wrongly, use recovery or write to the contact address |
| Pending owner decision | Whether an account with no second factor is admitted and alerted, rather than refused, on an unrecognised browser; staging currently admits and alerts |
Changes to this policy
This policy is revised as the product changes, not on a fixed schedule. The date at the top of every trust page, "Last reviewed", is updated when the text is reconciled against the code, and the figures on the pages are pinned to the code by tests so they cannot silently drift. The repository states no commitment to notify you individually of a change, so none is made here.
Contact
Email security@tdacorp.in. The same address is published in the machine-readable security.txt file. No postal address, telephone number or named officer is stated here because none is recorded in the repository.
What this page does not claim
- This is not legal advice, and not a substitute for it.
- TDACorp holds no privacy or security certification (no SOC 2, no ISO 27001) and offers no uptime guarantee.
- The primary database is not in India during pre-production; the placement the specification calls for was waived by the owner for this period and is to be revisited before launch. The database is in AWS US East 1 (N. Virginia).
- It does not cover a product built on this platform beyond authentication and permissions: that product is responsible for its own data and its own notice.
- It does not cover tdacorp.in, whose privacy policy is a separate document.
- Erasure is not total: a past session's user-agent hash, the address an invitation was sent to, device rows and audit events keyed by an account identifier remain, as set out above. Whether to change that is an open owner decision.
- Audit records are currently retained without automatic pruning.
- Background jobs, including exports and erasure, can run up to about a day late on the current hosting plan.
- The retention of application logs held by the hosting provider is that provider's and can change with its plan; this page does not guarantee it.
- No data protection officer, grievance officer or Indian representative is named, no response time to a rights request is promised, and no complaint procedure is described.
- No statement is made that any particular statute does or does not apply beyond the documentation already in the repository.
- No transfer safeguard, standard contractual clause or adequacy finding is claimed for any vendor.
- The platform does not guarantee that a vendor on the subprocessor page handles your data as this page does; the vendors' own terms govern them.