Public and pairwise subject identifiers

One identifier for everyone

The photo service uses public subject identifiers. Every client receives the same sub for the same account, so the printer and the collage app both stored user-2048.

That is simple, and often exactly right. At Lantern Studio, the project portal and the timesheet app both receive designer-42 from Lantern's identity provider, and Lantern wants them to. Both applications belong to the same organization, and matching a designer's records across them is part of running the business.

Between unrelated companies, the same property works against you. If the printing company and the collage company share customer data, sell it, or come under the same owner, user-2048 is a ready-made key for joining their records. Your print orders and your collages, which you gave to two separate companies, become one profile. Nobody had to guess or match on fuzzy details, because the photo service handed both companies the same value. Joining records about a person across services like this is called correlation, and a public subject makes it effortless.

A different identifier for each client

A provider can use pairwise subject identifiers instead, giving each client its own sub for the same person. The mail service works this way. When you sign in to the printer with your mail account, the printer receives a94f1c07e2. If you signed in to the collage app with the same mail account, it would receive a different value:

Compare the two mail service values and they share nothing. Only the mail service knows that both belong to you.

The provider calculates a pairwise value from your account and the client it is issuing to. Any method will do, provided it gives the same answer every time for the same person and client, a different answer for a different client, and an answer that nobody except the provider can trace back to the account. One example in the specification hashes three values joined together: a sector identifier, explained below, your account's internal identifier, and a secret salt that only the provider knows:

sub = SHA-256(sector_identifier || local_account_id || secret_salt)

Another is to generate a random value for each pairing and store it. The printer never needs to know which method a provider uses. It never calculates a subject. It receives one and stores it with the issuer, exactly as it does with user-2048, and looks you up by that pair.

A provider lists the types it offers in subject_types_supported in its discovery document, such as ["public", "pairwise"]. Where it offers both, a relying party chooses with the subject_type setting in its registration, as Registering a relying party mentioned. Some providers issue pairwise values to every client and offer no choice.

Pairwise subjects remove one easy way to correlate you. They do not make you anonymous. If the printer and the collage app both receive your email address, [email protected] joins their records just as well as user-2048 did. Some claims carry an identifier inside them. The photo service's picture address, https://photos.example/avatars/user-2048.jpg, contains your public account number, so a provider that switched to pairwise subjects but kept addresses like that would still hand every client the same key. Pairwise identifiers also limit what relying parties can learn by comparing notes, not what the provider knows. The mail service issued every one of those values and knows where it sent each of them. How much privacy you gain depends on everything else that is released, which Claim stability and privacy takes further.

Sector identifiers

"A different identifier for each client" is not quite precise. A pairwise subject is calculated for a sector identifier, and every client in the same sector receives the same value.

By default, the sector identifier is the host of the client's registered redirect URI. The printer's registration with the mail service has one return address, https://printer.example/signin/mail/callback, so its sector is printer.example, and a94f1c07e2 is your subject for that sector. That default has two consequences.

First, related applications on different hosts are kept apart. Suppose the printing company's phone app also offers sign-in with your mail account, under its own registration, returning to https://app.printer.example/signin/mail/callback, a claimed HTTPS address like the one in Redirect URIs and client metadata. Its sector would be app.printer.example, so the app would receive a different subject for you than the website does. The printer, which finds accounts by issuer and subject, would not find your account when you signed in through the app.

Second, a move changes every subject. If the printing company later moved its website's sign-in pages to www.printer.example, the sector would change with them, and every returning customer would arrive with a new subject that matches no account. The only remaining clue would be details such as email addresses, which Claim stability and privacy explains are no basis for finding an account.

Both problems have the same remedy. A registration can include a sector_identifier_uri, an HTTPS address of a JSON file listing redirect URIs. The provider then uses the host of that address as the sector identifier. The printing company publishes one file and names it in both registrations:

GET /oidc/redirect-uris.json HTTP/1.1
Host: printer.example

HTTP/1.1 200 OK
Content-Type: application/json

[
  "https://printer.example/signin/mail/callback",
  "https://app.printer.example/signin/mail/callback"
]

Registration setting, website and app:
  "sector_identifier_uri": "https://printer.example/oidc/redirect-uris.json"

When it accepts each registration, the mail service fetches the file and refuses the registration unless every one of that client's redirect URIs appears in it. The sector for both clients is now printer.example, the host of the file's address. The website and the app both receive a94f1c07e2 for you, and because printer.example was the website's sector all along, no existing subject changes. A later move works the same way: the company adds the new return address to the file and to its registration, keeps serving the file from printer.example, and subjects stay as they were. A registration whose redirect URIs span more than one host must name a sector identifier file, because the provider would otherwise have no single host to use.

The list of redirect URIs is what keeps outsiders out of the sector. The file is served from printer.example, so only the printing company decides which return addresses belong there. The collage company cannot register a client with this sector_identifier_uri, because its own redirect URIs are not in the file, and so it cannot receive the subjects the printer receives.

Whatever its type, a subject has the same properties. It is unique within its issuer and never reassigned to another person. It is a case-sensitive string of at most 255 ASCII characters, so the printer stores it exactly as received, in a field long enough for 255 characters, and never assumes it is a number or changes its case. And it is not a secret. Knowing that someone is user-2048 at the photo service does not let anyone sign in as them. A pairwise value limits who can connect records about you. That is a privacy protection, not a credential.