Signing API response payloads

[Dave Tonge]

As discussed on the last FAPI call, there is a use case for signing API response payloads. For example of an FI could make a credit decision based on a user's transaction history it obtains from another FI. In such a case it would like to have that transaction history signed rather than storing it as a raw JSON payload.

We discussed on the call that using JWS is the best approach for this use case and should be recommended in the FAPI spec.

I suggest that this is added to Part 1, Section 6.

The questions I have are what would be the standard set of claims for such JWTs, e.g. iat, etc? Should the resource server have the option to serve either plain JSON or JWTs depending on content negotiation?

[Philippe Leothaud]

Hi Dave,

In "Should the resource server have the option to serve either plain JSON or JWTs depending on content negotiation", by "plain JSON" do you mean "unsigned JSON" (application/json content type) or "JWS represented using JSON serialization" (application/jose+json content type) ?

I suspect having a server deciding based on content negotiation if it will sign or not a response is a security problem because of possible downgrade and MITM attacks.

Thanks,

Philippe

[Dave Tonge]

I meant unsigned JSON (application/json). In terms of the security issues, if the client requests a signed response then the client should be verifying the signature and should be able to detect downgrade / MITM attacks?

[Philippe Leothaud]

Yes you're right it changes nothing. Sorry for that... It won't be the same if/when we want to have the transaction history encrypted but that's another story

[Sascha Preibisch]

This reminds me of the OIDC /userinfo response which may also be a JWT. I think it should not be generally required but either by clients requests or as option for the server. I suggest to have default claims included such as iss, iat, exp, tid, aud. A JWT could have a default section such as "{"info":{ default claims}, "payload":{claims of the response}}"

[Nat Sakimura]

Perhaps we can use client registration. For those info re: Sascha, we could utilize the envelope.

[Nat Sakimura]

I understand that OB adopted detached JWS. Hopefully, that is fine with us. We probably should codify it somewhere.

OTOH, Berling group and STET seem to use draft-cavage-http-signatures. Need to follow this up with Phil.

[Dave Tonge]

We discussed, that it would good to provide some guidance from FAPI on this.

[Nat Sakimura]

Add it to a new sub-clause 6.3.

[Dave Tonge]

So I started drafting this, but I think we need to decide how far we will go.

OpenBanking is suggesting the use of https://tools.ietf.org/html/rfc7797 - unencoded payloads. I think this makes sense for FAPI as well.

The key questions I have are:

1. what should the header be - x-fapi-jws-signature or just x-jws-signature
2. should we require unencoded payloads and therefore b64:false in the header
3. should we require iss and iat equivalent claims in the header, openbanking currently has these 2 private header fields: - http://openbanking.org.uk/iat - http://openbanking.org.uk/iss
4. Do we need to say anything about how the client can find what key is used to sign these payloads, e.g. is it recommended that it be different from the key the AS uses to sign id tokens (as it is the RS signing rather than the AS)

[Dave Tonge]

After further discussion, I still like the idea of the resource server just serving JWT payloads instead of JSON (this could be an option, or something the client requests via content negotiation).

As noted previously, this would be similar to the userinfo endpoint in OIDC.

[Ralph Bragg]

I've always been in favour of straight JWTs and this is something that could simply be conveyed with accept header parameter application/json or application/json+jwt

Given that all of the Banks developers have had a chance to use jwt's for a year, I'll float the idea of re-discussing the payload signing mechanism.

It would help if OpenAPI / Tooling improvements could be made relatively quickly to handle JWTs.

[Dave Tonge]

@Nat can we discuss this on the next call?

[Nat Sakimura]

Discuss it in the OAuth SWS to gain a wider audience.

[Dave Tonge]

Resolving this as we've started a new document to address this issue.