[Openid-specs-fapi] A simpler signing solution

Anders Rundgren anders.rundgren.net at gmail.com
Sat Oct 24 04:37:12 UTC 2020


On 2020-10-23 15:40, Dave Tonge via Openid-specs-fapi wrote:
> Dear WG

Hi Dave,

> 
> 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

Pardon my ignorance, but how can you skip "detached" without having the body Base64Url-encoded?


>   - 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

Good idea.


> 
> 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.

No big deal.  I'm rather focusing on the "wallet" side of things where RFC 8785 fits like a glove.  I'm just putting the "finishing touches" on a universal receipt mechanism which also uses RFC 8785.

BTW, I believe the Open Banking community should carefully monitor https://github.com/rsolomakhin/secure-payment-confirmation#secure-payment-confirmation because if is succeeds it will most likely morph into a full-fledged "wallet" which [currently] is at odds with the Open Banking concept.  FIDO + Chrome + Stripe and a team of devoted Googlers is a lethal combination!  While the [fairly closed] banking community keep failing on a unified "SCA" solution, somebody else do that for them :)

Cheers,
Anders

> 
> Thanks
> 
> Dave



More information about the Openid-specs-fapi mailing list