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).
/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
[...]
> > 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.
> > 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?
>
> > 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://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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
