[Openid-specs-fapi] Alive and kicking: draft-cavage-http-signatures

Anders Rundgren anders.rundgren.net at gmail.com
Thu Mar 14 06:46:11 UTC 2019


Hi Dave,
To be honest I have actually been inspired by the cavage/sporny draft.  I even "borrowed" some text from it:
https://tools.ietf.org/html/draft-rundgren-signed-http-requests-00#section-11
BTW, your idea of (re)structuring the security data was very good; I just wasn't sure you wanted to be listed as contributor :-)

Now to your review:
4. This is my interpretation of the draft: https://tools.ietf.org/html/draft-rundgren-signed-http-requests-00#section-6.8
6. isn't the situation the same for the current OBIE solution?

If there actually is interest in creating a real standard, I would consider starting with requirements.

- Although signing headers and method probably is not what everybody needs, it must in my opinion be a part of a "possible standard" to comply with REST.
- Signing the canonical URI seems to me like a basic requirement. Even if you are not using the URI for transmitting "data", the "recipient" in Internet-sense is an important piece of information.
- Reusing JWA is not a terrible idea either.

I believe the most troublesome part is how to deal with the message text itself.  JWS/Base64 Encoding, HTTP Bindings and Canonicalization are pretty different animals!

Regards,
Anders

> Hi Joseph
> 
> The problem is that there is lots of non-standard stringification and parsing as well as other weirdness.
> 
> Here are the problems I encountered:
> 1. the draft defines its own set of algorithms rather than just using the JWA
> 2. the signing material should be new line separated (why?)
> 3. the header which specifies the alg, what is being signed and the signature should be of the form 'Signature key="value",key="value"'
> 4. the header names are case sensitive (against http specs and caused me no end of grief as some http client libraries automatically lowercase http header names)
> 5. requirement on a date header in a non-standard form
> 6. requirement that http body is completely untouched or the digest will break
> 7. relies on the http digest spec (https://tools.ietf.org/html/rfc3230) for actual content integrity
> 8. uses a custom header to pass the http method and path (but leaves out host?)
> 
> When we are mainly talking about signing JSON API requests and responses I really don't think its the right way to go.
> 
> I agree that it would be a good topic for discussion at the OAuth Security Workshop.
> 
> Dave
> 
> On Wed, 13 Mar 2019 at 17:25, Joseph Heenan via Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net>> wrote:
> 
>     I presume the interoperability issues are solvable one way or another?
> 
>     The early reports about OBUK’s signing algorithm seem to be cautiously pessimistic. I’m not sure if OB gave any reasons for not using the IETF cavage draft.
> 
>     I know we’ve discussed it before, but it does seem like the FAPI working group should try and favour one standard, which would also allow us to build interoperability/certification tests for that standard. I think the oauth working group feels similarly. Justin Richer pulled together some of the thoughts at IETF 101 ( https://datatracker.ietf.org/meeting/101/materials/slides-101-oauth-sessa-http-signing-00 ) but I’m not sure if the conversation moved on from there.
> 
>     Perhaps it’s one to put on the agenda for the oauth security workshop face-to-face?
> 
>     Joseph
> 
> 
> 
>>     On 13 Mar 2019, at 16:15, Dave Tonge via Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net>> wrote:
>>
>>     Having integrated against it - the draft is terrible.
>>
>>     I highly doubt that it is being implemented in an interoperable way.
>>
>>     We need a better solution and I'm very much in favour of JSON based signatures - cleartext json would be great, but detached JWTs are still a lot better than http-signatures.
>>
>>     On Wed, 13 Mar 2019 at 16:41, Anders Rundgren via Openid-specs-fapi <openid-specs-fapi at lists.openid.net <mailto:openid-specs-fapi at lists.openid.net>> wrote:
>>
>>         After posting https://cyberphone.github.io/ietf-signed-http-requests/hotrfc-shreq.pdf in the https://open-banking-global.slack.com <https://open-banking-global.slack.com/> forum it became clear that quite a bunch of API builders in the financial sector (including Starling) indeed have settled on https://tools.ietf.org/html/draft-cavage-http-signatures-10.
>>
>>         Under those circumstances it seems a bit premature suggesting that other entities should not use it.  That a draft has expired doesn't make it worthless.
>>
>>         What's surprising is that I found no traces of any discussions within the IETF regarding this draft (which IMO doesn't look that bad).
>>
>>         Note: I'm not advocating for adoption of http-signatures, but for a more open discussion about the alternatives.
>>
>>         Thanx,
>>         Anders
>>         _______________________________________________
>>         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
>>
>>
>>
>>     -- 
>>     Dave Tonge
>>     CTO
>>     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 <http://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.
>>     _______________________________________________
>>     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
> 
>     _______________________________________________
>     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
> 
> 
> 



More information about the Openid-specs-fapi mailing list