Hi Tom,
sorry for the delay in replying.
My comments are below.
Il 11/01/2022 12:03, Tom Harrison ha scritto:
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.
[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.
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.
[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
regext@ietf.org
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
_______________________________________________
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext
