> -----Original Message----- > From: Pawel Kowalik <[email protected]> > Sent: Monday, October 24, 2022 10:58 AM > To: Hollenbeck, Scott <[email protected]>; [email protected] > Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid- > 18.txt > > 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 Scott, > > Am 19.10.22 um 14:13 schrieb Hollenbeck, Scott: > >> > >>>> 1. How do we address web service clients? > >> [PK] I think the elements we need for web service clients were > >> already elaborated in the discussion over the version 17. > >> I'm happy to support with text proposal if needed. > > [SAH] Text would be appreciated. Something like this perhaps? > > > > 4.2.5 Web Service Clients > > > > <Paragraph that describes what a web service client is> > > > > 4.2.5.1 Web Service Client Login > > > > <Query parameters and/or path segment descriptions> > > > > 4.2.5.2 Web Service Client Session Management > > > > <Query parameters and/or path segment descriptions> > > > [PK] Please find attached my draft on Web Service Clients. Most of it is > based > on the concepts of the version 9. Scope "feature" is also included in the > proposal.
[SAH] I've been testing the proposed additions with my functionally-limited RDAP server. I've found two minor things so far: The tokens described in Section 4.2.5.2.1 should be placed in a named data structure. "farv1_tokens" could work. As described in RFC 6749, OP support for refresh tokens is OPTIONAL. As such, return of the refresh_token should be OPTIONAL. > Open point would be to add an optional possibility for > confidential/registered > clients and some security considerations. [SAH] Agreed. Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
