OAuth for RIRs - There is already any Idea like that?

Wed Mar 24 02:00:57 UTC 2021

The two proposals for RPKI signed attestatations, RSC and RTA, look
candidates for a role this. The primary question is not "who are you"
which OAuth is about, it is "what resources do you control, which
would inform what we're doing here" -which is what RPKI is about.

it's important to be clear, the RSC/RTA activity can't say who you
are. They don't provide identity. But, they do make a strong, provable
assertion of control over the INR in question.

If you want specifically what OAuth does, you're in a different place.
Its about who you are.

-G

On Tue, Mar 23, 2021 at 10:01 PM Douglas Fischer
<fischerdouglas at gmail.com> wrote:
>
> For me, every day it becomes more evident the need to validate information managed by the RIRs / NIRs / LIRs on separate information platforms.
>
> A very simple example is PeeringDB itself, which requires confirmation of correlation between the ASN whois contact and the account that is registering the organization.
>
> P.S.1: At least for me, this is more evident when it comes to numerical resources, but without going much deeper into the analysis, I believe that this is also applicable to name resources.
>
> I was wondering how complex it would be for RIRs / NIRs to implement some mechanism similar to the OAuth of NIC-Handler accounts to, through a delimitation protocol, allow accounts between information platforms to be correlated, information to be confirmed and maybe even inserted and updated.
>
> Still dreaming a little bit about the possibilities, I imagined that in a federation context, IANA or NRO could correlate NIC-Handlers from the same organization in different RIRs.
>
> In addition to the PeeringDB example, other uses (non-exhaustive list) of this solution could be:
>  - Linking between Maintainers of IRR bases and owners of resources in RIRs.
>  - Linking between accounts on the basis of IXPs, and ASN owners.
>  - Authentication and integration of RPKI CA Delegate services.
>
> I believe that we are already at a point where we can go beyond just using email confirmation.
>
> OAuth and similar protocols include benefits such as:
>  - Simplified use of cryptographic protections
>  - Specific definition of the duration of the authorization.
>  - Forced expiration of authorization.
>  - Granular definition of which attributes will have read-only or read and write access.
>
> I know that for a person with little experience everything seems possible, and for more hardened people things do not seem that simple.
> I also know that not everything in this world depends only on technological feasibility. For although there may be protocols and techniques to solve a problem, many questions depend on the layer 9 definitions of the OSI model.
>
> P.S.2: To be honest, I don't know if there are already initiatives in this direction from the point of view of making this a standard resource. But unless I am mistaken, https://www.denic.de/ already has something similar in place.
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação