In the future, these kind of things will be signed and relayed via #nostr . 
As a first pass, I'd model it like DNSSEC. The delegator (parent) has a DS record (event) having the delegatee (child) pubkey. Additional tags could be added for specific delegations.
Here, the workers from the government liquor monopoly are on strike for higher wages.
Regardless of the final conclusions, I much prefer a security model that is predicated on me keeping a secret than relying on someone else’s promise that they implemented the proper security controls.
‘The middle doesn’t matter.’ - a quote that should apply to good #nostr relay design.
Yeah, I feel like I am in 1983 again (not 1984)
Everything can be seized. Everyone just needs to clearly understand their deal with the digital devil.
HTTPS is great. Unfortunately most think you need to be blessed by a browser root program and CA to use it. Part of that capture has been mitigated by Let’s Encrypt (thank god) and there are other schemes like DANE (domain authentication of named entities) where you can self-generate and self-register your own cert using DNSSEC. But the browser vendors/CAs have little interest in implementing because that cuts them out of the authority loop.
It’s not so much centralization I am worried about; it’s more about authority-creep that leads to centralization.
I think NIP-05 is super-powerful because it gives an external trust context to an #npub. Some might argue, it is insecure, but that’s really a function of how the domain is managed and how you decide to trust.
NIP-05 also gives a really good bridge to the legacy world, and everyone knows how to read and make a judgment of a domain name (yes, I know about threats of character substitution, spoofing, etc., but that can be mitigated). All the DNS lookup stuff is deeply baked in the OS, so there is little reason not to use it.
If you dig into DNS, it’s not really centralized, as many claim.Yes, there is a root, but everything is delegated from that point downward. So it’s not really centralize or decentralized: I like to call it ‘delegated’. DNS (or more specifically DNSSEC) works for nation-states that are bombing each other, so I don’t see why it wouldn’t be leveraged by #nostr in a hopefully less-adversarial environment.
Finally domain names (URIs, URNs) have superpowers- have a read of RFCs 3986 and 8141. By their very structure, you, as a human, can read out the authority structure of a URN/URI before deciding what to do with (usually, trust). You can’t read a QR code, but you can read a text URI/URN to make a device-unassisted trust decision
We need to name a law for this:
'After a time, all platforms go against their users.'
Or something like:
'All users become eventually subjects of the platform.'
#serpow - signed events relayed; proof of work.
Yeah, the penny dropped when I saw what you did with npub login (kicking myself, why didn’t I think of that!). I realized I could generalize extend and make every #nostr client an authenticator, too!
I think there might be a solution with nip05 mapping. I have to put my thinking cap on.
I am experimenting with npub login where authorization is an encrypted dm challenge/response (no need to type in 6 digit code at site). When it’s ready, I will show you and you might consider it for your login.
FWIW, I spent about a month trying to get FIDO working with webauthn but it was too damn hard. In less than a week, I have almost completed a full login with npub - it was way simpler. Of course it needs the extra identity things I mentioned above, and perhaps some removable hardware platform that holds the nsec, but I am optimistic this is the right way to go.
I love the elegance of using npubs for solving the #authentication problem. Having an identifier that natively supports encrypted messaging and signing can vastly reduce the complexity of login (#authentication)solutions and eliminate entirely the need to store passwords.
But this still does not solve the #identity problem. If you are using the same npub to login to a multiplicity of sites, if your nsec is compromised, you’re screwed.
I’ve heard the criticism that login with npub is actually a ‘regression’ to less secure authentication but that’s not an authentication problem, that’s an identity problem.
The best approach is have seen to mitigating identity compromise is Lightning Login (#lud04) where the wallet derives a new pubic/private key for each site that is authenticating (using a hash of the domain to derive a new key pair). That way there is no correlation capability.
Carrying this over to #nostr, if a client is privy to your ‘identity’ (has your nsec), it should be able to derive different npubs for different domains, and handle all of the derivations so all those identities look like it’s all one from the perspective of the client.
So it’s a problem to be solved, but right now I see a huge benefit of just solving #authentication, getting rid of all those bespoke authenticator apps, and not become device-bound to someone’s hardware because of a passkey that refuses to leave the secure enclave.