Require X-Accept-Authenticate: LN-invoice header

[Kixunil]

I was randomly thinking about payment protocol over HTTP and realized it'd be nicer to require that the client sends X-Accept-Authenticate: LN-invoice header (could be standardized to not require X- in the future) This allows the server to know upfront that the client actually supports LN.

Advantages:

• The server can make conditional response and e.g. send CAPTCHA instead (if it's used as rate-limiting feature) or provide on-chain address for clients who wish to avoid LN and pay bigger amount upfront. (Or use fiat 🤮 )
• The server can avoid generating and storing the invoice if the endpoint was visited by accident. This is NOT meant as a protection against malicious actors attempting to DoS, just a small optimization/helper. Since various (spam, indexing...) bots today do not understand LN, it actually does serve as a spam protection temporarily.

Disadvantages:

• Slightly more complicated implementation
• Privacy implications if browsers unconditionally send the header while being minority. This can be mitigated by the server sending a header like X-Supports-LN: example.com/*, *.example.com/*, the browser could then offer the user to enable LN for that website.

[guggero]

Interesting proposal, I think this makes a lot of sense.

Would you suggest this to be a header that MUST be implemented (using the RFC meaning of must here) by a software that wants to be LSAT compliant or more of an extension that CAN be used? Meaning, on the server side, can you be certain the client doesn't support LSAT if the header isn't present or could the header just not be implemented there?

[Kixunil]

Good question.

If a server sends invoice regardless it probably only hurts itself or UX. (Although I believe sending both the invoice and some fallback page works?)
If a client never sends the header, then servers expecting it will not send back the invoice. I think the client MUST support sending the header. If it's turned on only for certain domains in the browser, that still counts as support.

If the header is not present it should mean "doesn't support or doesn't wish to use it".

[kiwiidb]

We've been working on a middleware library for LSAT's Gin: https://github.com/getAlby/gin-lsat, and we are also wondering if a client should initiate the LSAT flow by sending a certain Accept header: https://github.com/getAlby/gin-lsat/blob/main/ginlsat/ginlsat.go#L89.

Another advantage for the client would be that in the case that the files are large (eg. video), this would prevent unneeded downloading of the free content if you are actually after the paid content.

[guggero]

I've discussed this with @bumi before and I think the conclusion was that the Accept header field doesn't really fit, since the payment is a meta information and not actual content (and the MIME type application/vnd.lsat.v1.full would imply that there is an actual content type for LSAT).
I think a custom (X-...) field would make more sense. But the question of how to name it, what to put into the field and whether to make it required or not (privacy aspects as mentioned above) is still open for discussion.

[Kixunil]

@guggero that's exactly why I wrote X-Accept-Authenticate instead of Accept. IIRC there's currently no standard for clients to signal authentication methods to servers and there is some other header starting with Accept- so that's why I selected X-Accept-Austhenticate, might be nice to get it standardized but IDK how hard it'd be.

[bumi]

Accept-Authenticate sounds good to me, it's open and general. ( - isn't the X- deprecated anyway? (rfc6648)?)

What would be the proposed value of the Accept-Authenticate header to for lsat?

[Kixunil]

Interesting, didn't know about 6648.

I proposed LN-invoice but I don't really care as long s it's reasonably clear and doesn't conflict with anything else.

[bumi]

wondering if LN-invoice is specific enough to indicate that lsat should be used. - potentially there could be another authorization flow that uses lightning invoices.

[kiwiidb]

So to recap: the header's name would be Accept-Authenticate and the value could simply be LSAT?
In that case we could add this to the spec, so it is clear what clients wishing to use the LSAT flow should send over.

[bumi]

How/Where should we add this in the spec description?

[guggero]

I'd add a new section to https://github.com/lightninglabs/LSAT/blob/master/protocol-specification.md, maybe call it "Client support signaling" or something like that.

[Roasbeef]

Relevant to this document perhaps issue perhaps: lightning/blips#26