Summary

  • RIPE NCC says its RPKI dashboard is moving to OpenID Connect and that work has begun to replace current RPKI API keys with OIDC-based keys integrated with RIPE NCC Access. The implementation is still in progress.
  • OIDC can improve authentication and credential lifecycle, but it does not by itself prove which prefixes, actions or environments an automation principal may alter. RIPE NCC’s separate refusal to use an API able to edit ROAs for all its space shows why that distinction matters.

The most informative sentence in RIPE NCC’s Q4 2026 RPKI plan is not the announcement of OpenID Connect. It is the sentence in which the registry says no.

A community request proposed an RPKI routing beacon whose validity could change for research. RIPE NCC says it could not yet add the beacon because the API available for the work would allow editing ROAs for all RIPE NCC space. That reach was unacceptable, so the team will investigate another route with RIS.

This is a small operational decision with a large governance lesson. A control can know exactly who is calling and still grant that caller too much power. Identity assurance answers who presented the credential. Authorization must answer what the principal may do, where it may do it and on whose resources. A safe mutation also needs a receipt showing what the service accepted. None of those receipts can be substituted for another.

RIPE NCC’s parallel credential project makes the distinction immediate. Its plan, last updated on 17 September, says the RPKI Dashboard is being updated to use OpenID Connect through RIPE NCC Access. Work has also started to replace today’s RPKI API keys with OIDC-based keys integrated with the SSO system. Users are expected to manage them through a new dashboard section, while implementation and timing details are due at a coming RIPE Meeting. The published status is “in progress”, not delivered.

That is a worthwhile direction. RIPE NCC Access already mandates two-factor authentication. The current account-security policy ties API keys to a user account, caps their life at one year and deactivates them when the account is disabled or the user loses the relevant maintainer role. Bringing RPKI credentials into a common identity and lifecycle system could reduce forgotten secrets and make ownership more legible.

But OpenID Connect is an identity layer over OAuth 2.0. Its name is not an authorization design. The forthcoming details will need to show at least four different boundaries: the protected service that may accept a credential; the actions it permits; the LIR, certificate or prefix set it can affect; and whether it represents a person or a non-human workload. OAuth’s resource-indicator specification is explicit about the first distinction: a resource identifies where a token is intended to be used, while scope expresses what access is requested. Prefix ownership is a further, application-specific boundary.

The existing RPKI interface helps show the stakes. RIPE NCC’s documentation says the management API can administer an LIR’s certification authority and ROAs. A single publish call may add or delete multiple ROAs. A ROA is not a decorative record: it cryptographically authorizes an origin AS for a prefix, with an optional maximum length. The hosted system then signs, publishes and renews the resulting objects.

The current system also contains useful controls. An attempted ROA for a prefix the caller does not hold should receive a 403 response. The dashboard can hold changes pending, show affected announcements and apply a reviewed set atomically. The API offers an affected-announcements query for a prospective ROA. Those functions point towards the right safety model: authenticate, constrain, simulate, approve, publish and observe—each as a separate step.

The last step matters because a ROA is not a route. After a mutation is accepted, an object still has to be published to a repository, fetched and evaluated by validators, consumed by networks that perform route-origin validation, and acted on under local routing policy. A login success cannot prove any of those outcomes. Nor can an observed route prove which operator authorized the original change.

The practical question for members is therefore not “Does the new system use OIDC?” It is “What is the smallest authority an OIDC-based credential can carry?” A read-only inventory job should not inherit publish permission. A service maintaining one certificate should not receive an institution-wide mutation surface. A laboratory beacon should not need authority over production space. A departing engineer’s account should not remain the hidden identity of an unattended process.

RIPE NCC has not yet disclosed enough detail to judge those properties, and that uncertainty should be preserved rather than filled with suspicion. The beacon decision is not evidence that the future member API has the same reach. It is evidence that the registry recognizes overly broad reach as a reason to stop. The forthcoming design can turn that instinct into a verifiable contract.

The editorial lens here comes from Heng Lu’s work on minimum initial specification, reality layers and the agency problem in Internet governance. Applied to RPKI, it argues for narrow initial authority, resource-local future decisions and explicit separation between identity, authorization, signed objects and observed network state. That is an analytical framework, not a policy attributed to RIPE NCC.

Sources