Still super-excited about #nAuth, a decentralized authorization protocol I am working on. After reading a few more specs, I decided to add a ‘grant’ tag to make it easy to specify what is ‘granted’ after the conclusion of an authentication. I had also added ‘scope’ so the initiator could specify what they are looking for, and the respond replies with the corresponding grant.

It might look like overkill, but I am trying to make a very generic protocol than can serve the majority of #nostr use cases. The latest is here.

https://github.com/trbouma/safebox/blob/nauth-refactor/docs/NAUTH-PROTOCOL.md

Reply to this note

Please Login to reply.

Discussion

This looks really cool. I need to re read and think about this more deeply, but I have a couple of questions:

1. Nauth can publicly be decoded right?

2. So what is the purpose of the nonce?

3. Is there anything that guarantees that the nonce isn't just a preselected number? And what is the attack vector here?

1. nAuth is intended to be initiated over a potentially insecure channel. The bech32 is best for presenting a QR code or transmitting text that can be easily cut and pasted by a human.

2. The nonce is to prevent session hijacking. I generate a new nonce every time I present a QR and check to see if it’s the same in the reponse.

3. The nonce is really up to the initiator to generate and manage. They can ignore it if they wish but to their peril.

Okay, so nonce is a way to manage your initiations so you can expire them for example without complicating things with signatures for example, which would bloat the nauth.

Did I get that right?

Exactamento. It's basically a challenge and response. If I receive the challenge via a signed/encrypted DM then that is equivalent to the typical challenge and signed response. If you wish, you could add your own timeout, but that would be outside of the protocol spec, more like good practice guidance.