What if instead of introducing two parameters like this draft is doing now refresh_token_expires_in > The lifetime in seconds of the refresh token. For example, the value > "604800" denotes that the refresh token will expire in one week from > the time the response was generated. This value SHALL NOT exceed the > value in consent_expires_in.
consent_expires_in > The lifetime in seconds of the user's consent. For example, the > value > "2629800" denotes that the consent will expire in one month from the > time the response was generated. This value MAY exceed that of > refresh_token_expires_in. We end up with a single response parameter (consent_expires_in, or maybe even, consent_exp), with its value representing the number of seconds since the epoch? This way, we slightly simplify the logic on the AS side by returning a single, pre-calculated value, and the client has a clear understanding of what will happen when consent_expires_in is reached (a previously issued RT is no longer valid, and an AT is revoked). Will it meet your (initial) requirements? I guess it should... the client can take some actions to tell the user it's time to renew their consent. I also wonder why the authorization server (AS) can’t return an opaque URL in one of the parameters of the token endpoint response, allowing the client to present it to the user. This would be for users' convenience, for example, "You delegated access to me six months ago, and it’s time to renew your consent if you still want me to access your data". If the user "hits" this URL, gets authenticated, and gives their OK, the AS increases consent_expires_in for this particular client for another six months. What do you think? All the best, Andrii On Sat, Jun 28, 2025 at 10:10 AM Nick Watson <nwat...@google.com> wrote: > Responses inline > > On Fri, Jun 27, 2025 at 3:02 PM Andrii Deinega <andrii.dein...@gmail.com> > wrote: > >> Hi Nick, >> >> What does an AS do when time-limited user consent expires >> (consent_expires_in)? >> > > When user consent expires the state in the AS will essentially be reset > like the user has never granted access before, as there will be no > valid credentials in existence and no valid record of user consent on the > AS. (Different AS impls may retain a tombstone for auditing purposes.) Do > you think it's worth adding any of this in the spec? I'd probably make it > non-normative, e.g. in an implementation notes or privacy considerations > section. > >> >> Does it invalidate ATs for a user? Or... does it require the user to >> re-consent to the requested scopes? If so, how should it do that in your >> view? >> > > Good point. I'll add a line about how AT lifetime must not exceed > consent_expires_in. If a user renews their consent, I don't think it's > necessary for the AS to update AT expiration in addition to RT expiration, > as clients can just get a new one with the RT, but I'll mention it with > "MAY" just in case any AS issues stateful ATs and wants to do it. > >> >> Would you like to allow users to set an expiration date for their consent >> on the consent page? >> > > How consent expiration gets set is an implementation detail for the AS, I > think, but yes I would expect the most common choice is letting users > select an expiration on the consent page – either a predetermined set of > options or a freeform field. Could be another point for a non-normative > section maybe? > >> >> I suggest renaming field refresh_token_expiration_types to >> refresh_token_expiration_types_supported in AS's metadata (in order to use >> the same name convention). >> >> A minor nit, in the provided examples, you need to omit " around values >> provided for parameters *refresh_token_expires_in* and >> *consent_expires_in*. >> > > Thanks. Fixed both. > >> >> All the best, >> Andrii >> >> >> On Fri, Jun 27, 2025 at 10:44 AM Nick Watson <nwatson= >> 40google....@dmarc.ietf.org> wrote: >> >>> Hi all, >>> >>> I have written up a draft for expiring refresh tokens, including both >>> expiration from time-limited user consent as well as expiration due to >>> enforced RT rotation deadline. >>> >>> >>> https://datatracker.ietf.org/doc/draft-watson-oauth-refresh-token-expiration/ >>> >>> Have a look and let me know what you think. >>> >>> - Nick >>> _______________________________________________ >>> OAuth mailing list -- oauth@ietf.org >>> To unsubscribe send an email to oauth-le...@ietf.org >>> >> _______________________________________________ >> OAuth mailing list -- oauth@ietf.org >> To unsubscribe send an email to oauth-le...@ietf.org >> >
_______________________________________________ OAuth mailing list -- oauth@ietf.org To unsubscribe send an email to oauth-le...@ietf.org
