Thanks for the feedback, Tom! More below... > -----Original Message----- > From: regext <regext-boun...@ietf.org> On Behalf Of Tom Harrison > Sent: Monday, October 10, 2022 10:13 AM > To: James Galvin <gal...@elistx.com> > Cc: REGEXT WG <regext@ietf.org> > Subject: [EXTERNAL] Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17 > > 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. > > On Mon, Sep 26, 2022 at 10:03:35PM +0800, James Galvin wrote: > > The document editors have indicated that the following document is > > ready for submission to the IESG to be considered for publication as a > > Proposed Standard: > > > > Federated Authentication for the Registration Data Access Protocol > > (RDAP) using OpenID Connect > > https://secure-web.cisco.com/1mN6tUlcmJ1U5d7u- > OmVXsrpQm42sBtGh4xZNtMSU > > > y0temnHZrQ0NAMbF4hWDrtaG5d3YxjJ6J4qMLdQwfdtY07Vz6xrhxhc4c62sVJwx > Db6h9W > > > MdxsH0uMTiA9AEiwD6ajWTxBPTziQP1bXLUkpQa5ibHpQDaxDdW5r8Wstvibtzf > QuyDCx4 > > > t8rKNhV_zkp9W5OODbmBUTw2ZGGATJhOjonaK6PtjMDT4V3pdRL0KKrSNDDgB > yzLLZgK74 > > 3jCYUI/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-ietf-regext-rd > > ap-openid%2F17%2F > > > > Please indicate your support or no objection for the publication of > > this document by replying to this message on list (a simple “+1” is > > sufficient). > > > > If any working group member has questions regarding the the > > publication of this document please respond on the list with your > > concerns by close of business everywhere, Monday, 10 October 2022. > > If there are no objections the document will be submitted to the IESG. > > > > The Document Shepherd for this document is Zaid Al Banna. > > Looks good on the whole, some comments/questions: > > Section 3.1.3.1 is titled 'Provider Discovery', and describes the processes > that > an RDAP server might use to map an end-user identifier to a provider. In > other > parts of the document, though, the term 'end-user identifier discovery' is > used > to similar effect, including in the OIDC configuration response data > structure: > see 3.1.3, 4.1.3, and 4.2.1. 'Provider Discovery' seems like the more > accurate > term to use in each of these instances.
[SAH] OK, I'll change the text to use "provider discovery" consistently. > Section 3.1.3.1 has: > > An RP can also ask an End-User to identify the OP that issued > their identifier as part of an RDAP query workflow. In this case, > the RP will need to maintain state for the association between the > user's identifier and the OP in order to process later queries > that rely on passing the access token and user identifier as > authorization parameters. > > I think this text is no longer necessary now that the RDAP server stores the > user's tokens on the server side. (The original intent here was to cover > the case > where the end user provided an access token and a user identifier when > submitting a query, but that is not an option anymore with the current > text.) [SAH] Agreed. > The distinction between 'default' and 'remote' authorization servers could > be > clearer in the text (possibly in 3.1.2 or 3.1.3.1). (The fact that an > authorization > server is either one or the other was not apparent to me except after > reading > appendix A.) [SAH] OK, I'll see what I can do. > In section 4.1.1, the "farv1_session" data structure has a member called > "clientID", defined as being "a string value that represents the client > identifier > associated with the session". The example indicates that this value is > meant to > be that provided by the user as the "farv1_id" argument to the "login" > endpoint. > However, "client identifier" in the OIDC context (per RFC 6749) is an > identifier > specific to the RDAP server, rather than the end user. It would be better > if this > member were called "endUserID" or similar to avoid confusion. [SAH] How about "userID"? > Following on from the previous point, "clientID" appears to be mandatory in > the > "farv1_session" data structure (since "userClaims" > and "sessionInfo" are both expressly marked "OPTIONAL"), but if the end user > does not provide an identifier during the login process, the RDAP server may > not know what the identifier is, since there's no requirement that it be > returned > in the ID token or similar. Possibly this field should just be removed from > the > "farv1_session" structure. [SAH] I'd prefer to make it OPTIONAL instead of removing it completely because there's value in confirming the identity in the response if it's possible to do so. > Section 4.2.3 has: > > The response to the login request MUST use the response structures > specified in RFC 9083 [RFC9083]. > > Since 'response structures' is not further defined, it's possible that this > could be > confusing. Suggested change: > > The response to the login request MUST comprise members that would > be valid in an RDAP "/help" response, per RFC 9083 [RFC9083]. > > Since a "/help" response may contain all of the common top-level RDAP > response members. [SAH] The intention here is that the response should include any/all "standard" response data structures, such as RDAP conformance, notices, links, etc. Instead of specifically referring to a "/help" response, would this be clearer? "The response to the login request MUST contain all structures specified in RFC 9083 [RFC9083] that are appropriate for a protocol response ." > What should a logged-in end user see when they submit a standard RDAP > query, but their session has expired? [SAH] The query should be processed as if no identification/authentication information is available. The response should be whatever is appropriate based on processing the query under those circumstances. > Section 4.2 has: > > Additionally, an active session MAY be removed by the server due > to timeout expiration or because a maximum session lifetime has > been exceeded. > > Removing an active session due to timeout expiration will inhibit attempts > to > manually refresh that session. It may be worth including some text here > warning about that, and noting that removing sessions after some additional > grace period has elapsed after expiry may make things easier on end users. [SAH] How about something like this: "Clients SHOULD proactively monitor the tokenExpiration value associated with an active session and refresh the session as appropriate to provide a positive user experience." > If all requests are to use the GET method, it would be good to note that in > the > text somewhere. > > "notices" in an RDAP response should be an array of objects (RFC 9083 > section > 4.3), but is presented as a single object in each of the examples in the > document. [SAH] OK, that needs to be fixed. > Section 4.8 has: > > If a client sends any request that includes an unknown HTTP > cookie, the server MUST return an HTTP 409 (Conflict) error. > > What is an "unknown HTTP cookie"? [SAH] It's a cookie that isn't associated with a known session. Would "request that includes an HTTP cookie that isn't associated with a known session" be better? > Is there any way to signal the result of an implicit token refresh > operation? [SAH] The tokenExpiration value will be updated as sessions are refreshed, but I don't see a way of pushing that information a client directly. The updated value will be returned in a "farv1_session/status" response, so if the client is proactively monitoring the session as described above it'll be able to detect implicit refresh successes. > I agree with Andy's comments about it not being ideal that free-form text is > used to signal success/failure (e.g. when logging out). [SAH] Agreed and understood. Scott _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
