[Openid-specs-fapi] A simpler signing solution

[Anders Rundgren]

On 2020-10-29 12:07, Francis Pouatcha wrote:
> @Dave Tonge <mailto:dave.tonge at momentumft.co.uk>, @Anders Rundgren <mailto:anders.rundgren.net at gmail.com>,
> 
> there are many reasons why we shall not try to modify the body content of the http message for the purpose of signing the message.

Hi Francis,

If we stick to FAPI which is based on JSON the only technical reason (that I'm aware of NB) to why signatures are not featured in the HTTP body is the JWS/JWT requirement for Base64Url-encoding the data to be signed.

Detached signatures takes you out of this conundrum but at the expense of serializability.

Saturn OTOH [1], depends on stacked signed messages and thus cannot use the detached approach.  However, Base64Url-encoding stacked messages would make the system look like s**t.  This was the primary motivation behind RFC 8785.

What I'm saying is that the "window of opportunity" (if there ever was one...), for a single, all-encompassing HTTP signature standard have passed, but that I don't particularly object to FAPI taking the OBE route.

However, due to the growing interest in RFC 8785, the spec group recently decided to create a set of RFC's based on RFC 8785.  The initial RFC will be very simple to keep the ball rolling:)
Spec: https://github.com/cyberphone/jws-jcs#detailed-signing-operation
On-line service for testing: https://mobilepki.org/jws-jcs/home

Regards,
Anders

1] https://cyberphone.github.io/doc/saturn/saturn-v3-presentation.pdf

> 
> Following the work of OBE and other initiatives going in this direction, any work done shall focus on adding header fields to the message.
> 
> Best regards.
> /Francis
> ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> *From:* Openid-specs-fapi <openid-specs-fapi-bounces at lists.openid.net> on behalf of Dave Tonge via Openid-specs-fapi <openid-specs-fapi at lists.openid.net>
> *Sent:* Friday, October 23, 2020 9:40 AM
> *To:* Openid-specs Fapi <openid-specs-fapi at lists.openid.net>
> *Cc:* Dave Tonge <dave.tonge at momentumft.co.uk>
> *Subject:* [Openid-specs-fapi] A simpler signing solution
> Dear WG
> 
> After looking in more detail at the proposed OBE signing spec, I'm really quite concerned and think that this WG should work on something else simpler as soon as possible.
> 
> My suggestion is:
>   - abandon "detached" jwts
>   - build on dPoP by defining one additional claim - `htd` - the http body digest
>   - recommend that any info in headers that needs to be integrity protected is put in the body
> 
> So you would end up with a JWT with a standard header (no need for any `crit` claims), and a body that would be something like this:
> 
> {
>       "jti":"-BwC3ESc6acc2lTc",
>       "htm":"POST",
>       "htu":"https://server.example.com/payment",
> 
> "htd":"SHA-256=+xeh7JAayYPh8K13UnQCBBcniZzsyat+KDiuy8aZYdI=", "iat":1562262616 } The `htd` value would be created according to the instructions in RFC3230
> 
> Verification rules would be the same as dPoP, but with the addition of the verification of the `htd` value.
> 
> The advantage of this approach:
>   - should be supported by all standard JWT libraries
>   - should be much easier to get interoperability as there aren't the same serialisation problems as draft-cavage or the OBE profile.
>   - only one additional claim needs to be registered in the IANA registry
> 
> Any feedback?
> 
> @anders - I know you will suggest rather using rfc8785, and I think that as a WG we should definitely keep monitoring support for that, but the reality is that at the moment there isn't widespread adoption.
> 
> Thanks
> 
> Dave
>