I hate the feature, but I sort of get it. Maybe a different perspective could make it justifiable.
As a user, a service is asking for access to my private documents stored in Google Drive. But I don't trust it that much, and I can't be bothered to set myself a reminder and follow up later to potentially revoke access. So instead it would be great for Google Drive to offer me the capability to set how long said service can have access to my Drive. Service: is the client. And access: is a scope. Since my identity doesn't change, the refresh token should not be revoked, and as many different scopes could be provided, scope level metadata might actually be required here. Access will automatically be revoked at that time if I don't do anything. As a result of the OAuth process, we'll need the response from the AS to include per scope expiries. Or at least the shortest expiry. I find the actual implementation of a single field lacking in this regard, if we extend the use case. At that point, it is no different than the refresh token itself, and adding a second field is both over-engineered and does not solve the user story I've shared. But with that, then the service could continue to work as is, doing whatever it was doing before. However, I don't think this has any value at all. The value here for me, is the expiry configuration by the user, when communicating with the AS. This value being returned to the client in the token response is still next to useless. Surely as Neil said, the service can wait until the token expires. Actually it's worse, I think we are doing a disservice by including this information. There is next to very little reason to allow this, since these two scenarios are almost the same from a RS standpoint. The only difference is, if the scope expiry is in the token response, then some clients will start to harass users *before the token expires*. This creates noise and waste, because clients will attempt to do this before the token expiries. And what's the problem with waiting? Temporary loss of access for the service? If the user cares, they will fix it, if they don't then they won't. Proactively, where's the value? The negatives are really bad, and the positives? Why does it matter in any scenario for a client to wait to lose access before requesting continuation? On Fri, Nov 14, 2025 at 5:32 PM Neil Madden <[email protected]> wrote: > On 14 Nov 2025, at 16:08, Aaron Parecki <[email protected]> wrote: > > > > This has already been discussed and presented in the several past IETF > meetings about this draft. > > > It sounds like something should maybe be added to the document then if it > keeps coming up? > > > Yes, it means the client can prompt the user in the UI to tell them they > will need to re-authorize and re-approve access. This lets the client > proactively tell the user they need to re-authorize before the access is > lost. Without this, the client will lose access for an indeterminate amount > of time until the user realizes the client has stopped working and goes and > reconnects it. > > > So the user uses the app often enough that this prompting can happen at > some point near to expiry, but not often enough to notice a gap in service? > And the app has no backchannel notification mechanism (eg email) to inform > the user that access has expired? > > — Neil > > > On Fri, Nov 14, 2025 at 7:51 AM Neil Madden <[email protected]> > wrote: > >> >> >> > On 14 Nov 2025, at 15:14, Max Gerber <[email protected]> wrote: >> > >> > > […] The client can also schedule a notification to the user to renew >> the grant in 11 months. >> >> But what does this mean in practice? Asking them to re-login and >> re-approve the scopes? If so, why not just wait for the grant to expire and >> do that anyway? What is the concrete benefit to user or developer >> experience of this field? >> >> — Neil >> _______________________________________________ >> OAuth mailing list -- [email protected] >> To unsubscribe send an email to [email protected] >> > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] >
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
