Subject: Re: [regext] id_token parameter usage in rdap-openid

From: Tom Harrison <[email-masked]>
Date: Tue, 11 Jan 2022 21:03:19 +1000

Hi Mario,

On Fri, Dec 17, 2021 at 11:54:57AM +0100, Mario Loffredo wrote:
> Il 17/12/2021 06:59, Tom Harrison ha scritto:
>> On Thu, Nov 11, 2021 at 11:51:13AM +0100, Mario Loffredo wrote:
>>> I open a separate discussion about the usage of the id_token parameter as
>>> defined in the rdap-openid document.
>>> 
>>> The document states in section 5.2 that the id_token MUST be passed in the
>>> query string.
>>> 
>>> IMO, there are some drawbacks coming from it:
>>> 
>>> - I intended that the purpose of this parameter is enabling server operators
>>> to make fine-grained access control decisions based on the claims about the
>>> authenticated end-user. However, the same claims can be obtained by
>>> accessing  the standard OIDC /userinfo  endpoint
>>> (https://openid.net/specs/openid-connect-core-1_0.html#UserInfo) using the
>>> Access Token. Only the server operators willing to refine their access
>>> control based on claims would eventually make use of such OIDC feature. Note
>>> also that the /userinfo endpoint returns a JSON response that is much easier
>>> to process than a JWT. Finally note that access control is normally based on
>>> user roles that can be stored in the Access Token.
>>> 
>>> - removing the id_token parameter would save server operators to check and
>>> signal possible inconsistencies between the id_token and the access_token;
>>> 
>>> - stripping the id_token would significantly shorten the query string and,
>>> consequently, provide benefits to all the players. End-users would deal with
>>> leaner queries, clients could save memory, servers' logs would be less
>>> cumbersome and more readable;
>>> 
>>> - a JWT can be decrypted and the id_token may potentially include many PIIs.
>>> It isn't recommended to send PIIs as parameters of a query string even when
>>> the request is issued over an SSL connection.
>>> 
>>> The only advantage I found is that it would save server operators from
>>> querying the /userinfo endpoint each time the required claims are needed.
>>> 
>>> If so, I think that the issues outweigh the benefits and I would opt for its
>>> removal.
>> I'm not sure that it's possible to remove the ID token parameter from
>> the document, at least as it's currently written.  If no ID token is
>> provided, then the RDAP server will have only an access token to work
>> with, and the RDAP server must treat that token as opaque, since it's
>> a relying party (only the resource server can interrogate the access
>> token).  If all that the RDAP server gets is an opaque access token,
>> then it won't know which authorization server to contact in order to
>> verify that access token, so it won't be able to verify that the user
>> is authorized.
> 
> In theory, RFC6749 does not mandate any specific format for the access token
> but, in practice, many Auth 2.0 implementations has elected to use JWT (see
> https://www.rfc-editor.org/rfc/rfc9068.html#name-introduction).
> 
> Hence, RDAP clients would probably be required to send an unnecessary ID
> Token.

But the relying party must treat the access token as opaque,
regardless of whether it uses JWT or similar.  From RFC 9068:

    6.  Privacy Considerations

       As JWT access tokens carry information by value, it now becomes
       possible for clients and potentially even end users to directly
       peek inside the token claims collection of unencrypted tokens.

       The client MUST NOT inspect the content of the access token:
       the authorization server and the resource server might decide
       to change the token format at any time (for example, by
       switching from this profile to opaque tokens); hence, any logic
       in the client relying on the ability to read the access token
       content would break without recourse.  The OAuth 2.0 framework
       assumes that access tokens are treated as opaque by clients.

> Secondly, the oauthwg "OAuth 2.0 Security Best Current Practice" draft (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-19#section-4.3.2)
> forbids the delivery of the access token as a query parameter. Such a
> statement furtherly enforces the recommendation done by RFC6750
> (https://www.rfc-editor.org/rfc/rfc6750.html#section-2.3). Despite this, we
> affirm that, not only the access token, but also the ID token are issued as
> query parameters, which appears to me much worse because surely the ID Token
> is not opaque and presumably it includes many PII elements.
> 
> Finally, as described in RFC9068, the access tokens normally include "roles"
> and "groups" that are the most commonly used claims to make access control
> decisions.
> 
> For the reasons above, I'm inclined to remove both the tokens from the query
> string and make the access token be issued only through the "Authorization"
> request header field.
> 
> When the access token is opaque and more than an OP supporting the RDAP
> seerver , the RDAP server will have to store somewhere the relationship
> between the access token and the OP and validate the access token by
> querying the /userinfo or the /introspect endpoints. The former would be
> preferable when the RDAP server needs additional claims about a user. But I
> guess this would be the exception rather than the rule.

Possibly the simpler way to deal with the underlying problem here is
to have the RDAP server be responsible for token storage/management,
rather than passing that off to the client.  If the RDAP server
maintains knowledge of the client in some other way (e.g. via a
cookie), then the problems with the transmission of token information
become moot.  This does mean that the RDAP server needs to maintain
some state, but that doesn't seem like a serious problem.  It also
means the flow is more like conventional OIDC, which may help from an
analysis/review perspective.

-Tom

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 14 Jan 2022 09:19:55 +0100

Hi Tom,

sorry for the delay in replying.

My comments are below.

>         assumes that access tokens are treated as opaque by clients.

[ML] I think that in the sentence above the term "client" refers to the 
frontend application that is normally used in the classic OIDC pattern.

In that pattern, the client does not need to inspect the access token 
because it contains only information useful for the resource server.

On the contrary, I'm much more worried about what is stated in the 
subsequent paragraphs of the same section of RFC 9068:

In scenarios in which JWT access tokens are accessible to the end
    user, it should be evaluated whether the information can be accessed
    without privacy violations (for example, if an end user would simply
    access his or her own personal information) or if steps must be taken
    to enforce confidentiality.

Possible measures to prevent leakage of information to clients and
    end users include: encrypting the access token, encrypting the
    sensitive claims, omitting the sensitive claims or not using this
    profile, and falling back on opaque access tokens.

Based on the content of rdap-openid draft, an end user could be able to 
access the information stored in a JWT token.

Therefore, my proposal is to let the RDAP operators use the access token 
format as they see fit. If the access token is a JWT, it SHOULD/MUST not 
include sensitive information.

As an additional note, such paragraphs enforce the concept that the ID 
token should not be exchanged between the client and the server in RDAP 
because for sure the ID token is decryptable and includes sensitive 
information.

> analysis/review perspective.

[ML] If I understood well, it seems to me you are proposing to 
drastically review the draft.

I'm not saying that it is a wrong proposal but it would simply result in 
refactoring the document. We should give answer to some questions, such 
as: should the /tokens endpoint still be useful? which information 
should the token response contain? how could refreshment be requested ?

I think we should also consider the session management as an alternative 
to passing always the access token but without making large changes.

Best,

Mario

>
> -Tom
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

-- 
Dr. Mario Loffredo
Technological Unit “Digital Innovation”
Institute of Informatics and Telematics (IIT)
National Research Council (CNR)
via G. Moruzzi 1, I-56124 PISA, Italy
Phone: +39.0503153497
Web:http://www.iit.cnr.it/mario.loffredo

---

From: Tom Harrison <[email-masked]>
Date: Mon, 17 Jan 2022 11:07:14 +1000

Hi Mario,

On Fri, Jan 14, 2022 at 09:19:55AM +0100, Mario Loffredo wrote:
>>>> I'm not sure that it's possible to remove the ID token parameter
>>>> from the document, at least as it's currently written.  If no ID
>>>> token is provided, then the RDAP server will have only an access
>>>> token to work with, and the RDAP server must treat that token as
>>>> opaque, since it's a relying party (only the resource server can
>>>> interrogate the access token).  If all that the RDAP server gets
>>>> is an opaque access token, then it won't know which authorization
>>>> server to contact in order to verify that access token, so it
>>>> won't be able to verify that the user is authorized.
>>>
>>> In theory, RFC6749 does not mandate any specific format for the
>>> access token but, in practice, many Auth 2.0 implementations has
>>> elected to use JWT (see
>>> Hence, RDAP clients would probably be required to send an
>>> unnecessary ID Token.
>>
>>         As JWT access tokens carry information by value, it now
>>         becomes possible for clients and potentially even end users
>>         to directly peek inside the token claims collection of
>>         unencrypted tokens.
>> 
>>         The client MUST NOT inspect the content of the access
>>         token: the authorization server and the resource server
>>         might decide to change the token format at any time (for
>>         example, by switching from this profile to opaque tokens);
>>         hence, any logic in the client relying on the ability to
>>         read the access token content would break without recourse.
>>         The OAuth 2.0 framework assumes that access tokens are
>>         treated as opaque by clients.
> 
> [ML] I think that in the sentence above the term "client" refers to
> the frontend application that is normally used in the classic OIDC
> pattern.

That's right.  A "client" that uses OIDC is referred to as a "relying
party" in the OIDC context, too.  In the draft, the RDAP server is a
"client" per OAuth 2 and a "relying party" per OIDC.

> In that pattern, the client does not need to inspect the access
> token because it contains only information useful for the resource
> server.

I don't understand this point.  Even if the (OAuth) client might make
use of the information in the access token, the (OAuth) client is not
permitted to inspect it, and must treat it as if it were opaque.

> Based on the content of rdap-openid draft, an end user could be able
> to access the information stored in a JWT token.
>
> Therefore, my proposal is to let the RDAP operators use the access
> token format as they see fit. If the access token is a JWT, it
> SHOULD/MUST not include sensitive information.
> 
> As an additional note, such paragraphs enforce the concept that the
> ID token should not be exchanged between the client and the server
> in RDAP because for sure the ID token is decryptable and includes
> sensitive information.

I think the text quoted above is about including content in ID/access
tokens that should not be exposed to the (OAuth) client or the (OAuth)
end-user at all, rather than about content that should not be exposed
to unrelated third parties.  Given that providing the ID token to the
(OAuth) client is an essential part of the OIDC flow, it's unlikely
that the ID token will contain information that shouldn't be exposed
to the (OAuth) end-user.  (That's not to say that information like
this should be passed around unnecessarily, given that extra transport
generally introduces additional risks around exposure to unrelated
third parties.)

>> Possibly the simpler way to deal with the underlying problem here
>> is to have the RDAP server be responsible for token
>> storage/management, rather than passing that off to the client.  If
>> the RDAP server maintains knowledge of the client in some other way
>> (e.g. via a cookie), then the problems with the transmission of
>> token information become moot.  This does mean that the RDAP server
>> needs to maintain some state, but that doesn't seem like a serious
>> problem.  It also means the flow is more like conventional OIDC,
>> which may help from an analysis/review perspective.
> 
> I'm not saying that it is a wrong proposal but it would simply
> result in refactoring the document. We should give answer to some
> questions, such as: should the /tokens endpoint still be useful?
> which information should the token response contain? how could
> refreshment be requested ?

Without having thought about this in detail:

 - The /tokens endpoint would no longer be useful, and would be
   removed.
 - Assuming that the RDAP server is able to use cookies to maintain
   session state with relevant RDAP clients, then the RDAP server
   could handle token refresh transparently.  In the event that the
   token was expired and could not be refreshed, the RDAP server would
   prompt the user to authenticate again.

> I think we should also consider the session management as an
> alternative to passing always the access token but without making
> large changes.

I don't think having it as an alternative to the current approach is a
good idea.  The motivation for adding it is to address the concerns
raised around how tokens are passed around.  If there is another way
to address those concerns, I'd prefer that that change be made and
there be a single 'path' for implementors to follow.

-Tom

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 17 Jan 2022 10:58:16 +0100

Hi Tom,

please find my commnets inline.

> permitted to inspect it, and must treat it as if it were opaque.

[ML] What I meant to say is that in the OIDC reference interaction 
pattern, the RDAP server would act as a Resource Server. An RDAP client 
would act as a Relying Party.

Normally, the RP, that is a frontend for the RS, is a trusted 
application and it doesn't need to inspect the access token. On the 
contrary, the RS inspects tha access token to make access control decisions

based on some claims designed for being included in the access token 
such as groups, roles, entitlements.

In the draft, an RDAP client is normally untrusted so the RDAP server 
acts as an RP but we cannot ignore that the RDAP server is still an RS.

I think that both the OAuth and the OIDC actors was defined for the 
reference pattern so we cannot apply them to the draft pattern 
straightforwardly because otherwise we'll face some inconsistencies.

For example, now the mostly used access token format is JWT. Such a 
format is perfectly consistent with the reference pattern because it 
isn't normally exchanged outside a trusted context.

So, with reference to the draft, we cannot say that  the access token 
MUST be opaque but we can say that it MUST be treated as opaque by the 
RDAP client and, anyway, it MUST NOT include sensitive information.

In addition, we cannot say that the RDAP server MUST treat the access 
token as opaque because it is normally inspected by the RS.

Definitively, we have two patterns: the classic one that is likely to be 
currently used in practice and the one proposed by the draft that in my 
opinion should be harmonized with the former to make them coexist.

Hope I made myself clear.

> generally introduces additional risks around exposure to unrelated
[ML] Agreed.
>     prompt the user to authenticate again.
[ML]  Personally, I wouldn't object to your proposal.
> there be a single 'path' for implementors to follow.

[ML] My suggestion was based on the assumption to maintain the basic 
principles of the current document.

Anyway, if there was a consensus on reviewing radically the document to 
be more compliant with the OIDC reference pattern, I would be pleased.

Best,

Mario

Web: http://www.iit.cnr.it/mario.loffredo

---

From: Tom Harrison <[email-masked]>
Date: Wed, 19 Jan 2022 09:14:13 +1000

Hi Mario,

On Mon, Jan 17, 2022 at 10:58:16AM +0100, Mario Loffredo wrote:
>>>>          becomes possible for clients and potentially even end
>>>>          users to directly peek inside the token claims
>>>>          collection of unencrypted tokens.
>>>> 
>>>>          example, by switching from this profile to opaque
>>>>          tokens); hence, any logic in the client relying on the
>>>>          ability to read the access token content would break
>>>>          without recourse.  The OAuth 2.0 framework assumes that
>>>>          access tokens are treated as opaque by clients.
>>>
>>> [ML] I think that in the sentence above the term "client" refers
>>> to the frontend application that is normally used in the classic
>>> OIDC pattern.
>>
>> That's right.  A "client" that uses OIDC is referred to as a
>> "relying party" in the OIDC context, too.  In the draft, the RDAP
>> server is a "client" per OAuth 2 and a "relying party" per OIDC.
>> 
>> I don't understand this point.  Even if the (OAuth) client might
>> make use of the information in the access token, the (OAuth) client
>> is not permitted to inspect it, and must treat it as if it were
>> opaque.
> 
> pattern, the RDAP server would act as a Resource Server. An RDAP
> client would act as a Relying Party.
> 
> In the draft, an RDAP client is normally untrusted so the RDAP
> server acts as an RP but we cannot ignore that the RDAP server is
> still an RS.
>

The only difference I can see between the approach used in the draft
and the approach described in the OIDC specification is that the
relationship between the RDAP server and the RDAP client is maintained
by passing the tokens back to the RDAP client, and having the RDAP
client include them in requests to the server.  I don't think this
makes the RDAP server an (OAuth) resource server, or the RDAP client
an (OAuth) client.  The fact that the RDAP server makes authorisation
decisions based on the information provided to it by the OpenID
provider doesn't change this.  It seems to me to be analogous to an
(OIDC) relying party (an (OAuth) client) making authorisation
decisions based on the "acr" claim in the ID token (e.g., per the OIDC
documentation: "[a]uthentications with level 0 SHOULD NOT be used to
authorize access to any resource of any monetary value").

> So, with reference to the draft, we cannot say that  the access
> token MUST be opaque but we can say that it MUST be treated as
> opaque by the RDAP client and, anyway, it MUST NOT include sensitive
> information.
> 
> In addition, we cannot say that the RDAP server MUST treat the
> access token as opaque because it is normally inspected by the RS.

I think updating the document in this way makes it sufficiently
different from the standard OAuth/OIDC model that ensuring that it
retains all the important properties of those models will be
difficult.  The fact that the RDAP client gets the ID token and access
token is a little unusual as it is (IME), but turning the RDAP server
into a sort of hybrid (OAuth) client and (OAuth) resource server,
along with guaranteeing the format and claims in an access token, goes
quite a bit further than that.  This may all be moot, though, if using
cookies (or similar) to maintain a session between the RDAP client and
RDAP server is acceptable.

> ...
> Anyway, if there was a consensus on reviewing radically the document to be
> more compliant with the OIDC reference pattern, I would be pleased.

Does anybody else have any input on this?

-Tom

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 19 Jan 2022 13:22:04 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Tom Harrison
> Sent: Tuesday, January 18, 2022 6:14 PM
> To: Mario Loffredo <[email-masked]>
> Cc: [email-masked]
> Subject: [EXTERNAL] Re: [regext] id_token parameter usage in rdap-openid

[SAH] snip

> The only difference I can see between the approach used in the draft and
> the approach described in the OIDC specification is that the relationship
> between the RDAP server and the RDAP client is maintained by passing the
> tokens back to the RDAP client, and having the RDAP client include them in
> requests to the server.  I don't think this makes the RDAP server an (OAuth)
> resource server, or the RDAP client an (OAuth) client.  The fact that the 
> RDAP
> server makes authorisation decisions based on the information provided to it
> by the OpenID provider doesn't change this.  It seems to me to be analogous
> to an
> (OIDC) relying party (an (OAuth) client) making authorisation decisions 
> based
> on the "acr" claim in the ID token (e.g., per the OIDC
> I think updating the document in this way makes it sufficiently different 
> from
> the standard OAuth/OIDC model that ensuring that it retains all the
> important properties of those models will be difficult.  The fact that the 
> RDAP
> client gets the ID token and access token is a little unusual as it is 
> (IME), but
> turning the RDAP server into a sort of hybrid (OAuth) client and (OAuth)
> resource server, along with guaranteeing the format and claims in an access
> token, goes quite a bit further than that.  This may all be moot, though, if
> using cookies (or similar) to maintain a session between the RDAP client and
> > Anyway, if there was a consensus on reviewing radically the document
> > to be more compliant with the OIDC reference pattern, I would be pleased.
>

[SAH] I wonder if the changes made in -09 are helpful or not in the context of 
this discussion. It's worth re-reading the draft to be sure.

Anyway, after thinking about it a bit I don't think we have an issue with 
sessions. I'm working with the following assumptions:

1. Every RDAP query is a discrete transaction between an RDAP client and an 
RDAP server.
2. Every access token has a validity period.
3. Every RDAP request that requires federated authentication/authorization 
includes an access token.
4. Access tokens can be refreshed when they get close to the end of their 
validity period.
5. An RDAP query that doesn't include an HTTP Authorization header should be 
treated as a request that does not require authentication/authorization.

I don't see the need for additional session management features if these 
assumptions are valid. A "session" is tied to the validity period of the 
access token. The client requests tokens from the RDAP server (using a /tokens 
query) and is authenticated as a result of making that request. If the client 
can be authenticated, they receive a set of tokens that can be used for 
subsequent queries. The client provides the access token with each query that 
requires authentication/authorization. The client refreshes the access token 
(sending the refresh token to the RDAP serve using a /tokens query and a query 
parameter) as needed, and there's no need for the server to maintain 
additional state information.

Am I missing something?

Scott

---

From: Tom Harrison <[email-masked]>
Date: Thu, 20 Jan 2022 12:08:51 +1000

On Wed, Jan 19, 2022 at 01:22:04PM +0000, Scott Hollenbeck wrote:
> [SAH] I wonder if the changes made in -09 are helpful or not in the
> context of  this discussion. It's worth re-reading the draft to be
> sure.

It looks like the key update is that the ID token is no longer passed
to the RDAP server by the RDAP client, with the user's identifier
taking the place of that token.  However, if the RDAP server has only
an access token and a user identifier, it won't be able to determine
definitively the authorisation server that it needs to contact to
verify that token (I don't think the user's identifier is sufficient
for a 1:1 mapping to an authorisation server in this respect).
Possibly another option is to pass back the 'iss' claim from the ID
token to the RDAP client, and have the RDAP client provide that claim
on each request.

> Anyway, after thinking about it a bit I don't think we have an issue
> with sessions. I'm working with the following assumptions:
> 
> 1. Every RDAP query is a discrete transaction between an RDAP client
> and an RDAP server.
> 3. Every RDAP request that requires federated
> authentication/authorization includes an access token.
> 4. Access tokens can be refreshed when they get close to the end of
> their validity period.
> 5. An RDAP query that doesn't include an HTTP Authorization header
> should be treated as a request that does not require
> authentication/authorization.
> 
> I don't see the need for additional session management features if
> these assumptions are valid. A "session" is tied to the validity
> period of the access token. The client requests tokens from the RDAP
> server (using a /tokens query) and is authenticated as a result of
> making that request. If the client can be authenticated, they
> receive a set of tokens that can be used for subsequent queries. The
> client provides the access token with each query that requires
> authentication/authorization. The client refreshes the access token
> (sending the refresh token to the RDAP serve using a /tokens query
> and a query parameter) as needed, and there's no need for the server
> to maintain additional state information.
> 
> Am I missing something?

The above is fine (IMHO, as somebody without any particular experience
in OAuth/OIDC/security) save for the need to map the request to a
given authorisation server.  If returning the 'iss' claim to the RDAP
client and having the RDAP client include that on subsequent requests
solves that problem, while also addressing the concerns around the use
of the ID token, then maybe that's the only extra thing that needs to
happen.  (My suggestion about cookies was mostly about trying to head
off the possibility of the RDAP server inspecting the access token
directly.)

-Tom

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 20 Jan 2022 14:41:06 +0000

> From: Tom Harrison <[email-masked]>
> Sent: Wednesday, January 19, 2022 9:09 PM
> To: Hollenbeck, Scott <[email-masked]>
> Cc: [email-masked]; [email-masked]
> Subject: [EXTERNAL] Re: Re: [regext] id_token parameter usage in rdap-
> openid

[SAH] [snip]

> It looks like the key update is that the ID token is no longer passed to the
> RDAP server by the RDAP client, with the user's identifier taking the place 
> of
> that token.  However, if the RDAP server has only an access token and a user
> identifier, it won't be able to determine definitively the authorisation 
> server
> that it needs to contact to verify that token (I don't think the user's 
> identifier
> is sufficient for a 1:1 mapping to an authorisation server in this respect).
> Possibly another option is to pass back the 'iss' claim from the ID token to 
> the
> RDAP client, and have the RDAP client provide that claim on each request.

[SAH] According to the OpenID Connect Discovery protocol, it *is* possible to 
determine the OpenID Provider based on the identifier alone and out-of-band 
means. See:

https://openid.net/specs/openid-connect-discovery-1_0.html#IssuerDiscovery

So, I think we have that covered.

> > making that request. If the client can be authenticated, they receive
> > a set of tokens that can be used for subsequent queries. The client
> > provides the access token with each query that requires
> > (sending the refresh token to the RDAP serve using a /tokens query and
> > a query parameter) as needed, and there's no need for the server to
> > maintain additional state information.
> >
> > Am I missing something?
>
> The above is fine (IMHO, as somebody without any particular experience in
> OAuth/OIDC/security) save for the need to map the request to a given
> authorisation server.  If returning the 'iss' claim to the RDAP client and 
> having
> the RDAP client include that on subsequent requests solves that problem,
> while also addressing the concerns around the use of the ID token, then
> maybe that's the only extra thing that needs to happen.  (My suggestion
> about cookies was mostly about trying to head off the possibility of the 
> RDAP
> server inspecting the access token
> directly.)

[SAH] Understood!

Scott

---

From: Mario Loffredo <[email-masked]>
Date: Thu, 20 Jan 2022 15:40:40 +0100

Hi Scott and Tom,

> token to the RDAP client, and have the RDAP client provide that claim

[ML] To Tom:

Sorry but I didn't catch how the user identifier is sufficient to 
determine the Authorization Server in order to obtain the access token 
but then is no more sufficient when the same access token needs to be 
validated.

The 'iss' claim (passed as a parameter instead of the "id" parameter 
once the access token has been obtained) can be helpful to save the RDAP 
server to run the discovery process at every request, However, the 
issuer is included in the ID Token so, unless such information was 
included in the /tokens response, it should be obtained by decrypting 
the ID token.

>> to maintain additional state information.

[ML] To Scott:

I mentioned the session managment because I have a little feeling that 
the OIDC pattern described in the draft may result in a inefficiency if 
the OP implements session management but, honestly, cannot estimate its 
extent.

Session management is an optional OIDC feature.  In addition, I'm only 
experienced with a local OP, specifically Keycloak, implementing the 
session management and I don't know how many OPs operate in the  same 
manner.

Just to summarize the matter, in OIDC session managment, once the 
end-user has been authenticated, a session (in place of an access token) 
is exchanged between the web browser and the RP. As a consequence, in 
order to comply with the draft spec, the RDAP server (acting as an RP in 
the draft) would be required to invalidate the session at every response 
and regenerate the security context starting from the access token at 
every request.

I just presented my experience so if you think the draft shouldn't 
address this topic, I'm OK.

Best,

Mario

---

From: Tom Harrison <[email-masked]>
Date: Fri, 21 Jan 2022 08:26:20 +1000

On Thu, Jan 20, 2022 at 02:41:06PM +0000, Scott Hollenbeck wrote:
>> It looks like the key update is that the ID token is no longer
>> passed to the RDAP server by the RDAP client, with the user's
>> identifier taking the place of that token.  However, if the RDAP
>> server has only an access token and a user identifier, it won't be
>> able to determine definitively the authorisation server that it
>> needs to contact to verify that token (I don't think the user's
>> identifier is sufficient for a 1:1 mapping to an authorisation
>> server in this respect).  Possibly another option is to pass back
>> the 'iss' claim from the ID token to the RDAP client, and have the
>> RDAP client provide that claim on each request.
> 
> [SAH] According to the OpenID Connect Discovery protocol, it *is*
> possible to determine the OpenID Provider based on the identifier
> alone and out-of-band means. See:
> 

But it's not guaranteed that every user identifier will be associated
with a host that is implementing issuer discovery.  For example, an
RDAP server might be configured to use multiple authorisation servers,
each of which permits the use of arbitrary email addresses as
identifiers.  Because each permits arbitrary email addresses, it's not
possible to use a simple mapping from the domain of the email address
to the authorisation server.  The RDAP server is then reliant on
issuer discovery being implemented by the email host, but there's no
guarantee that it will be (Gmail doesn't implement it, for example).
If an RDAP server has some specific out-of-band means for mapping
identifiers to authorisation servers, then it could rely on that, but
that may not be possible in all situations.  The RDAP server then has
to fall back to requesting that the user select an authorisation
server during the login process: this is fine, but it means that the
RDAP server is receiving extra information during the login process
that it won't have available to it during subsequent token-based
requests.

-Tom

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 21 Jan 2022 15:10:02 +0000

> Sent: Thursday, January 20, 2022 5:26 PM
> Subject: [EXTERNAL] Re: Re: Re: [regext] id_token parameter usage in rdap-
> openid
>
> 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.
>
> >> Subject: [EXTERNAL] Re: Re: [regext] id_token parameter usage in
> >> rdap- openid
> >
> > [SAH] [snip]
> >
> > https://secure-web.cisco.com/18PfVwBIpVxxYoyT6xsN-1-
> IefbAjsVTLIbWTRUzM
> >
> 9B8GxvyvkjwdPUNBmxgDrU68dej6y85b2k_rE7tIVWHPm1nwOJIMXDC9n9F8
> NcdMqjOydL
> > 3U8oBBrvfeCEvR_uMlK5H9AKeSO-
> rl_ZPBPe6DoNG2K3yczOw3cF84mAhUY0DM-dOiqdzd
> > s_laawBFj9OmBnWfbXMunQzGuVkBvu5nwZ1IZnZ6_cQhdVaQZ9bY-
> _PkVdlMDJ_P6NQAMr
> > Q1ePif/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-
> discovery-1_0
> > .html%23IssuerDiscovery
> >
> But it's not guaranteed that every user identifier will be associated with a
> host that is implementing issuer discovery.  For example, an RDAP server
> might be configured to use multiple authorisation servers, each of which
> permits the use of arbitrary email addresses as identifiers.  Because each
> permits arbitrary email addresses, it's not possible to use a simple mapping
> from the domain of the email address to the authorisation server.  The RDAP
> server is then reliant on issuer discovery being implemented by the email
> host, but there's no guarantee that it will be (Gmail doesn't implement it, for
> example).
> identifiers to authorisation servers, then it could rely on that, but that may
> not be possible in all situations.  The RDAP server then has to fall back to
> requesting that the user select an authorisation server during the login
> process: this is fine, but it means that the RDAP server is receiving extra
> information during the login process that it won't have available to it during
> subsequent token-based requests.

[SAH] Hmm, Google used to support webfinger with Gmail. I can't find anything that says they've discontinued the service, but the resources I used in the past can't be found at their old locations.

If we can't assume that discovery based on attributes of the identifier is reliable, what can we do? Out-of-band negotiation/configuration is one method, or we can ask the user/client to somehow identify the Identity Provider when they request tokens. That sounds more complicated than I'd prefer, but do we have any other options?

Scott

---

From: Tom Harrison <[email-masked]>
Date: Mon, 24 Jan 2022 08:11:13 +1000

On Fri, Jan 21, 2022 at 03:10:02PM +0000, Scott Hollenbeck wrote:
> On Fri, Jan 21, 2022 at 08:26:20AM +1000, Tom Harrison wrote:
>> But it's not guaranteed that every user identifier will be
>> associated with a host that is implementing issuer discovery.  For
>> example, an RDAP server might be configured to use multiple
>> authorisation servers, each of which permits the use of arbitrary
>> email addresses as identifiers.  Because each permits arbitrary
>> email addresses, it's not possible to use a simple mapping from the
>> domain of the email address to the authorisation server.  The RDAP
>> server is then reliant on issuer discovery being implemented by the
>> email host, but there's no guarantee that it will be (Gmail doesn't
>> implement it, for example).  If an RDAP server has some specific
>> out-of-band means for mapping identifiers to authorisation servers,
>> then it could rely on that, but that may not be possible in all
>> situations.  The RDAP server then has to fall back to requesting
>> that the user select an authorisation server during the login
>> process: this is fine, but it means that the RDAP server is
>> receiving extra information during the login process that it won't
>> have available to it during subsequent token-based requests.
> 
> [SAH] Hmm, Google used to support webfinger with Gmail. I can't find
> anything that says they've discontinued the service, but the
> resources I used in the past can't be found at their old locations.
> 
> If we can't assume that discovery based on attributes of the
> identifier is reliable, what can we do? Out-of-band
> negotiation/configuration is one method, or we can ask the
> user/client to somehow identify the Identity Provider when they
> request tokens. That sounds more complicated than I'd prefer, but do
> we have any other options?

No, I don't think there are other options.  But given that login is an
interactive process anyway, asking them to select an identity provider
at that point doesn't sound like too much of a problem.

-Tom

---

From: Mario Loffredo <[email-masked]>
Date: Mon, 24 Jan 2022 09:15:43 +0100

> at that point doesn't sound like too much of a problem.
Please note that except for authorization, token and userinfo endpoints, 
all the other endpoints are optional so if we can't assume that a 
webFinger server exists, the same should go for the other OP endpoints

recalled in this draft.

As opposed to the fact that the discovery metadata endpoint seems to be 
provided by many OPs, dynamic client registration doesn't seem to me 
largely implemented.

AFAIK, the google OP doesn't provide the client registration endpoint 
(https://accounts.google.com/.well-known/openid-configuration).

As a consequence, the RDAP server should maintain the client credentials 
resulting from an out-of-band registration.

IMHO, the pairs <OP, client credentials> should be maintained anyway to 
avoid that the RDAP server starts the registration process at every RDAP 
requests to the /tokens endpoint.

Mario

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 24 Jan 2022 14:43:40 +0000

> Sent: Sunday, January 23, 2022 5:11 PM
> Subject: [EXTERNAL] Re: Re: Re: Re: [regext] id_token parameter usage in
> rdap-openid
>
> >> RDAP server might be configured to use multiple authorisation
> >> servers, each of which permits the use of arbitrary email addresses
> >> as identifiers.  Because each permits arbitrary email addresses, it's
> >> not possible to use a simple mapping from the domain of the email
> >> address to the authorisation server.  The RDAP server is then reliant
> >> on issuer discovery being implemented by the email host, but there's
> >> no guarantee that it will be (Gmail doesn't implement it, for
> >> example).  If an RDAP server has some specific out-of-band means for
> >> mapping identifiers to authorisation servers, then it could rely on
> >> that, but that may not be possible in all situations.  The RDAP
> >> server then has to fall back to requesting that the user select an
> >> authorisation server during the login
> >> process: this is fine, but it means that the RDAP server is receiving
> >> extra information during the login process that it won't have
> >> available to it during subsequent token-based requests.
> >
> > anything that says they've discontinued the service, but the resources
> > I used in the past can't be found at their old locations.
> >
> > negotiation/configuration is one method, or we can ask the user/client
> > to somehow identify the Identity Provider when they request tokens.
> > That sounds more complicated than I'd prefer, but do we have any other
> > options?
>
> interactive
> process anyway, asking them to select an identity provider at that point
> doesn't sound like too much of a problem.

[SAH] The best thing we can do is to explain the situation in Section 3.1.3.1. 
What's there now needs to change:

OLD:
3.1.3.1.  Provider Discovery

An RDAP server/RP needs to receive an identifier from an End-User that can be 
used to discover the End-User's OP.  That process is required and is 
documented in the "OpenID Connect Discovery" protocol [OIDCD].

PROPOSED NEW:
3.1.3.1.  Provider Discovery

An RDAP server/RP needs to be able to map an End-User's identifier to an OP. 
This can be accomplished using the OPTIONAL "OpenID Connect Discovery" 
protocol [OIDCD], but that protocol is not widely implemented and can be 
unreliable. Out-of-band methods are also possible and can be more dependable. 
For example, an RP can support a limited number of OPs and maintain internal 
associations of those identifiers with the OPs that issued them. An RP can 
also ask an end-user to identify the OP that issued their identifier as part 
of an RDAP query workflow. An RP MAY use any provider discovery approach that 
is suitable for its operating environment.

How does that sound?

Scott

---

From: Tom Harrison <[email-masked]>
Date: Tue, 25 Jan 2022 15:03:37 +1000

On Mon, Jan 24, 2022 at 02:43:40PM +0000, Hollenbeck, Scott wrote:
> [SAH] The best thing we can do is to explain the situation in
> Section 3.1.3.1.  What's there now needs to change:
> 
> OLD:
> An RDAP server/RP needs to receive an identifier from an End-User
> that can be used to discover the End-User's OP.  That process is
> required and is documented in the "OpenID Connect Discovery"
> protocol [OIDCD].
> 
> PROPOSED NEW:
> An RDAP server/RP needs to be able to map an End-User's identifier
> to an OP.  This can be accomplished using the OPTIONAL "OpenID
> Connect Discovery" protocol [OIDCD], but that protocol is not widely
> implemented and can be unreliable. Out-of-band methods are also
> possible and can be more dependable.  For example, an RP can support
> a limited number of OPs and maintain internal associations of those
> identifiers with the OPs that issued them. An RP can also ask an
> end-user to identify the OP that issued their identifier as part of
> an RDAP query workflow. An RP MAY use any provider discovery
> approach that is suitable for its operating environment.
> 
> How does that sound?

I think this is fine, but one adjustment for the "select an OP" case:

    An RP can also ask an end-user to identify the OP that issued
    their identifier as part of an RDAP query workflow.  In this case,
    the RP will need to maintain state for the association between the
    user's identifier and the OP in order to process later queries
    that rely on passing the access token and user identifier as
    authorization parameters.

Alternatively, the RDAP client could pass the issuer value (from the
ID token) instead of the user identifier when doing this sort of
query.

-Tom

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Tue, 25 Jan 2022 14:17:33 +0000

> Sent: Tuesday, January 25, 2022 12:04 AM
> > [SAH] The best thing we can do is to explain the situation in Section
> > 3.1.3.1.  What's there now needs to change:
> >
> > OLD:
> > An RDAP server/RP needs to receive an identifier from an End-User that
> > can be used to discover the End-User's OP.  That process is required
> > and is documented in the "OpenID Connect Discovery"
> > protocol [OIDCD].
> >
> > PROPOSED NEW:
> > An RDAP server/RP needs to be able to map an End-User's identifier to
> > an OP.  This can be accomplished using the OPTIONAL "OpenID Connect
> > Discovery" protocol [OIDCD], but that protocol is not widely
> > possible and can be more dependable.  For example, an RP can support a
> > limited number of OPs and maintain internal associations of those
> > end-user to identify the OP that issued their identifier as part of an
> > RDAP query workflow. An RP MAY use any provider discovery approach
> > that is suitable for its operating environment.
> >
> > How does that sound?
> 
> Alternatively, the RDAP client could pass the issuer value (from the ID token)
> instead of the user identifier when doing this sort of query.

[SAH] Thanks. I'll use the addition you suggested above.

Scott