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, 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.)
[ML] Agreed.
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.
[ML] Personally, I wouldn't object to your proposal.
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.
[ML] My suggestion was based on the assumption to maintain the basic
principles of the current document.
Anyway, if there was a consensus on reviewing radically the document to
be more compliant with the OIDC reference pattern, I would be pleased.
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
