Replace OAuth 2.0 with HTTP Message Signatures

[oneiros]

Fixes #24

See that issue for a discussion.

Please note that in this draft, I also chose to sign the HTTP method and the target URI. This would mean that the receiver can verifiy that the action is actually the one the holder of the secret key wanted to make. It does not protect the message body / payload against tampering but it might be an interesting additional layer of security nonetheless.

If we remove this, the result is pretty similar to option 2 from the issue and #26.

[ThisIsMissEm]

I think method + timestamp + request URI is a good option, maybe there's something for like a sha256 hash of the message body that could be included?

[oneiros]

I think method + timestamp + request URI is a good option, maybe there's something for like a sha256 hash of the message body that could be included?

The RFC recommends to add the HTTP Content-Digest header to the set of signed fields for that purpose. While this works it adds yet another layer of indirection and makes constructing those HTTP requests even harder.

The guarantees you can get from HTTP message signatures sure look nice, but I really fear the implementation complexity.

Also, as noted in #24 there do not seem to be many existing libraries for this. But many parties having to roll their own implementations increases the chance of interopability problems and eventually also security issues :confused:

[ThisIsMissEm]

If you're not signing the request body and most of the data is in the body, then the requests could be forged. Using Content-Digest sounds right to me, and as people adopt HTTP Message Signatures, libraries will be written.

[oneiros]

Posted a large-ish update with:

• ed25519 based signing
• Mandatory and signed Content-Digest HTTP header
• a comletely revamped registration process, that I hope is even simpler (no more pasting JWTs)

Please note that the OpenAPI file is now totally outdated.

[ThisIsMissEm]

This is looking really good, I think exchanging information during registration about capabilities may be the next part to add, since it's not clear how these are gathered atm. (unless it's in another document)

You could also have a callback to the FASP when the registration is approved or rejected. The FASP's registration could also include an expiresAt value, such that they can clean up registrations not completed within a given timeframe.