sponses in JWT Profile for OAuth 2.0 Access
Tokens
Hi Vittorio,
I was chatting with Aaron offline about this issue and my concern is the
addition of Authentication Information Claims in this spec opens up more
interoperability issues that can’t be addressed with just a JWT Access Token
spec.
Alrighty. I added language to explicitly call out 6570 and invalid_token... and
eliminated step 7 in the validation for other reasons, indirectly obviating for
the need to clarify the reauthentication signaling mechanism.
Updating the draft shortly.
On 3/25/20, 12:59, "vittorio.berto...@auth0.c
Hi Vittorio,
I was chatting with Aaron offline about this issue and my concern is the
addition of Authentication Information Claims in this spec opens up more
interoperability issues that can’t be addressed with just a JWT Access Token
spec.
OAuth 2.0 AFAIK, doesn’t define any behaviors around
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 t