Hi Tom,
please find my commnets inline.
Il 17/01/2022 02:07, Tom Harrison ha scritto:
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.
[ML] What I meant to say is that in the OIDC reference interaction
pattern, the RDAP server would act as a Resource Server. An RDAP client
would act as a Relying Party.
Normally, the RP, that is a frontend for the RS, is a trusted
application and it doesn't need to inspect the access token. On the
contrary, the RS inspects tha access token to make access control decisions
based on some claims designed for being included in the access token
such as groups, roles, entitlements.
In the draft, an RDAP client is normally untrusted so the RDAP server
acts as an RP but we cannot ignore that the RDAP server is still an RS.
I think that both the OAuth and the OIDC actors was defined for the
reference pattern so we cannot apply them to the draft pattern
straightforwardly because otherwise we'll face some inconsistencies.
For example, now the mostly used access token format is JWT. Such a
format is perfectly consistent with the reference pattern because it
isn't normally exchanged outside a trusted context.
So, with reference to the draft, we cannot say that the access token
MUST be opaque but we can say that it MUST be treated as opaque by the
RDAP client and, anyway, it MUST NOT include sensitive information.
In addition, we cannot say that the RDAP server MUST treat the access
token as opaque because it is normally inspected by the RS.
Definitively, we have two patterns: the classic one that is likely to be
currently used in practice and the one proposed by the draft that in my
opinion should be harmonized with the former to make them coexist.
Hope I made myself clear.
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
