Hi Scott, It looks good, I have few minor points:
1. The new paragraph in Section 3 uses a term "bearer token". I suggest to use "Access Token" as a defined term (same in 6.2).
Also the "session" in this case can go beyond the lifespan of the Access Token if token refresh is possible.
2. In 3.1.2 maybe it is worth to state the obvious, that the server not supporting one or the other kind of client would not support Protocol Features - the data structures, path segments, parameters and interactions - for this kind of client. Common Protocol Features would be supported by both kind of clients.
I would also include a reference to the signaling of supported client types in 4.1.
3. The note about "Implicit Flow" - wouldn't "Security Considerations" be a better place for this remark?
Kind Regards, Pawel Am 01.02.23 um 17:36 schrieb Hollenbeck, Scott:
-----Original Message----- From: I-D-Announce <i-d-announce-boun...@ietf.org> On Behalf Of internet- dra...@ietf.org Sent: Wednesday, February 1, 2023 12:31 PM To: i-d-annou...@ietf.org Cc: regext@ietf.org Subject: [EXTERNAL] I-D Action: draft-ietf-regext-rdap-openid-21.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. A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Registration Protocols Extensions WG of the IETF. Title : Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect Author : Scott Hollenbeck Filename : draft-ietf-regext-rdap-openid-21.txt Pages : 48 Date : 2023-02-01 Abstract: The Registration Data Access Protocol (RDAP) provides "RESTful" web services to retrieve registration metadata from domain name and regional internet registries. RDAP allows a server to make access control decisions based on client identity, and as such it includes support for client identification features provided by the Hypertext Transfer Protocol (HTTP). Identification methods that require clients to obtain and manage credentials from every RDAP server operator present management challenges for both clients and servers, whereas a federated authentication system would make it easier to operate and use RDAP without the need to maintain server-specific client credentials. This document describes a federated authentication system for RDAP based on OpenID Connect.[SAH] This version addresses recent feedback provided by Julien Bernard and Mario Loffredo. Please let me know if I missed anything or if you see anything else that needs to be addressed. Julien, I just realized that I missed adding your name in the "Acknowledgments" section. I'll take car of that in -22. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
