Use more extensible JSON signature as the Basic Authentication header token

[gavfu]

Hi, this is a really nice functional extension to IPFS gateway. Yet, it would be great if we could make it easily extensible to support more blockchain signatures like ethereum, solana, etc.

So, here is one proposal: instead of using Basic Authentication header token in format of

Authorization: Basic <base64(PubKey:SignedMsg)>

How about using base64 JSON signature like:

Authorization: Basic <base64({"chain":xx, "address":xx, "msg":xx, "sig":xx, "timestamp":xx})>

For example, "chain" value "ethereum / polkadot / crust" indicates an ethereum / polkadot / crust signature respectively.

[gavfu]

A bit more explanation why "timestamp" is needed. This is try to fix the REPLAY security issue.

Since any party could follow our guideline to host an IPFS W3Auth Gateway and contribute to Polkadot or Crust Apps. A malicious IPFS W3Auth Gateway operator could eavesdrop user's Basic Authentication header token, and use that to REPLAY user's IPFS requests, forever.

Including a "timestamp" gives the header token a TTL (Time-To-Live), like 5 minutes. The IPFS W3Auth Gateway could simply fail an expired signature tokens. This is an imperfect but lightweight solution that makes our gateway much more securer. We could give it a thought.

[badkk]

We're like changing to format CHAIN.PUBKEY:SIG compatible with most of http basic auth call.

[brenzi]

I didn't see much activity here. Replay is a serious concern by @gavfu and timestamps as part of the signature payload could mitigate it. Will it be addressed? @badkk suggestion does not solve that. Are there plans for more advanced challenge-response schemes?

[badkk]

Yes, reply attack is a serious problem in this situation. But finally we think TTL is not the best idea to solve it, and the whole coversation is paused here(a little bit long tho😂) Any more thoughts on this? @mmyyrroonn