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

From: Tom Harrison <[email-masked]>
Date: Fri, 17 Dec 2021 15:59:45 +1000

Hi Mario,

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.

-Tom

---

From: Mario Loffredo <[email-masked]>
Date: Fri, 17 Dec 2021 11:54:57 +0100

Hi Tom,

> verify that access token, so it won't be able to verify that the user

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.

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.

Best,

Mario

-- 
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: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 17 Dec 2021 13:37:04 +0000

Below…

From: regext <[email-masked]> On Behalf Of Mario Loffredo
Sent: Friday, December 17, 2021 5:55 AM
To: [email-masked]; Tom Harrison <[email-masked]>
Subject: [EXTERNAL] 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.

Hi Tom,

   Hi Mario,

      (https://openid.net/specs/openid-connect-core-1_0.html#UserInfo<https://secure-web.cisco.com/1KKW2SApQj1N6ZeKduHy-mggaka3k6jXXY8hpjVxaNIBBpp3CUNEIJbawxFxXtS96tfk2JJGzc6luoZH0HrbWrlhpRxcRCqF7t6kTrGAplyngCfU7WDXUcV03EvL9YTpKI2q1TfHWWRi6TeWFIpFSb469aKsxQPVQT4GLIMzhDQMVvtaM6e8zi-C5XM3P-GM1yT45sy1OOPlhkFjNqAF5a5mts0_yvc9asQbRUBsgnRSH-8ZIKFLaD2-jWZIY217q8wD7K5j5LejAxoNu_y7Wktq2cCFN5GZ2qBLhT5XD3hw/https%3A%2F%2Fopenid.net%2Fspecs%2Fopenid-connect-core-1_0.html%23UserInfo>) using the

   -Tom

   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<https://secure-web.cisco.com/1TmBir9fgwd1wrEa7PSILHpj4seOLrHlrW-1PS2wWF_kWVccOhmsNJDk1flytwoqBM6-rX4fPeNVSB10BzDS5TFILO19QGJWopUE6TDQE2WHmYf_OvTKCkPxqM2MCW0Xko2oasK_2xJJlmlCtogAxOGJLOj-VPy2NjGdpS32saL1-gvJBRD4Js-9bjtZEqLxDZaqpMcBzRMkfxi8sGu2c3xGcU193pPQ6lRUHlHFxbmzyFF0rA3yqCcgxpOSs_OYcm7s3S7TUfN3WKCAHjxSwW1kTcsL-lNmo2XkRJN6YDBc/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc9068.html%23name-introduction>).

   Hence, RDAP clients would probably be required to send an unnecessary ID Token.

   Secondly, the oauth wg "OAuth 2.0 Security Best Current Practice" draft (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-19#section-4.3.2<https://secure-web.cisco.com/135U4Vip1nZnZbbtDOkWPubfGzfuh_coG3Wr9CeB_fyT3iSIc5nf0xz1dJG5SOKqUQjQpugIT33ejHk4u2_GRdjnrfndWQT7d7jLxTLHK8al2aOffm71Lb8MKCQC-mYcfJTBf7BLMZNgvKmVW-ImUkOJboEtYnagR-7nuUM9V-bAQHoYzNykd4uOBVqzMTJ-No18kyLaoWHCSoNJ8_JkL9tc4568I9btXXtJIwASAymYeuGkzdy-fcN2K8bD662g5dzuGw51vaMslGUZkALo5MJclsbHp95oMhrT_k_9UIws/https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-ietf-oauth-security-topics-19%23section-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<https://secure-web.cisco.com/1Yva-QzdxzcD8nEOa1iAIjPrAml45YXEFti6RpST40Q-y3z6sI-u9e8Xm3ecQQF3g1wS0rgoGCTjXQexhH-wtvR6bTK0_Nrfcb3EPc0rbvZrjTeDlfiYeBHGv1_UapMkAPS7tNj09OxPqmEAI6p6XGNATckf-u465vS8CdaF5SNmvFOU9q1CNVrqX7PoUetqvWqVfOurTKP4QvwI7mCqzF9NUoSXovR7PbT7SCo4LKDzf9CHAm5v9MUGEhaj5Me6sYe2nfNeBC74tuKBsHSdUbqAiNhtre6EcyGg4AwM-t74/https%3A%2F%2Fwww.rfc-editor.org%2Frfc%2Frfc6750.html%23section-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.

   [SAH] Yes, I need to look into removing tokens as query parameters and moving them to request headers. I hope to get to that in January.

   Scott