Hi Pavel,
please find me comments below.
Il 11/10/2022 17:42, Pawel Kowalik ha scritto:
Hi Mario,
Am 11.10.22 um 16:38 schrieb Mario Loffredo:
Il 11/10/2022 15:04, Andrew Newton ha scritto:
On Tue, Oct 11, 2022 at 8:16 AM Mario Loffredo
<mario.loffr...@iit.cnr.it> wrote:
my humble opinion is that this document shouldn't deal with any
kind of RDAP client other than a browser.
Looking at the chapter 1 of this document, but also at chapter 3 and
3.1 there is no indication of such narrow usage of this specification.
Also 4.2.4. Clients with Limited User Interfaces indicates other
types of clients than the browser directly.
This is partailly true.
That section requires that the end user makes use of a second device
that is able to access a web browser.
The concept that the proposed approach is more tailored on brower-like
clients looks clear from the incipit of section 3.1.2 and from the
references to OAuth flows requiring the presence of an end user.
At the moment, I disagree with this. Authentication for non-browser
clients can be very useful. GitHub's client is a great example for
anybody who has ever needed Oauth/OpenID at the command line.
Andy, I didn't write that non-browser clients are unuseful.
On the contrary, I was the first here raising the question of how to
deal with non-browser clients that most likely will issue the biggest
number of requests to the RDAP servers.
I only expressed my concern about using for non-browser clients the
same approach used thus far. IMHO, the classic scheme based on
tokens fit better in that case while sessions are the best for end
users operating through a browser.
I can only agree to that concerns and as I understand till version 9
of this draft this was in fact the approach.
The browser use case was not supported well but all the others
including clients other than the browser.
I expected the document should eventually support both therefore I
raised the concerns about non browser clients not possible.
Until version 9, the tokens were delivered to the server in a manner
(i.e. through the query string) that has been deprecated by OAuth WG due
to security reasons.
Besides, the end user had to manage the tokens that, instead, are
normally managed by applications.
Therefore, Scott's choice to move to a more intuitive and more secure
approach based on sessions was welcomed by everyone.
I raised the question about how to deal with non-browser clients first
and proposed a solution requiring a client to get an access token
directly by the OP somehow and, then, include it as a bearer in the
requests to the RDAP server.
Normally, to get an access token, the clients are registered with the
OPs and, as such, are able to use other flows (e.g. Client Credential or
Resource Owner Password) reserved for trusted applications.
RDAP servers would be required to process an access token. Hence, a
server could manage either sessions or tokens or both.
If we are OK with that way to go, maybe it would be better to finalize
the document as is and let Scott write another document addressing the
case of non-browser clients.
That said, I would support any session-based secure solution for
non-browser clients.
With regard to GitHub, AFAIK non-browser clients can access a
repository either through an access token or via SSH key, anyway
nothing similar to the exchange of a session cookie, right ?
GitHub CLI and other this kind of tools typically use a form of OAuth
as well and store tokens locally.
Tokens precisely :)
Best,
Mario
Kind Regards,
Pawel
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
--
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web: http://www.iit.cnr.it/mario.loffredo
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
