Decision on message signing for FAPI 2 Advanced

[Daniel Fett]

The attacker model for FAPI 2 necessitates message signing for messages from and to the RS. We need to make a reasonable recommendation here.

An option could be to just prescribe some signing mechanism, but leave the details open to the implementer. This would partially undermine the goal of creating an on-the-wire interoperable standard, however.

[Dave Tonge]

I suggest that we go for detached JWS.

@Ralph Bragg isn't that what jades JAdES thing is anyway?

[Anders Rundgren]

There is a bunch of proposals were ETSI’s seems overly complex. The simplest to date is the combination of RFC 7515 (JWS) and RFC 8785 (JCS) which also happens to be useful as a standalone signature scheme (signed JSON objects). You may test it on-line in case of doubts: https://mobilepki.org/jws-jcs

{
  "amount": "345.00",
  "currency": "EUR",
  "creditor": {
    "name": "Acme corp.",
    "account": "DE89370400440532013000"
  },
  "debtor": {
    "name": "Jacques LEGRAND",
     "account": "FR7630004003200001019471656"
  },
  "signature": "eyJhbGciOiJFUzI1NiIsImp3ayI6eyJrdHkiOiJFQyIsImNydiI6IlAtMjU2IiwieCI6IjZCS3hwdHk4Y0ktZXhEekNraC1nb1U2ZFhxM01iY1kwY2QxTGFBeGlOclUiLCJ5IjoibUNiY3ZVem00NGozTHQyYjVCUHlRbG9ROTF0ZjJEMlYtZ3plVXhXYVVkZyJ9fQ..dQbVCxRSuATbYAyn1vvwFACwqqyk5s6FB5vPEqZhfBVoL2WaCNOjo3bhLSEKFPaPX3YMeOyDGVoU0VHm3EY05Q"
}

Although RFC 8785 is brand new it has been adopted by Microsoft for a distributed PKI project.

[Francis Pouatcha]

What about the evolving https://www.ietf.org/id/draft-ietf-httpbis-message-signatures-00.txt. The preceding version is being used by the current NextGenPSD2 initiative.

[Anders Rundgren]

A generic issue is that all proposals (except those built on top of RFC 8785), will result in signature scheme fragmentation, at least if something like Embedded SCA with client-generated signatures eventually becomes a reality. In the latter case there are no HTTP headers to cling to which effectively makes it necessary encoding the whole caboodle in Base64Url.

[Dave Tonge]

As discussed on the call, @Francis Pouatcha has suggested that FAPI work on a legislation neutral version of the OBE/etsi signing profile.

[Dave Tonge]

@Brian Campbell and I have worked on a draft based on DPoP which may be suitable for this: https://bitbucket.org/openid/fapi/pull-requests/209/add-initial-draft-of-simple-http-message

It would be great to get some feedback on this draft

[Anders Rundgren]

@Dave Tonge It is fine but will unlikely be the “universal” solution, ETSI are on to their thing and JCS is alive and kicking as well:

https://lists.w3.org/Archives/Public/public-credentials/2020Nov/0129.html

[Francis Pouatcha]

Just read through the draft, looks good for me, but i still do not believe this is the right way:

• Non repudiation has more legal than technical implications.
• Details specific to some jurisdictions will require the inclusion of jurisdiction specific http headers in the signature.
• Moving away of ETSI/OBE suggestion reduces chances for global interoperability
• DPoP ist too tight to the oAuth2. Http-Signing shall be independent of the authorization scheme, event if it could also be used to cover some attack vectors.

I still do believe it makes sense to build on top of the work performed by ETSI/OBE we did here: https://bitbucket.org/openid/fapi/issues/297/open-banking-europe-jws-profile-for#comment-59040544

‌

I will try to contact the ETSI/OBE world and see if they can contribute in a common draft we FAPI.

[Francis Pouatcha]

ETSI/OBE still looks like a good template:

• We could define a mechanism for FAPI requests, as we know they are all JSON messages, JCS will fit well in here.
• Payment requests from RP to RS will need some domain (legislation) constrained extensions.

