[regext] Feedback to draft-ietf-regext-rdap-openid-12

[Pawel Kowalik <[e-mail]>]

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: [phone] | Fax: [phone]
E-mail: [e-mail] | 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.