Below…
From: regext <regext-boun...@ietf.org> On Behalf Of Mario Loffredo
Sent: Friday, December 17, 2021 5:55 AM
To: regext@ietf.org; Tom Harrison <t...@apnic.net>
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,
Il 17/12/2021 06:59, Tom Harrison ha scritto:
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<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
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
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
