[Openid-specs-fapi] A simpler signing solution

Brian Campbell bcampbell at pingidentity.com
Mon Oct 26 14:05:28 UTC 2020


As someone who has expressed distaste for pretty much every HTTP signature
scheme attempted and also tried to keep the scope of DPoP to
proof-of-possession so that it doesn't try to be yet another HTTP signature
scheme, I don't actually hate this idea as much as you might expect. It
does seem simpler than others and maybe finds a pragmatic place in the
continuum of doing enough to address the basic need while not going
overboard. Maybe anyway.

Is there only need to have a signature for requests? It'd become a lot more
than building on DPoP with one additional claim, if it needs to cover
responses.

I've not looked at either in detail, TBH, but there is work underway that
aims to obsolete RFC 3230
https://datatracker.ietf.org/doc/draft-ietf-httpbis-digest-headers/ which
should be considered if this is pursued.







On Fri, Oct 23, 2020 at 7:41 AM Dave Tonge via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> 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
>
>
>
>
> --
> Dave Tonge
> CTO
> [image: Moneyhub Enterprise]
> <http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
> Moneyhub Financial Technology, 5th Floor, 10 Temple Back, Bristol, BS1 6FL
> t: +44 (0)117 280 5120
>
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
> Limited which is authorised and regulated by the Financial Conduct
> Authority ("FCA"). Moneyhub Financial Technology is entered on the
> Financial Services Register (FRN 809360) at fca.org.uk/register. Moneyhub Financial
> Technology is registered in England & Wales, company registration number
> 06909772 .
> Moneyhub Financial Technology Limited 2018 ©
>
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all
> attachments for viruses. All calls and emails to and from this company may
> be monitored and recorded for legitimate purposes relating to this
> company's business. Any opinions expressed in this email (or in any
> attachments) are those of the author and do not necessarily represent the
> opinions of Moneyhub Financial Technology Limited or of any other group
> company.
>
> Moneyhub Enterprise is a trading style of Moneyhub Financial Technology
> Limited which is authorised and regulated by the Financial Conduct
> Authority ("FCA"). Moneyhub Financial Technology is entered on the
> Financial Services Register (FRN 809360) at https://register.fca.org.uk/.
> Moneyhub Financial Technology is registered in England & Wales, company
> registration number 06909772. Moneyhub Financial Technology Limited 2020 ©
> Moneyhub Enterprise, Regus Building, Temple Quay, 1 Friary, Bristol, BS1
> 6EA.
>
> DISCLAIMER: This email (including any attachments) is subject to
> copyright, and the information in it is confidential. Use of this email or
> of any information in it other than by the addressee is unauthorised and
> unlawful. Whilst reasonable efforts are made to ensure that any attachments
> are virus-free, it is the recipient's sole responsibility to scan all
> attachments for viruses. All calls and emails to and from this company may
> be monitored and recorded for legitimate purposes relating to this
> company's business. Any opinions expressed in this email (or in any
> attachments) are those of the author and do not necessarily represent the
> opinions of Moneyhub Financial Technology Limited or of any other group
> company.
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20201026/bf25da43/attachment.html>


More information about the Openid-specs-fapi mailing list