GPlatform SSO privacy notice

Who is responsible

The controller is Gelhaus Solutions, a sole proprietorship of Enno Gelhaus, Eichenwald 3, 49624 Löningen, Germany, reachable at contact@gplatform.org.

There is one exception, and it is set out under "Organisations, teams and access" below: for what an organisation records about its own people in GPlatform SSO, the organisation is responsible, and we process it on the organisation's behalf under the processing annex.

What this notice covers

GPlatform SSO, at sso.gplatform.org, is the identity layer for our products: the account you sign in with, the organisations and teams you belong to, the sessions you hold in every product at once, and which products you may reach. This notice covers:

• your account, its addresses, its ways in and its sessions;
• what GPlatform SSO passes on to the applications you sign in to and receives from the sign-in providers you use;
• organisations, teams, access grants and enterprises, as far as we are responsible for them;
• support access, the audit log, the mail we send and the cookies the GPlatform SSO console sets.

What a product does with what it is told about you is in that product's own privacy notice. The website around it is covered by the site's privacy policy. The GPlatform SSO terms describe how the service works.

The short version

• Your account holds your email addresses, a display name if you give one, and your ways in. Passwords are stored as argon2id hashes, authenticator secrets encrypted, and recovery codes, session tokens and the codes in our letters only as hashes. No postal address, no phone number, no date of birth.
• Each product knows you by an identifier of its own and is told your display name and your primary confirmed address when it asks. Somebody else's application learns who you are only after you agree on its consent screen, and never learns which of our other products you use.
• A sign-in provider tells us your account there, your address, your name and a link to your picture. We send it nothing about you, and we do not keep its tokens.
• A session records your IP address, a coarse device label and the country, so that you can see where you are signed in and be warned about a country you have never signed in from. The country comes from a database on our own server; no address is sent to a lookup service. Raw IP addresses are kept for 90 days, then only a keyed hash that cannot be turned back into the address.
• One control ends every session in every product. Our products stop accepting them within a minute, and a token already given to an application lasts five minutes at most.
• The audit log records every sign-in, refusal and change. It is kept for as long as GPlatform SSO exists, and once an account is erased it names only the account's identifier. You see your own last 90 days.
• Account data is kept while the account exists and for 12 months after it ends, then erased, leaving only the identifier.
• Our support can act as you only with your consent, and you are told by email after every such session.
• An organisation you belong to sees your membership, role, teams and access, and decides about them; we process that on its behalf.
• Only the cookies the console needs, and one for the colour scheme you choose, so there is no consent banner. No trackers, no analytics, no advertising.
• The servers are in Germany. Error reports go to Sentry's EU data region with every category of personal data switched off.

Your account

When you register on the console, or a product of ours makes an account for you on its own sign-up page, we store:

• your email address, in lower case, and when it was confirmed. You may add more addresses and choose which confirmed one is your primary address; accepting an invitation while signed in can add the invited address. An address can be claimed by one full account only, and we record when it was claimed;
• your display name, if you give one, and a link to a picture, if you set one. We store the link, not the picture: wherever the picture is shown, the viewer's browser fetches it from where the link points;
• the kind of account: a full account, or an account made inside one product, which signs in to that product only;
• the state of the account: active, suspended or disabled, and when that last changed; when you last signed in; how many sign-ins in a row failed and until when sign-in is paused; and whether a lockdown requires a new password at the next sign-in, and since when;
• your preference for how often a product asks you to sign in again, overall and per product;
• when the account was created, and when something a product is told about you (your name, your primary address or your picture) last changed, so that products holding your name can catch up with the change;
• if you are under 18, your confirmation at sign-up that a parent or guardian agrees.

Why. To provide the account you asked for (Art. 6(1)(b) GDPR), and to keep it and the products behind it secure (Art. 6(1)(f) GDPR, the legitimate interest being the security of the service and of your account). The confirmation of a parent's or guardian's agreement is how we make sure the contract is valid (Sections 107 and 108 BGB; Art. 6(1)(b) and (f) GDPR).

Passwords, second factor and recovery codes

