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

[Andrew Newton <[e-mail]>]

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.

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?

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.

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.
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.

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.

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.

-andy

On Mon, Oct 3, 2022 at 8:39 AM James Galvin <[e-mail]> wrote:
>
> REMINDER:
>
> This document is in WGLC and has only received support from its Editor and its Document Shepherd.
>
> To advance this document we need expressions of support from others to advance this document to the IESG to be considered for publication as a Proposed Standard.
>
> WGLC remains open through Monday, 10 October.  This document can not advance without support.
>
> Thanks,
>
> Antoin and Jim
> WG Co-Chairs
>
>
> On 26 Sep 2022, at 10:03, James Galvin wrote:
>
> > The document editors have indicated that the following document is ready for submission to the IESG to be considered for publication as a Proposed Standard:
> >
> > Federated Authentication for the Registration Data Access Protocol (RDAP) using OpenID Connect
> > https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/17/
> >
> > Please indicate your support or no objection for the publication of this document by replying to this message on list (a simple “+1” is sufficient).
> >
> > If any working group member has questions regarding the the publication of this document please respond on the list with your concerns by close of business everywhere, Monday, 10 October 2022.  If there are no objections the document will be submitted to the IESG.
> >
> > The Document Shepherd for this document is Zaid Al Banna.
> >
> > Thanks,
> >
> > Antoin and Jim
> > WG Co-Chairs
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext