Bug with accessing LTI tool's public key set?

Question

My explorations suggest that Canvas is failing to find a public key from a URL which returns a JWK Set with a content-type header of "application/jwk-set+json" as per the JSON Web Key (JWK) spec (see https://datatracker.ietf.org/doc/html/rfc7517).  I get an error of

{"errors":{"jwt":[{"attribute":"jwt","type":"JSON::JWK::Set::KidNotFound","message":"JSON::JWK::Set::KidNotFound"},{"attribute":"jwt","type":"JWT verification failure","message":"JWT verification failure"}]}}

When the content-type header used by the public key endpoint is "application/json" the error does not occur.

Has anyone else encountered this issue?

Thanks.

svickers2 · Answer

I have been using application/jwk-set+json with my own tools, including the saLTIre test tool.  Canvas is the only platform with which I have encountered an issue when doing so and its error message could be a little more helpful.  I do not understand why Canvas chooses to be so prescriptive over the content-type header; if the body includes a valid public key set, why not just generate a warning message over the content-type header?  Perhaps there is a security issue here, in which case, the list of permitted content-type header values needs to be extended.  That is my view anyway.

matthew_buckett · Answer

Yeah it would be good if Canvas just acceped it. Out of interest what's the tool that's outputting the JWKS with a MIME type of `application/jwk-set+json`?

svickers2 · Answer

Thanks @matthew_buckett .  So we both seem to be in agreement that the content-type of application/jwk-set+json is valid, albeit not in widespread use, so surely Canvas should accept it when accessing a public key set, rather than generating an error.  That way, those tools which are using it can continue doing so, rather than having to change or use a proxy URL to workaround it.  So how about it Instructure?