Hi Roman, The concerns of this document are largely specific to OpenID Connect, and not vanilla OAuth, but of course many of us in the community overlap and I’m happy to help provide some feedback here. I’m not familiar with RDAP, so if any of my concerns are addressed by other aspects of the RDAP ecosystem, I would be happy to be corrected.
That said, I believe parts of the approach are fundamentally flawed as it conflates the RS and client roles in a potentially dangers and certainly confusing way. Some thoughts as I read through this: §3.2.1: - there seems to be some conflation of the RP and RS roles here in the RDAP server; it seems more proper that the RDAP server is the RS, and the RDAP client is the RP (the same as the OAuth client); this seems to stem from a problem with how the RDAP server actually gets user claims, see paragraph below for more §3.1.3: - this seems to assume the authorization code grant type; though this is explained a little bit more in 3.1.4.2, it’s not clear that other grant types are supported here within this protocol - the first section on “session-oriented clients” conflates the end-user with the client (to wit: "An RDAP client (acting as an OpenID End-User)”); consequently it’s unclear who is getting “redirected” or interacting at any step; more properly, it seems that the end-user is interacting with the RDAP client to initiate the flow, which is borne out in the diagram More importantly, in this section it becomes clear that the core of the specification’s “token-oriented” approach relies on the RDAP client passing the access token to the RDAP server and then having the RDAP server replay that same token to the OpenID IdP in order to get user claims. It is not considered good practice to have the RS replay the access tokens it receives to an external party, and on the surface this could potentially be exploited by an attacker. This also fails under sender-constrained token usage, wherein the RDAP client would need to also share key material with the RDAP server in order for the latter to use the token. A better pattern would be a profile of OAuth Token Introspection (RFC7667) wherein user information could be specified. This would also allow the RDAP server to authenticate its call to the OpenID IdP. Introspection was designed specifically to allow the RS to call back to the AS to determine what (and who) a token is for, and it provides an extensible mechanism for doing so. An alternative would be to profile the access token itself to contain user information in a format readable by the RDAP server. More on this in the note for §6.3 below. §3.1.5.1 - The registry information here should be in a separate IANA section that is forward-referenced from here - which parties are responsible for validating the allowed purposes claims? Does the IdP need to know the list of allowed purposes applicable to the RS (RDAP server)? §4.1 - I appreciate that the fav1 data structure separates the applicable flags into a clear substructure, which will be easier to process as an extension to existing code §4.2 - RFC3986 doesn’t actually specify the key=value format normatively; these days, that belongs to the HTML URL specification from WHATWG and so I would recommend that this reference be used instead: https://url.spec.whatwg.org/#application/x-www-form-urlencoded<https://url.spec.whatwg.org/> §4.2.1 - is it really the case that a client can only request a single purpose, but multiple can be authorized? I’m not an expert in the RDAP world, but this would seem to be quickly turn insufficient as purposes are not required to be completely separate and distinct from each other in the registration section §4.3 - I think this section was probably meant to be a subsection of 4.2? §5.1.1 - OpenID Connect does not define a single global string value for a user identifier; instead only the tuple of issuer and subject are considered suitably unique; ergo, the UserID value in the data structure would need to have either a construction method or some other specification, or to have this declared as RDAP-server-specific explicitly §5.1.2 - this seems to replicate RFC8628, OAuth Device Flow, without any of the implementation detail or security considerations of that specification; furthermore, the device flow isn’t specified in OpenID Connect (which is being profiled here) though its use is far from unheard of in practice; this use is further expanded in §5.2.4, but it’s unclear that that’s why this is here §5.2.1 - I’m unclear when reading this whether the identifier in question is an OAuth client_id or a user identifier, as the text seems to indicate it can be either; these represent drastically different things, and one could argue that separating the identity of the client software from the identity of the end-user is the entire point of OAuth and protocols like it - Ultimately this seems to be a discovery step for RDAP, and so I would expect to see more types of identifiers that could be used for discovery purposes, such as user-facing identifiers like email addresses or phone numbers if that’s the goal - Significant effort is currently being proposed in the OAuth WG for dealing with the inherent security issues of multi-device authorization issues like this; this draft would do well to incorporate some of that §5.2.4.2 - the device code is included here as a query parameter instead of a body parameter, what’s the purpose of that? As written it’s incompatible with RFC8628, which is claims to be a profile of (eg, "This request performs the polling function described in...”) §6.3 - if the token is intended to be used in proxy as stated in §6.2, then the validation here is redundant as an invalid token would not return claims listed in this step; I would suggest that the pattern in §6.2 be removed entirely and instead the validation patterns in §6.3 be expanded into a full profile §6.4 - Token exchange is generally targeted for access tokens, not ID tokens; it seems that this is part of the conflation between RS and RP in this mode §11 - The security considerations section is remarkably thin for a protocol of this nature, and I would especially expect more discussion on how to select which mode of operation and for which purposes In closing, I think the “token-oriented” approach has major problems in that it seems to be encoding an anti-pattern without a lot of guidance for why it would be applied. But to reiterate, I am not an expert in the RDAP ecosystem, so if any of these concerns are addressed by that ecosystem I am ignorant of those considerations. — Justin On Sep 28, 2023, at 11:32 AM, Roman Danyliw <r...@cert.org> wrote: Hi! I deferred this document to Thursday, October 5 telechat. If anyone has time to review this document, it would be appreciated. Roman -----Original Message----- From: Roman Danyliw Sent: Friday, September 15, 2023 3:29 PM To: oauth <oauth@ietf.org> Subject: Review of draft-ietf-regext-rdap-openid Hi! I wanted to raise awareness that on next week's IESG telechat draft-ietf-regext-rdap-openid will be reviewed. See https://datatracker.ietf.org/doc/draft-ietf-regext-rdap-openid/. This document provides normative guidance on using OpenID and OAuth to secure the RDAP ecosystem (https://datatracker.ietf.org/wg/regext/about/). Given that this is the core expertise of the WG, if there are cycles, additional reviewed would be welcome. Thanks, Roman _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