I will suggest we work on a substantial and simple suggestion for integrity and non repudiation.

[Anders Rundgren]

@Francis Pouatcha It is possible that I have misinterpreted the draft but it seems that it only uses the DPoP syntax. The main difference (ignoring syntax) to the ETSI/OBE proposal is that it doesn’t support signing of arbitrary HTTP headers, at least not out-of-the-box. OTOH, this feels like edge cases. Maybe FAPI have no reason to go after such?

Then we have https://tools.ietf.org/html/draft-ietf-httpbis-message-signatures-01

I think my claim that there will not be a single standard remains valid. It is a pity but it will probably have a limited impact on open banking. What’s clearly missing here is something entirely different: a way to discover what APIs and methods a specific bank actually supports. Hoping for a unified API is simply put not realistic.

[Francis Pouatcha]

As non repudiation is strong related to (law and legislation) in target markets, it is important to define a meta standard standard that opens room for:

• Market specific definition of the key management and legitimation scheme
• Market specific definition of headers (mandatory, optional, …)
• API specific definition of canonicalization of the request/response (header, body, …).

https://tools.ietf.org/html/draft-ietf-httpbis-message-signatures-01 is on a good way, but still have a lot of issues to deal with. Exactly I is mentioned above (See appendix B).
OBE/ETSI seems more mature and our extension can open room for market specific headers.

@Anders Rundgren lets synch on how to extend OBE draft for this purpose.

[Anders Rundgren]

Thanx @Francis Pouatcha . However, unlike most of the other people involved in these issues I have no sponsor and must therefore carefully select what I spend my precious cycles on. JCS (RFC 8785) was rejected by the IETF as “Standards Track” item but has nevertheless gotten traction in quite different contexts so I think continuing along this path with JWS/CT as “the next stop” seems like the best alternative.

None of the other proposed signature solutions for Open Banking support serialization, embedding, and counter-signing. In addition, they only work in an HTTP context so JWS/CT which is universal, will presumable get some friends as well.

I’m also [sort of] working with a multi-billion EURO project known as the European Payments Initiative (EPI):
https://cyberphone.github.io/doc/saturn/epi(presumed)-vs-saturn.pdf
If any of this happens, I’m booked for years. This system takes the signature question yet another step by leaving the JOSE stack except for Algorithms and JWK.

BTW, I don’t see a need for signing custom HTTP headers.

Anders

‌

‌

‌

[Dave Tonge]

@Francis Pouatcha thanks for going through the draft. As Anders mentioned this can be used on top of DPoP so that proof of possession and message signing are combined. Or it can be used purely for message singing. It is therefore completely independent of OAuth and could theoretically be used for any HTTP exchange.

HTTP Headers - I agree with Anders, I don’t think they need to be signed.

Key Management - In the draft we detail 4 different ways in which keys can be looked up. I don’t see what the actual issue is here? You are proposing an additional parameter to the OBE spec (sigF) which could be added here if really required. However I’m not sure if it is. If I go to a court with a DPoP proof (with self-contained key) and a matching certificate then what is the issue?

API Specific canonicalization - I think if this happens then its not really a standard. The optionality needs to be reduced to increase interoperability.

‌

OBE/ETSI seems more mature

I disagree with this. It seems like a mix of different standards - just because many people came together to create it, doesn’t mean its more mature.

I highly doubt that OBE/ETSI will ever get global adoption, I strongly doubt it will get cross-European adoption.

‌

‌

‌

‌

[Anders Rundgren]

@Dave Tonge FWIW, I support your and Brain’s spec. A bit reluctantly but waiting for the world to settle on something that may never happen seems like the worst solution of all I’m (also) a fan of simplicity.

If you had these TPP and ASPSP discovery services I keep blabbering about, one could even migrate to “better” (whatever that is…) solutions, including quantum safe algorithms, but in a controlled manner. This is sort of the opposite to the ISO 20020 approach which builds on very complex messages with huge sets of options that (literally) takes years to get interoperable.

[Francis Pouatcha]

