Summary

  • ARIN's ACSP suggestion 2011.17 asks for action, read/write and POC limits on individual API keys. Its public status is still Open.
  • ARIN estimated $1,458,000 in engineering work in April 2012 and last commented on the ticket in April 2018. That old estimate is a dated planning number; the public record has no current project price.

A key is supposed to open a door. In ARIN's public API documentation, the same kind of key can accompany registration changes, DNS work, RPKI requests and restricted report downloads. Mike Joseph looked at that arrangement in April 2011 and asked a smaller question than “Who owns the account?”: what may this particular key do after it has been copied into an automation system?

His suggestion was specific. A registrant should be able to limit a generated key to named RESTful or template actions, separate reading from writing for each type of change, and restrict it to one POC rather than every POC linked to an ARIN Online account. Joseph's operational scene was plain: a credential stored on a shared system can be seen by more people than the human it represents. Give that machine a key with fewer powers and the credential's reach narrows with the job.

ARIN initially proposed community discussion. In 2012, staff put the engineering estimate at approximately $1,458,000, plus substantial communications work, and warned that function-level controls could complicate code and confuse users. The last public comment, dated 10 April 2018, said the item was absent from that year's work plan and would be considered in a consultation on open suggestions. The current ACSP index still lists 2011.17 as Open. A fifteen-year-old ticket has outlived several generations of the systems it was meant to restrain.

The current API-key guide explains what a key does well: it identifies a user, can be deactivated, does not expire on its own, and can be reused across multiple interactions. People may create multiple keys to track requests locally. For REST calls, the linked POC must also have authority. These are useful controls, but they answer different questions. Identification tells ARIN whose account is speaking. POC authority tells it whether that account may make a request. Joseph wanted a third test inside the credential: whether this particular key may perform this particular act for this particular POC.

The guide does not document that third test. ARIN's public ticket supplies no later decision on 2011.17 after 2018; a published resolution or a current per-key scope specification would change this reading. Meanwhile, a user choosing between a broad automation credential and a cluster of role accounts has no public closure record to consult. ARIN can deactivate a key. The old request asks whether it can make the key smaller before it has to.