From 2a1945cc7ffe2b9dd8afeea4244ed0e636b25921 Mon Sep 17 00:00:00 2001 From: Daniel Roberts Date: Fri, 26 Jul 2024 22:17:56 -0500 Subject: [PATCH] wip: Reconcile NIP-96 and NIP-98 and address implementation challenge --- 96.md | 3 ++- 98.md | 17 ++++++++++++++++- 2 files changed, 18 insertions(+), 2 deletions(-) diff --git a/96.md b/96.md index be709991..7045431e 100644 --- a/96.md +++ b/96.md @@ -84,7 +84,8 @@ See https://github.com/aljazceru/awesome-nostr#nip-96-file-storage-servers. ## Auth -When indicated, `clients` must add an [NIP-98](98.md) `Authorization` header (**optionally** with the encoded `payload` tag set to the base64-encoded 256-bit SHA-256 hash of the file - not the hash of the whole request body). +When indicated, `clients` must add an [NIP-98](98.md) `Authorization` header. +`clients` SHOULD include either the `payload` tag or the `payload_multipart` tag with the `file` multipart field name included in the digest (`["payload_multipart", "", "file"]`). ## Upload diff --git a/98.md b/98.md index be425b28..dbb78bce 100644 --- a/98.md +++ b/98.md @@ -43,12 +43,27 @@ Servers MUST perform the following checks in order to validate the event: 3. The `u` tag MUST be exactly the same as the absolute request URL (including query parameters). 4. The `method` tag MUST be the same HTTP method used for the requested resource. -When the request contains a body (as in POST/PUT/PATCH methods) clients SHOULD include a SHA256 hash of the request body in a `payload` tag as hex (`["payload", ""]`), servers MAY check this to validate that the requested payload is authorized. +When the request contains a body (as in POST/PUT/PATCH methods) clients SHOULD include a SHA256 hash of the request body in a `payload` tag as hex (`["payload", ""]`) or a SHA256 hash of the relevant fields in a `payload_multipart` tag. +Servers MAY check these to validate that the requested payload is authorized. If one of the checks was to fail the server SHOULD respond with a 401 Unauthorized response code. Servers MAY perform additional implementation-specific validation checks. +### The `payload_multipart` tag + +The `payload_multipart` tag SHOULD only be sent when authorizing a request with a `Content-Type` of `multipart/form-data`. +A valid `payload_multipart` tag will always consist of 3 or more elements. +The first element is always the tag name, `payload_multipart`. +The second element is the sha256 hash, which is computed over the concatenation of every serialized multipart field, in order. +The third through last elements name the form fields which will be concatenated together to calculate the hash. + +`["payload_multipart", "", "", ...""]` + +The multipart-field-names MUST appear in the same order as they appear in the multipart body. +Repeated field names MUST have corresponding repeated fields in the multipart body. +After a multipart field is added to the sha256 digest, no subsequent multipart-field-name may refer to any multipart field up to and including the one which was just processed (field processing always progresses forward in the request body, never backwards). + ## Request Flow Using the `Authorization` HTTP header, the `kind 27235` event MUST be `base64` encoded and use the Authorization scheme `Nostr`