Summary

  • ARIN’s 28 July 2026 release added a preferred Authorization-header method for Reg-RWS API keys. Its current Quick Start Guide still labels the older URL-query method Supported, and the 11 August migration guidance supplies no retirement date.
  • Moving a credential out of the URL materially reduces its accidental appearance in browser history, server logs, proxy logs and referrers. It does not make the header impossible to capture, and ARIN’s own blog uses the more accurate language of risk reduction.
  • The distinction matters because Reg-RWS can retrieve and modify registration records, create reassignments, submit ROAs and edit IRR objects. The sources establish no breach or misuse; they establish that one credential channel has a wider routine propagation surface.
  • A privacy-safe migration receipt should show which channels remain accepted, aggregate legacy-channel use, redaction coverage, notice and support milestones, the retirement gate, rejection behaviour and rotation guidance—without publishing a key, customer identity or raw log.

Two request shapes now sit side by side in ARIN’s public documentation. The recommended one sends Authorization: ApiKey [redacted]. The supported legacy shape appends ?apikey=[redacted] to the URL. Both reach Reg-RWS with authentication material. What differs is the trail that request infrastructure is likely to create around them.

This is not a cosmetic preference. A URL is routinely copied as a unit. It can enter browser history, command history, application diagnostics, access logs, proxy logs, monitoring records, screenshots and support messages. ARIN’s 11 August guidance names browser, server and proxy logs as specific places where a URL-carried key could end up. A header is separated from the resource identifier and is more likely to receive special handling as authentication metadata.

ARIN deserves credit for shipping that separation. The 28 July release made header authentication a preferred alternative and said the work had been completed with systems operating normally. The release also closed Suggestion 2022.5. Operators no longer need to place a reusable credential inside the requested resource’s address simply because that was the interface shape available to them.

But three states should not be compressed into the word “completed.” The capability is available. Client migration is still under way. Retirement of the URL channel is a future event. The Quick Start Guide explicitly presents header authentication as Recommended and URL authentication as Supported across GET, POST and PUT examples. The migration blog says URL use remains acceptable and “will eventually be retired,” without giving a date.

That compatibility window may be sensible. Registration automation can be embedded in scripts, orchestration systems, IP-address-management platforms and operational procedures that cannot all change on release day. A sudden rejection could interrupt record maintenance or routing-security work. Keeping both channels open gives operators time to modify clients, test error handling and rotate credentials that may have travelled through the older path.

Compatibility, however, preserves the very exposure surface the release is designed to reduce. The security outcome therefore depends on adoption, not only availability. Closing a suggestion proves that the requested feature was delivered. It does not prove that callers moved, that old URLs disappeared from retained records or that the legacy authentication path can yet be rejected safely.

ARIN’s documentation also contains a narrower accuracy problem. The Quick Start Guide says the header endpoint is designed to keep the key private by transmitting it within the call and “not allowing it to be captured at any point in the process.” That sentence is stronger than ARIN’s own blog, which says header placement “significantly reduces the chance of accidental exposure.” The blog’s formulation is the defensible one.

An Authorization header is still part of an HTTP request. Client libraries can expose it to debugging hooks. Reverse proxies and application servers can be configured to log headers. Tracing and observability systems can collect request metadata. Memory, crash dumps, support bundles and compromised endpoints can capture credentials regardless of whether they were placed in a URL or a header. TLS protects the request in transit between authenticated endpoints; it does not erase the credential from the systems legitimately handling it.

The IETF’s OAuth threat analysis makes the same distinction. RFC 6819 says URI-query tokens may leak into log files and referrers and recommends Authorization headers instead. It describes those headers as reducing the likelihood of leakage or unintended storage. It separately calls for appropriate logging configuration and restricted access to logs. The standard does not treat the header name as a guarantee that no component can record the value.

This does not show that ARIN logs Authorization headers, that a customer exposed a key or that any credential was abused. No such event appears in the frozen sources. The point is documentary precision: a safer channel should be described as reducing known propagation paths, not as making capture impossible. Absolute language can weaken otherwise sound guidance because operators may mistake a transport improvement for a complete secret-management control.

The authority carried by a Reg-RWS key makes precision consequential. ARIN says the service can retrieve and modify delegations and networks, manage organizations, Points of Contact and customers, add messages to tickets, submit Route Origin Authorizations, edit Internet Routing Registry objects and request reports. The actual authority of any call still depends on the account, POC links and the records it is permitted to manage. Moving a key into a header does not broaden or narrow those permissions. It reduces one way the credential can escape its intended request context.

That is why the public control should be a migration receipt rather than a declaration that the endpoint is secure. The receipt can remain aggregate and privacy-safe. It should name the release and documentation version; list which Reg-RWS operation families accept each channel; classify the header as recommended and the URL method as supported, deprecated or rejected; report the legacy channel’s share of calls over a stated window; and confirm the redaction boundary for URL, header, proxy, application and diagnostic logs.

It should also show the transition clock. Operators need the notice date, support period, deprecation milestones, final rejection date and rollback rule. A post-cutover request should fail in a documented way that does not echo the credential. Rotation guidance should cover keys previously placed in URLs, but it should not imply that every legacy caller has suffered exposure. Correction history matters because examples copied into scripts can outlive the page that originally published them.

No public metric needs to identify a customer. ARIN could report the proportion of authenticated calls using each channel, the number of operation families still seeing query credentials and the trend after each notice. Even those aggregates require care if a cohort is very small. The purpose is to prove that the old door can close without turning operational telemetry into a list of who has not migrated.

The current documentation already supplies the core state map. Header authentication became available on 28 July. It is recommended. Query authentication remains supported. Eventual retirement has been announced in principle. What is missing is the observable bridge between those states: how adoption will be measured, what completion requires and when the service will stop accepting a credential in the part of the request most likely to travel.

Sources