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
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
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
Brian, there are plenty of ways in which an RS can surprise you with odd
behavior- for example, developers might see that you used a key for signing an
IDtoken and use that for init all their validation middleware for ATs as well,
say because the library only supports one key at a time, and
That works for me!
From: George Fletcher
Sent: Wednesday, March 25, 2020 11:56 AM
To: vittorio.berto...@auth0.com; 'Brian Campbell'
Cc: 'Brian Campbell' ; 'oauth'
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens"
If we don't want to give
Thanks Aaron!
You are right, we could be clearer re:errors. AFAIK the only errors we can
rely on from an RS are in RFC6750, and the entire section is about what to
look for in an incoming AT to validate, hence it doesn't look like we have
much choice but to return invalid_token for every error in
Fair. I went back to the aggregated research rather than the individual emails
and I did find those samples from you- thanks for pointing this out.
Nonetheless, I don’t think this changes the main argument. Symmetric isn’t
disallowed, it just cannot give a complete end to end solution that
Thank you for the perspective- I guessed something similar (“there would be no
way for the RS to know what key is used for what").
As stated below, the intent wasn’t to prevent substitution/confusion, but
mostly to give ASes license to use different keys if they choose to (for the
reasons
Thanks Hannes!
I will go thru the comments and update accordingly by EoW.
From: OAuth On Behalf Of Hannes Tschofenig
Sent: Monday, September 7, 2020 11:30 PM
To: oauth@ietf.org
Subject: [OAUTH-WG] draft-ietf-oauth-access-token-jwt-07
Hi Victorio, Hi all,
I am doing my shepherd
Hey Jim, regarding
> Every logout event should trigger token revocation
That isn’t necessarily the case. An access token represents the ability of a
client to access a given resource; the fact that it requires an authentication
transaction/session establishment to be issued to the client does
Thanks for bringing the revocation topic up. In brief:
* I agree on the comments that differentiate between userinfo and
introspection- userinfo doesn’t really play a role in validation hence I’d keep
it out of the JWT AT doc.
* I agree that the introspection endpoint shouldn’t
Hi Andrii,
Thanks for the thoughtful comments! Here’s my 2 c.
On the proposed language: given that the JWT AT profile is just providing more
details on the content of an AT, making JWT ATs a proper subset of all ATs,
readers should have no reason to believe that introspection or any other
Hey Aaron,
Auth0 does offer a configurable grace period, during which the “preceding”
token can be reused.
I am not 100% sure what we do in the exact scenario you described, and I will
double check for you, but here’s my intuition.
The operation redeem(RT_n) should result in AT, RT_n+1.
Thanks for the clarification! I agree, the scenarios you described would be
improved by actually killing the ability of the app to access the resources,
instead on relying on the client to discard the tokens without leaking them.
That's why I am a big proponent of the online_access scope, tho I
+1
From: OAuth On Behalf Of Dick Hardt
Sent: Wednesday, July 15, 2020 10:55 AM
To: Rifaat Shekh-Yusef
Cc: oauth
Subject: Re: [OAUTH-WG] Call for adoption - OAuth 2.1 document
+1
On Wed, Jul 15, 2020 at 10:42 AM Rifaat Shekh-Yusef mailto:rifaat.s.i...@gmail.com> > wrote:
All,
Dear authors,
It took ages but I finally managed to go thru a full review of the current
OAuth2.1 draft. Apologies for the delay.
Metacomments:
* The VAST majority of the comments are suggestions for improving
clarity, mostly on historical language coming from 2.0 that I found myself
Hi Nikos,
Thanks for looking into this!
The profile aims at reflecting currently adopted practice as much as it is
viable, and the overwhelming majority of the use cases involving access
tokens today relies on bearer tokens.
Note: although there's no practical difference between versions in the
Hi Denis, this aspect was debated at length (one example in
https://mailarchive.ietf.org/arch/msg/oauth/OYgGsIa_4q8UYnl6SiGyvJ9Hnxw/, there
are many others) and the consensus reflected in the current text was clear.
From: Denis
Sent: Wednesday, April 14, 2021 1:19 AM
To: Vittorio Bertocci
18 matches
Mail list logo
