-
Notifications
You must be signed in to change notification settings - Fork 26
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Modification of content type by attached JWS signature method #109
Comments
I would agree with removing this. Although conceptually simpler this breaks the key benefit of RESTful JSON APIs of over the wire readability. In practice this has been a big benefit to developer experience and debugging. |
I think it's early for the beauty contest among signature methods, so let's not prune the list just yet. Besides, I'm not sure about fragility. I don't think there's any system that will try to decode and mangle the base64-encoded JWS. There are good reasons why "attached JWS" is not best for the RC-RS API, but it's actually very useful for RC-AS. |
My own implementation of this method has to pre-decode the JWS payload in a filter in order to present the application with something that it can parse into objects to present to the controllers. It also keeps the "raw" version around for the signature validation code to be able to work with, but for this stack it means basically keeping two full copies of the request around in order to check the signature later. It's doable, but I can attest that it's awkward. This issue isn't present if you're doing the parsing at a late stage, for example doing it by hand within the controller. |
This is a known issue that is discussed in the text, and it is intrinsic to the method. |
§8.2 Attached JWS: Editor's note:
A downside to this method is that it requires the content type to be something other than application/json, and it doesn't work against an RS without additional profiling since it takes over the request body - plus we have to specify different delivery locations for a GET vs. a POST, for example. Additionally it is potentially fragile like a detached JWS since a multi-tier system could parse the payload and pass the parsed payload downstream with potential transformations. We might want to remove this in favor of general-purpose HTTP signing, or at least provide guidance on its use.
The text was updated successfully, but these errors were encountered: