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").
>> 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.)
>> 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?
-Tom
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
