Summary

  • RIPE NCC's Q3 2026 plan calls an in-progress browser-authentication change OIDC 2.0, although the relevant standard is OpenID Connect 1.0 built on OAuth 2.0. The label should be repaired or resolved in a versioned implementation record.
  • A successful OIDC sign-in establishes identity and a session. It does not by itself decide which RIPE Database object that identity may update; public documentation places that decision in the mntner authorisation model.
  • Completion should be proved by a privacy-safe cutover receipt joining protocol profile, local session lifetime, logout, legacy-cookie retirement, mntner lookup, API-key treatment, denied tests, rollback and accepting authority.

A version number is an operating instruction

The smallest phrase in a quarterly plan can carry the largest ambiguity. RIPE NCC's RIPE Database plan for Q3 2026 lists an item called “Switch DB web application to OIDC 2.0”. Its explanation says interactive authentication will move from a site-wide secure cookie to an OIDC 2.0 session, so authenticated requests are more secure. The item is marked in progress and the page says it was last updated on 11 June 2026.

There is a useful intention here. A site-wide application cookie can make too much authentication state depend on one locally interpreted token. A standards-based federation flow can give the web application clearer issuer, audience, freshness and account context. It can also place login policy, including stronger account controls, behind RIPE NCC Access rather than reproducing it inside every service. None of those benefits needs to be diminished to ask what the version name means.

OpenID Connect Core is version 1.0. It defines an identity layer on top of OAuth 2.0. Session Management, Front-Channel Logout, Back-Channel Logout and RP-Initiated Logout are separate specifications in the same family. Calling the intended design OIDC 2.0 may be a harmless compression of “OpenID Connect on OAuth 2.0”. It may be an internal project name. It may simply be a documentation error. The public record does not settle which.

That uncertainty is not a standards trivia contest. An acceptance team cannot test “OIDC 2.0” without deciding which protocol, flow and session obligations the phrase imports. Does the browser use an authorization-code flow? Is Proof Key for Code Exchange required? Which issuer and client identity are accepted? Which claims bind the RIPE NCC Access identity to the application? Is logout local, provider-initiated, relying-party-initiated or back-channel? What terminates a session after an account or maintainer relationship changes? A real specification answer can be tested. A blended label cannot.

OIDC does not make sessions disappear

The plan contrasts a site-wide secure cookie with an OIDC session. That sentence can be read as if a cookie is replaced by a protocol and the old category vanishes. In a browser application, the boundary is less tidy. OpenID Connect can authenticate the user at an OpenID Provider and return identity assertions to a relying party. The relying party may still create local state, often represented to the browser by a cookie. The provider also maintains its own login state. Those states can have different lifetimes and different logout paths.

The OpenID Connect Session Management specification exists precisely because an authenticated session needs management after the original response. RP-Initiated Logout separately defines how a relying party asks the provider to end an end-user session. Neither specification says that every local application session automatically ends when a provider session changes. Nor does it force one universal cookie design. The operator must choose, implement and test the joins.

This matters during migration. Suppose an old application cookie remains valid for thirty minutes after the new OIDC path is enabled. That overlap may be deliberate and safe, or it may be rejected by policy. Suppose the provider session ends but the RIPE Database relying-party session remains valid until its local expiry. Again, that can be a normal design choice or an unacceptable one. The evidence needed is the declared boundary, not a guess based on the protocol name.

The public receipt therefore needs at least four clocks: provider authentication, token validity, local relying-party session and database authorisation lookup. It also needs an event map. Login, refresh, local logout, provider logout, account disablement, maintainer removal and application rollback are not synonyms. If the system treats them differently, the acceptance record should say so without exposing a user, token, cookie or secret.

Authentication stops before the object decision

RIPE Database documentation gives the cleanest reason not to close the project at login. It distinguishes authorisation, authentication and credential. Authentication establishes that an actor is what the actor claims to be. Authorisation supplies the power to act. A credential provides a basis for confidence that the actor may exercise that power.

