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@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