On 8/31/18 12:15 PM, Phil Hunt wrote:
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.
I had the same thought as I was reading through. To get message signing
you have to use the Digest header which has a signature of the message
and then sign that header in addition to the others. At least that is
the way I read it for handing message signing. So basically a two-step
signing/verification method.
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.
+1
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
