[Openid-specs-fapi] Signed HTTP in IETF
anders.rundgren.net at gmail.com
Mon Apr 20 06:03:07 UTC 2020
On 2020-04-20 02:02, Stuart Low via Openid-specs-fapi wrote:
> Hi Anders,
>> Cavage HTTP Signatures appears to have become an HTTP-bis item:
> Interesting. I note the intention of this spec is to facilitate message
> integrity within an SSL border. This seems like a valuable addition.
I may have read the I-D too quickly but I couldn't find anything special regarding TLS except that TLS sometimes is not enough due to end-point termination.
>> 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.
The current alternatives would require a complete redesign, far beyond "syntax". I guess the non-standard JSON-based cryptographic constructs [1,2] may indeed cause some additional work. OTOH, they are very much the reason to why the system looks so cool :-) The foundation for those  will be published as an (ISE) RFC later this year.
BTW, FAPI has its own "signature standard" and switching to a future IETF ditto will not be easy since the draft (currently) does not build on the JOSE stack.
Conclusion: there will probably never be a true standard for signed HTTP.
> 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
From what I have understood, one of the reasons to why for example the JOSE WG didn't consider such a work-item was the difficult handling of headers by for example reverse proxies.
>> In addition, counter-signing which is great way simplifying system
>> design, also becomes a breeze if you stick to HTTP bodies:
> Except restricting the method to bodies only also precludes all other
> HTTP methods beyond POST.
Right, I'm a true heretic and and have even been excommunicated by the REST cult :-) Seriously, what does REST bring for information-rich messaging of the kind used in Saturn? Self-contained strongly typed message-objects seemed like a better idea.
Only the [for Saturn crucial] discovery services use REST-looking unauthenticated GET operations:
>> 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?):
> 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).
Yes, it is media-independent as well.
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
More information about the Openid-specs-fapi