NUT-XX: Authentication by starbackr-dev · Pull Request #106 · cashubtc/nuts

starbackr-dev · 2024-03-26T01:16:17Z

Currently, access to mint endpoints are open to anyone. Since Cashu tokens are IOUs, the mint should have an optional way of restricting access to some end points if needed. We propose a new feature to provide optional access control for specific endpoints. This will address the need to restrict sensitive operations like minting and melting to authorized parties. This NUT is completely optional and may not be supported by mints and wallets.

We have developed a (NUT) specification for implementing authentication through bearer tokens. This approach is easy to integrate into wallet provdiders, allowing mints to control access to their endpoints.

Selective Endpoint Authentication

Mints have the flexibility to authenticate certain endpoints selectively. For example, they could restrict minting while allowing unrestricted swapping and melting.

Ofcourse, this will compromise privacy. Both the mint and wallet should be explicit in informing the users about this.

Example Scenario

Consider a mint such as the one I am currently running (https://stablenut.umint.cash) connected to Strike, a platform enforcing KYC for users transacting with its API. By enabling authentication, the mint can limit minting and melting only to KYC-compliant users. Meanwhile, tokens minted through this restricted channel can continue to be swapped between users freely without restrictions. (Calle can still post them on Nostr/twitter)

Each mint will clearly indicate its access policy on their /info endpoint, empowering wallet providers with the necessary information to guide their users' decisions.

Registration Process is out of scope for this NUT - The registration process for authorized public keys is scoped out of this NUT. Mints can implement their own authentication mechanisms and include authed pubkeys table inside mint database

We invite your review and comments on this proposal.

This NUT describes a mechanism for obtaining time-bounded OAuth bearer tokens for accessing protected endpoints for a mint. The registration process for authorizing public keys is outside the scope of this NUT.

Updated and removed based on Calle's initial feedback.

@trbouma

Thanks for the great feedback and discussion during last month's Dev call! I've made some updates based on the suggestions provided. Regarding point 1, I've taken out the references to Mint and Melt and instead implemented authentication for any endpoint. This will make it more flexible and allow for easier integration with other platforms. Point 2 was a game-changer! @trbouma's suggestion to look at LUD-04 LNURL Auth was super helpful, and I was able to incorporate some of the implementation logic to simplify and enhance the privacy of our solution. Specifically, I've implemented the linking key concept from LNURL-Auth to create private/pub keys based on the auth URL. This means that each user will have a unique key for each mint, preventing any tied keys to multiple mints. The wallet can still calculate the keys easily from the seed, but the user will have full control over their keys. Finally, I've introduced an "action" enum to determine the type of action the user is authorized to perform. This will help us keep track of the user's permissions and ensure they only have access to the appropriate actions. There were some other minor cleanups and code optimization, but these are the main updates. I'm excited about the progress and looking forward to the nextDev call to get more feedback and continue improving the protocol 🚀

starbackr-dev · 2024-03-31T20:13:12Z

Thanks for the great feedback and discussion during last month's Dev call! I've made some updates based on the suggestions provided.

1, I've taken out the references to Mint and Melt and instead implemented authentication for any endpoint. This will make it more flexible and allow for easier integration.

2 @trbouma's suggestion to look at LUD-04 LNURL Auth was super helpful, and I was able to incorporate some of the implementation logic to simplify and enhance the privacy. Specifically, I've implemented the linking key concept from LNURL-Auth to create private/pub keys based on the mint URL. This means that each user will have a unique key for each mint, preventing any tied keys to multiple mints. The wallet can still calculate the keys easily from the seed.

Finally, I've introduced an "action" enum to determine the type of action the user is authorized to perform. This will help us keep track of the user's permissions and ensure they only have access to the appropriate actions.

There were some other minor cleanups and code optimization, but these are the main updates. I'm excited about the progress and looking forward to the to get more feedback 🚀

thesimplekid · 2024-03-31T20:25:46Z

+  action:"mint", 
+  k1:"8278e1a48e61c261916791dabb6af760488e4f01932e11fe7054f59754e3de6e"
+  signature:c568f78e4b234a5f7d8c3b2a679e48d1234567890abcdef
+  linkingKey:7345786068584cd33000582ba87a9ddf77db5377c67910ab59d7e9a5f44


Suggested change

action:"mint",

k1:"8278e1a48e61c261916791dabb6af760488e4f01932e11fe7054f59754e3de6e"

signature:c568f78e4b234a5f7d8c3b2a679e48d1234567890abcdef

linkingKey:7345786068584cd33000582ba87a9ddf77db5377c67910ab59d7e9a5f44

"action":"mint",

"k1":"8278e1a48e61c261916791dabb6af760488e4f01932e11fe7054f59754e3de6e"

"signature": "c568f78e4b234a5f7d8c3b2a679e48d1234567890abcdef"

"linking_key": "7345786068584cd33000582ba87a9ddf77db5377c67910ab59d7e9a5f44"

thesimplekid · 2024-03-31T20:26:41Z

+```json
+{
+    "nuts": {
+    "15": {


Suggested change

"15": {

"16": {

thesimplekid · 2024-03-31T20:27:15Z

+  signature:c568f78e4b234a5f7d8c3b2a679e48d1234567890abcdef
+  linkingKey:7345786068584cd33000582ba87a9ddf77db5377c67910ab59d7e9a5f44
+}
+


Missing a ``` here to end the code block

thesimplekid · 2024-03-31T20:29:07Z

+
+}
+
+```


Suggested change

```

thesimplekid · 2024-03-31T20:29:49Z

 | [12][12] | DLEQ proofs | [Nutshell][py] | [Nutshell][py] |
 | [13][13] | Deterministic secrets | [Nutshell][py], [Moksha][cashume], [cashu-ts][ts] | - |
