Re: [regext] WGLC: draft-ietf-regext-rdap-openid-17

["Hollenbeck, Scott" <[e-mail]>]

Thanks for the feedback, Andy. More below...

> -----Original Message-----
> From: Andrew Newton <[e-mail]>
> Sent: Tuesday, October 4, 2022 10:37 AM
> To: REGEXT WG <[e-mail]>; Hollenbeck, Scott
> <[e-mail]>
> Cc: James Galvin <[e-mail]>
> 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