On Tue, 12 Apr 2022 at 15:09, Hollenbeck, Scott <shollenb...@verisign.com> wrote: > > > -----Original Message----- > > From: Pawel Kowalik <pawel.kowa...@ionos.com> > > Sent: Tuesday, April 12, 2022 3:32 AM > > To: Hollenbeck, Scott <shollenb...@verisign.com> > > Cc: regext@ietf.org > > Subject: [EXTERNAL] Re: [regext] Feedback to draft-ietf-regext-rdap-openid- > > 12 > >
> [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. [PK] fair enough > [SAH] "RDAP client is unknown to the user"? How can this be when the user > selects the client and deliberately chooses to use it? [PK] In the worst case we should consider phishing/scam scenarios where the user may be tricked into using an unintended client. > > 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. [PK] yes, per query is the other extreme which may not have any practical use. On the other hand, based on my experience, change of any claim via IdP is complicated, as long as it is a managed claim, not a self-managed claim. In this case we are for sure talking about a managed claim that would be assigned to a user based on some review/policy for the highest allowance purposes. That's why the purpose assigned to a session (a parameter to /login end point) seems to be the right balance. If authorization is not sufficient, the authorization would fail on this level not opening an active session. > > > > > 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. [PK] sure, not insisting on dynamic registration. How do you want to proceed with drafting the text update? Do you maintain the test somewhere on github or alike where I could chip in a proposal? Pawel _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
