fense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>
> *.*
>
>
>
> *From:* Nick Watson
> *Sent:* July 1, 2025 6:28 PM
> *To:* Lombardo, Jeff
>
e feedback **here*
> <https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3NoEk6hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>
> *.*
>
>
>
> *From:* Nick Watson
> *Sent:* June 30, 2025 1:45 P
hihx7dNHnQuejn6SSH2CP8Iow3G-tTzppHeg$>
> *.*
>
>
>
> *Thoughts on our interaction? Provide feedback **here*
> <https://urldefense.com/v3/__https:/feedback.aws.amazon.com/?ea=jeffsec&fn=Jean*20Francois&ln=Lombardo__;JQ!!Pe07N362zA!0k9CkAV8Djpw_8EfIAKrbhP3TQrJr0oMnznlUgBJ3V3
Hi Jeff,
Thanks for the draft. It looks to be a useful extension. I've also been
thinking about this problem as failure modes have become significantly more
complicated in the last several years due to evolving privacy/security
landscapes, regulation, and now the proliferation of agents. I have an
ention).
>
> 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
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 t
I also agree that scope, max_age, and acr_values are insufficiently
expressive to cover all cases that arise in practice. I think we need
something more freeform like the ability for the AS or RS to provide an
arbitrary set of query parameters to pass to the authorization endpoint (or
maybe just a
_____
>> 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
>
--
Nick Watson | Software Engineer | nwat...@google.com | (781) 608-3352
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
ly? What's the
>>> alternative? If Google and Microsoft want to expose potential privacy data
>>> for unauthenticated users, they definitely can, but I will personally die
>>> on this hill. Until the user is authenticated, exposing any data regarding
>>> the use
pt those scopes. That's a pretty malicious
> thing to do, the user already rejected those scopes, forcing them through
> the exact same flow again is not something that makes sense, at least to
> me, but it isn't the case that this should be SHOULD let alone MUST.
>
>
copes differ from the requested scopes.
This allows RPs to be informed if the resource owner only grants partial
consent.
- Nick Watson
___
OAuth mailing list -- oauth@ietf.org
To unsubscribe send an email to oauth-le...@ietf.org
11 matches
Mail list logo
