Summary

  • RIPE NCC’s current RPKI Management API documentation describes an LIR-specific surface for managing a Certificate Authority and ROAs through an API access key.
  • RIPE NCC’s Q3 2026 plan says a replacement of current RPKI API keys with OpenID Connect based keys integrated with RIPE NCC Access is planned, not deployed.
  • The same plan says a proposed RPKI-beacon API was not added because it would allow editing ROAs for all RIPE NCC space. That statement concerns the rejected beacon path, not the ordinary current API.
  • Identity, account lifecycle and a particular resource-scoped ROA change are different evidence objects. A privacy-safe scope receipt can keep them distinct without exposing a key or a holder’s resources.

A key identifies an access path; it does not describe one change

The RIPE NCC RPKI Management API documentation is clear about the current perimeter. The service lets an LIR manage its Certificate Authority and ROAs through an API access key. Its documented operations include resource information, ROA creation and alert setup. The key is shown once when it is created; its stored form is hashed, and unused keys can be revoked.

That is useful security and product information. It is not, by itself, a record of the authority behind one later request. A key can be linked to an account, while a resource certificate, an exact ROA state, a requested operation and the result of that operation remain separate facts. Conflating them creates a tempting but unreliable shortcut: “an authenticated request happened” is made to stand for “the right actor was authorised for this bounded change, and the result can be reconstructed later.”

RIPE-843 supplies another important boundary. It says API keys are linked to a specific RIPE NCC Access account, and it describes deactivation if that account is disabled or the user is removed as an account maintainer in the relevant application. That is an account-lifecycle rule. It does not announce a public, per-request ledger of resource authority, and it does not need to. The point is simply that account identity and change scope are not interchangeable records.

The plan names a future identity mechanism and a rejected scope

RIPE NCC’s Q3 2026 RPKI Quarterly Planning page says the organisation is planning to replace current RPKI API keys with OpenID Connect based keys integrated with RIPE NCC Access. It also plans a dashboard section for managing those keys in the RPKI context. The published status is “Planned.” The page does not provide a deployment date, final token design or a public event schema for future changes.

The same page carries a sharper design constraint in its response to a proposed RPKI beacon. RIPE NCC says it could not yet add that beacon because the API used would allow editing ROAs for all RIPE NCC space, which it found unacceptable. This should be read precisely. It is not evidence that the ordinary RPKI Management API has an all-space write capability, nor evidence of an incident, a faulty key or an unauthorised ROA. It is public evidence that a proposed path was rejected because its potential authority perimeter was too broad.

That distinction makes the OIDC plan more interesting, not less. A move from one credential arrangement to another may improve account integration and key management. It does not automatically tell a reviewer what resource set a later change was allowed to affect. The rejected beacon path illustrates why the two questions should stay separate.

Keep a narrow receipt with each meaningful change

The answer is not to publish credentials, prefixes, autonomous-system numbers, customer details, raw API requests or operational configuration. Those disclosures would create risks without necessarily explaining a decision. The useful record is smaller.

For a material ROA change, a privacy-safe scope receipt could preserve the access-policy and implementation version; an actor or client class without a secret; the account context; a bounded authorised-resource set or protected digest; requested action; protected before-and-after state or state digests; the authorisation decision and execution times; outcome; any later publication observation; and a correction or supersession history. It can prove the shape of a decision without exposing the resources behind it.

This is an editorial design, not a RIPE NCC requirement. The cited pages do not say that such a receipt is absent from internal systems, and they do not prescribe its fields. They establish a narrower lesson: a planned identity mechanism, an account lifecycle and the scope of one state-changing action are different questions. Public reporting should not silently turn one answer into all three.

Sources