1. OpenID Foundation Avatar OpenID Foundation
  2. WGs
  3. fapi
  4. Issues

HTTP Signing

Issue #411 resolved
Dave Tonge created an issue

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)

  1. Brian Campbell

    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.

  4. Dave Tonge 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.

  5. Ralph Bragg

    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.

  7. Dave Tonge 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

  8. Dave Tonge 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 optionality

    DPoP / SHMIP have some issues:
    - no support for signing headers
    - no support for signing of the query string

    An 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.

  9. Dave Tonge 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)

  10. Joseph Heenan

    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.

  11. Nat Sakimura

    Questions

    • Any progress on ETSI side?
    • IETF side seems to depend on the new digest header specs

    ‌

  12. Justin Richer

    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.

  15. Dave Tonge reporter

    Thanks Justin - I’ve added an initial go at adding to our advanced spec using some of the wording from GNAP

  16. Dave Tonge 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

  17. Joseph Heenan

    At the IETF hackathon two days ago, Justin/Aaron covered HTTP Signing (at least as used within GNAP); the summary is here:

    https://github.com/IETF-Hackathon/ietf113-project-presentations/blob/main/GNAP IETF 113 Hackathon.pdf

    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)

    ‌

    ‌

    ‌

  18. Justin Richer

    @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.

  20. Justin Richer

    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.

  23. Log in to comment
Assignee
Type
proposal
Priority
major
Status
resolved
Component
FAPI2: Message Signing
Milestone
–
Votes
0
Watchers
6
Jira: the preferred issue tracker for Bitbucket. Join the team!