HTTP Signing
We should consider whether the updated http signing draft (https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html) is worth referencing or whether we should continue work on SHMIP.
Comments (22)
-
-
Though I’m a supporter of the work on https://bitbucket.org/openid/fapi/src/master/Financial_API_Simple_HTTP_Message_Integrity_Protocol.md, I agree that we should explore whether https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-04.html can be leveraged.
-
If there’s a decent message standard emerging that solves this then lets use it.
-
reporter we discussed on the call today - and there was no pushback on referencing this spec.
We need to decide for FAPI 2 whether we will support a variety of signing mechanisms - or just a single one.
I mentioned that I think the fact that SHMIP supports binding the request and the response together is a potentially useful feature that it would be good to get more feedback on.
-
Dictating the signing mechanisms for payloads may be a step too far, at least if the clause was a SHALL. If the WG wants to pick one and make them a SHOULD with appropriate warnings on the conformance suite then that would be OK. different jurisdictions will have different requirements as too what signing processes are used which we need to be mindful of.
-
I wanted to let this group know that I’ve proposed a mechanism to bind the request and response together using HTTP Message Signatures: https://github.com/httpwg/http-extensions/pull/1566
-
reporter We discussed this on the call last week - there is definitely a desire to have the advanced profile of FAPI 2. So we need to move this forward.
We weren’t sure about how much adoption / progress there would be on HTTP Message Signatures.
There was discussion about also looking at whether sender constraining and http signatures could be combined - or at least the key management could be combined
-
reporter We had another discussion:
- Some in favour of multiple options, i.e. if using DPoP then maybe use SHMIP
- Others in favour of reducing optionalityDPoP / SHMIP have some issues:
- no support for signing headers
- no support for signing of the query stringAn advantage of the HTTP Message Signatures draft is that it provides a migration path for people using draft-cavage (e.g. Berlin Group)
There was no one on the call in support of detached JWTs (as used in the UK OpenBanking ecosystem)
We also discussed the importance of getting the language right.
-
reporter We discussed on the call adding a few options to the fapi 2 advanced doc, and then gaining implementation feedback prior to moving to a final version that may have a reduced set of options (or a single option)
-
Discussed on today’s call - we talked about implementers draft 1 adopting only https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures (noting that this is not final, and depends on other non-final things).
Brian noted that the above is a toolkit, and to achieve non-repudiation we’d need to profile the spec and specify exactly what should/shouldn’t be signed etc. I wondered if we can base that on how people are using the cavage draft today.
-
Questions
- Any progress on ETSI side?
- IETF side seems to depend on the new digest header specs
-
To clarify: The signatures spec does not depend on the digest header spec, however many use cases will want to use them together. They’ll reference each other informatively, especially in the security considerations and applications section. Brian is absolutely correct that FAPI would need to build a profile of the signing spec (and possibly digest spec as well) in order for interoperability. Some guidance for that is in this section: https://www.ietf.org/archive/id/draft-ietf-httpbis-message-signatures-08.html#name-application-of-http-message
I don’t know of any dependencies from ETSI here.
-
reporter -
assigned issue to
-
assigned issue to
-
reporter -
reporter Thanks Justin - I’ve added an initial go at adding to our advanced spec using some of the wording from GNAP
-
reporter We should probably include the Authorization header
We also need to think about overlap with DPoP and whether this needs to be called out
-
At the IETF hackathon two days ago, Justin/Aaron covered HTTP Signing (at least as used within GNAP); the summary is here:
The most relevant bits are likely these bits, I assume to some extent these will also apply to the usage of HTTPSig in FAPI, but I am far from an expert:
What did we learn?
-
HTTP Message Signatures is complex to do from scratch
- Requires crypto, structured fields, HTTP message manipulation, etc.
- Surprising fiddly bits (e.g., order of parameter fields)
- Transparent if available within an HTTP library, but we aren’t there yet
Improving the Specs
● HTTP Structured Values
- Would benefit from an implementer’s quickstart guide
● HTTP Message Signatures
- Parameter order needs to be stable
- Some library support, but more is needed (ours was all by hand)
-
-
@Joseph Heenan The most relevant bit, which we covered better in the vocal presentation, was “from scratch”. We were both working on platforms that don’t have any general-purpose HTTP Signing libraries available, and that was part of our goal of the hackathon.
What we both found was that as soon as we’d implemented a method to sign an HTTP message on request, we could just use that method for the entire rest of the protocol development. So it’s the kind of thing that you build and debug once for your platform/library, and then it’s simple to apply.
HTTP Signatures definitely benefits from that kind of general purpose library on whatever platform you’re on, and obviously the more of those that get built the better off the ecosystem is.
-
reporter For widespread interoperable adoption I think it definitely needs library support, ideally in HTTP client libraries. My minimal version of draft-cavage in node.js was relatively easy: https://github.com/davidgtonge/http-signing/blob/main/src/draft-cavage.js
I’ll have a go at re-implementing it with the current http-sig draft.
-
That would be great to see. My own limited JS implementation from the hackathon starts here: https://github.com/bspk/oauth.xyz-java/blob/master/rc/src/main/js/spa.js#L271
Note that I used a Structured Fields library which has a REALLY weird API and I’m not happy with it, I’d like to pull that out for something better when I can. I opted to use that instead of just coding the structured field portions by hand, which is honestly easy enough to do but that wasn’t part of the Hackathon’s exercise goals.
-
reporter - changed status to resolved
I'm resolving this issue for the moment - we have merged this PR https://bitbucket.org/openid/fapi/pull-requests/317 in which added references to the HTTP Signatures draft to FAPI 2 Advanced.
The aim is to get FAPI 2 Advanced out as an implementers draft and get feedback.
-
- changed component to FAPI2: Message Signing
- Log in to comment
I think it would probably need a reference as well as a little profiling of what content is required to be covered by the signature. Also maybe some direction about keys and algs. But it is definitely worth considering picking up the work coming out of the IETF and maybe abandoning the SHMIP stuff.