Hi, I joined the IETF and this working group quite recently so my comments to this draft may appear to come a bit late and maybe were a part of past discussions. Apologies if it is so. With 10 years of experience in the domains industry and few recent years activity on identity federations based on id4me protocol, which is in fact OpenID Connect with DNS-based identifier discovery [1][2], and also maintaining few implementations of OAuth/OIDC libraries and OAuth-based tool client software, I think I can support this draft with valuable input.
TL; DR; Main issues I see around /session/login endpoint being a mix of RESTful and interactive design, userClaims passed to RDAP client, purpose claim from Identity Provider and necessity to always provide id parameter. In detail: 3.1.2. Overview The flow has the main focus on the browser-like client use-case, whereas rfc7480 specifies RDAP's objective to be possible to use it with simple scripting tools like "bash and wget". This assumption introduces few design decisions, which in result render inconsistent behaviors. In this terms /session/login end-point is on one side machine-friendly RESTful API, but in fact renders an HTTP redirect to a human-friendly interactive authorization website of the OP. On the other hand using /session/login for any scripting tool will render many obstacles, starting from the fact that most tools and frameworks will choose to follow http redirect instead of grabbing the Location header as an input for the process step. If the interactive part would be completed in the browser first, one would need to extract the cookies from the browser and inject them into the tool of his choice for further usage. Same if /session/login RESTful API would need to be used by a human-friendly browser front-end (AJAX), it wouldn't be able to do so because of the redirect issue. Afaik Javascript in a browser cannot access http headers. In fact device flow remains the only working option for the scripting tool like client, which will limit the number of OPs possible to use due to this flow not being as common as the standard code flow. My proposal would be to either make /session/login a fully interactive flow for humans, without any RESTful elements, or make it fully RESTful without the interactive part allowing also scripting tool clients to use the code flow. The second option would be my favorite however supporting both might be equally useful. Same design choices were actually made for OAuth2. Authorization end-point is interactive and meant for humans, while token end-point is for machine-2-machine interaction. 4.1.1. Session The draft specifies "userClaims" object being made available to the RP client.. What is it good for? Why is it needed? The claims and the user identity information are necessary for the RDAP server to make policy decisions about the data access, but not necessarily to the RDAP client. Avoiding transmission of PII when it's not necessary would support data minimization principle and increase data security. Note that the RDAP client might not be controlled by the end user and the end-user gives consent (in OP authorization step) about his personal data being shared with the RP (RDAP server) not to the RDAP client. If there is no particular reason to keep it I propose to remove the "userClaims" object. 3.1.4.1. Stated Purpose The draft proposes to state purpose in the claims of the user identity issued by the OP. In my opinion this is very much misplaced. Purpose describes the reason why the user wants to access certain resources of the RDAP server. In the very fine-granular way this is a property of each single RDAP request, because each request may be issued out of a different purpose. One may simplify the approach by attaching this property to the session. It must not be however attached as a property of an identity. This would exclude the use case that one and the same user would query RDAP with different purposes when acting in a different context. On the other hand, the RDAP server may need additional information from OP about an identity to determine which authorizations the user may have. This could be a list of purposes that OP allows the user to open a session with. Other claims may also be needed for certain policy decisions, this shall however remain out of scope of this specification and be mutually agreed between RDAP server and OP. The proposal would be to add a "purpose" query parameter to /session/login and /session/device end points and at the same time add an optional"rdap_allowed_purposes" claim (array of strings) to the user info claims instead of "purpose" claim. RDAP server would also need to have certain policies when onboarding OPs, to know whether "rdap_allowed_purposes" claim can be trusted from the OP and which values OP is allowed to claim. 4.2. Client Login The draft mandates an id parameter/Authorization header with an identifier of the end-user, which is in turn used to identify the identity provider used in the authentication process. This would be useful and workable if the discovery protocol would be used, however this is not mandated in 3.1.3.1. In practice, especially if "special purpose" IdPs come into play, one user identifier like email address may map to several IdPs and the discovery based on id won't even be possible. Also IdP may choose not to use identifiers at all (WebAuthN, FIDO or other kinds of passwordless flows) and only issue privacy-preserving pseudonymous "sub" claims. In these terms I think it's worth considering the authorization flow which would be initiated by the RDAP client passing only the indication of the IdP, through iss parameter, same as OIDC issuer. id parameter would be optional in this case, I would even propose to rename it to id_hint to reflect the same behavior of OIDC in this respect, as there is no obligation for id to match. [1] https://datatracker.ietf.org/doc/draft-sanz-openid-dns-discovery/ [2] https://datatracker.ietf.org/doc/draft-bertola-dns-openid-pidi-architecture/ Kind Regards, Pawel Kowalik Expert Domain Processes and Identity Domain Services 1&1 IONOS SE | Hinterm Hauptbahnhof 5 | 76137 Karlsruhe | Germany Phone: +49 721 91374-6571 | Fax: +49 7261 913538 E-mail: pawel.kowa...@ionos.com | Web: www.ionos.de Hauptsitz Montabaur, Amtsgericht Montabaur, HRB 24498 Vorstand: Hüseyin Dogan, Dr. Martin Endreß, Claudia Frese, Henning Kettler, Arthur Mai, Matthias Steinberg, Achim Weiß Aufsichtsratsvorsitzender: Markus Kadelke Member of United Internet Diese E-Mail kann vertrauliche und/oder gesetzlich geschützte Informationen enthalten. Wenn Sie nicht der bestimmungsgemäße Adressat sind oder diese E-Mail irrtümlich erhalten haben, unterrichten Sie bitte den Absender und vernichten Sie diese E-Mail. Anderen als dem bestimmungsgemäßen Adressaten ist untersagt, diese E-Mail zu speichern, weiterzuleiten oder ihren Inhalt auf welche Weise auch immer zu verwenden. This e-mail may contain confidential and/or privileged information. If you are not the intended recipient of this e-mail, you are hereby notified that saving, distribution or use of the content of this e-mail in any way is prohibited. If you have received this e-mail in error, please notify the sender and delete the e-mail. _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
