From: Jasdip Singh <[email protected]>
Sent: Monday, February 14, 2022 10:34 AM
To: Hollenbeck, Scott <[email protected]>; [email protected]
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.
Hello Scott,
I like the overall direction of this draft to help simplify things for RDAP
clients and facilitate adoption, but wanted to share couple of observations:
1. There are 3 newly proposed RDAP path segments, starting with “login”,
“session”, and “logout”. Looks like, for simplicity, we could coalesce them as
“session/{start|refresh|end}”, with “login” becoming “session/start”, and
“logout” “session/end”. “device” and “devicepoll” could be appended in the path
as-n-when needed.
[SAH] What do you all think of this suggestion? The draft currently has
“login”, logout”, and “session” path segments. Should they be combined?
2. Wonder if we would be better-off defining a new RDAP object class called
“session” instead of overloading the current definition of a notice? IIUC, per
RFC 9083, “description” (in a notice object) is an array of strings for the
purposes of conveying any descriptive text. Looks like returning “claims” and
the session expiration info could use a new, more axiomatic structure instead.
Further, this should help RDAP clients avoid parsing descriptive text
(something not recommended) for the session semantics. Defining this new
“session” object class should also correlate well with the proposed coalescing
of the 3 new path segments into “session/…”.
[SAH] Agreed, this is a good idea.
Regards,
Jasdip
From: regext <[email protected]<mailto:[email protected]>> on
behalf of "Hollenbeck, Scott"
<[email protected]<mailto:[email protected]>>
Date: Monday, February 14, 2022 at 8:44 AM
To: "[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>,
"[email protected]<mailto:[email protected]>"
<[email protected]<mailto:[email protected]>>
Subject: Re: [regext] I-D Action: draft-ietf-regext-rdap-openid-10.txt
From: Mario Loffredo
<[email protected]<mailto:[email protected]>>
Sent: Monday, February 14, 2022 2:05 AM
To: Hollenbeck, Scott
<[email protected]<mailto:[email protected]>>;
[email protected]<mailto:[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/regext
