GPlatform SSO data processing annex

When this applies

This annex supplements the data processing agreement and applies where an organisation or an enterprise ("you") uses GPlatform SSO for its own people: to hold them in a directory, to invite them, to give them access to products with a role, to set rules for how they sign in, to run service accounts, and, as an enterprise, to claim domains and manage the accounts on them. Where the annex is silent, the data processing agreement applies, and the GPlatform SSO terms describe how the service works. GPlatform SSO runs at sso.gplatform.org.

Where the line runs. Each person's own account is not yours: their addresses, credentials, passkeys, linked providers, sessions, the protection of their sign-in, our audit log and our mail log are ours, as controller, and the privacy notice tells them so. What you record about your people in GPlatform SSO is yours, and for that we are your processor. The one exception is an enterprise that manages its people's accounts: for the accounts it manages, we process the account itself on its instructions as well.

Subject matter and duration

Running your directory in GPlatform SSO and signing your people in to the products you give them, for as long as your organisation or enterprise exists in GPlatform SSO, and then until the deletion described below.

Nature and purpose

• holding your members, their roles and your teams, and showing them to your owners and admins;
• sending the invitations you issue, and admitting the people who accept them;
• telling the products you give your people what they need to sign them in: who the person is to that product, their name and primary confirmed address, your organisation, their role in it, their teams and the role you gave them in that product;
• applying the rules you set when your people sign in;
• running the service accounts you make, and the tokens they use;
• showing your owners and admins your organisation's activity;
• ending access when you remove somebody or close the organisation, so that the products concerned stop admitting them;
• for an enterprise: checking the domains it claims, telling it when an address on a proven domain is confirmed, and carrying out on the accounts it manages what it decides.

Your instructions

Your instructions are this annex, the data processing agreement, and what your owners and admins do in the GPlatform SSO console. Where you ask us to act for you, for example to set up an enterprise, to place an organisation in it or to enrol one of your applications, we act on a documented request from you, and the act is recorded with its reason. If we believe an instruction infringes data protection law, we tell you and do not carry it out until it is confirmed or changed.

Categories of data subject

• your members, in every role: owner, admin, member, billing and auditor;
• people you invite, including people who do not yet have an account;
• people in your teams and people you give access to a product;
• the people who make your service accounts;
• for an enterprise: people who confirm an address on a domain it has proven, and people whose accounts it manages.

Categories of personal data

Your directory: each member's account reference, display name and primary confirmed address as your owners and admins see them, their role, their teams, and when they joined.

Invitations: the address invited, the role offered, who sent it, and when it was sent, accepted, withdrawn or expired.

Access: which product, which role, and whether given by name, through a team or to the whole organisation; the role sets and rules you define.

Service accounts: name, description, who made it, and for each token its last four characters, its expiry, who made it and when it was last used. The token itself is stored only as a hash.

Your activity view: 90 days of what happened in your organisation, who did it and when. It never shows the IP address or the country, which stay in our own audit log.

What the products you grant are told: the identifier each product knows a person by, their display name and primary confirmed address, and the membership facts listed above.

For an enterprise: the domains it claims, the result of each proof check and the first 200 characters of what came back; a notice naming the account and the domain when an address on a proven domain is confirmed; and, for accounts it manages, the account itself and the state of its credentials, never a password, a recovery code or an authenticator secret.

No special categories of personal data are processed.

Processing operations

Receipt, storage, display to your owners and admins, transmission to the products you grant through the session protocol and through OpenID Connect, sending invitations by mail, checking domain proofs every 15 minutes by fetching a file from your web server and looking up a DNS record, signed notices to products that access has ended (carrying only the identifier the product knows the person by), enforcement of your rules at sign-in, restriction and deletion.

Your own applications. Where we enrol an application of yours as an OpenID Connect client, each person is asked on a consent screen before it learns who they are, and the application receives what they agree to. What your application does with it is your responsibility, outside this annex.

Sub-processors

• IONOS SE, Elgendorfer Straße 57, 56410 Montabaur, Germany: the server in Germany on which GPlatform SSO, its database and our own mail server (Stalwart) run.
• Sentry (Functional Software, Inc.), on its EU data region: error reports, configured to receive no user identifier, cookie, header, request body, query string or value of a local variable. The data is stored in the EU; the company is based in the United States, so access from there cannot be ruled out, and it is covered by the EU standard contractual clauses in Sentry's data processing agreement.

