In the current LUD-04 spec, it is mandatory that the k1 value is presented up-front.
There are two main problems with this approach that I have run into repeatedly:
There may be more information that the server wishes to collect from the device (such as a session id) before generating a k1 value.
The server may want a default auth endpoint that any device can use to initiate an authorization flow (such as a static qr code for login).
I think that the LUD-04 flow can be upgraded to be more like LUD-06, without breaking backwards-compatibility.
Example of the new LUD-04:
If k1 value is presented, everything flows as normal (similar to LUD-06 when an amount value is presented).
If the k1 value is omitted, then the server and wallet negotiate the terms of the signing (again similar to LUD-06, but with k1 value) with a callback.
With this simple change, I can present users with a static QR code for authentication, and better negotiate the k1 value for them to sign.
This change would also allow the auth spec to be upgraded more easily in the future, as the negotiation step could include different signature types, derivation paths, etc.
I am submitting this change as an issue to garner support. I would also like to create a PR for LUD-04 which would include the new change, plus update the current formatting of LUD-04 so that it is easier to read.
I would find this change incredibly useful, plus it would make lnurl auth more robust. Please let me know what you think. Thank you.
In the current LUD-04 spec, it is mandatory that the k1 value is presented up-front.
There are two main problems with this approach that I have run into repeatedly:
I think that the LUD-04 flow can be upgraded to be more like LUD-06, without breaking backwards-compatibility.
Example of the new LUD-04:
With this simple change, I can present users with a static QR code for authentication, and better negotiate the k1 value for them to sign.
This change would also allow the auth spec to be upgraded more easily in the future, as the negotiation step could include different signature types, derivation paths, etc.
I am submitting this change as an issue to garner support. I would also like to create a PR for LUD-04 which would include the new change, plus update the current formatting of LUD-04 so that it is easier to read.
I would find this change incredibly useful, plus it would make lnurl auth more robust. Please let me know what you think. Thank you.