Define a mechanism for looking up an offer from a user/domain pair

04-onion-routing.md

@@ -1482,6 +1482,19 @@ even, of course!).
     1. type: 68 (`invoice_error`)
     2. data:
         * [`tlv_invoice_error`:`inverr`]
+    1. type: 70 (`offer_request`)
+    2. data:
+        * [`u8`:`name_len`]
+        * [`name_len*byte`:`name`]
+        * [`u8`:`domain_len`]
+        * [`name_len*byte`:`domain`]
+    1. type: 72 (`offer_response`)
+    2. data:
+        * [`u8`:`name_len`]
+        * [`name_len*byte`:`name`]
+        * [`u8`:`domain_len`]
+        * [`name_len*byte`:`domain`]
+        * [`tlv_offer`:`offer`]
 
 1. subtype: `blinded_path`
 2. data:

12-offer-encoding.md

@@ -10,6 +10,7 @@
   * [Invoice Requests](#invoice-requests)
   * [Invoices](#invoices)
   * [Invoice Errors](#invoice-errors)
+  * [Offer Requests](#offer-requests)
 
 # Limitations of BOLT 11
 
@@ -186,6 +187,12 @@ distinct TLV ranges.
 
 The human-readable prefix for offers is `lno`.
 
+If a URI scheme is desired, offers should be encoded in standard `bitcoin:`
+URIs as defined in BIP 21, as query parameter with a key of `b12` and a value
+of the ASCII encoding defined above. Both the key and value are
+case-independent and, for compactness, should be uppercase for URIs which are
+encoded in QR codes.
+
 ## TLV Fields for Offers
 
 1. `tlv_stream`: `offer`
@@ -818,6 +825,26 @@ sender of the invoice would have to guess how many msat that was,
 and could use the `invoice_error` to indicate if the recipient disagreed
 with the conversion so the sender can send a new invoice.
 
+# Offer Requests
+
+`bitcoin:` URIs with a query paraketer key (case-insensitive) of `omlookup`
+indicate that an offer should be requested over onion messages. The value in
+the query parameter should be a hex-encoded `blinded_path` which represents a
+(FIXME: Use a specific name here for blinded paths for onion messages)
+recipient to send an `offer_request`-containing onion message to. These URIs
+only make sense in the context of a BIP XXXX resolution, where a sender is
+resolving a `name`/`domain` pair to payment instructions.
+
+## Requirements
+The sender of an `offer_request`-containing onion message:
+ * MUST set `name` and `domain` to printable ASCII charachters only,
+ * MUST set `domain` to a canonically-encoded domain name, ending in a "."
+
+The recipient of an `offer_request`-containing onion message:
+ * if the `name` and `domain` describe a recipient it is responsible for, SHOULD
+   reply with an `offer_response`-containing onion message with the same `name`
+   and `domain`.
+
 # FIXME: Possible future extensions:
 
 1. The offer can require delivery info in the `invoice_request`.