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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
