Investigate if authentication via HTTP Message Signatures / keypairs is possible

[ThisIsMissEm]

Theoretically we could use HTTP Message Signatures for authenticating API calls to a FIRES server, though I'm not sure exactly how this would work, since we also need authorization controls.

I think it'd be a matter of either the FIRES server storing the public key and Key ID, and associating the permissions with that key ID, but then the question becomes "how do you trust that keypair"? You'd have to have some sort of bootstrapping process.

But moving in this direction in the future could be interesting, as it'd pave the road towards maybe integrating via the FASP system.

cc @dahlia @julianlam in case either of you have thoughts on this.

[julianlam]

Considering that the signed messages are already there, implemented, and working, it's seems to be a no brainer to take advantage of it.

[ThisIsMissEm]

@julianlam Yeah, but you don't have a "user account" on a FIRES server, so for write/admin access, we'd need some way to say "this Key ID can do those things" — much like we do with access tokens in #41

FIRES is pull-based, so we're not signing outgoing messages at all, just receiving http requests. As far as I know HTTP Message Signatures mandate having a URI for the public key to verify the requester.

Maybe I could have the FIRES server generate and store keypairs, where we only store the public key, but it's still a lot of complexity.

[julianlam]

If it's an activity you need, have FIRES display an OTP and have the user send it to FIRES via DM snerk

In all seriousness it sounds like you're looking for a way to use HTTP Signatures instead of rolling your own token scheme. It makes sense.

What would an S2S implementation send to FIRES? A bespoke Activity type might be in order.