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

["Hollenbeck, Scott" <[e-mail]>]

> -----Original Message-----
> From: regext <[e-mail]> On Behalf Of Pawel Kowalik
> Sent: Monday, April 11, 2022 6:41 AM
> To: [e-mail]
> Subject: [EXTERNAL] [regext] Feedback to draft-ietf-regext-rdap-openid-12
>
> Caution: This email originated from outside the organization. Do not click 
> links
> or open attachments unless you recognize the sender and know the content
> is safe.
>
> 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.

[SAH] Thanks for the feedback!

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

[SAH] I'm open to specific suggestions when you say "make /session/login a fully interactive flow for humans, without any RESTful elements, or make it fully RESTful without the interactive part". However, I believe that some interaction is required because the human user needs to be identified, authenticated, and authorized as part of the process when they request access to "protected" data. That means the human user MUST do *something*. Note that the draft already describes flows for both web-service-capable clients and clients with constrained user interfaces.

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

[SAH] I think it needs to be there so the client can show the end user what's being shared with the RDAP server operator and explicitly confirm that this is what the end user intends. I understand that the end user will have already provided permission to share certain bits of identifying information as part of the authentication process. Returning the claims to the client provides transparency in terms of what's been shared.

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

[SAH] The problem with using a purpose query parameter is that users will use whatever purpose gives them the "highest" level of access. The draft is currently written the way it is so that the set of allowable purposes is a function of the end-user's identity, and determination of which purposes are allowed (and which aren't) is a matter of negotiation between the end-user and their identity provider. As a server operator, I'm going to put more trust in the agreement I have with my set of acceptable identity providers than I will with any statements about query purposes received from end-users. What you've proposed above with the "rdap_allowed_purposes" claim is essentially already described in the draft, albeit using a different data structure.

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

[SAH] LOL, yes, we've had some past discussion about the discovery protocol and why it might not be the best solution. We could, of course, mandate that it be supported by any provider that works with RDAP, but I don't think that's workable. Can you share some examples of what the value of the iss parameter might look like? I'm assuming you're describing a URL that's identical to the iss claim value in ID Tokens issued from this issuer.

Scott