• Your password is stored only as an argon2id hash, never as itself, and has at least 12 characters. A password brought across from a product's earlier sign-in service keeps that service's hash (bcrypt) until you next sign in with it, when it is replaced by an argon2id hash.
• Your authenticator secret, if you set up a second factor, is stored encrypted (AES-256-GCM), because it has to be read back to check a code, with when you confirmed it.
• Your ten recovery codes are stored only as hashes, with when each was used. Confirming a new authenticator replaces all ten.

An account without a password signs in with a code by email, a passkey or a provider.

Why. Signing you in securely (Art. 6(1)(b) and (f) GDPR).

Letters, links and codes

We send mail for these purposes only: to confirm an address, to reset a password, with a sign-in code, with an invitation to an organisation, with the offer to join two accounts, to confirm linking a provider, and to tell you that our support acted as you.

The mail is plain text, sent from our shared mailbox sso@gplatform.org by our own mail server (Stalwart), which runs in Germany on the same IONOS server as GPlatform SSO. No mail carries a tracking pixel or a link that tells us whether you opened it. You can reply to every one of them, and your reply reaches us. A sign-in code is put in the subject line on purpose, so that a notification preview shows it.

Links and codes are stored only as hashes, with the address they were sent to, what they are for, and when they were made, expire and were used. A link is valid for one hour; a sign-in code has six characters and is valid for ten minutes. Asking again cancels the previous one of the same kind.

The mail log. For every message we keep its kind, the address it went to, its subject, whether it was sent, how many attempts it took and any delivery error. For every letter that carries a link or a code, the text of the message is not kept, and a sign-in code's subject is logged as "A sign-in code". The notice that our support acted as you is kept in full, because it is the record you may want to rely on.

Asking for a letter again is possible once every 60 seconds per address and kind. To enforce that, we note per address and kind when a letter was last asked for. This is noted for any address typed into the form, whether or not an account holds it, so that the answer does not reveal whether one does, and the note is deleted after 24 hours.

Mail we keep. The mail log, the mail server's delivery log and the mail in our shared mailboxes (sso@ and contact@gplatform.org) are not deleted automatically. We delete them by hand once they are no longer needed.

Why. Sending what your account needs you to have (Art. 6(1)(b) GDPR), knowing whether our mail arrives, and keeping the forms from being used to flood somebody's mailbox (Art. 6(1)(f) GDPR).

Passkeys

For each passkey we store its credential identifier, its public key, its signature counter, its transports, whether it is backed up to a provider's cloud, the label you give it, and when it was created and last used. The private key never leaves your device. We ask for no attestation, so your authenticator does not have to prove its make or model to us.

A passkey is bound to sso.gplatform.org and answers nowhere else. It is discoverable, so the browser offers it without you typing an address. When you create one, your browser gives your primary confirmed address to your authenticator as the account's user name, so that you can tell your passkeys apart; it is stored on the authenticator, and where your passkeys are synced by a provider, such as the password manager of your operating system, that provider holds it too, under its own terms. Each ceremony uses a one-time challenge valid for five minutes.

Why. Signing you in securely (Art. 6(1)(b) and (f) GDPR).

Sign-in providers

You may sign in through a provider such as Google, GitHub or Microsoft, where we have set it up. Your browser goes to the provider, and we send it nothing about you: only our own client identifier and one-time values that protect the round trip. When you come back, the provider tells us your account identifier there, your email address and whether it says it has confirmed it, your name and a link to your picture. We store these on the link between your account and the provider, with when you last used it. We do not keep the provider's tokens: they are used once to read who you are and then discarded.

While you are away at the provider, we keep a record of the round trip (a hash of its state value, an encrypted verifier, a one-time number and where to return you) for up to ten minutes. Where a provider names an address a full account already holds, what the provider said is kept on that record until the confirmation letter is opened or expires.

The provider is responsible for what it does under its own privacy notice. Several providers are based in the United States, and what you do with them is between you and them.

Why. Signing you in the way you chose (Art. 6(1)(b) GDPR).

Sessions

When you sign in, we store a session:

• a SHA-256 hash of its token, never the token itself;
• when it was made, when you last fully authenticated, when it ends, and whether it was ended early;
• the IP address it was made from. The raw address is kept for 90 days at most; after that only a keyed hash of it stays, which can show that two sessions came from the same address and cannot be turned back into it;
• the country that address belongs to, as a two-letter code. It is looked up in a country database (MaxMind GeoLite2) on our own server, so the address is never sent to anybody to find out. We record a country, never a city;
• a coarse device label, such as "Firefox on Linux", taken from your browser's user agent at sign-in. The user agent itself is not stored;
• whether you confirmed that a session from an unfamiliar country was you;
• how many times in a row a fresh confirmation failed on this session.

