Thanks for the feedback, Andy. More below... > -----Original Message----- > From: Andrew Newton <[email protected]> > Sent: Tuesday, October 4, 2022 10:37 AM > To: REGEXT WG <[email protected]>; Hollenbeck, Scott > <[email protected]> > Cc: James Galvin <[email protected]> > 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. > > Scott (and the WG), > > My apologies for not taking the time to do a more read of this document > earlier. Overall, I believe it to be good. And I believe it to cover the > range of > features I have seen discussed in the various RDAP circles. Below you will > find > my comments. > > Section 3.1.2 could benefit from a sequence or ladder diagram.
[SAH] OK, I'll see what I can come up with. > In Sections 4.1.1 and Sections 4.1.2, there are TTLs for the session and > device. > These are expressed in relative seconds, but from reading this I cannot > determine the relation. Could or should these be absolute time values? [SAH] They're provided by the IdP and relative to the start of the session. I'll make that clear in the text. > In Section 4.2.1, is there a reason both forms of signaling the end user > identifier > must be used? Can we just pick one? Or make one MANDATORY to support? > From a security standpoint, it might be best to use the Authentication > header. [SAH] They're both there as a matter of being liberal in what we'll accept from clients. Some clients, like a web browser, make it more difficult for a human user to provide an authorization header. The query parameter is much easier. > In Section 4.2.3, a notice MUST be supplied with login successes and > failures. I > think the notice should be a MAY and not a MUST as the client will know the > success/failure based on the farv1_session. [SAH] OK, agreed. > Furthermore, the draft should probably give examples of what might be in > those notices. Such as when login success, the notice may indicate any > limited > scope of use, etc... and for failure, a more descriptive reason for the > failure. > > I have a similar concept for Section 4.2.4.1 as with Section 4.2.3. > Furthermore, is it possible to signal a failure with a farv1_deviceInfo > structure? > Otherwise, the client is left to determine the failure on the notice > structure, > making the text a formal signaling mechanism. If the failure is indicated by > a > lack of farv1_deviceInfo structure, that needs to be explicitly stated. [SAH] Agreed again. I'd like to provide non-normative examples of success and failure notices and refer to the definition of the notice data structure in RFC 9083 for the details. > For the Do Not Track feature in Section 4.3.2, it is unclear to me what a > server > should respond with if the user requests farv1_dnt=true but the policy does > not > allow it for that user. The draft says return a 501 Not Implemented, but a > 401 > or 403 seems more appropriate. [SAH] Agreed, I'll change it to 403 since retrying won't make a difference. > Section 4.4, 4.5, and 4.6, same comment about notices as section 4.2.3. I > guess I > am a bit uneasy with free form text being used to signal success/failure. > > In Section 4.7, the server responds to unrecognized identification with a > 501. I > think this should be 400, unless the server is required by policy to > understand > the information. [SAH] Agreed, 400 makes more sense. Thanks again! Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