For database updates, the documented control object is the mntner. It holds credential references, including SSO accounts and cryptographic keys. An authenticated person may be associated with one or more maintainers, and different database objects point to the maintainers that protect them. The web session can carry an identity into the application. It cannot, merely by being valid, confer permission over every object.

The API-key documentation makes the separation concrete. A database API key belongs to a RIPE NCC Access account. Before the key can authenticate an update, that account must already be associated with a mntner by an auth: SSO attribute. A key may be restricted to a particular maintainer. The documentation also gives the key an expiry date, last-use visibility and revocation. These are valuable credential controls; they are not substitutes for the object's maintainer relationship.

RIPE-843 adds an account-governance layer. It requires two-factor authentication for RIPE NCC Access accounts, says usernames are intended for one person and limits API keys to one year. It also says a key is deactivated when the associated SSO account is disabled or when the user is removed as an account maintainer in the relevant business-application database. That is a dependency chain: account state can affect a credential, while the maintained object's authorisation still needs its own decision.

The 2025 bearer path is adjacent evidence, not completion

The public RIPE-NCC/whois repository records Support OAuth 2.0 (#1688) under release 1.117. Pull request 1688 was merged on 3 March 2025. Its changed files include a bearer-authentication integration test suite. Among the visible negative cases are an update attempted with a bearer token tied to the wrong maintainer and an update attempted with a mismatched SSO identity. The expected result is rejection, with the object left unchanged.

That is strong evidence for the conceptual boundary. A token can be syntactically valid and still lack the required maintainer authority. A positive authentication test is therefore not enough. Acceptance needs both permitted and denied object-update cases, and the denied case should prove absence of state change rather than merely display an error message.

But the merged bearer work does not prove the Q3 2026 browser item is complete. The dates, surfaces and labels differ. One artifact concerns bearer authorization reaching the Whois service; the other plans a change to interactive web authentication and local session handling. Treating the earlier merge as the later delivery would collapse exactly the distinction the public record should preserve.

A cutover receipt with two columns of truth

The most useful public artifact would not publish configuration secrets. It would join two columns of truth.

The first column describes authentication and session state: the exact OpenID Connect Core and OAuth profiles, issuer and relying-party identity at a safe level, flow, claim classes, token and local-session lifetimes, cookie scope and protection, refresh rules, logout paths, legacy-cookie stop time, treatment of sessions already alive at cutover, monitoring window and rollback point.

The second column describes authority: how the authenticated identity is resolved, when mntner associations are read, how removal or account disablement reaches an active session, whether API keys follow the same clock, which protected object and operation classes were tested, which negative cases were rejected, whether rejected writes left state unchanged, and which role accepted completion.

The join between the columns is the control. A session identifier should never be public, but an anonymous test-case identifier can be. An email address should not appear, but the identity-state class can. A maintainer secret must remain private, but the expected relationship and decision result can be recorded. Corrections should append a new version rather than overwrite the evidence used for the original acceptance.

This receipt also gives the phrase OIDC 2.0 a graceful exit. RIPE NCC can state that the phrase meant OpenID Connect Core 1.0 over OAuth 2.0 with named companion profiles, or correct the plan and link the correction. Either outcome is more useful than leaving future operators to infer a protocol from a project nickname.

What the record does not show

The reviewed material does not disclose the issuer, client, scopes, claims, flow, token lifetime, cookie attributes, logout mode, deployment date, compatibility interval or rollback rule for the planned browser change. It does not establish that OIDC 2.0 is a mistake. It does not show an insecure live cookie, a stale session, an account takeover, a mismatched maintainer, an unauthorised update, data loss or an outage.

The correct conclusion is therefore narrow. The migration can be worthwhile and still require a better completion record. The in-progress status should remain in-progress until RIPE NCC's chosen authority can connect the actual protocol profile to session termination and to both positive and negative maintainer tests. That is not an accusation. It is the difference between a modern login and a reviewable control.

Sources