In that example, Zapier *is* the client that needs the information from the AS in order to proactively notify the user.
On Fri, Nov 14, 2025 at 9:24 AM Neil Madden <[email protected]> wrote: > Ok, that makes sense, and I’m not against adding this if it’s useful. It > seems to me generally better if the AS (Zapier in this case) just took care > of this rather than every client having to implement it, but it’s a fairly > lightweight addition to the spec. > > — Neil > > On 14 Nov 2025, at 17:05, Max Gerber <[email protected]> wrote: > > > > 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? > > The point is for the user to be prompted before expiry, so no gap in > service occurs. There are plenty of "set-and-forget" OAuth connections - > anything that involves syncing data from one place to another comes to > mind. I have some Zapier integrations with various systems that I use > daily, but I barely touch the zapier dashboard anymore now that the initial > connection is set up. Sure, Zapier could notify me after the connection > breaks, but that would be pretty disruptive. I'd need to figure out how to > sync all the missed events across different systems, and my coworkers that > depend on the integration working would be left in the dark until I come > back to fix it. For personal usecases, a small gap in service might be > fine. For enterprise usecases, it's a much bigger deal. > > On Fri, Nov 14, 2025 at 8:29 AM 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]
