Add authorize by payment

42.md

@@ -12,9 +12,9 @@ This NIP defines a way for clients to authenticate to relays by signing an ephem
 
 A relay may want to require clients to authenticate to access restricted resources. For example,
 
-  - A relay may request payment or other forms of whitelisting to publish events -- this can naïvely be achieved by limiting publication to events signed by the whitelisted key, but with this NIP they may choose to accept any events as long as they are published from an authenticated user;
-  - A relay may limit access to `kind: 4` DMs to only the parties involved in the chat exchange, and for that it may require authentication before clients can query for that kind.
-  - A relay may limit subscriptions of any kind to paying users or users whitelisted through any other means, and require authentication.
+- A relay may request payment or other forms of whitelisting to publish events -- this can naïvely be achieved by limiting publication to events signed by the whitelisted key, but with this NIP they may choose to accept any events as long as they are published from an authenticated user;
+- A relay may limit access to `kind: 4` DMs to only the parties involved in the chat exchange, and for that it may require authentication before clients can query for that kind.
+- A relay may limit subscriptions of any kind to paying users or users whitelisted through any other means, and require authentication.
 
 ## Definitions
 
@@ -23,8 +23,17 @@ A relay may want to require clients to authenticate to access restricted resourc
 This NIP defines a new message, `AUTH`, which relays CAN send when they support authentication and clients can send to relays when they want to authenticate. When sent by relays the message has the following form:
 
 ```
-["AUTH", <challenge-string>]
+["AUTH", <challenge-string>, <payment-request>]
 ```
+- `<payment-request>` (optional) is a Cashu [NUT-18](https://github.com/cashubtc/nuts/blob/main/18.md) payment request. Its transports field must include at least the following transport method:
+
+    ```json
+    {
+      "type" : "nostr",
+      "target" : "",
+      "tags" : [ [ "n", "42" ] ]
+    }
+    ```
 
 And, when sent by clients, the following form:
 
@@ -32,7 +41,7 @@ And, when sent by clients, the following form:
 ["AUTH", <signed-event-json>]
 ```
 
-`AUTH` messages sent by clients MUST be answered with an `OK` message, like any `EVENT` message.
+- `AUTH` messages sent by clients MUST be answered with an `OK` message, like any `EVENT` message.
 
 ### Canonical authentication event
 
@@ -45,10 +54,13 @@ The signed event is an ephemeral event not meant to be published or queried, it
     ["relay", "wss://relay.example.com/"],
     ["challenge", "challengestringhere"]
   ],
+  "content": "<payment>"
   // other fields...
 }
 ```
 
+`<payment>` (optional) is only to be filled as a response to a [NUT-18](https://github.com/cashubtc/nuts/blob/main/18.md) `<payment-request>`. It must be a valid [NUT-00](https://github.com/cashubtc/nuts/blob/main/00.md#03---methods) cashu token.
+
 ### `OK` and `CLOSED` machine-readable prefixes
 
 This NIP defines two new prefixes that can be used in `OK` (in response to event writes by clients) and `CLOSED` (in response to rejected subscriptions by clients):
@@ -98,8 +110,9 @@ relay: ["OK", "012345...", true, ""]
 
 To verify `AUTH` messages, relays must ensure:
 
-  - that the `kind` is `22242`;
-  - that the event `created_at` is close (e.g. within ~10 minutes) of the current time;
-  - that the `"challenge"` tag matches the challenge sent before;
-  - that the `"relay"` tag matches the relay URL:
+- that the `kind` is `22242`;
+- that the event `created_at` is close (e.g. within ~10 minutes) of the current time;
+- that the `"challenge"` tag matches the challenge sent before;
+- that the `"relay"` tag matches the relay URL:
     - URL normalization techniques can be applied. For most cases just checking if the domain name is correct should be enough.
+- that the `content` field (if present) contains a valid, unspent cashu token.