From: Mario Loffredo <mario.loffr...@iit.cnr.it> Sent: Monday, February 14, 2022 2:05 AM To: Hollenbeck, Scott <shollenb...@verisign.com>; regext@ietf.org Subject: [EXTERNAL] Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.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, here in the following some additional feedback: 1) In the introductory sections, nothing is written about the fact that an RDAP server outsources authentication services to an OP if the registry trusts that OP. I think that this is a pre-condition to make a federation and for this reason, in my opinion, it's worth being mentioned somewhere at the beginning of the draft. [SAH] OK, I’ll see what I can add. 2) It seems from the text of section 3.1.3 that dynamic registration is the only method available to register an RP. Instead, we all know that the most commonly used method to do that is manually through an out-of-band procedure. I think this alternative should also be mentioned to make section 3.1.3 consistent with the text in section 3.1.3.1 about the fact that an RDAP server can trust a limited number of OPs and out-of-band methods are used to implement the discovery process. If an RDAP server supports a limit number of OPs, it doesn't make sense that it is registered dynamically. [SAH] Agreed, I’ll add text to make it clear that out-of-band methods are both available and acceptable. 3) It seems from the draft content that the session expiring time is tied to the access token lifespan. Instead, in my experience with Keycloak, the session max idle time corresponds to the refresh token lifespan. Honestly, don't know if this happens in other OPs, anyway, I would opt for letting the RDAP server choose the basis to calculate the session expiring time upon and in Section 4.2 I would omit the sentence "... to refresh the access token associated with the current session and ...". [SAH] Agreed. The expiration value is only RECOMMENDED per the normative reference, so it really is up to the RDAP server to determine when things expire. In addition, in general, I would replace "token refresh" with "session refresh". After all, the endpoint that should be used for refreshing is called "session/refresh" and the final result to the End-User would be that the session lifetime is extended. [SAH] Agreed. 4) It doesn't make sense to me to return the claims in the response to the "session/refresh" query. Can they really change during the session? [SAH] They can’t, but I think it’s a good idea to return them so that the client has an easy way to retrieve that information at any time without having to logout and then login again. 5) If I understood well, a successful "session/refresh" query don't always result in resetting the session expiring time. How can the RDAP server decide to do that? [SAH] As noted above, it’s something that the RDAP server has to manage. I’d like to RECOMMEND and make it clear that the RDAP server SHOULD extend the duration of a session as part of processing a refresh, otherwise a refresh doesn’t do anything. Thanks again for the feedback! Scott
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
