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

From: Mario Loffredo <[email-masked]>
Date: Thu, 11 Nov 2021 11:51:13 +0100

Hi Scott and folks,

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.

To better explain the difference between the two options, I show below 
an example of ID Token and /userinfo response provided by my devel 
version of Keycloak.

*ID Token (a bit more than 1K)*

eyJhbGciOiJSUzI1NiIsInR5cCIgOiAiSldUIiwia2lkIiA6ICJuaFQ0ZERHMkxWcmtJaHdLcVJ4Y1lQOGtRYTBRbTJ6c0FuTm1Yd0hraHcwIn0.eyJleHAiOjE2MzY2MTk3MzksImlhdCI6MTYzNjYxOTQzOSwiYXV0aF90aW1lIjowLCJqdGkiOiI0NjgxODc4NS1jZjU5LTQzM2EtODk3Ni0xMDBkOGMwMTgxM2EiLCJpc3MiOiJodHRwczovL2F1dGguZGV2ZWwubmljLml0L2F1dGgvcmVhbG1zL3JkYXAiLCJhdWQiOiJyZGFwLXdlYiIsInN1YiI6ImY6N2FmMmIxZjgtMmU1OC00YzE4LWJlOTctMmE2OWRjNTRkOWQyOjc3NjEiLCJ0eXAiOiJJRCIsImF6cCI6InJkYXAtd2ViIiwic2Vzc2lvbl9zdGF0ZSI6ImRlYzY0ODNlLTJlNWMtNDYwMy1hZjdmLWNiZjdlNjI2ODFkZiIsImF0X2hhc2giOiItdThTZkpIOE53cVNMVzN2bmJPUUl3IiwiYWNyIjoiMSIsIm5hbWUiOiJNYXJpbyBMb2ZmcmVkbyIsInByZWZlcnJlZF91c2VybmFtZSI6Im1hcmlvLmxvZmZyZWRvIiwiZ2l2ZW5fbmFtZSI6Ik1hcmlvIExvZmZyZWRvIn0.Qh1BPzkvvzZVIl9r5fQx2TJUv-0b_IVCayDcMBvLl6l8KvfMjMcMgLP4MWbRrIxlBNty9hiMPldA2FyfRTeOgWcTIvLBgfiT3JUzBoP7cJgZa09ZfBZeLOxs6GhnD0eKssWEIGMWy89E253HuTafa7avbtX18YOYgrMWvqr7IJlZmfOr1GXlBnM1PxwfAUrqp5aNGe2Q3SWp7IrAi-5m35akkhnkfN9YidgKXw3W-TY7_2_r-MO4XS04CqoESgD24s7UgHtFCVZrqgVQZT6VILHBuhAduLr1JR_XWK7Xc27Ih_GkkEU9w53RQHEdr_KFVdYc7HTRq6P86OBURaeUxg

*JWT payload (obtained through https://jwt.io/)*

{
   "exp": 1636619739,
   "iat": 1636619439,
   "auth_time": 0,
   "jti": "46818785-cf59-433a-8976-100d8c01813a",
   "iss": "https://auth.devel.nic.it/auth/realms/rdap",
   "aud": "rdap-web",
   "sub": "f:7af2b1f8-2e58-4c18-be97-2a69dc54d9d2:7761",
   "typ": "ID",
   "azp": "rdap-web",
   "session_state": "dec6483e-2e5c-4603-af7f-cbf7e62681df",
   "at_hash": "-u8SfJH8NwqSLW3vnbOQIw",
   "acr": "1",
   "name": "Mario Loffredo",
   "preferred_username": "mario.loffredo",
   "given_name": "Mario Loffredo"
}

*/userinfo response*

{
     "name": "Mario Loffredo",
     "sub": "f:7af2b1f8-2e58-4c18-be97-2a69dc54d9d2:7761",
     "preferred_username": "mario.loffredo",
     "given_name": "Mario Loffredo"
}

Hope it could be helpful.

Best,

Mario

P.S.

Someone may wonder why I'm so careful in sending PIIs as query 
parameters in a GET request in this context but apparently not in the 
reverse search proposal.

The response is because, in this context, there exists a more secure 
alternative to achieve the same result. Moreover, in my last talk about 
reverse search, I included this topic among the ones to address.

-- 

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