NUT-XX: Authentication #106

2024-03-26T01:16:17Z

starbackr-dev commented

2024-03-26 01:16:17 +00:00

(Migrated from github.com)

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.

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.

👎 1

starbackr-dev commented

2024-03-31 20:13:12 +00:00

(Migrated from github.com)

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 🚀

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 🚀

👍 1

thesimplekid (Migrated from github.com) reviewed

2024-03-31 20:55:10 +00:00

16.md

					
				@ -16,0 +16,4 @@

				```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:

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

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

16.md

					
				@ -27,0 +58,4 @@

				  action:"mint", 

				  k1:"8278e1a48e61c261916791dabb6af760488e4f01932e11fe7054f59754e3de6e"

				  signature:c568f78e4b234a5f7d8c3b2a679e48d1234567890abcdef

				  linkingKey:7345786068584cd33000582ba87a9ddf77db5377c67910ab59d7e9a5f44

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

```suggestion "action":"mint", "k1":"8278e1a48e61c261916791dabb6af760488e4f01932e11fe7054f59754e3de6e" "signature": "c568f78e4b234a5f7d8c3b2a679e48d1234567890abcdef" "linking_key": "7345786068584cd33000582ba87a9ddf77db5377c67910ab59d7e9a5f44" ```

16.md

					
				@ -27,0 +60,4 @@

				  signature:c568f78e4b234a5f7d8c3b2a679e48d1234567890abcdef

				  linkingKey:7345786068584cd33000582ba87a9ddf77db5377c67910ab59d7e9a5f44

				}

Missing a ``` here to end the code block

16.md

					
				@ -27,0 +69,4 @@

				{

				  "access_token": "9876543210fedcba",

				  "token_type": "Bearer",

				  "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

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

16.md

					
				@ -27,0 +102,4 @@

				```json

				{

				    "nuts": {

				    "15": {

    "16": {

```suggestion "16": { ```

16.md

					
				@ -27,0 +115,4 @@

				}

				```

```suggestion ```

README.md

					
				@ -49,0 +29,4 @@

				| [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 |

				#### Wallets:

| [16][16] | Authentication |

```suggestion | [16][16] | Authentication | ```

README.md

[16]: 16.md

```suggestion [16]: 16.md ```

davidcaseria (Migrated from github.com) reviewed

2024-04-24 20:05:34 +00:00

16.md

					
				@ -27,0 +39,4 @@

				 - `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 commented

2024-05-13 18:54:51 +00:00

(Migrated from github.com)

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.

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.