In theory, you can issue a token that only becomes valid in the future. That
would have a different iat and nbf timestamp. I have not seen this in practice
though.
Given that RFC 7519 lists “iat” as informative, I would not change that
behavior in a specific use case if there is no significant
Hence my question
What should be the recommended semantics - “informative” - “or don’t accept
before a certain time stamp” ?
———
Dominick Baier
On 20. April 2020 at 09:05:53, Philippe De Ryck (
phili...@pragmaticwebsecurity.com) wrote:
In theory, you can issue a token that only becomes valid in
Thanks Dominick for your comments!
Inline
> All other OAuth specs make a very clear distinction between users and client.
There’s a nuance worth highlighting here: sub != user. In previous discussions
on this topic it has been brought up that the JWT spec defines sub as
identifying the prin
Thanks for the catch! Will add a mention of that in section 2.1 as well.
From: OAuth On Behalf Of Brian Campbell
Sent: Thursday, April 16, 2020 1:16 PM
To: Aaron Parecki
Cc: oauth
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth
2.0 Access Tokens"
I'll +1 t
Thanks guys for the commentary here.
I wasn’t too partial on the “time claim” type. I just went for “Iat” very much
in line with Vladimir’s guess, it was quite empirical:
* it comes from OIDC, and for the usual consideration that existing logic
used for processing ID_tokens will be parti
All,
You can find the minutes for this meeting on the following link:
https://datatracker.ietf.org/meeting/interim-2020-oauth-05/materials/minutes-interim-2020-oauth-05-202004201200
Thanks to *Jared Jennings *for taking these notes.
Regards,
Rifaat & Hannes
I've seen several circumstances where "clever" clients implement an open
redirector by encoding a URL to redirect to in the state parameter value.
Attackers can then utilize this open redirector by choosing a state value.
Can we please add an explicit prohibition of this practice in
draft-ietf
In case of access tokens obtained through grants where no resource
owner is involved, such as the client credentials grant, the value of
sub SHOULD correspond to an identifier the authorization server uses
to indicate the client application.
Maybe I am missing something, but does it say anywhere
