From f5120c570e0cd36f37dd14066085aada8433e292 Mon Sep 17 00:00:00 2001
From: earonesty <erik@q32.com>
Date: Thu, 1 Jun 2023 06:42:31 -0700
Subject: [PATCH] Update 26.md

---
 26.md | 34 +++++++++++++++++++++++++++++++++-
 1 file changed, 33 insertions(+), 1 deletion(-)

diff --git a/26.md b/26.md
index b8fa9028..6e4abeb6 100644
--- a/26.md
+++ b/26.md
@@ -105,4 +105,36 @@ Clients should display the delegated note as if it was published directly by the
 
 Relays should answer requests such as `["REQ", "", {"authors": ["A"]}]` by querying both the `pubkey` and delegation tags `[1]` value.
 
-Relays SHOULD allow the delegator (8e0d3d3e) to delete the events published by the delegatee (477318cf).
\ No newline at end of file
+Relays SHOULD allow the delegator (8e0d3d3e) to delete the events published by the delegatee (477318cf).
+
+#### Protocol Handler Support
+
+Using NIP26, a new oauth-style protocol handler can allow oauth-style login for nostr apps that do not want to be the primary custodians of identity keys.:
+
+Consider the following link that can be opened as an intent in browser and mobile apps:
+
+```url
+nkey://auth?id=<uuid>&**uri**=x &kinds=1,2,4,5&from=<epoch>&to=<epoch>&**pubkey**=<64-char hex pub key>&reason=descriptive+text&relays=r1,r2...
+```
+
+This can open up an associated app or browser that:
+
+ - On success:
+     - Posts NIP26 delegate info to the requested relays (if any)
+     - Optionally posts delegate info to additional relays (if configured
+     -  POSTs a response to the **URI** containing a delegate key encrypted with the requested pubkey and information about what was approved (if anything)
+     ```js
+     {
+      id:"<request-id>",
+      status:"authorized",
+      key:"<b64 encoded nip44 encrypted with the **pubkey**>",
+      from:<epoch-approved-from-time>
+      to:<epoch-approved-to-time>,
+      kinds: [1,2]
+     } 
+     ```
+ -On rejection, POSTs a "rejection" to the **URI**
+ {
+     id:"<request-id>",
+     status:"denied",
+  }