> -----Original Message----- > From: regext <[email protected]> On Behalf Of Pawel Kowalik > Sent: Tuesday, October 11, 2022 11:42 AM > To: [email protected] > Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17 - > Clients > > Caution: This email originated from outside the organization. Do not click > links > or open attachments unless you recognize the sender and know the content is > safe. > > 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 > >> <[email protected]> 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. > > > >> 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.
[SAH] Since the draft already includes text that describes support for two different types of clients, I'm OK with the idea of adding (or re-adding) text that describes support for web service clients, too. The challenge is in deciding how to support those clients. Pawel, what I had in the earlier versions of the draft worked liked this: Client requests access, ID, and refresh tokens by sending a query to the RDAP server. RDAP server retrieves tokens from the OP and returns them to the client. The access token can then be passed to the server for use with an RDAP query by including the encoded token in an HTTP Bearer authorization header. Does this address the issue? I'm not confident that the token refresh and revocation descriptions in -09 are workable, though. It describes passing the refresh token as a query parameter; can that work? Can a refresh token be passed in an authorization header? Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