For each product the session reaches, we note the product, your account in it, and when the product last checked the session.

A sign-in lasts at most 12 hours, or less where an organisation you belong to has said so, and the session is deleted once it has expired. A fresh confirmation counts for five minutes. Ten wrong answers to a fresh confirmation pause it on that session for 15 minutes, and leave your account alone.

Your account lists your sessions with the device, the IP address, the country and the products each reached. A session from a country your account has never signed in from before is shown as unfamiliar, to you only, until you end it or confirm it was you.

Why. Keeping you signed in and letting you see and end every session (Art. 6(1)(b) GDPR), and recognising a session that is not yours (Art. 6(1)(f) GDPR, the legitimate interest being the security of your account).

The lockdown

The lockdown ends every session in every product, and at the steps you choose also requires a new password, revokes your personal access tokens and cancels outstanding reset and sign-in codes, suspends the account, and drops every linked provider. Each product you were signed in to receives a signed notice carrying only the identifier it knows you by; it is told nothing else about you. The receipt the console shows afterwards is held in a cookie on your device for 15 minutes, because there is no session left to fetch it with.

Why. Protecting your account at your request (Art. 6(1)(b) and (f) GDPR).

Accounts made inside a product, and joining accounts

A product of ours can sign you up on its own page. It passes us what you typed there: your address, your password and your name. That account signs in to that product only.

Every day we look for the same confirmed address on two accounts, such as an account made inside a product and a full account. Where we find one, we send an offer to that address to join them. Nothing is joined unless somebody accepts it from that mailbox. When two accounts are joined, the other account's accounts in the products, memberships, teams and linked providers move to the account that remains, which keeps its own password, second factor and passkeys. The other account's sessions, password, second factor, recovery codes and passkeys are destroyed, and its record and addresses are deleted. Every product goes on knowing you by the identifier it already had.

Why. Giving you one account rather than two without merging two people by mistake (Art. 6(1)(b) and (f) GDPR).

Organisations, teams and access

For your own account, we are responsible. An organisation you join does not own your account: it cannot see your sessions, your credentials, your other organisations or your activity outside it.

For what an organisation records about its people, the organisation is responsible, and we process it on its behalf under the processing annex:

• your membership and your role in it (owner, admin, member, billing or auditor);
• the teams you are in;
• the access granted to you: which product, which role, and whether granted to you by name, through a team or to the whole organisation;
• the rules it sets for its people, and the role sets it defines;
• the invitations it sends: the address, the role offered, who sent it, and when it was sent, accepted, withdrawn or expired;
• the service accounts it makes, with the name of the person who made each;
• its activity view, which shows its owners and admins 90 days of what happened in the organisation and who did it, never the IP address or the country.

Its owners and admins see its members with their name and their primary confirmed address. Questions about what an organisation does with this are for that organisation; you can also write to us, and we pass your request on to it.

If you were invited and have no account, the address came from the person who invited you, on behalf of the organisation. It is used to send you the invitation and to let you accept it. The invitation is valid for seven days and is deleted once it has been accepted or has expired.

Products are told your memberships when they ask: the organisation, your role in it, its enterprise if it has one, your teams, and the role granted to you in that product.

Why. For what the organisation records, the organisation's own legal basis. For our part, providing the account you use it with (Art. 6(1)(b) GDPR).

Enterprises and claimed domains

An enterprise groups organisations under one company, and we set it up for a customer. It sees its organisations, its people and its rules.

Domains. An enterprise proves a domain with a file on its web server or a DNS record. We check outstanding claims every 15 minutes, by fetching that file and looking up that record, and store the answer and the first 200 characters of what came back.

If you confirm an address on a domain an enterprise has claimed and proven, an entry naming your account and the domain is written to the audit log, and that enterprise's own record shows it. An enterprise that manages its people's accounts may force a password reset, manage or remove a second factor and close an account; for accounts it manages, we process the account on its instructions as well. An account that already exists comes under an enterprise's management only after you have been told and have had the chance to refuse.

