- From: Anders Rundgren <anders.rundgren.net@gmail.com>
- Date: Mon, 17 Oct 2022 18:45:39 +0200
- To: Julian Reschke <julian.reschke@gmx.de>, ietf-http-wg@w3.org
On 2022-10-17 18:31, Julian Reschke wrote: > On 17.10.2022 18:27, Anders Rundgren wrote: >> On 2022-10-17 13:59, Julian Reschke wrote: >>> On 17.10.2022 12:44, Anders Rundgren wrote: >>>> +1 >>>> >>>> Target URI and Method (as well as other data related to the message), >>>> may equally well be put in the payload. HTTP header signing is an >>>> unnecessary complication. >>>> ... >>> >>> Can you elaborate? You might have a media type that allows adding a >>> *copy* of that information, but that's not the same thing. >> >> Hi Julian, >> It is quite possible that I misunderstand what you write but I don't see >> a problem with having a copy of targetUri in the payload. >> An RP may (depending on proxying etc) compare this data with the HTTP >> header counterpart and fail if there is a mismatch. >> >> An additional advantage with this arrangement is that signed messages >> become serializable and thus can easily be stored in databases, embedded >> in other objects, etc. >> >> Regards, >> Anders > > Well, that would only work with certain media types. It's not a generic > solution. Right, from an HTTP point of view this is of course correct. However, in many systems, images are also included in the message payload. That is, it seems rather unlikely that there ever will be a single method or standard for dealing with signed data (not to mention encrypted data), transferred over HTTP. However, that does absolutely not mean that "draft-ietf-httpbis-message-signatures-13" is useless and should be abandoned :) Regards, Anders > > Best regards, Julian >
Received on Monday, 17 October 2022 16:45:51 UTC