> On 7. Oct 2020, at 19:45, Seán Kelleher <s...@trustap.com> wrote: > > Hi all, > > Long time lurker, first time poster, glad to be finally getting involved! > > In terms of weighing in on the revocation practice, I don't think this > document needs to address it as JWT ATs don't seem to require special > handling in this case. I think a general coverage of approaches to token > revocation would be more appropriate in a BCP. > > One thing I'm unsure of when reading this is how a RS can depend on an AS to > give it a JWT AT. Due to the opaque nature of ATs, it seems natural that an > AS can change the AT profile it uses at its own discretion, but there's no > negotiation or parameter that can force an AS to return a JWT AT, with the > potential for breakages. Do the RS and AS agree on the profile ahead of time? >
yes, they do. Basically, the AS is acting on behalf of the RS and centralises the authorization work. > Perhaps this is specified in a separate document, but I think the topic of > profile negotiation should be covered in this document, even at a high level, > or reference to more detailed coverage. Good point. I think this is a general assumption in OAuth. Should probably go into OAuth 2.1. > > A few other notes on the document itself: > • Section 2.1: Is there precedence of "application/at+jwt" being used > in the wild that prevents the SHOULD from being a MUST? > • Figure 1: Nitpick: An `&` that looks like it should prefix `state` is > on the preceding line. > • Figure 2: The example `typ` is `at+JWT`, should this be `at+jwt`? > • Section 4: This is a personal opinion, but I'd recommend moving the > step concerning `aud` validation to the top of the list, for focus. This is > because, having personally taken more than a little while to figure out the > difference between access tokens and ID tokens, I see the risk of cross-JWT > confusion as very relevant. I think the necessity of the other steps are a > bit more obvious. > Thanks! > > Kind regards, > > Seán. > > On Tue, 6 Oct 2020 at 22:53, <vittorio.bertocci=40auth0....@dmarc.ietf.org> > wrote: > Hi Andrii, > > Thanks for the thoughtful comments! Here’s my 2 c. > > > > On the proposed language: given that the JWT AT profile is just providing > more details on the content of an AT, making JWT ATs a proper subset of all > ATs, readers should have no reason to believe that introspection or any other > existing spec discussing AT behavior should operate differently. That > assumption holds for everything across the board, hence it would be a bit odd > to call out this particular case. On the userinfo case, I would find it even > more left field to say anything about it. > If we do reach a consensus on specific revocation practices that apply to JWT > ATs specifically, and we conclude that they should live in this document, I > will be happy to add language accordingly. > > > > On the AJWT: I hear you on the dissonance that JWT AT carries, but I am very > hesitant to introduce new acronyms to an already crowded/impenetrable domain. > JWT access token might not roll off the tongue, but at this point ‘JWT’ is > nearly a proprietary eponym and the expression “JWT token” is extraordinarily > common in literature, a quick google query will give you the full measure of > the phenomenon, hence I think we’ll be OK with the current form. > > Cheers, > > V. > > > > From: Andrii Deinega <andrii.dein...@gmail.com> > Sent: Tuesday, October 6, 2020 2:25 PM > To: vittorio.berto...@auth0.com; oauth@ietf.org > Cc: Jim Manico <j...@manicode.com>; Nicolas Mora <nico...@babelouest.org> > Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint > > > > Vittorio and WG, > > > > Would it be possible to include something like the following to > https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-10 > > > In case the authorization server exposes the introspection, revocation, and > OpenID Connect userinfo endpoints they MUST act in the same way as it happens > with a regular access token. That allows the AS to change the type of an > access token on the fly and that won’t lead to interoperate issues. Plus, the > consumers of these endpoints use them regardless of the type of access token. > > > > The way how the AS can notify RSs that the token revocation event happened > (if it decides to do so) is completely left to implementers. > > > > ? > > > > Another minor editorial thing from me is it would possible to change and > refer to "JWT access tokens" as AJWT. Thus, this document won't repeat the > token word twice. > > > > Regards, > > Andrii > > > > On Tue, Oct 6, 2020 at 2:22 PM <vittorio.bertocci=40auth0....@dmarc.ietf.org> > wrote: > > Hey Jim, regarding > > Every logout event should trigger token revocation > That isn’t necessarily the case. An access token represents the ability of a > client to access a given resource; the fact that it requires an > authentication transaction/session establishment to be issued to the client > does not mean that the AT lifetime is tied to the lifetime of that session. > Say that I allow LinkedIn to tweet on my behalf. Once I have done that, it > doesn’t matter whether I stay logged in their web app or otherwise. Even if I > log out of the session in which context I got my twitter AT, I can still post > on LinkedIn from my native LinkedIn app and the corresponding post will show > up on twitter as well. > Now, one might choose to *explicitly* tie tokens lifetime to originating > sessions lifetime, see the discussion on the OpenID Connect group about a > possible online_access scope for influencing RTs and Ats (in particular, in > the context of SPAs) but that's additional semantic that isn’t defined today. > > -----Original Message----- > From: OAuth <oauth-boun...@ietf.org> On Behalf Of Jim Manico > Sent: Sunday, October 4, 2020 5:17 PM > To: Nicolas Mora <nico...@babelouest.org> > Cc: oauth@ietf.org > Subject: Re: [OAUTH-WG] JWT access tokens and the revocation endpoint > > > In this model, considering that token revocations don't happen a lot... > > Just a brief note, a secure piece of software makes the logout feature > prominent. Every logout event should trigger token revocation. > > I’m mentioning this because a lot of OAuth solutions in the mobile space > literally ignore the logout event, such as Facebook’s mobile OAuth solution. > > - Jim > > > On Oct 4, 2020, at 6:55 AM, Nicolas Mora <nico...@babelouest.org> wrote: > > > > Hello, > > > >> Le 20-10-04 à 11 h 27, Thomas Broyer a écrit : > >> > >> There might be some kind of pushed events between the AS and the RS when > >> a JWT AT is revoked, to allow the RS not to introspect a JWT AT at all. > >> Like this, the RS knows if a JWT AT has been revoked or not. > >> > >> > >> If there are some kind of pushed events between the AS and the RS, > >> then it could push the revoked (and/or expired) opaque AT too, giving > >> almost no advantage to JWT ATs. > >> > > Not necessarily, let's say the AS informs the RS only of the revoked > > ATs, when a RS checks an AT, it verifies the signature first, then the > > claims, then checks if the AT has been revoked by checking its > > internal list filled by the AS pushed events. > > > > In this model, considering that token revocations don't happen a lot, > > the ratio revoked AT/valid AT is very low, so the advantage of a JWT > > is important, because it means not so much communication between the > > AS and the RSs, and a very reliable AT. > > > > But this means a communication mechanism that isn't standardized yet. > > > > /Nicolas > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
