> -----Original Message----- > From: Tom Harrison <[email protected]> > Sent: Monday, October 10, 2022 7:16 PM > To: Hollenbeck, Scott <[email protected]> > Cc: [email protected]; [email protected] > Subject: [EXTERNAL] Re: 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. > > Hi Scott, > > On Mon, Oct 10, 2022 at 06:39:30PM +0000, Scott Hollenbeck wrote: > >> 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"? > > Thanks, sounds good. > > >> 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. > > Yep, makes sense. > > >> 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 ." > > Although the example will help to clarify things, this text reads to me like > all of > the optional response members must be included. Also, the fact that > "appropriate for a protocol response" should be interpreted as limiting the > response to common members may not be immediately obvious. What about: > > The response to the login request MUST be a valid RDAP response, > per RFC 9083 [RFC9083]. It MUST NOT include any members that > relate to a specific RDAP object type (e.g. "events", "status").
[SAH] OK, I can live with that. > >> 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. > > I think it would be better if the user got some sort of error response in > this > instance, possibly 401. If the server is configured e.g. to include > additional > entity information in an authenticated response, but nothing else > distinguishes > the response from one that's unauthenticated, then a client with an expired > session might not realise that they are getting unauthenticated responses. > (The > client could look at the expiration time in the session data structure to > determine when to refresh/reauthenticate, but there's no guarantee that the > session will not be evicted or similar prior to that time.) [SAH] After thinking about this a bit more, I think you're right. A difference between submitting a query after a session has expired and submitting a query in the absence of an authenticated session would be that the former would be accompanied by a session cookie and the latter would not, correct? If so, I agree. The RDAP server will be able to associate the first query with an expired session, it will know that the second isn't associated with a session, and it can provide an appropriate error for either situation. > >> 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." > > Yep, this works. On this topic more generally, though, the document doesn't > discuss the validity period of the refresh token as against that of the > access > token. tokenExpiration is about the access token's validity, but the > refresh > token may expire much later than the access token. If the intent is that > the > session be treated as non-existent if the access token expires prior to > refresh, > it's probably worth noting that explicitly in the document as well. > > >> 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? > > Yep, I think that would 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. > > The problem here is similar to that where an end user's session expires and > it's > not possible for the end user to distinguish an authenticated response from > an > unauthenticated response. Assuming a > 401 can be returned in that other case, then returning a 401 here when > implicit > token refresh fails might work? [SAH] I think you're right here, too. Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
