On Fri, Aug 31, 2018 at 06:56:34AM +0200, Dave Tonge wrote: [snip] > In Europe we have a number of standards groups who are defining these APIs > on behalf of banks. Unfortunately they are all taking different approaches > to this problem - including the use of a draft that I understand isn't on a > standards track. > > Berlin Group (https://www.berlin-group.org/nextgenpsd2-downloads) requires > the use of the individual "Signing HTTP Messages" draft - > https://datatracker.ietf.org/doc/draft-cavage-http-signatures/ > > STET (https://www.stet.eu/en/psd2/) also requires the use of the same > "Signing HTTP Messages" draft. > > OpenBanking UK specifies the use of RFC7515 (JWS) & RFC7797 (JWS Unencoded > Payload Option) - specifically with the detached payload option. However > they require a custom header: `x-jws-signature` and custom private header > parameter names that replicate `iat` and `iss` keys that are normally in > the JWT body. ( > https://openbanking.atlassian.net/wiki/spaces/DZ/pages/5785171/Account+and+Transaction+API+Specification+-+v1.1.0#AccountandTransactionAPISpecification-v1.1.0-Non-repudiation > ) > > I have a number of questions that it would be great to hear your views on: > > 1. Does anyone have further information about > the draft-cavage-http-signatures spec - I am concerned about an individual > draft being used for these high value APIs?
I don't, but I'll try to ask around. > 2. Are there any views on a better way to solve this problem, for example: > https://tools.ietf.org/html/draft-erdtman-jose-cleartext-jws-00 This one has been proposed in a couple of WGs and there was a late attempt at a (related) BoF proposal for IETF 101; it doesn't seem to have garnered much interest, due to historical work in the JSON canonicalization area. -Ben > The reason I've heard against just returning a JWT is that it means that > APIs are essentially just serving blobs of encoded data which could make > them harder to develop against or debug. > > I don't like the idea of a detached signature in the header as it makes the > process of storing the data for later non-repudiation purposes harder and > more error prone (when compared to a message with a self-contained > signature). > > While in some ways tangential to OAuth, I believe that this working group > is well placed to solve this problem. I am concerned that as things stand > we will end up without any interoperability for this problem due to the > lack of appropriate standards. > > Thanks > > Dave > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
