Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-18.txt

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: Pawel Kowalik <[e-mail]>
> Sent: Monday, October 24, 2022 10:58 AM
> To: Hollenbeck, Scott <[e-mail]>; [e-mail]
> 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