Hi Mario, On Fri, Jan 14, 2022 at 09:19:55AM +0100, Mario Loffredo wrote: > Il 11/01/2022 12:03, Tom Harrison ha scritto: >> On Fri, Dec 17, 2021 at 11:54:57AM +0100, Mario Loffredo wrote: >>> Il 17/12/2021 06:59, Tom Harrison ha scritto: >>>> 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.
That's right. A "client" that uses OIDC is referred to as a "relying party" in the OIDC context, too. In the draft, the RDAP server is a "client" per OAuth 2 and a "relying party" per OIDC. > In that pattern, the client does not need to inspect the access > token because it contains only information useful for the resource > server. I don't understand this point. Even if the (OAuth) client might make use of the information in the access token, the (OAuth) client is not permitted to inspect it, and must treat it as if it were opaque. > 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. I think the text quoted above is about including content in ID/access tokens that should not be exposed to the (OAuth) client or the (OAuth) end-user at all, rather than about content that should not be exposed to unrelated third parties. Given that providing the ID token to the (OAuth) client is an essential part of the OIDC flow, it's unlikely that the ID token will contain information that shouldn't be exposed to the (OAuth) end-user. (That's not to say that information like this should be passed around unnecessarily, given that extra transport generally introduces additional risks around exposure to unrelated third parties.) >> 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 ? Without having thought about this in detail: - The /tokens endpoint would no longer be useful, and would be removed. - Assuming that the RDAP server is able to use cookies to maintain session state with relevant RDAP clients, then the RDAP server could handle token refresh transparently. In the event that the token was expired and could not be refreshed, the RDAP server would prompt the user to authenticate again. > I think we should also consider the session management as an > alternative to passing always the access token but without making > large changes. I don't think having it as an alternative to the current approach is a good idea. The motivation for adding it is to address the concerns raised around how tokens are passed around. If there is another way to address those concerns, I'd prefer that that change be made and there be a single 'path' for implementors to follow. -Tom _______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
