Tim Bouma on Nostr: For my project #nostr #safebox I am developing an authentication protocol which I am ...
For my project #nostr #safebox I am developing an authentication protocol which I am calling #nauth. The reason I developed this new protocol is so that either party, name initiator and recipient can initiate the protocol. I wanted to address a situation where only one party might have the ability to scan a QR code, either the patient or the physician. The QR code is merely an out-of-band initiation method, it could be a text or whatever. So here goes,
1. Initiator prepares and sends a #nauth request consisting of:
a. Initiator npub
b. nonce
c. auth kind
d. auth relays
e. transmittal kind
f. transmittal relays
2. Recipient receives #nauth request (usually by scanning a QR code). The recipient inspects the #nauth request and returns another #nauth request as a NIP-59 gift wrapped message using the specified auth kind and auth relays
a. Recipient npub
b. nonce (should be the nonce provided)
c. auth kind (may be the same or different)
d. auth relays (may be the same or different)
e. transmittal kind (may be the same or different)
f. transmittal relays (may be the the same or different)
3. The initiator, upon receiving the #nauth , inspects to see if the nonce is ok, and that the parameters are satisfactory. If so, it may provide an acknowledgment via an out-of-band indication, or through the auth kind/ relays channel proposed.
4. All secure transmittals are sent as giftwrapped messages as kind=transmittal kinds. Any subsequent authentication control messages are sent as gift wrapped messages of kind=auth kind.
BTW, I have this all implemented in #nostr #safebox for #mednostr and it is working like a charm so far. With this scheme I have 99.99999% confidence that health data records are being transmitted with no third party surveillance or model training.
NosFabrica (npub1hea…vp8p)
1. Initiator prepares and sends a #nauth request consisting of:
a. Initiator npub
b. nonce
c. auth kind
d. auth relays
e. transmittal kind
f. transmittal relays
2. Recipient receives #nauth request (usually by scanning a QR code). The recipient inspects the #nauth request and returns another #nauth request as a NIP-59 gift wrapped message using the specified auth kind and auth relays
a. Recipient npub
b. nonce (should be the nonce provided)
c. auth kind (may be the same or different)
d. auth relays (may be the same or different)
e. transmittal kind (may be the same or different)
f. transmittal relays (may be the the same or different)
3. The initiator, upon receiving the #nauth , inspects to see if the nonce is ok, and that the parameters are satisfactory. If so, it may provide an acknowledgment via an out-of-band indication, or through the auth kind/ relays channel proposed.
4. All secure transmittals are sent as giftwrapped messages as kind=transmittal kinds. Any subsequent authentication control messages are sent as gift wrapped messages of kind=auth kind.
BTW, I have this all implemented in #nostr #safebox for #mednostr and it is working like a charm so far. With this scheme I have 99.99999% confidence that health data records are being transmitted with no third party surveillance or model training.
NosFabrica (npub1hea…vp8p)