[Openid-specs-fapi] HTTP Signing

Dave Tonge dave.tonge at momentumft.co.uk
Wed Jan 13 15:00:12 UTC 2021


Just bumping this to people's inboxes.
If you are interested in this work continuing in the FAPI WG, please reply
to this thread.

Thanks

Dave

On Sat, 9 Jan 2021 at 05:49, Anders Rundgren via Openid-specs-fapi <
openid-specs-fapi at lists.openid.net> wrote:

> On 2021-01-08 23:33, Brian Campbell wrote:
> > It's definitely more than just the claims as it uses and extends DPoP
> including the HTTP header that carries the DPoP JWT proof.
>
> I got that.  My question was rather related to the DPoP protocol like:
> https://tools.ietf.org/html/draft-ietf-oauth-dpop-02#section-5
>
>  From what I deduct see the draft can be used in any context and that is
> good :)
>
> Anders
>
> >
> > A slight modification to part of Dave's description might be helpful:
> >
> > /This specification is an extension to DPoP that supports the following
> >
> >   1. I*nclusion of a digest of the HTTP body as a claim in the DPoP
> proof *
> >   2. Using DPoP proofs in HTTP responses
> >   3. Allowing a signed HTTP response to be cryptographically linked to a
> signed HTTP request/
> >
> >
> > On Wed, Jan 6, 2021 at 11:17 PM Anders Rundgren via Openid-specs-fapi <
> openid-specs-fapi at lists.openid.net <mailto:
> openid-specs-fapi at lists.openid.net>> wrote:
> >
> >     Hi Dave,
> >
> >     I would like the draft to clearly state that it only uses DPoP
> claims rather than the DPoP protocol.
> >     Or is this assertion is wrong?  If so, I'm obviously confused :(
> >
> >     Thanx,
> >     Anders
> >
> >     On 2021-01-06 16:15, Dave Tonge via Openid-specs-fapi wrote:
> >      > Dear WG
> >      >
> >      > The FAPI2 Advanced spec requires a mechanism for HTTP signing.
> >      >
> >      > Brian and I have worked on the following spec based on DPoP that
> could be used to enable this:
> >      >
> >      >
> https://bitbucket.org/openid/fapi/src/581a0350bca97240f104fa27f4e9f0d9d851aab0/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md
> <
> https://bitbucket.org/openid/fapi/src/581a0350bca97240f104fa27f4e9f0d9d851aab0/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md>
> <
> https://bitbucket.org/openid/fapi/src/581a0350bca97240f104fa27f4e9f0d9d851aab0/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md
> <
> https://bitbucket.org/openid/fapi/src/581a0350bca97240f104fa27f4e9f0d9d851aab0/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md>>
> (SHIMP)
> >      > There has been some discussion in this issue <
> https://bitbucket.org/openid/fapi/issues/309/decision-on-message-signing-for-fapi-2
> <
> https://bitbucket.org/openid/fapi/issues/309/decision-on-message-signing-for-fapi-2
> >>
> >      >
> >      > I'll provide some more info below, but my ask of the WG is:
> >      >
> >      > *Should the FAPI WG adopt this document as a WG draft and start
> working on it?*
> >      >
> >      > I would be grateful for any feedback. If there is not support to
> work on such a spec within the WG then we can leave it and potentially in
> FAPI2 advanced require http signing but without specifying the method to
> use.
> >      >
> >      > ---
> >      >
> >      > Here is an overview of the spec from the intro:
> >      >
> >      > /The OAuth working group at the IETF has defined the DPOP
> standard which "enables a client to demonstrate proof-of-possession of a
> public/private key pair by including a DPoP header in an HTTP request".
> DPOP specifies a way for a client to sign a proof which contains claims for
> the HTTP method and URI. The specification allows DPoP proofs to be
> extended to protect additional HTTP data.
> >      >
> >      > This specification is an extension to DPoP that supports the
> following
> >      >
> >      >   1. Signing a digest of the HTTP body data
> >      >   2. Using DPoP proofs in HTTP responses
> >      >   3. Allowing a signed HTTP response to be cryptographically
> linked to a signed HTTP request
> >      >
> >      > The aim of this specification is to provide a simple,
> interoperable method of signing HTTP requests and responses. By utilizing
> DPOP (which itself utilizes the JOSE suite of standards) and DIGEST there
> is no need for custom canonicalization rules. The DPoP proof is a simple
> self-contained JWT and is therefore simple to verify./
> >      > ----
> >      >
> >      > I personally think that the ability to have a standards based
> approach to link the request and response for http signing will be
> important for the non-repudiation use-case.
> >      >
> >      > Issues with other solutions:
> >      >
> >      > 1. Draft Cavage - custom (error prone) canonicalization and
> algorithm specification
> >      > 2. OBE / ETSI - same problem as Cavage, but with the addition of
> a strange use of detached JWS for signing caoniclisated http headers rather
> than the body
> >      > 3. Detached JWS (used by OB UK) - only signs the body, requires
> custom JWT header claims
> >      >
> >      > In contrast SHIMP has these advantages:
> >      >   - uses simple JWTs, easy to implement, interoperable
> >      >   - no need for custom JWT header claims
> >      >   - no error-prone canonicalization
> >      >
> >      > I look forward to receiving your feedback.
> >      >
> >      > Dave
> >      >
> >      >
> >      > 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/> <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.
> >      >
> >      >
> >      >
> >      > _______________________________________________
> >      > Openid-specs-fapi mailing list
> >      > Openid-specs-fapi at lists.openid.net <mailto:
> Openid-specs-fapi at lists.openid.net>
> >      > http://lists.openid.net/mailman/listinfo/openid-specs-fapi <
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi>
> >      >
> >
> >     _______________________________________________
> >     Openid-specs-fapi mailing list
> >     Openid-specs-fapi at lists.openid.net <mailto:
> Openid-specs-fapi at lists.openid.net>
> >     http://lists.openid.net/mailman/listinfo/openid-specs-fapi <
> 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./
>
> _______________________________________________
> Openid-specs-fapi mailing list
> Openid-specs-fapi at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-fapi
>


-- 
Dave Tonge
CTO
[image: Moneyhub Enterprise]
<http://www.google.com/url?q=http%3A%2F%2Fmoneyhubenterprise.com%2F&sa=D&sntz=1&usg=AFQjCNGUnR5opJv5S1uZOVg8aISwPKAv3A>
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/20210113/407dc2e7/attachment-0001.html>


More information about the Openid-specs-fapi mailing list