OpenID Federation policies for Pairwise Pseudonymous Identifiers (PPID)

Vladimir Dzhuvinov / Connect2id · 2024-02-26

How to mandate identity providers in a OpenID Federation to issue ID tokens and UserInfo responses with pairwise pseudonymous identifiers (PPID)? And how to make the PPIDs in a federation share the same sector identifier?

This question was raised in the OpenID Federation issue tracker. PPIDs are crucial in federations built around the privacy-by-default principle.

A standard for federating entities, such as OpenID providers and relying parties, must be neutral in regard to the protocols that the entities use among themselves. Neutrality separates the concerns of the federation infrastructure from those of the application protocols. It makes it easier to reason about systems, which is also good for security. The internet protocol is good example of neutrality. Its purpose is to relay datagrams and it's not concerned with their content.

If a particular federation has some requirement on an identity or application protocol in its jurisdiction, the OpenID Federation standard provides a simple and flexible tool to express that, called metadata policies. The use of metadata policies in a federation is optional.

A federation operator can mandate PPIDs by placing the following policy at the trust anchor level:

"metadata_policy": {
  "openid_provider": {
     "subject_types_supported": { "value": ["pairwise"] }
  },
  "openid_relying_party": {
     "subject_type": { "value": "pairwise" }
  }
}

This will automatically cause the metadata of OpenID providers and relying parties in the federation to assume the necessary parameters for PPID issue.

Once set by an authority, the value policy operator guarantees that the metadata parameter cannot be changed or overridden by subordinate authorities in the federation and in trust chains.

An intermediate federation entity, for example a participating organisation with multiple relying parties, may choose to define a common sector ID URL for them, to ensure its applications receive an identical IDs for the same end-user.

"metadata_policy": {
  "openid_relying_party": {
     "sector_identifier_uri": { "value": "https://org.example.com/sector-ids.json" }
  }
}

When the openid_relying_party metadata policies in the trust chain for these entities get merged, the resulting policy will become this:

"metadata_policy": {
  "openid_relying_party": {
     "subject_type": { "value": "pairwise" },
     "sector_identifier_uri": { "value": "https://org.example.com/sector-ids.json" }
  }
}

A federation may choose to define a sector_identifier_uri at the top-level, in the trust anchor metadata, so that it applies to all OpenID relying parties, across all participating organisation. However, this may require some additional coordination or customisation, because OpenID Connect requires the sector ID URL to point to a JSON document that contains the redirect_uris of the OpenID relying parties:

The value of the sector_identifier_uri MUST be a URL using the https scheme that points to a JSON file containing an array of redirect_uri values. The values of the registered redirect_uris MUST be included in the elements of the array.

One work around, without breaking OpenID Connect, is to use the OpenID Federation web APIs to crawl the federation to collect the redirect_uris of all applications. If you study the OpenID Federation 1.0 spec you will likely be pleased by its powerful tools and APIs, so we shouldn't be surprised when one day it comes to replace X.509 and CAs, in a future TLS 2.0 standard.