-
+| [15][16] |Authentication with Schnorr Signatures |


thesimplekid · 2024-03-31T20:30:15Z

 [11]: 11.md
 [12]: 12.md
 [13]: 13.md
+[15]: 15.md


Suggested change

[15]: 15.md

[16]: 16.md

thesimplekid · 2024-03-31T20:38:04Z

+{
+  "access_token": "9876543210fedcba",
+  "token_type": "Bearer",
+  "expires_in": 3600


Suggested change

"expires_in": 3600

"expiry": 1711917473

I think this should be the unix time the token expires at more in line with mint/melt quote expiry feilds

thesimplekid · 2024-03-31T20:44:36Z

+```http
+GET https://bob.com/v1/auth/challenge?&tag=<(action enums)>
+```
+Bob's mint generates a challenge `k1` consisting of randomly generated 32 bytes, for example:


Suggested change

Bob's mint generates a challenge `k1` consisting of randomly generated 32 bytes, for example:

Bob's mint generates a challenge `k1` consisting of a 64 character hex string generated from 32 random bytes, for example:

davidcaseria · 2024-04-24T20:05:34Z

+
+ - `linkingKey` This is a public key derived from `linkingPrivKey`
+ - `linkingPrivKey` To keep the derived public key unique to each mint, the `linkingPrivKey` should be derived as follows
+ -  Use the derivation path m/138'/0 from the master key to get `hashingkey`


Is it necessary to specify the exact derivation path used by the client?

davidcaseria · 2024-05-13T18:54:51Z

Is the access token intended to be stateful? Ideally, the mint server would not keep a complete list of active tokens in its database. An alternative could be to specify the claims in a JWT.

Additionally, has something like an HMAC signing been considered instead of an access token? The HMAC secret can be an ECDH exchange with the user’s linking key and the mint’s key, published in the info endpoint. The user’s public key and a timestamp would be required as request headers for the server to validate the request and prevent replay attacks.

starbackr-dev and others added 7 commits March 23, 2024 10:48

Added NUT-15

08b3d37

This NUT describes a mechanism for obtaining time-bounded OAuth bearer tokens for accessing protected endpoints for a mint. The registration process for authorizing public keys is outside the scope of this NUT.

minor update

3a380ca

removed identity word

1a52fdb

Update 15.md

0be36bc

Updated and removed based on Calle's initial feedback.

updated to NUT-16

0fa3be1

added registration tag to the /info endpoint

79e483b

starbackr-dev changed the title ~~NUT-16: Authentication with Schnorr Signatures~~ NUT-16: Authentication Mar 31, 2024

thesimplekid reviewed Mar 31, 2024

View reviewed changes

thesimplekid mentioned this pull request Apr 5, 2024

Implement NUTXX: Authentication cashubtc/cdk#69

Closed

davidcaseria reviewed Apr 24, 2024

View reviewed changes

callebtc added needs implementation Needs a reference implementation new nut A new protocol NUT needs discussion Needs more discussion labels May 11, 2024

callebtc changed the title ~~NUT-16: Authentication~~ NUT-XX: Authentication May 17, 2024

callebtc closed this Dec 3, 2024

Navigation Menu

Uh oh!

NUT-XX: Authentication - #106

NUT-XX: Authentication#106
starbackr-dev wants to merge 7 commits into
cashubtc:mainfrom
starbackr-dev:main

starbackr-dev commented Mar 26, 2024

Uh oh!

starbackr-dev commented Mar 31, 2024 •

edited

Loading

Uh oh!

thesimplekid Mar 31, 2024

Uh oh!

thesimplekid Mar 31, 2024

Uh oh!

thesimplekid Mar 31, 2024 •

edited

Loading

Uh oh!

thesimplekid Mar 31, 2024

Uh oh!

thesimplekid Mar 31, 2024 •

edited

Loading

Uh oh!

thesimplekid Mar 31, 2024

Uh oh!

thesimplekid Mar 31, 2024

Uh oh!

thesimplekid Mar 31, 2024

Uh oh!

davidcaseria Apr 24, 2024

Uh oh!

davidcaseria commented May 13, 2024 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

	\| [15][16] \|Authentication with Schnorr Signatures \|
	\| [16][16] \| Authentication \|

	Bob's mint generates a challenge `k1` consisting of randomly generated 32 bytes, for example:
	Bob's mint generates a challenge `k1` consisting of a 64 character hex string generated from 32 random bytes, for example:

Uh oh!

Conversation

starbackr-dev commented Mar 26, 2024

Uh oh!

starbackr-dev commented Mar 31, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

thesimplekid Mar 31, 2024

Choose a reason for hiding this comment

Uh oh!

thesimplekid Mar 31, 2024

Choose a reason for hiding this comment

Uh oh!

thesimplekid Mar 31, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thesimplekid Mar 31, 2024

Choose a reason for hiding this comment

Uh oh!

thesimplekid Mar 31, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

thesimplekid Mar 31, 2024

Choose a reason for hiding this comment

Uh oh!

thesimplekid Mar 31, 2024

Choose a reason for hiding this comment

Uh oh!

thesimplekid Mar 31, 2024

Choose a reason for hiding this comment

Uh oh!

davidcaseria Apr 24, 2024

Choose a reason for hiding this comment

Uh oh!

davidcaseria commented May 13, 2024 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

starbackr-dev commented Mar 31, 2024 •

edited

Loading

thesimplekid Mar 31, 2024 •

edited

Loading

thesimplekid Mar 31, 2024 •

edited

Loading

davidcaseria commented May 13, 2024 •

edited

Loading