[OAUTH-WG] Security BCP and mTLS/PoP tokens

[Neil Madden <[e-mail]>]

I was wondering if the security BCP should mention something about what an RS should do if it encounters a token introspection response or JWT claims set that contains a "cnf" value, but either:

 * the RS doesn't support any kind of PoP/sender-constraints at all, or
 * the RS doesn't understand the particular confirmation method(s) in the "cnf" object

At the moment, the generic rules in RFC 7519 for processing JWTs say:

   Specific applications of JWTs will require implementations to
   understand and process some claims in particular ways.  However, in
   the absence of such requirements, all claims that are not understood
   by implementations MUST be ignored.

I think for confirmation keys we want to have specific requirements that say that an access token with a not-understood confirmation method should be rejected. Otherwise a client may be using a token on the understanding that it is PoP-protected/sender-constrained when the RS is silently ignoring these constraints.

In retrospect, it's a shame that JWT doesn't have something like "crit" for claims rather than headers. (We could perhaps bootstrap this by adding a new critical-claims header, which itself can be marked critical, but that won't help for normal JSON token introspection responses).

PS - the latest security BCP draft appears to have expired. Is a new version pending?

Cheers,

Neil