@Anders Rundgren i am not suggesting the signing of custom http headers. I am suggesting two steps approach:

• A base specification template
• Market adoption like EU-PSD2 that allow extensions.

Unless we want to redefine non repudiation.

[Francis Pouatcha]

HTTP Headers - I agree with Anders, I don’t think they need to be signed.

This decision shall be left to legislation specific working groups like ETSI for PSD2

This is why you need sigD.

Key Management - In the draft we detail 4 different ways in which keys can be looked up. I don’t see what the actual issue is here? You are proposing an additional parameter to the OBE spec (sigF) which could be added here if really required. However I’m not sure if it is. If I go to a court with a DPoP proof (with self-contained key) and a matching certificate then what is the issue?

Same applies here:

• eIDAS shall decide on how to legitimate a key in the PSD2 context.
• ACCC provide certificates for Australia for both banks and tpps.

This is why you need sigF.

‌

API Specific canonicalization

I think if this happens then its not really a standard. The optionality needs to be reduced to increase interoperability

‌Yes. Might nevertheless be part of mechanism spec in sigD if found necessary.

OBE/ETSI seems more mature

I disagree with this. It seems like a mix of different standards - just because many people came together to create it, doesn’t mean its more mature.

ETSI/OBE ist not clean jetzt. I just like the fact it is simply based on JWS + sigD + sigF (I am suggesting we add to it)

I highly doubt that OBE/ETSI will ever get global adoption, I strongly doubt it will get cross-European adoption.

I am also not sure. We will find out after ETSI releases JAdES (Actually being done behind close doors)

[Anders Rundgren]

@Francis Pouatcha @Dave Tonge as far as I can tell the data associated with a request or response can be signed with a key which in turn is related to a certificate path (“x5c”). It is hard to see that this would not meet regulatory requirements.

Now imagine that the payload is an XML or PNG object and you still need one or more additional signed objects to form the actual data. By putting these (presumably rather short) objects inside of the JWS/JWT payload you get rid of difficult HTTP header handling. Another solution is putting a CBOR structure in the HTTP body which permits very dense packaging of composite, arbitrary, and potentially voluminous data.

My conclusion is (if I got this right NB…) is that this scheme imposes no hard limits [*] and thus would fill the bill for the majority of the imaginable use cases for HTTP signing. Perfection is simply put not achievable without revising core standards like HTTP and JSON.

---

*] There will surely be a few “dissidents” like me who insist on JSON-level serializability but they should not destroy the fun those who doesn’t need it

[Ralph Bragg]

I don’t think we can just universally say we can ignore headers unless we want to remove all reference to any headers in the spec that could potentially need to be relied to inform decision making and insist that this information move to the body of the request.

FAPI 1 Advanced inherits all of the obligations in FAPI 1 Baseline unless overridden. In FAPI 1 Baseline 6.2.1 Protected resources provisions we make a bit of a song and dance about certain headers being present. In some ecosystems implementations rightly or wrongly they do form core part of the specification. If we can’t protect them i think we’re missing a trick. We’re pretty hot on ensuring that all other information can be signed and protected why not headers?

Alternatively we retire any use of headers to convey any information that could be used in a decision making process and insist on all of the information being in the body so that our recommended signing solution can protect everything that is needed in the message.

[Dave Tonge]

Headers

So with regards to headers, I’m in favour of removing them in FAPI 2.0. (apart from interaction id)

I think there is a problem with a protocol if the change of a value of a custom header, has a vastly different outcome for an API call.

If an ecosystem really needed to use headers, and really needed those headers to be signed - then its fairly easy to extend the spec to add support for that. But I can’t see a convincing reason to have it in the base spec.

Key Verification / Trust Model

This can never be fully expressed in an API. By its nature, the trust model requires touch points with external trust anchors. As Anders points out, this spec allows a number of different ways for certificates to be referenced. An ecosystem wanting to use this spec that has a requirement that only certificates from a certain CA are accepted simply needs to have that as a policy.

‌

‌

‌

‌

[Dave Tonge]

legacy issue