Re: [regext] Federated Authentication for Machine-to-Machine Interactions in RDAP

Andrew Newton <> Mon, 01 August 2022 20:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 3C642C1594A9 for <>; Mon, 1 Aug 2022 13:31:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=unavailable autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MkNUyMkxt89x for <>; Mon, 1 Aug 2022 13:31:09 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::e2f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by (Postfix) with ESMTPS id 397E0C14F723 for <>; Mon, 1 Aug 2022 13:31:09 -0700 (PDT)
Received: by with SMTP id j2so6025227vsp.1 for <>; Mon, 01 Aug 2022 13:31:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Tf6RYAxl16lSkVg4A3xK8O3mQFgdWMRgu5j8oLK4Glo=; b=4n4IlyoIwWnGIG1pyR1bCxup2PP/GGFzxWV4seL/5oS8nc1fpFAUoZOP/IaZI6xWwo EgvsXgvyvhi6NodKyULTuCICy+UARyE6NkMvEbwFEjqtCBMchF+899OI7qPnifs3srky U0HSK4O+2kDw3v36AP2C6FKA1j5j8mcSXzEqofWliEdign1nZWcgDkAuC0WM/5ASkzZK r+rKeWUubsn401K2wKyq/ov0uLA5IkIiMZwof6q9WNEaHi0Oc9EqjA2G3NjDwtTWLTm4 AqBc4ERLDAInauTiXgW+QxI+MJ9nc8npKlR/PIniFoQduWEkAMKi24MMPf8RfnbkBZDD CCaQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Tf6RYAxl16lSkVg4A3xK8O3mQFgdWMRgu5j8oLK4Glo=; b=egs+36yfXAfaeX3oQ9ehrUQPa2TG6zG7k5+MVgePXDHXtvQKeHQ0jWcs80wSGzA79B mM3O7Qc47rOhbCwokJnDvGDz8o7HTo7SbMuS38RUVJZj96ikaM5uqJ2hriSr70UDELwR X9HuxlgPXhpiLN4bQ+IU8+iz9RlI1rAh+Yb9YEXuc/GcxJlMqNWvwornzW/RPBi8BIar mv/P2nG4tvJNYF0KnZROUXEl9rKTclfhyBtvAMzxUjbJt+YMDrZpRpxXx0hqr6mMsBd5 TUZNRdjCOygJKYXpKJjtqYm4WU/44BnAmRPUyjPgZyt0T3Jbm9XNL6I8aLz6CHGgVo8l 2mKA==
X-Gm-Message-State: AJIora+tW+5J7gM+EU9t4GPiS1fKLLo6poC/DizChwb4vx7/LYLJbtec ZX0ByhfSscG3FFamq9Cj/vxQHYDF5nLk3xMaZT63mDK7z6dnmg==
X-Google-Smtp-Source: AGRyM1tHqd8KO9tfao+gBeIgjayS8FNIF73JBtF7JEuhGWE/9QNyy9c5uire0R473gCRn7HVEAjbebcs6zzgGOjDGYY=
X-Received: by 2002:a05:6102:2432:b0:357:4793:d267 with SMTP id l18-20020a056102243200b003574793d267mr6614967vsi.83.1659385867839; Mon, 01 Aug 2022 13:31:07 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Andrew Newton <>
Date: Mon, 01 Aug 2022 16:30:57 -0400
Message-ID: <>
To: Mario Loffredo <>
Cc: "Hollenbeck, Scott" <>, "" <>
Content-Type: text/plain; charset="UTF-8"
Archived-At: <>
Subject: Re: [regext] Federated Authentication for Machine-to-Machine Interactions in RDAP
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: Registration Protocols Extensions <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 01 Aug 2022 20:31:10 -0000

On Fri, Jul 29, 2022 at 7:59 AM Mario Loffredo
<> wrote:
> The authentication flows explored so far fit well the use cases where a
> human occasionally submits a request. The case of authenticated software
> agents submitting a lot of requests routinely doesn't find a practical
> solution in this draft. I would like to remind everyone that EU
> Parliament and EU Council has recently reached an agreement on core
> elements of the e-Evidence proposal. Therefore, I guess that soon we
> will have to figure out how to provide regular authenticated access to
> registration data to categories of users legitimated for their purposes
> such as authorities and cybercrime agencies.
> That being said, I see two big drawbacks in using the Client Credential
> flow, at least as is:
> - Client Credential flow is for trusted clients. Clients need to be
> registered by the OP before submitting a request for an access token.
> But, RDAP clients are generally untrusted and I don't consider scalable
> a solution where several RDAP clients are required to register by many
> OPs including the local ones. In the approach described in this draft,
> the trusted client is the RDAP server.
> - Roles and access grants are generally assigned to users not to
> clients. In addition, think there would be a potential risk of providing
> access to illegitimate users via legitimate clients.
> The Resource Owner Password Credential Flow would have fiited better but
> it has been rightly deprecated by OAuth. I'm afraid that a usage of CC
> Flow in a manner similar to the ROPC flow wouldn't be welcome by
> security experts.
> I would suggest to explore another approach where a third-party
> authority interconnects clients and servers that are mutually authenticated.

As long as one method is not to the exclusion of the others, I think
we should consider both types of use cases.

I agree that there are internet-wide scalability issues in an OP
handing out credentials to specific clients.
Yet, we have that today. LACNIC rate limits anonymous RDAP queries,
and those rate limits may
be exceeded if a client uses a LACNIC authorized credential.