[Openid-specs-fapi] A simpler signing solution

Dave Tonge dave.tonge at momentumft.co.uk
Fri Oct 30 09:43:05 UTC 2020


Hi Francis

> sigT - this is equivalent to `iat` and if we have a standard JWT, then we
can use the standard `iat` claim

> sigD - now there are three types of data that need to be signed:

*1. url & method*
dpop has a defined way to convey these in a standard JWT. I see no reason
why the representation of these values according to the OBE spec is any
better. Arguably it is worse as it relies on canonicalisation rules from
draft-cavage.

*2. request body*
obe/draft cavage don't directly sign this, but rather rely on an http
digest header being created and use that as the signing material. My
suggestion is that rather than sign the http header, we actually include
the digest as a defined claim in a JWT. This makes both signing and
verification easier and arguably makes the resulting JWT easier to
understand and use as it is a self-contained token, there is no need to
reconstruct the signing material, the verifier simply has to compute the
digest and compare it to the verified digest in the JWT.

*3. other http headers*
My recommendation is that for any new API standard these should be avoided.
I think the industry has settled on a best practice for RESTful JSON APIs
of having payloads containing `data` and `meta` objects. Any metadata is
better to be sent in the body rather than as a header. However I understand
that many existing API specs (including current drafts of FAPI) use http
headers to convey relevant metadata. Now if request size is not an issue
then my suggestion is that http headers that need to be signed are repeated
in the JWT (e.g.
https://github.com/davidgtonge/http-signing/blob/main/src/dpop-plus3.js).

*Verification Complexity*

Verification steps for dpop-plus
1. compute body digest hash
2. decode JWT to get public key details
3. retrieve public key
4. verify JWT
5. check equality between http method and `htm` claim
6. check equality between http uri and `htu` claim
7. check equality between digest hash and `htd` claim
8. check equality between `hth` claim and other http headers (ensuring that
header names are lowercased)

All of this can be done using standard JWT libraries.
The verification checks are simple equality checks.
It is very clear to understand if anything goes wrong.

Verification steps for OBE
1. compute body digest hash
2. parse signature header to retrieve the JWS header
3. decode JWS header
4. retrieve public key
5. verify that non-standard JWS header claims are included in the `crit`
claim
6. use the `sigD.pars` data to construct the signing material according to
the `sigD/mId` scheme
7. verify the JWS using the signing material

This can't be done by all standard JWT libraries
 - many will base64url encode with jws payload
 - many won't verify `crit` claims automatically
 - many won't decode a detached JWS

Step 6 is quite complex and if something goes wrong the verifier has no
idea that the problem is. This can be a big barrier to interoperability. As
pointed out in the OBE spec they haven't understood the importance of
lower-casing http headers, and that is a group of very technically minded
people trying to write a spec. Implementers are very likely to make similar
issues and it will be hard to understand what has gone wrong.

Do you think its worth having a call to talk about this?

Thanks

Dave

On Fri, 30 Oct 2020 at 00:22, Francis Pouatcha <Francis.Pouatcha at adorsys.com>
wrote:

> Dave,
>
> DPoP is simple because if focusses on the transport (moment) and can
> thereby limited on transport related issues. It is IMHO designed for
> ephemeral transport based key materials, where there is no need to have a
> key legitimated.
>
> A Http Signature must be designed to allow for use as proof in a court
> case or as supporting material for an audit. This is the reason why you
> need those additional attributes that by consequence lead to more
> complexity.
>
> As for OBE, attributes added are
>
>    - sigT: the signature time. This could in many cases be different from
>    the transmission time of the request.
>    - sigD: the signature data specification: this is essential to define
>    what is to be signed. As
>       - different legislation might require the presence of different
>       header parameters
>       - the body type canonicalization might vary depending on the nature
>       of the request body (or not). The canonicalization of the body content will
>       be a variant to deal with. In particular, when it will come to archiving
>       signed http requests.
>
>
> We are suggesting an additional:
>
>    - sigF: to indicate the trust framework for. resolution and
>    legitimation of the key material.
>
>
> PSD2 API initiatives in Europe in Europe are contributor to OBE,
> therefore the highest probability they will all adopt it. Beside this it is
> prepared for eIDAS conformity, making signed material a valid proof under
> European law.
>
> /Francis
>
> ------------------------------
> *From:* Dave Tonge <dave.tonge at momentumft.co.uk>
> *Sent:* Thursday, October 29, 2020 12:43 PM
> *To:* Francis Pouatcha <Francis.Pouatcha at adorsys.com>
> *Cc:* FAPI Working Group List <openid-specs-fapi at lists.openid.net>; Brian
> Campbell <bcampbell at pingidentity.com>
> *Subject:* Re: [Openid-specs-fapi] A simpler signing solution
>
> I've pushed some example code for the some of the different signing
> mechanisms here: https://github.com/davidgtonge/http-signing
>
> I'll add a bit more analysis.
> But my main issue with the OBE approach is the unnecessary complexity.
>
> For example compare this file:
> https://github.com/davidgtonge/http-signing/blob/main/src/obe.js
> With this one:
> https://github.com/davidgtonge/http-signing/blob/main/src/dpop-plus.js
>
> This is just the signing rather than the verification.
>
> The question to my mind is will PSD2 API initiatives in Europe adopt the
> OBE profile. I'm not sure that OBUK will. Do you know if Berlin Group will?
>
> Dave
>
> On Thu, 29 Oct 2020 at 15:33, Francis Pouatcha <
> Francis.Pouatcha at adorsys.com> wrote:
>
>
> ------------------------------
> *From:* Dave Tonge <dave.tonge at momentumft.co.uk>
> *Sent:* Thursday, October 29, 2020 10:09 AM
> *To:* FAPI Working Group List <openid-specs-fapi at lists.openid.net>
> *Cc:* Francis Pouatcha <Francis.Pouatcha at adorsys.com>; Brian Campbell <
> bcampbell at pingidentity.com>
> *Subject:* Re: [Openid-specs-fapi] A simpler signing solution
>
> Hi Francis, Brian
>
> I am proposing that we define a new mechanism for http signing in the FAPI
> WG.
> Obviously it should use existing standards where at all applicable.
>
> As discussed on the call, it would be good to come up with a document that
> we can present to the WG.
> It seems that we have two options at the moment:
>
> *1. Build on the OBE spec*
> *2. Build on dPOP*
>
> At first I was leaning towards option 1, but after further review of the
> OBE spec I personally am very much leaning towards option 2. I think the
> OBE spec is not fit for purpose, it adds lots of unnecessary complexity
> just because its trying to join draft-cavage and  an earlier version of the
> UK OpenBanking signing spec together. I may try and show some worked
> examples as I think my suggestion will result in a small http payload even
> if some header values are repeated.
>
> I do believe the payload size is less interesting here than
> interoperability. I prefer we look at how to simplify  the current OBE
> draft.
>
> @Brian Campbell <bcampbell at pingidentity.com> -> reply inline bellow:
>
> On Thu, 29 Oct 2020 at 14:12, Brian Campbell via Openid-specs-fapi <
> openid-specs-fapi at lists.openid.net> wrote:
>
>
> On Thu, Oct 29, 2020 at 5:10 AM Francis Pouatcha <
> Francis.Pouatcha at adorsys.com> wrote:
>
> I agree with Dave we shall not define a new signature mechanism.
>
>
> As I understood the message that started this thread and the discussion
> about it during the call yesterday, Dave is very much proposing that we
> define a new mechanism. Maybe there's some semantic difference or
> miscommunication here but I'm confused by your statement.
>
> I think having compatibility with OBE is essential.
>
>
>
> As for the replacement of RFC3230 with
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-digest-headers/,
> adding a signature header field to indicate the mechanism used to digest
> the http body might solve the problem.
>
>
> What problem? I just wanted to note that there was work underway to
> update/obsolete RFC3230 as it seemed relevant given Dave's initial proposal
> relied on RFC3230. But I don't understand what problem you're suggesting
> would be introduced by the new document or how that would solve it.
>
> No problem. Like elaborated in
> https://bitbucket.org/openid/fapi/issues/297/open-banking-europe-jws-profile-for#comment-59040544 the
> field "sigD"."pars" can be  used to indicate canonicalization and digest
> rules for body. Giving implementor a choice on how to process the http body.
>
> <https://bitbucket.org/openid/fapi/issues/297/open-banking-europe-jws-profile-for#comment-59040544>
> Open Banking Europe JWS PROFILE for OpenBanking
> <https://bitbucket.org/openid/fapi/issues/297/open-banking-europe-jws-profile-for#comment-59040544>
> This JWS profile consolidate the work done at ETSI \\(JADes\\) and the
> Internet Draft draft-cavage-http-signatures-10 and Signing HTTP Messages.
> This issue will be used to collect details associated with referencing that
> work in the FAPI profiles for the purpose of addressing non repudiation.
> bitbucket.org
>
>
> I am a bit concerned (or rather just don't really understand the
> implications of) about RFC3230 and it's successor digesting the "instance"
> or "representation" of the resource as opposed to the payload of the
> message itself. But as far as I can tell RFC3230 and
> https://datatracker.ietf.org/doc/draft-ietf-httpbis-digest-headers/ are
> the same in this regard but just use different language to describe it.
>
>
> Yes.
>
> /Francis
>
>
>
> --
> 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.
>
>

-- 
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/ 
<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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20201030/3986804f/attachment-0001.html>


More information about the Openid-specs-fapi mailing list