Nostr Web Tokens

[pippellia-btc]

Readable Version

TLDR;
A Nostr Web Token (NWT) is a Nostr event used to convey signed claims between parties on the web, inspired by JSON Web Tokens.

NWT is able to represent both NIP-98 and Blossom authorization event, and anything in between, allowing clients much more flexibility for how and how long these tokens are considered valid.

Depending on the use case, the benefits are improved signing UX and/or security.

Here is a detailed comparison: NWT vs NIP-98 vs Blossom Auth

Here is a video explanation: Introducing NWT

EDIT:
Here is the reference library implementation: Golang NWT

[vitorpamplona]

Looks good.

I would break all multi-value tags into multiple tags, like:

["aud", "blossom.example.com"],
["aud", "cdn.another.com"],
["aud", "cdn.last.one"],

Though I don't think this will or needs to replace NIP-98 or Blossom's Auth.

[pippellia-btc]

Thanks for the feedback @vitorpamplona. I don't have a strong preference regarding tags.
Having either multiple values per tag or multiple tags is fine. Is the latter more nostr idiomatic?

Regarding your last comment, I think Blossom Auth requires reworking because:

• each endpoint has its own verification rules
• it's currently susceptible to replay attacks (which is bad for DELETEs)

But this is a separate discussion to have with @hzrd149 :)

[vitorpamplona]

Is the latter more nostr idiomatic?

I think so.

each endpoint has its own verification rules

Not sure what you mean by that. But it should be fine if they do have.. no?

currently susceptible to replay attacks (which is bad for DELETEs)

I think Blossom's 24242 has a server tag to fix that:["server", "https://cdn.example.com/"]

However, because mirroring is common/desirable on Blossom, this could be more of a feature than an attack.

[pippellia-btc]

Not sure what you mean by that. But it should be fine if they do have.. no?

It's not terrible but it's not ideal in its current form IMO.

I think Blossom's 24242 has a server tag to fix that:["server", "https://cdn.example.com/"]

Maybe it had it in the past, but not now. In fact hzrd suggested to add it only to the DELETE endpoint to prevent this replay attack, which would exacerbate my first point about each endpoint having its own validation rules.

However, because mirroring is common/desirable on Blossom, this could be more of a feature than an attack.

It's desirable for reads, uploads, mirrors, but not for deletes or lists in general. If deletes are meant to be global, it's also desirable for them.

To give more context, NWT have been inspired by this discussion about blossom auth.

hzrd149/blossom#87

[vitorpamplona]

It is there for the GET in BUD-01. A simple change can add it to the DELETE too.

Given the debate over there, I still think this is not a replacement for NIP-98 or Blossom's Auth. This one is for cases where you need much more configurability (e.g. separate iss from pubkey, separate iat from created_at, separate exp from expiration, separate audience and subjects as opposed to combined in NIP-98 and Blossom's) than what Blossom uses. This one can just specialize in usecases where that configurability is an absolute necessity.

[hzrd149]

I would like to see this or something like this replace NIP-98 only because any app I use that is using NIP-98 requires me to give away all control of my private key so it can auto sign for every damn http request.

I'm undecided if this could be a replacement for the blossom authorization since as you guys have mentioned its missing clear documentation around the server tag to scope the tokens. and using NWT would be a breaking change, where as just defining the role of the server tag wouldn't be

@pippellia-btc ill try to get some time in the next few days to make a PR to the blossom spec to update the documentation around the authorization event and the server tag

[vitorpamplona]

I would like to see this or something like this replace NIP-98 only because any app I use that is using NIP-98 requires me to give away all control of my private key so it can auto sign for every damn http request.

I think that goes beyond replacing it, since one can replace it but still require a new NWT at every http request.

I think you are asking for a new way to sign in with broader permissions on the server and token reuse by clients, which is not just a simple replacement. To me, this is a new thing and would need additional boundaries that nip98 doesn't even bother about.