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

From: Pawel Kowalik <[email-masked]>
Date: Mon, 11 Apr 2022 12:41:10 +0200

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: [email-masked] | 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.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 11 Apr 2022 14:26:41 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Pawel Kowalik
> Sent: Monday, April 11, 2022 6:41 AM
> To: [email-masked]
> 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.
> 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.

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

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

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

---

From: Pawel Kowalik <[email-masked]>
Date: Tue, 12 Apr 2022 09:32:24 +0200

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". H…

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

/session/login would output a JSON with a structure similar to the
proposed device flow

  {
    "rdapConformance": [
      "rdap_openidc_remote_level_0"
    ],
    "lang": "en-US",
    "notices": {
      "title": "Federated OpenID Connect Authentication required",
      "description": [
        "Login in progress",
        "user.idp.example"
      ]
    },
    "deviceInfo": {
      "authentication_url":
"https://www.example.com/auth?id_hint=user.idp.example&...",
      "expires_in": 1800
    }
  }

For the tools use-case, the tool would read out authentication_url and
ask the user to complete the flow in the web browser. This is the
interactive part you've mentioned.
The code flow in the browser needs to terminate on the RDAP server (or
another URL onboarded with IdP as allowed redirect_uri) with a page
displaying the code to the end-user, allowing him to copy it and
continue with his tool.
Here a real-life example how such page may look like:
https://dynamicdns.domainconnect.org/ddnscode?code=this-is-a-test-oauth-code-to-copy&state=null

Passing the code back to the tool and complete of OAuth code flow to
exchange for tokens requires a second end-point:
/session/finalizelogin?code=xxx

Response would be the success structure defined in 4.2

  {
    "rdapConformance": [
      "rdap_openidc_remote_level_0"
    ],
    "lang": "en-US",
    "notices": {
      "title": "Login Result",
      "description": [
        "Login succeeded",
        "user.idp.example"
      ],
    },
    "session": {
      "userClaims": {
...
      },
      "sessionInfo": {
        "tokenExpiration": 3599,
        "tokenRefresh": true
      }
    }
  }

That's true that the device flow works equally fine for this use case,
or even better as no input is required on the tool side.
My concern is that it's not as widely supported as the code flow, also
UX might be confusing as its intended use is about devices,
so allowing tools via code flow would be of benefit.

For the AJAX use-case, where the user is within the same session using
his browser, there is no need to copy the code manually, but in order
for the front-end to receive the code, the flow needs to terminate
with a page belonging to this front-end. As it is not possible to
register an URL belonging to a RDAP client directly on IdP, the
redirect needs to happen at the end of the interactive flow. Login
session would have to be initiated with this redirect_uri.

/session/login?id=...&redirect_uri=https://frontend.example.com/code

  {
    "rdapConformance": [
      "rdap_openidc_remote_level_0"
    ],
    "lang": "en-US",
    "notices": {
...
    },
    "deviceInfo": {
      "authentication_url":
"https://www.example.com/auth?id_hint=user.idp.example&...",
      "redirect_uri": "https://frontend.example.com/code",
      "expires_in": 1800
    }
  }

The front-end, after receiving the code on an own URI, can then
complete the flow same way with a REST call to /session/finalizelogin

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.

> > 4.1.1.  Session
[...]
> [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…

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.

> > 3.1.4.1.  Stated Purpose
[...]
> [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…

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?

> > 4.2.  Client Login
[...]
> [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 w…

Yes, iss parameter in a form of URL (same as the one in ID token) is
the most common one.
Example: https://idp.example.com/auth/realms/master/

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.

Pawel

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 12 Apr 2022 13:08:57 +0000

> From: Pawel Kowalik <[email-masked]>
> Sent: Tuesday, April 12, 2022 3:32 AM
> To: Hollenbeck, Scott <[email-masked]>
> Cc: [email-masked]
> Subject: [EXTERNAL] Re: [regext] Feedback to draft-ietf-regext-rdap-openid-
> 12
>
> > [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.

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

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

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

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

---

From: Pawel Kowalik <[email-masked]>
Date: Tue, 12 Apr 2022 16:37:56 +0200

> who've developed RDAP clients could share opinions.

[PK] fair enough

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

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

> 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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 12 Apr 2022 15:54:54 +0000

> Sent: Tuesday, April 12, 2022 10:38 AM

[SAH] [snip]

> [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?

[SAH] Please send proposed text to the list. I'm still doing this draft the old school way. 😉

Scott