Looks good, as long as the server doesn't use the identifier as the session cookie.

created_at check (must be < 5 minutes from the request) could also be performed.

Looks good, as long as the server doesn't use the identifier as the session cookie.

created_at check (must be < 5 minutes from the request) could also be performed.

The identifier is associated with the session cookie in some way, but it shouldn't be it.
The created_at check is a part of NIP-98 and services can also determine when to expire a login string.

Why not use NIP-98?

EDIT: I see NIP-98 is already a part of this. I don't understand what this is solving.

I don't get this at all. What happens when you click? Who is going to handle that link?
I think it's better to let websites come up with their own login process using NIP-98.
Maybe recommend a common pattern on that NIP.

I don't get this at all. What happens when you click? Who is going to handle that link? I think it's better to let websites come up with their own login process using NIP-98. Maybe recommend a common pattern on that NIP.

not everyone has an extension. the point of this is if you don't have an extension, you could just scan a QR code/click a link and prove you control an npub without inputting your nsec everywhere.

What about NIP-46?

not everyone has an extension. the point of this is if you don't have an extension, you could just scan a QR code/click a link and prove you control an npub without inputting your nsec everywhere.

I missed the part where you prove anything. Is that part of this NIP? How does clicking a link prove anything? Maybe it is just missing a sentence where this is explained.

cc @danieldaquino for review since you introduced a similar flow for damus purple

not everyone has an extension. the point of this is if you don't have an extension, you could just scan a QR code/click a link and prove you control an npub without inputting your nsec everywhere.

I missed the part where you prove anything. Is that part of this NIP? How does clicking a link prove anything? Maybe it is just missing a sentence where this is explained.

The request has a nip-98 header

not everyone has an extension. the point of this is if you don't have an extension, you could just scan a QR code/click a link and prove you control an npub without inputting your nsec everywhere.

I missed the part where you prove anything. Is that part of this NIP? How does clicking a link prove anything? Maybe it is just missing a sentence where this is explained.

your client sends a POST request that is authenticated with your public key (NIP-98) with an identifier in the login link

What about NIP-46?

@fiatjaf This is for use cases where you don't need signing access and only need to prove your ownership of a key.

@Semisol do you have any server where this was implemented already? I need to test Amethyst's implementation of this.

@Semisol do you have any server where this was implemented already? I need to test Amethyst's implementation of this.

I'll implement one on nostr.build in the next couple of days.

This looks good I will implement it also.

For testing: https://media.utxo.nl/nip97test/nip97login.php

For testing: https://media.utxo.nl/nip97test/nip97login.php

@fabianfabian I don't think your server properly enforces NIP-98. It expects the event to have a u tag containing only the URL without the query parameters and then the i query parameter is in a separate tag. But if you look at the spec for NIP-98, the u tag should include the entire absolute request URL including query parameters.

For testing: https://media.utxo.nl/nip97test/nip97login.php

@fabianfabian I don't think your server properly enforces NIP-98. It expects the event to have a u tag containing only the URL without the query parameters and then the i query parameter is in a separate tag. But if you look at the spec for NIP-98, the u tag should include the entire absolute request URL including query parameters.

I'm checking the i tag for the challenge but I see the spec doesn't describe it like that, not sure what happened there probably I read it too quick, I'll update the test code later, this is the current test code: https://gist.github.com/fabianfabian/0c68d75aeb84860dcd7fc2995ec98af6

I've also implemented a server for testing but only accessible via REST API: https://git.rebelofbabylon.com/api/v1/login

I really like this spec, and I think it will be very useful.

Only thing I would add to it is an optional redirect_url field to the JSON response from the server, but otherwise it looks good to me.

agreed, this is pretty important.

@Semisol do you have any server where this was implemented already? I need to test Amethyst's implementation of this.

I'll implement one on nostr.build in the next couple of days.

@fishcakeday is this available on nostr.build? I want to try it out

Security concerns: Domain compromise could impact login systems, potentially harming Nostr's reputation. Motivation and security surface would benefit from further elaboration.

Existing efforts: Consider ongoing Nostr integration with Oauth/OIDC for new authentication methods.

Suggestion: Future auth NIPs should include a comparison section:

• Comparison with existing auth methods, e.g. nostrlogin, nip98, nwc, nsecbunker, there's more ongoing oauth and oidc integrations ive seen too
• Advantages offered
• Use cases
• Adoption status

Concept NACK: Needs clearer explanation and/or broader adoption to justify implementation (IMHO).

Just my 2 cents.

The main usecase we had is that we wanted to explicitly give memberships to npubs to have the ability to display stars on profiles and to give them a purple member number, I see this as more of a thing for niche thing for specifically verifying that a user controls a key to an npub, not as a generic login mechanism, although its true its likely this will be abused for that.

I think pushing npubs as a login mechanism is a bit sketchy, because once your key leaks you basically have doors wide open into all the websites you visit. Maybe we should make this explicit in the NIP that this should be probably just be used as a two factor mechanism or for niche use cases like verifying a user controls a key to an npub? Not as a main login mechanism.

I think pushing npubs as a login mechanism is a bit sketchy, because once your key leaks you basically have doors wide open into all the websites you visit. Maybe we should make this explicit in the NIP that this should be probably just be used as a two factor mechanism or for niche use cases like verifying a user controls a key to an npub? Not as a main login mechanism.

Not even as two factor. The intent for this NIP was to allow easy login to services already linked to your nostr account, like relays, media hosts or NIP-05 providers.