On Sat, Feb 20, 2021 at 12:42 AM Vittorio Bertocci <vittorio.bertocci@xxxxxxxxx> wrote:
Thank you Joseph for your comments!
[Joe] Thanks for your response, comments inline below:
> 1. (Editorial) What is the relationship between this document and RFC 7523.
> They are using JWT for different purposes, but I think it would be useful to
> clarify this in the introduction.
Good point, I agree it would be good to preempt doubts on this. I am suggesting to append the following language to the current introduction (pardon the XML).
Please note: although both this document and <xref target="RFC7523"/> both use JSON Web Tokens in the context of the OAuth2 framework, the two specifications differ in both intent and mechanics. Whereas <xref target=" RFC7523"/> defines how a JWT Bearer Token can be used to request an access token, this documents describes how to encode access tokens in JWT format.
[Joe] Yes, that looks good to me.
> 2. (Issue) The specification does not specify any mandatory to implement for
> the recommended asymmetric algorithms. This will not help interop. Perhaps
> specify one or both of "RS256" and "ES256".
The current text doesn’t mandate a format for two main reasons:
- thanks to the AS metadata the negotiation between a RS and an AS is very easy to perform, hence the likelihood of interop issues at runtime is very low
- worries that as crypto advances, what we mandate at this point might no longer be suitable.
That said, if you feel strongly about this please do let me know, and I will be OK with adding RS256 as a mandatory supported alg for both AS and RS.
From a cursory check, ES256 doesn’t seem to enjoy as widespread support at the moment (see https://jwt.io/ libraries list) hence I would be hesitant to make it mandatory.
[Joe] I think you should add RS256 as mandatory to implement. Since RFC 7518 does not mandate an asymmetric algorithm it's possible that two implementations make different choices on which one to support.
> 3. (Question) Is it currently possible to use the JWT access token in a mode
> other than a bearer token? For example is there a way to bind the JWT to a
> verifiable key or identifier. If there is, there should be some discussion of
> this in the security considerations. If not, do the authors know if there is
> any work planned in this area?
At this time, the main mechanisms that can work with non-bearer ATs are dPOP and MTLS. In both cases, the binding mechanism relies on a cnf claim (or reference to it) - which can be added to a JWT access token without changing any of the guidance in this specification. There's a quick primer for both approaches in https://auth0.com/blog/identity-unlocked-explained-episode-1/. Given that there are no changes in the AT format and verification, and MTLS/DPOP would be purely additive, any language here would likely be functionally equivalent to "You should be aware that MTLS exists, and the tokens defined here do not break it" (DPOP isn’t mentioned because it's still in progress) but my intuition is that the compatibility should be assumed, with a note being required when it's not the case and the reader should be aware of potential problems. What do you think?
[Joe] Thanks for the explanation. I don't think there needs to be anything added to the document for this.
-- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
