> -----Original Message----- > From: Pawel Kowalik <[email protected]> > Sent: Tuesday, April 12, 2022 3:32 AM > To: Hollenbeck, Scott <[email protected]> > Cc: [email protected] > Subject: [EXTERNAL] Re: [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 Scott, > > Responses inline below. > > > > 3.1.2. Overview > [...] > > [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. > > [PK] My proposal would be first to focus on the RESTful variant, to make it > workable with a code flow for both tools scenario and frontend integration > scenario (AJAX with Javascript).
[SAH] [snip] > It may look a bit more complex compared to the proposal in the actual draft, > however this is how this flow would be actually workable for real-life use- > cases. > The Current draft is working well for a user interacting with RESTful API > via > web browser. This is not a real-life use in my eyes. [SAH] I need to think about this a bit. It's definitely more complicated than the approach described in the draft. It would be helpful if some other folks who've developed RDAP clients could share opinions. > > > 4.1.1. Session > [...] > > > 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. > > The user shall be already informed by the IdP what data is being shared > during the authorization step. > My point is that RDAP client != RDAP server. IdP only knows of RDAP server > and the user consents data share with RDAP server (this is what is being > shown to the user as OIDC client data in the authorization step). RDAP > client > is unknown to the user and what is more concerning, RDAP client is also not > authenticated to the RDAP server, so in fact an unknown actor. > This raises my concern about passing PII of the end user to the RDAP client. > In fact the same applies to the PII contained within RDAP responses further > down the line. [SAH] "RDAP client is unknown to the user"? How can this be when the user selects the client and deliberately chooses to use it? Mario had the same suggestion to not return the claims when we first discussed this several weeks ago. I'm not firm in my conviction to return it, but I would like to hear other opinions. Again, it would be helpful if a client developer could chime in and confirm or deny the utility of returning the claims. If it's not something the client would use, then I agree that there's no need to return them. > > > 3.1.4.1. Stated Purpose > [...] > > > 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. > > I don't understand "purposes" as an ordered list of always growing levels of > access. I understand each purpose may render a different set of grants on > data sets or data representations, so there is no clear "highest" level of > access. Let's say "technicalIssueResolution" allows for access to full techC > data, while "legalActions" allows access to RegC and AdminC. > An actor may have an allowance to use both (by specifying > "rdap_allowed_purposes": ["technicalIssueResolution", "legalActions"] at his > IdP) and this is the negotiation between the end-user and his IdP. RDAP > server operator may in turn say that this IdP is only allowed for > "technicalIssueResolution" purpose, narrowing down the authorization for > identities issued by this IdP. Another RDAP server operator may onboard the > same IdP for both purposes. The end user would then state the purpose by > opening the session, which will then be authorized or not based on the > claims issued by his IdP and the allowed purposes of this IdP at the RDAP > server. > Is it now more understandable where I am heading to? [SAH] It is, but I still think this is something that'll be abused. If, for example, we assume that the "criminalInvestigationAndDNSAbuseMitigation" purpose allows the highest level of access for authorized users, it's a safe bet that we'll frequently see that value used as a query parameter whether a user is authorized to use it or not. This will lead to authorization failures when it's not matched to the set of allowed purposes that are associated with the end-user's identity. I see the theoretical value is using the parameter on a per-query basis, but I question the practical value of doing so. > > > 4.2. Client Login > [...] > > > 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. > > Yes, iss parameter in a form of URL (same as the one in ID token) is the > most > common one. > Example: https://secure- > web.cisco.com/1o9tlOzGqHwoCwx_Y6l5DRIIuyOeTTqp5Rlr8njWhJNtTOcYdF6 > RkyV3XQeJDH8SNsb1TVhFmD9_94x6nj34xFpSMTgvkMnv7Df2jN9nXXAYmgig > pk7_LtoamNqkPB9pGu2e48FnaNGAWhHOxiDZ9uVlUzCZ4HLEmt7MSLGsS5V > pAZFCnM3C85vZTMPJkSeEKR01rBuoomB0CfNST1K5- > UIIjr_HdRtObI0itRcaFTmtXEBD4l1Z0BADIB81c4Ra6/https%3A%2F%2Fidp.exa > mple.com%2Fauth%2Frealms%2Fmaster%2F > > As per OIDC discovery specification appending .well-known/openid- > configuration to the iss URL renders a OIDC configuration document. > > If both RDAP server and IdP support dynamic client registration (which is > more commonly supported compared to discovery) then it may also connect > to this IdP automatically. > > As an extension it might be beneficial for an RDAP server to list its > capabilities > in the /help end point, to list the IdPs supported and dynamic registration > capability. > This way a front-end integrated with this RDAP server may render a choice of > IdPs the user may use and then start the RDAP session with this server. [SAH] This might work, but I'm not a fan of dynamic registration in this context. If we can assume that client software will submit a /help query to retrieve the list of supported IdPs, the user can be given the opportunity to select one and they won't have to worry about finding issuer URLs by themselves. That sounds useful. Scott _______________________________________________ regext mailing list [email protected] https://www.ietf.org/mailman/listinfo/regext
