[Openid-specs-fapi] Signed HTTP in IETF

[Stuart Low]

Hi Anders,

> Cavage HTTP Signatures appears to have become an HTTP-bis item:
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-message-signatures/

Interesting. I note the intention of this spec is to facilitate message
integrity within an SSL border. This seems like a valuable addition.

> Even if it becomes an IETF standard, I will most likely stick to my
> current https://cyberphone.github.io/doc/web/yasmin.html scheme
> because using HTTP headers for carrying data of such importance that
> it must be signed seems like a not entirely recommendable solution
> since such data may not survive proxies etc.  The "predecessor"
> WS-Security did (AFAICT) not depend on such features either.

Creating islands of standards by declaring you will stick with your own
spec only creates more work for adopters. Regarding the reference to
proxies, if I read the introduction to the httpbis spec correctly, this
isn't a use case that is intended as it appears to be primarily focused
on transiting infrastructure owned by a single or cooperating set of
parties.

> In addition, counter-signing which is great way simplifying system
> design, also becomes a breeze if you stick to HTTP bodies:
> https://cyberphone.github.io/doc/saturn/bank2bank-payment.html#6

Except restricting the method to bodies only also precludes all other
HTTP methods beyond POST.

> However, putting an explicit "recepientUrl" in message requests is
> though logical since it is useful information for both parties (where
> did I send it? am I the proper receiver?):
> https://cyberphone.github.io/doc/saturn/bank2bank-payment.html#4

The httpbis spec seems to be focused on a more generalised signature
method as opposed to being implementation specific (ie. the header names
are more generalised such as keyId, signature etc).

Stuart