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