> -----Original Message----- > From: Pawel Kowalik <kowa...@denic.de> > Sent: Thursday, February 2, 2023 1:59 AM > To: Hollenbeck, Scott <shollenb...@verisign.com>; regext@ietf.org > Subject: [EXTERNAL] Re: [regext] 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. > > 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.
[SAH] Yes, the concept of the session is directly related to the existence and validity of an Access Token, which may be refreshed. How would you suggest that this be reworded? > 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. [SAH] OK. > 3. The note about "Implicit Flow" - wouldn't "Security Considerations" > be a better place for this remark? [SAH] I like noting it where it's first mentioned, but yes, it could be mentioned in the "Security Considerations" section, too. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
