NIP43 Authentication Delegation

[monlovesmango]

NIP to allow delegation of NIP42 authentication to other key pairs. can be used to create login tokens for relay access or grant permissions to restricted events (which is another pr).

this NIP could also be extensible to other types of authenticated access in the future, like permitting certain users to publish protected events in pr #1030.

https://github.com/monlovesmango/nips/blob/NIP43-auth-delegation/43.md

references to NIP-71 will point to pr #1083 (https://github.com/monlovesmango/nips/blob/NIP71-restricted-events-by-tag/71.md)

[arthurfranca]

A #<one-letter-tag> condition could be useful.

For example an event with ["s", "platinum-subscribers"] tag only meant for users holding a token with a { #s: ["platinum-subscribers"] } condition.

[monlovesmango]

yeah perhaps, but would also need to be integrated into restricted events NIP.

I think both are already introducing enough complexity so I would prefer not to add more. however, I did make the 'mode condition' in this NIP specifically so we can extend this to allow for different types of permissions to restricted events in the future.

[arthurfranca]

I mean, still considering what you said "The filter condition ALWAYS IMPLICITLY includes the filter criteria "authors": ["${delegator pubkey}"].

So it would still be limited to delegator events, thus your NIP-71 PR wouldn't need to change.

[monlovesmango]

yes, true. was just thinking about this myself. actually don't think I would need to change anything other than add it as another option to the filter condition right?

[monlovesmango]

really like the idea @arthurfranca ! being able to allow access to different subscription levels or different sets of content is so neat.

[staab]

How is this different from NIP 26? I would like users to be able to log in as a separate pubkey, but without revealing their identity, which this doesn't support. The way I imagine that is you would claim a badge with a one-off private key, then authenticate (with a relay, third party service, whatever) using that key to prove you have the badge. You could reveal your main pubkey or not in that scenario.

[monlovesmango]

this is different from NIP26 in that this only gets added to kind 22242 event tags and the permissions in the token refer to what access is granted on the relay on the delegator's behalf (rather than permissions for what events are allowed to be signed by delegatee).

I would like users to be able to log in as a separate pubkey, but without revealing their identity, which this doesn't support.

if you do this using the "claim" wouldn't this be vulnerable to someone reselling the claim?

edit: never mind, I see claims would be shareable and free. auth delegation would only be able to do restrictive claims that are not human readable (ie each claim would have to be issued by centralized authority, claims couldn't be shared, and claims would have expiration built in)

The way I imagine that is you would claim a badge with a one-off private key, then authenticate (with a relay, third party service, whatever) using that key to prove you have the badge. You could reveal your main pubkey or not in that scenario.

I think this could be done but not sure I am fully understanding the scenario. NIP42 as is would you allow you to do this already, no (authenticate as a one-off private key)? does the badge unlock certain permissions on the relay/third party service?

if your goal is just to prove ownership of the badge, but be able to use any arbitrary pubkey to login you could:

1. claim badge with one-off private key
2. create auth delegation token (with mode = 0-login) from one-off private key as delegator and key you want to reveal to relay as delegatee
3. authenticate with key you want to reveal but add auth delegation token to the kind 22242 event tags

this will allow you to authenticate with the key you want to reveal, but tell the relay to give permissions that one-off private key (that owns the badge) would have.

but I'm pretty sure I'm still not understanding correctly, let me know what I got wrong.