Why. Telling an enterprise about addresses on the domain it proved it controls (Art. 6(1)(f) GDPR, the legitimate interest being the enterprise's control of its own domain). For managed accounts, the enterprise's own legal basis.

Applications you sign in to

Every application is enrolled by us as one of three kinds: our own products, software we run but did not write, or somebody else's software, including an organisation's own applications. What an application learns depends on the kind and on what it asks for.

Through the session protocol, which our own products and software we run use, an application is told: the identifier it knows you by, your primary confirmed address, your display name, your memberships as described above, when your session ends, when you last fully authenticated and whether that was in the last five minutes, and whether our support is acting as you.

Through OpenID Connect, which every kind may use, an application is told the identifier it knows you by, when you authenticated and an identifier of your session, and, if it asks:

• with profile, your display name and the link to your picture;
• with email, your primary confirmed address;
• with gplatform_memberships, your memberships as described above;
• with gplatform_apps, which of our other products you can reach. Our own products are told this; software we run only where we have allowed it; somebody else's software never.

Before an application learns who you are over OpenID Connect, you are asked. The consent screen shows which kind of application it is and what it asks for. We record which application, which of these it may have, and when; a later request for more asks again. An account made inside a product is not asked when it signs in to that same product.

The tokens of this exchange are short-lived. A code works once, within 60 seconds, and only its hash is stored. An access token and an identity token last five minutes, are signed with a key held in our key store (HashiCorp Vault) and are not stored. A refresh token is replaced at every use, only its hash is stored, and it never outlives the sign-in it came from.

When an application asks to sign you out, we ask you whether to end only that application or every session, and keep that request for up to ten minutes. When a device such as a television or a terminal signs in, it shows a short code you type into the console within 15 minutes, and the device's own name is shown to you before you approve it.

On one of our products' own sign-in pages, what you type, your password included, passes through that product's server on its way to us.

When a session ends, each product it reached receives a signed notice carrying only the identifier it knows you by. When something a product holds about you changes, such as your name, a product can ask which of its people changed since a given time.

Who is responsible for what an application does with it. Our own products and the software we run are ours, under the same controller, and their own privacy notices say what they do inside. Somebody else's software is responsible for what it receives under its own privacy notice.

Why. Signing you in where you asked to go (Art. 6(1)(b) GDPR). Where somebody else's application is in a country outside the EU without an adequacy decision, passing it what you agreed to is necessary to sign you in there at your request (Art. 49(1)(b) GDPR).

Support access

Our support can act as you only with your consent. We record who granted it, the reason you were shown, until when it lasts (seven days at most) and when it was withdrawn. A session opened under it is marked with the member of staff and the reason, every act inside it is recorded as support acting as you, and each product is told that the session is support acting as you. Withdrawing the consent ends every session opened under it. After every such session we tell you by email, and that letter is kept in the mail log in full.

Why. Your consent (Art. 6(1)(a) GDPR), which you can withdraw at any time without affecting what was done before. Recording it and telling you: accountability for every act done in your name (Art. 6(1)(f) GDPR).

Inside Gelhaus Solutions

Our staff work in three roles: admin, support and auditor. Every act of staff on an account records a reason, and searching for an account and opening one are recorded too. No role can read a password, a recovery code or a product's secret, and no role can sign in as you without your consent. Staff can force a password reset or a lockdown, suspend an account and lift a suspension; disabling an account and erasing one are for admins only.

Personal access tokens and service accounts

For a personal access token we store the name you give it, a hash of the token, its last four characters, which products it is narrowed to, when it expires, when it was revoked and when it was last used. The token is shown to you once.

For a service account we store its name and description, the organisation or enterprise that owns it, who made it, and for each token a hash, the last four characters, the expiry, who made it and when it was last used.

Why. Letting you and your organisation automate safely (Art. 6(1)(b) GDPR).

Accounts moved from a product's earlier sign-in

When one of our products moves its sign-in onto GPlatform SSO, we receive from the product's earlier sign-in service: your address and whether it was confirmed, your password hash, your display name, the link to your picture, your linked provider accounts where GPlatform SSO offers the same provider, and the identifier that service knew you by, which we record in the audit log so that a repeated move recognises you; it is erased with the rest of your account data. Passkeys and authenticator secrets do not come across. We give the product a table from its old identifier for you to the new one, so that it goes on recognising you.

Two people are never merged by rule. Where an address is shared by several people in the old service, was never confirmed there, or is held here already, a member of our staff decides and records why. The record of each move (the addresses concerned, the old and new identifiers, the decision, who took it and why) is kept; the addresses in it are erased with the account data they belong to.

Why. Continuing the account you already have with that product (Art. 6(1)(b) GDPR), and moving it without joining two people by mistake (Art. 6(1)(f) GDPR). The product's terms and the general terms say how you are told in advance.

The audit log and your activity

Every sign-in, every refusal, every change to how you sign in, every lockdown, every grant and every act of our staff writes an audit entry: who acted (you, a member of staff, staff acting as you with your consent, an application, or the system), what was done, whose account it concerns, which organisation, product or enterprise, the IP address it came from and its country, and the details the act needs. The raw IP address is kept for 90 days; after that only a keyed hash of it stays with the entry. The details never hold a token, a code, or an address that is not already the subject of the entry. Each entry carries a sequence number and the hash of the one before it, so a removed or altered entry shows.

Audit entries are kept for as long as GPlatform SSO exists. Once an account is erased, the entries about it name only its identifier. They are the record of what this service and its staff did, which is what accountability rests on; we regard keeping them as a compelling legitimate ground in the sense of Art. 21(1) GDPR.

You see your own activity of the last 90 days, with the IP address and country. An organisation's owners and admins see 90 days of what happened in the organisation, without the IP address or country.

Why. Security, defence against abuse and accountability for every change (Art. 6(1)(f) GDPR).

Request logs

The web server in front of GPlatform SSO and its API record each request, with the IP address it came from. Request logs are deleted after 14 days.

Why. Operating the service, finding faults and defending it against attacks (Art. 6(1)(f) GDPR).

Sign-in protection

Failed sign-ins are counted per account and per address typed, whether or not an account holds that address. Ten in a row pause sign-in for 15 minutes. The count per address is removed once the pause or the window it counted in has passed; we check every 15 minutes.

Why. Defending accounts against guessing (Art. 6(1)(f) GDPR).

Where the data comes from

Most of it comes from you. Beyond that, it comes:

• from a product's own sign-up or sign-in page, which passes on what you typed there;
• from a product's earlier sign-in service, when the product moves its sign-in here;
• from the sign-in provider you choose;
• from an organisation's owners and admins, for invitations, roles, teams and access;
• from an enterprise, for its domains and the accounts it manages;
• from the country database on our own server, for the country of an IP address.

Who else receives it

• The products you sign in to, as described under "Applications you sign in to".
• The sign-in provider you choose, which receives the request to sign you in and nothing about you.
• The organisations and enterprises you belong to, as described above.
• IONOS SE, Elgendorfer Straße 57, 56410 Montabaur, Germany, provides 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, receives error reports. It is configured to receive no user identifier, cookie, header, request body, query string or value of a local variable: an error report carries the exception, its stack trace, the route that failed and the request identifier. 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. It is on Sentry's Team plan, and error events are kept for 90 days.
• Our own hardware in Germany holds the key that signs every token (HashiCorp Vault, where the private key is made and never leaves) and our encrypted backups, which are made every night to our Proxmox Backup Server and kept for 90 days. It is reached over an encrypted WireGuard tunnel.
• Courts and authorities receive data only where the law obliges us to hand it over (Art. 6(1)(c) GDPR).

Outside the EU

GPlatform SSO processes personal data in Germany. Three things reach further, and two of them only at your choice: access to error reports from the United States cannot be ruled out for Sentry, as described above; a sign-in provider you choose may be outside the EU; and somebody else's application you agree to may be.

How long

• Account data (your addresses, your credentials and your profile): while the account exists, and for 12 months after it ends. When you close your account, your password, second factor, recovery codes, passkeys and linked providers are deleted at once, and your memberships and the access granted to you by name are removed. Twelve months after the account ends, the rest is erased: every address is replaced by a placeholder that cannot receive mail, and your display name, your picture link, your preferences, your consents and your confirmation of a parent's or guardian's agreement are deleted. Only the account's identifier stays, so that audit entries, and the identifiers products know you by, name nobody.
• Raw IP addresses: 90 days, in sessions and in audit entries. After that only a keyed hash stays.
• User agents: not stored. A session keeps only a coarse device label.
• Sessions: deleted once they have expired.
• Tokens, codes and challenges (refresh tokens, personal access tokens, service account tokens, the codes and links in our letters, invitation links, codes of the OpenID Connect exchange, device sign-ins, passkey challenges, round trips to a provider and sign-out requests): deleted once they have expired or been used. Access and identity tokens are not stored.
• Your identifier in each product: kept, also when you leave a product or close your account, because the product has recorded things under it. It is a random value that names nobody.
• Memberships, teams and access in an organisation: until they are removed, you leave or close your account, or the organisation is closed.
• Audit entries: for as long as GPlatform SSO exists, naming only the identifier once an account is erased.
• Request logs: 14 days.
• Notes of when a letter was last asked for: 24 hours.
• Sign-in counts per address: removed once the pause or the window they counted in has passed.
• The records of moving a product's accounts here: kept as the record of how each person was moved; the addresses in them are erased with the account data.
• The mail log, and mail on our mail server and in our shared mailboxes: not deleted automatically, but deleted by hand once no longer needed.
• Error events at Sentry: 90 days.
• Backups: made every night to our Proxmox Backup Server on our own hardware in Germany, and kept for 90 days. They are not edited, and are restored only to recover the service.

Where a statutory retention period applies, it applies instead.

Your device

The GPlatform SSO console sets these cookies:

• gpsso_session, when you sign in: a random token of 32 bytes and nothing else. Script cannot read it (HttpOnly), the browser sends it only over HTTPS (Secure) and to sso.gplatform.org alone, and not with requests other sites start in the background (SameSite=Lax). It ends with your session, after 12 hours at most.
• gpsso_provider_name, when you go to a sign-in provider: the provider's name, so that the next screen can name it. 15 minutes, HttpOnly.
• gpsso_provider_confirming, when a provider named an address a full account already holds: that address and the provider's name, for the page telling you to check your inbox and no other. 15 minutes, HttpOnly.
• gpsso_lockdown_receipt, after a lockdown: what it ended and in which products, for the receipt page and no other. 15 minutes, HttpOnly.
• gpsso_theme, only if you choose a colour scheme: "light", "dark" or "system", kept for a year.

Each of them is strictly necessary to provide what you asked for, the last one because you asked for it, so no consent is needed (Section 25(2) No. 2 TDDDG) and there is no banner. Nothing else is stored on or read from your device: no other cookie, no local storage, no analytics, no trackers, no advertising and no fingerprinting. Fonts are served from our own server. The products you sign in to set their own cookies, as their notices describe.

Your rights

You have the right of access (Art. 15), rectification (Art. 16), erasure (Art. 17), restriction of processing (Art. 18), data portability (Art. 20) and the right to object to processing based on legitimate interests (Art. 21 GDPR). Where processing rests on your consent, as support access does, you may withdraw it at any time, without affecting what was done before. Write to contact@gplatform.org; an informal email is enough, and we answer within one month.

Erasure has the limits described under "How long": the account's identifier stays, audit entries are kept and name only that identifier, products keep the identifier they know you by, and an organisation's records are the organisation's. Most of what you can change, you can change yourself on the console: your addresses, your name and picture, your ways in, your sessions, your preferences, the products you leave and the account itself.

You have the right to lodge a complaint with a supervisory authority. Ours is Die Landesbeauftragte für den Datenschutz Niedersachsen, Prinzenstraße 5, 30159 Hannover.

What you must provide, and automated decisions

An email address is required for an account, and a way in: a password, a passkey, a sign-in provider or codes by email. Without them we cannot provide the account. Nothing works on an account registered on the console until its address is confirmed. You must be at least 16, and if you are under 18 the account needs a parent's or guardian's agreement.

Nothing about you is decided by automated means in the sense of Art. 22 GDPR. Pausing sign-in for 15 minutes after ten failed attempts is a security measure, not a decision about you. The warning about an unfamiliar country is shown only to you and decides nothing. The offer to join two accounts decides nothing until somebody accepts it. Checking an enterprise's domain proves the domain and decides nothing about your account.

Changes

This notice changes when GPlatform SSO does. A material change is announced in advance, with what changed, as the general terms set out. Every version is kept in the document archive.