On Mon, Sep 26, 2022 at 10:03:35PM +0800, 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.
Looks good on the whole, some comments/questions:
Section 3.1.3.1 is titled 'Provider Discovery', and describes the
processes that an RDAP server might use to map an end-user identifier
to a provider. In other parts of the document, though, the term
'end-user identifier discovery' is used to similar effect, including
in the OIDC configuration response data structure: see 3.1.3, 4.1.3,
and 4.2.1. 'Provider Discovery' seems like the more accurate term to
use in each of these instances.
Section 3.1.3.1 has:
An RP can also ask an End-User to identify the OP that issued
their identifier as part of an RDAP query workflow. In this case,
the RP will need to maintain state for the association between the
user's identifier and the OP in order to process later queries
that rely on passing the access token and user identifier as
authorization parameters.
I think this text is no longer necessary now that the RDAP server
stores the user's tokens on the server side. (The original intent
here was to cover the case where the end user provided an access token
and a user identifier when submitting a query, but that is not an
option anymore with the current text.)
The distinction between 'default' and 'remote' authorization servers
could be clearer in the text (possibly in 3.1.2 or 3.1.3.1). (The
fact that an authorization server is either one or the other was not
apparent to me except after reading appendix A.)
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.
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.
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.
What should a logged-in end user see when they submit a standard RDAP
query, but their session has expired?
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.
If all requests are to use the GET method, it would be good to note
that in the text somewhere.
"notices" in an RDAP response should be an array of objects (RFC 9083
section 4.3), but is presented as a single object in each of the
examples in the document.
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"?
Is there any way to signal the result of an implicit token refresh
operation?
I agree with Andy's comments about it not being ideal that free-form
text is used to signal success/failure (e.g. when logging out).
-Tom
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
