[Openid-specs-fapi] A simpler signing solution

[Dave Tonge]

Thanks Anders

> Pardon my ignorance, but how can you skip "detached" without having the
body Base64Url-encoded?
I mean that a full JWT should be sent in the header, rather than the
so-called detached mode, where the JWS body is removed.

On Sat, 24 Oct 2020 at 06:37, Anders Rundgren <anders.rundgren.net at gmail.com>
wrote:

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

-- 
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/20201026/3fa666db/attachment.html>