Session Date/Time: 11 May 2026 17:00
Rifaat Shekh-Yusef: Going to give people two more minutes and then we get going. Okay, let's get going. So, first, thanks Hannes for taking notes. Appreciate that. Deb is not going to be here, so I think we're good to go here. So, a reminder, the Note Well applies here, as you know. This governs everything that we do at IETF, including IPR, how we conduct ourselves, and how we do business at IETF. So if you're not familiar with this, please make sure you get familiar with this.
So today, Nick will be talking about refresh token and authorization expiration, and we still have one more interim that will be June 1st. So that's our agenda for today. I'm going to stop here unless somebody has any comments or questions. And I'm going to share those slides and hand the control to Nick. Nick, it's yours.
Nick Watson: All right. You can all hear me, right?
Rifaat Shekh-Yusef: Yes.
Nick Watson: Okay, excellent. So, yeah, I mean, I guess I will start by saying that I don't think this will take anywhere close to the full time, I hope. So, yeah, this is basically just a continuation of the draft-ietf-oauth-refresh-token-expiration draft, which I presented in Montreal and has since been adopted. I was unable to go to Shenzhen, so having a quick little interim here to go over a couple changes and see what the next steps are before Vienna, where I will actually be attending, which is great.
Okay. Right. So this is a quick summary. I think, looking at the names here, I think most people were there at the last time I presented this. So the idea is that there are two timeouts that might be of interest to the client. One of them being the validity of the credential itself, the refresh token, which in this case, this draft is saying the refresh token is a means of the client to obtain more access tokens, and that's all it is. It is not—the refresh token itself is not an indicator of the user's authorization or the resource owner, I should say, their authorization, which is a more broad concept that can cross-cut multiple tokens or any other access patterns.
And then there's then the authorization expiration, which is referring to the timeout on the whole sort of resource owner authorization. So, you know, a motivating use case at least for me was that sometime last year, Google launched a limited authorization for Gmail scopes, and we got a lot of feedback from clients that they needed this information in order to provide the best user experience they could because they didn't want users just like doing some authorization, forgetting about it, something's running in the background and then six months later everything stops working, they don't know why, the app now has to go find the user again to get them to reauthorize, or at least explain to them what happened.
So, yeah, and then, let's see, couple other bullet points here, like out-of-band updates. So this—the draft supports updating these values directly at the AS by the user. This isn't necessarily covered by normative language; it's more saying—telling the client and the authorization server how they should behave in the case where that does happen. It's not explaining necessarily how the user should go to an AS and do that. Then, no new error codes are introduced; invalid_grant is fine for this if the token does end up expiring or the authorization's expiring—that same type of error works on the refresh token grant.
Let's see, covering here on the right, yeah, the two new parameter names. There's a paragraph I've written, which I—this was in response to a review by George talking about the relationship to individual scopes. You can imagine, depending on how the client is implemented, if they are making multiple different—doing multiple different authorization flows for individual scopes, you can end up in a position where different scopes or different tokens have different expirations. So I've added a paragraph kind of calling this out as like a—an edge case that—and certain things that might be able to be done there, but I have largely put it out of scope of the draft in terms of trying to fully define what should happen there. So there's a paragraph on that that's been added since Montreal.
And then just covering a couple other things here that were about how server metadata and how infinite time works. Let me, right. Yeah, okay. So this is—and then this is the actual changes basically. So specifically those last two there, that how clients should handle a transition from infinite to finite, and then a field renamed in metadata. Some of the examples were updated. And then, yeah, this is—these were largely in response to a review by Vanshaj about making some of the UX considerations a bit more prominent, or at least linked to from other parts of the draft. Yeah, and then actually that last bullet was one of the things I first mentioned here about sort of what is the difference between a token lifetime and an authorization lifetime. So added some definitional stuff there.
Yeah, so those are—those are the changes and a summary of the draft. So maybe then a couple things to talk about. So one of the things Vanshaj suggested in his review was that this draft should expand to discuss changes to token introspection where clients would potentially also like to get this information from the token introspection endpoint. So I think that would—like, there was also a sort of related topic of can lifetimes be shortened from either infinite to finite or from finite to less finite, which the draft didn't currently address. Didn't prohibit, it just didn't address it. And so if that's the case, then token introspection changes might be needed for because clients don't necessarily know that the last call on their refresh token grant is still accurate at any given time.
And then there's the case of in token introspection, you're probably sending up an access token to that. I guess I don't know how everyone else has implemented it, but for us it generally expects access tokens. And so then is that, you know, you would presumably then look up the backing—whatever backing records you have for that and return that. So definitely want to check with the group what people think about including that. Okay, Max just put in a comment that introspection takes refresh tokens as well. Okay, so okay, so then that could work there cleanly.
I wanted, I guess, my guess, I don't know if anyone has actually read the latest version of the draft, but the question about the clarity of the section on per-scope expiration. Is it sort of is the right level of detail there? Should it—I worry if more detail goes in, it might need to be actually just specked out, which might get a little hairy. And or if I should say less and leave more to the imagination where the, you know, to really avoid getting into the weeds at all.
And then, what else do people want to see in the draft, you know, before Vienna to help move this along? Like, I don't think there's anything super complicated here. It'd be really nice to just kind of make this a 2026 project that doesn't languish for years. So the—I think one of the things I maybe would say is if there are more non-normative considerations, like in sort of just giving more examples of how users or clients might interact with these mechanisms involved, like, you know, how might a user go to the AS to update lifetime or something like that, or, you know, suggesting like maybe the AS wants to send push notifications? I don't know, just something in a UX consideration, something like that, if that would be something I could consider. And then, of course, we can always bike shed names. So that's really really it. That's my spiel. And I don't know actually how the interims usually go. I'm used to having, you know, 5-10 minutes at the live meeting. So.
Rifaat Shekh-Yusef: Yeah, that's fine. So typically we allocate an hour for a topic because we want to give people enough time to discuss whatever they want, right? Obviously, we don't need to use the full hour if you don't—if you don't need it, that's fine. Okay, anybody has any comments, questions, suggestions? Max.
Maxwell Gerber: Hi, Nick. So I'm reading through the section "Relationship of Authorization Expires in to Scopes," and there's an example of a calendar scope that's short-lived and then an indefinite access for an OpenID scope. And then I'm wondering, like, for the refresh token that would be returned from that grant type, would that refresh token also have indefinite access, but then the authorization_expires_in value would be finite? Like, what's the relationship between those two values when the underlying grant, I guess, shrinks over the course of the authorization?
Nick Watson: I mean, I'm generally the spec recommends to take the minimum value of anything that's been authorized, just to try to avoid any accidents. But I think it's—it feels like something that could be, you know, as long as the authorization server's enforcing the right things, it potentially could make different decisions. But yeah, I mean, that—I guess it would depend also in terms of like what—like if you're talking refresh token timeout, like why—it would depend what the—like what the AS is accomplishing with refresh token timeout there versus authorization expires in. So like it might still want clients to use their refresh token at some duration or interval. But for authorization expires in, the spec definitely sort of strongly recommends taking the minimum value. I suspect taking the larger value is just going to result in like you're kind of—this is the thorny part with this, the fact that this happens. It's like if you take the minimum value, you're potentially going to be bugging the user more than you need to because the client might send the user back to the authorization server when it doesn't have to. And if you take the maximum value, you're going to get people who—like access that expires unexpectedly because the client thought it had more time than it did.
Maxwell Gerber: Yeah. Yeah, that makes sense. So is there ever a situation where the authorization_expires_in would be quite short? Like say authorization_expires_in is a month, and then refresh_token_timeout would be greater than the authorization_expires_in?
Nick Watson: Um, so I believe the draft says not to do that. That said, I think there's—I think there's probably an instance where like the authorization server sort of doesn't care about refresh token timeout. It's just not like a—like it doesn't have any reason to return it or implement it. And then there, I suppose, there could be some confusion around an omitted refresh token timeout with an authorization_expires_in field that is finite. So maybe worth adding a sentence there explaining like how those relate. Because I'm pretty sure I said right, refresh_token_timeout is defined as shall not exceed the value in authorization_expires_in, which I think makes sense if you are defining refresh token timeout. But then there's the question of if—like if you're an AS that doesn't really that doesn't care about refresh token timeout, you're only talking about authorization, should you always return refresh token timeout equal to authorization expires in, or is it okay to omit? Because otherwise, if you are using both values, the draft does say that refresh token timeout needs to be lower or equal to.
Maxwell Gerber: Yeah. Cool. All right. That makes sense.
Rifaat Shekh-Yusef: Vanshaj.
Vanshaj Singhania: Hey, Nick. Just on the comment about refresh token timeouts, I'm having trouble finding that line in the draft. I see the line about the refresh tokens must not expire later than the authorization expires. Um, the way that I was reading this, and correct me if that's not the intended read, is the refresh token timeout is something that the authorization server might decide like consistently across the board. Refresh tokens must be used at least once every N days or something like that. But then the authorization expiration is something that is sort of joint shared between the authorization server and maybe also the end user deciding. So I'm thinking about whether or not it might be possible for the authorization server to have its fixed refresh token timeout and then a user comes in and says, actually, I want this authorization to expire in a day. In that case, are you saying that the refresh token timeout should be updated also to be whatever the minimum of the two values is?
Nick Watson: Yeah, I mean, that was—that is the intent as it's written now. I have down in the security considerations section, it says it basically says while it is possible to allow refresh token expiration to exceed that of user authorization expiration, if the authorization server checks both timestamps when validating, this is a potentially dangerous source of bugs in systems with complicated authorization models. So it could be, I'm not terribly opposed to it. It just I had said not to do it in the draft largely to try to head off any kind of buggy implementations where you end up with multiple timestamps that you aren't ordered. I'm—that's one where I mean, I'm open to changing that if if people have implementations or features that they think benefit from that. It just I didn't really think of anything concrete when I was first writing it up. So I left it as "don't do it," but I am, yeah, open to people's thoughts on that.
Vanshaj Singhania: Okay, that's fair. Thanks.
Rifaat Shekh-Yusef: Okay. Anybody else? Any comments?
Nick Watson: On, yeah, I mean, token introspection, I'm going to—I'll add it if nobody objects is sort of where I'm at on that. So. Yeah. Um, and obviously looking happy for happy for more reviews. I think I've gotten three so far. Um, so.
Rifaat Shekh-Yusef: Okay. Anybody else? Anything else?
Vanshaj Singhania: What names would you like us to bike shed?
Nick Watson: Honestly, any—any of them. Like anything where if if several months from now this goes to Last Call and then someone goes, oh, I don't like that name, I don't know, any—I'm personally not—not too picky about names. I want names that make other people happy so that they help progress the draft. Thanks, Brian. We're not going to change that, Brian.
Rifaat Shekh-Yusef: Okay, anybody else? Besides Brian. Okay, if not, then thank you, Nick. And Hannes, going to say something?
Hannes Tschofenig: Yeah, it's um—I'm trying to sense the—the view of the group. Um, I don't hear a lot of controversy around this document. That might be either the result of the document being not overly complicated, which appears to be. But it could also be a lack of interest. I'm not sure which—which part—which section we are in. So that's what I want to find out.
Rifaat Shekh-Yusef: I thought, Nick, you mentioned you got some reviews, right? You got some three reviews with some feedback.
Nick Watson: Yeah, I've gotten three reviews. Um, I hope it's more to do with the simplicity. It is a reasonably straightforward draft. Um, I'm hoping that it's not lack of interest at least if people attended the interim. Um, yeah, but I mean, you know, I'm happy to try to move this forward as fast as possible.
Rifaat Shekh-Yusef: Yeah. So beside those open issues that we've discussed. Okay, thanks, Aaron. Yeah, thanks, Aaron. So beside those open issues, is there anything controversial that you see that you want to discuss in Vienna, or what's—do you have—also do you have some implementation of this already? Like that—that would help probably get some feedback from those guys. Like it would be super easy to implement, right? Like in a prototype. Deployment-wise it's a different story, but. Yeah.
Hannes Tschofenig: It almost looks to me that this is something that a document that we could finish sooner rather than later, right? You make some small changes here and there and then we ship it. Done. Maybe. Yeah.
Rifaat Shekh-Yusef: Yeah. So and I'd—I'd like us to wait for that decision in Vienna, right? So maybe maybe like see if you can get more reviews and some feedback, and then in Vienna we can decide if we want to start a Working Group Last Call after that. Right? So.
Hannes Tschofenig: But Rifaat, maybe maybe we can also like do the Working Group Last Call earlier if—is there any urgency around this?
Rifaat Shekh-Yusef: Is there any—is there an urgency around this?
Hannes Tschofenig: Um, maybe maybe not urgency, but but if you do the update, those are smaller changes and then we will surely get review comments during the Working Group Last Call.
Rifaat Shekh-Yusef: Yeah, true. We could do that. Yeah. Yeah, okay. Yeah, that's—that's—that's possible. Fair. Fair, Aaron. Okay. Okay then, Nick, I guess try to update the document based on the feedback you got today and see if you can if you can get some feedback from others. And if not, we maybe we can start a Working Group Last Call even before—before Vienna so you don't need to present in Vienna. I don't know. We'll see.
Nick Watson: All right, cool. All right, thank you all.
Rifaat Shekh-Yusef: Yeah, thank you, thank you guys, and see you in the on June 1st next interim. Okay, thank you all.
Nick Watson: Thanks. Bye-bye.
Hannes Tschofenig: Thanks a lot. Bye.