Phil
> On Aug 31, 2018, at 7:45 AM, Benjamin Kaduk <ka...@mit.edu> wrote:
>
>> 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.
If you read the draft it does not sign any request content. It really serves
only to help prevent replay attacks by signing dates.
The OAuth WG HTTP draft was far more complete but likewise suffers from worries
about too many false negatives.
If you want attestation, better to use SET or plain JWT.
>
>> 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.
+1
>
> -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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
