What class of attacks is this trying to prevent? I frankly don't see a
problem with confusing different types of JWT. But I may just be
ignorant.
On Thu, Jul 27, 2017 at 2:49 PM, Brian Campbell
<bcampb...@pingidentity.com> wrote:
> During the first WG meeting last week I asked if use of the JOSE "crit"
> (Critical) Header Parameter had been considered as a recommendation for
> preventing confusion of one kind of JWT for another. Time was running short
> in the meeting so there wasn't much discussion and it was requested that I
> take the question to the list. And so here on the list is that.
>
> Section 3.9 of the JWT BCP draft now recommends explicit typing using the
> "typ" JWS/JWE header parameter but does concede that 'the use of explicit
> typing may not achieve disambiguation from existing kinds of JWTs, as the
> validation rules for existing kinds JWTs often do not use the "typ" header
> parameter value.' And the recommendations for how to use the Type Header
> Parameter in JWT strongly suggest that it's not currently being used for any
> validation.
>
> Alternatively using the JWS/JWE "crit" (Critical) Header Parameter to signal
> the type/intent/profile/application of a JWT could achieve disambiguation
> even in validation of existing kinds of JWTs. The critical header lists
> other headers which must be understood and processed by the receiver and
> that the JWS/JWE is invalid if those listed aren't understood. So a new
> type/profile of JWT that uses the "crit" header would produce JWTs that
> would be rejected even by existing applications of JWT validation (that
> actually implement "crit" properly anyway).
>
> The JWT BCP could suggest the use of "crit" in conjunction with a
> profile/application/type specific header. Or it could provide a bit more of
> a framework like defining a registering a new JOSE header "p" (strawman of p
> as a very short name for profile) and create a registry for its values. A
> JWT header using that approach might look like the following where the value
> 1 is registered as some cool new JWT profile/application. The consumer of
> such a JWT would have to understand and process the "p" header, which would
> mean checking that it had the value expected.
>
> {
> "alg":"ES256",
> "crit":["p"],
> "p":1
> }
>
> A JOSE compliant JWT validator would reject such a JWT even for an OAuth
> access token or OIDC id_token because the "p" header isn't known or
> understood but is marked as critical.
>
> To me, that seems like an approach to preventing confusion that has more
> teeth than the "typ" header. Which is why I asked about it last week and am
> now bringing it to the list.
>
>
>
>
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This email may contain confidential and privileged
> material for the sole use of the intended recipient(s). Any review, use,
> distribution or disclosure by others is strictly prohibited. If you have
> received this communication in error, please notify the sender immediately
> by e-mail and delete the message and any file attachments from your
> computer. Thank you.
> _______________________________________________
> jose mailing list
> j...@ietf.org
> https://www.ietf.org/mailman/listinfo/jose
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
