In addition to PeeringDB OAuth, propose that RPKI can also be used

[job]

RFC 9323 specifies a mechanism for Autonomous System holders to issue a signature over an arbitrary SHA256 message digest, then in turn, Relying Parties can verify this signature against the global RPKI.

This means that the Initiator and the Receiver can perform a challenge/response procedure based on the RPKI - which is cryptographically stronger than relying on PeeringDB's OAuth infrastructure.

The Initator and the Receiver can establish an arc of trust by having the Initator signal an arbitrary SHA256 hash over which the Receiver must produce a RPKI-RSC signature; the receiver can challenge the Initator in a similar manner. Once both parties have signed the other-party's challenge, both parties know that each party possesses access to private keys associated with the Autonomous Systems on both sides.

[caguado]

+1 on RFC9323 (or RTA too) to bind API requests to ASN holdership.

I would build on top of that to, instead of a dynamic challenge/response chain of trust between parties as I understand it, use the RSC/RTA to bind the INRs to a OAuth2 issuer via their well-known discovery point (RFC8414). This would allow to:

• reuse current identity management solutions based on bearer tokens for async validation
• maintain attestation of individual caller identities on API requests as well as the capability to constrain access to parts of the API defined in this doc via usual scopes or other claims
• extend the integrity checks to the entire API call payload, beyond reliance on a TLS transport, for proof of possession and HTTP signing when those become standard (e.g. RFC9449)

I would also defer this to a separate RFC process that builds atop this doc and now gather consensus on the peering API using a bespoke authz implementation.

[job]

The RTA proposal was abandoned by the working group. There are no implementations.

[jramseyer]

I like the idea of splitting it into two proposals, or having authentication be a "future work" part of this RFC.

Trying to tackle both the idea of a machine-to-machine peering API, and machine-to-machine API network verification seems like two related projects. We could put them all into one RFC, but I worry that we risk distracting ourselves in one or the other, and achieving neither. If you think it would be appropriate, I would propose we submit

• peering API, with "future work" or "proposed discussion" around authentication and different options
• (second) send an amendment or second RFC around API authentication for network configuration
  If you think it would be more appropriate just to file one, larger, RFC, please let me know and we can rescope.

[job]

Id stick it in one larger doc, that way people have a complete spec to look at.