Our own hardware in Germany holds the key that signs every token and our encrypted backups, and is reached over an encrypted WireGuard tunnel. You are told before a new sub-processor is engaged and may object, as the data processing agreement sets out.

Where the processing takes place

In Germany. The one exception is the access to error reports from the United States that cannot be ruled out for Sentry, described above.

Technical and organisational measures

Credentials and secrets. Passwords are stored as argon2id hashes, with at least 12 characters. Authenticator secrets are encrypted (AES-256-GCM). Session tokens, the codes in our letters, invitation tokens, application secrets, service account tokens and personal access tokens are stored only as SHA-256 hashes, and every token is shown once. The key that signs every OpenID Connect token is held in HashiCorp Vault, made there and never exported; the service refuses to start in production with a key held on disk.

Sessions and revocation. Every token descends from one sign-in, and ending the sign-in ends them all. Our products check a session again at least every 60 seconds and receive signed notices when it ends; a token issued over OpenID Connect lasts five minutes at most; PKCE is required of every OpenID Connect client, and a client excused from it is marked as such in our registry. A sign-in lasts at most 12 hours, and your rules can shorten it.

Separation between applications. Each application knows a person by an identifier of its own. What an application may do is fixed by its tier in one table: only our own products may create accounts, and somebody else's software is never told which other products a person uses.

Sign-in protection. Ten failed sign-ins in a row pause sign-in for 15 minutes, counted per account and per address. A letter can be asked for once every 60 seconds per address. Your rules can require a second factor.

Transport. The service refuses to start in production if mail to another host would travel unencrypted, and requires mutual TLS for its internal workflow engine (Temporal).

Access on our side. Our staff work in three roles (admin, support and auditor). Every act on an account records a reason, and searching for and opening an account are recorded too. No role can read a password, a recovery code or an application secret. Our support can act as a person only with that person's consent, for at most seven days, and the person is told afterwards every time. Disabling and erasing an account are for admins only.

Records and retention. Every sign-in, refusal and change is written to an audit log in which each entry carries a sequence number and the hash of the one before it; entries are kept for as long as GPlatform SSO exists and name only the identifier once an account is erased. Raw IP addresses are kept for 90 days, in sessions and in audit entries, and after that only a keyed hash; user agents are not stored, only a coarse device label. The country of a sign-in is read from a database on our own server; no address is sent to a lookup service. Request logs are deleted after 14 days. Sessions, tokens, codes and challenges are deleted once they have expired or been used. A person's account data is erased 12 months after their account ends, leaving only its identifier.

Availability and recovery. Encrypted backups are made every night to our own hardware in Germany and kept for 90 days.

Assistance

Your people can change most of what concerns them themselves, in the console. For the rest, we help you answer a data subject's request, and we help you meet your obligations under Art. 32 to 36 GDPR. If a person asks us about what you record, we pass the request on to you. We tell you without undue delay about a personal data breach affecting your data.

Deletion and return

As you go. Removing a member, a team or an access grant deletes it at once, and the products concerned see the change at their next check, within a minute. Switching off a service account revokes its tokens at once; its record stays so that our audit log can name it, and its tokens are deleted once they have expired. An invitation is deleted once it has been accepted or has expired; a withdrawn one stays on your list, marked withdrawn, until then. A domain claim an enterprise releases is deleted.

When the organisation is closed. Its owner closes it in the console. Every access grant, membership, team and invitation is deleted at once, the products concerned are told, and its service accounts stop working. The organisation's record (its name, its short name and the mark that it is closed) and the records of its service accounts stay, so that our audit log goes on naming what its entries are about. Before you close it, your owners and admins can read everything in it on its screens, and on request we give you a copy.

What stays. Audit entries about acts in your organisation are our own record, as controller, kept for as long as GPlatform SSO exists, and hold who did what and when. Each person's account stays theirs, under the privacy notice. Backups are made every night, are not edited and are kept for 90 days.

Where the law requires data to be kept, it is kept for that period and for that purpose only.