I dislike email, but I don’t see a good way of (1) resetting forgotten keys/passwords, (2) getting moderator support, and (3) facilitating payments for namespace realestate. Any thoughts?
Well, I think email serves four purposes as a login method:
- To reset passwords
- To reduce spam
- To message users
- To link users’ identities
I don’t know what your plans for authentication in the scrapscript ecosystem are. Is authentication meant to be used by software programmed in ScrapScript, too, or just for developer tooling? Is it planned to be centralized, federated/semi-centralized (DNS-bound accounts like, well, email), or decentralized (everyone has the power to manage their own keys)?
If it’s meant to be decentralized, here are some rough ideas for addressing the above:
1 - To reset passwords
Users have a main key and a backup key. Only the main key can sign scraps. The backup key can publish a key migration message containing a new public key, and signatures under that new key would be published for all scraps that should stay valid. The user would then usually delegate that key to a third party, which would use e-mail, phone or SSO to verify their identity.
Using this system, the backup key has the ultimate authority. The service managing this backup key can be held accountable, because key migration messages inherently have to be public, and they can’t sign any scraps. The user never has to disclose their main private key to anyone, as the service would only need to sign a public key. And lastly, if the user gets hacked and loses their main key, they can simply get the service to sign a new key, which revokes the old one.
I’m in favor of simplifying this process for onboarding by just choosing a default centralized provider and even managing main keys for the users by default. But if someone wants more agency over their own keys, they can get it.
2 - To reduce spam
Here, we can take advantage of the existing IETF privacy pass project Privacy Pass (privacypass)
This has the advantage of industry backing, by Cloudflare and hCaptcha.
3+4 - To message users & To link users’ identities
Well, this could simply be solved by publishing a standardized “this is my email/identity” scrap. There could be services providing a signed “proof of identity” verifying that a certain email/GitHub account or ID belongs to you.
What do you think of this? Or is this not what you want at all?
If it’s meant to be (semi-)centralized, honestly, I would just stick with email. I don’t know your reasons for disliking it, but it’s so ubiquitious that I can’t really think of any benefits to killing it in this scenario that would outweigh the drawbacks.
Actually, this alone might be enough to solve the lost key problem too!
- A horse registers for scrapmap with
{ username = "horse", email = "horse@yahoo.com" }, which is signed with KEY A. They publish a few scraps likehorse/exampleandhorse/test. - The horse loses KEY A because horses and can’t be trusted with computers.
- The horse reaches out to the scrapmap maintainer from
horse@yahoo.comwith a new structure signed with KEY B. - The scrapmap maintainer verifies the email recipient and manually updates the scrapmap to show the new key.
This semi-centralized approach is perfect for my tastes. People can choose not to use an email if they want to preserve their privacy, and if we want to move to “scrapmail” (haha) in the future or whatever then we can just add it to the list of supported verification methods.
Okay, I’m liking this.
We just need to make sure that scrapmaps carry some sort of interface where you can get a list of signed { username, email } records for a given namespace. As long as you trust the scrapmap maintainer, this seems to work pretty well.
IMO, there shouldn’t be a way to recover lost keys. Ever. If horse loses Key A, their options are to fork under a different name and communicate out of band that the new version is horse2.
Alternatively, have a list of keys instead of a single key, and a majority vote in signatures from keys in the keylist to amend the list of keys with a new canonical record. The more keys there are in the keylist, the more secure it is, but the less power any individual key holds and the less likely the source-tree to be compromised. It lets you scale organizations, distributed open source maintainers, and one guy and his spare Yubikey buried in the back yard.
If you want to get fancy, you give a way to forward-link from a original source tree to the forks like GitHub does, though you’ll want some sort of weak reputation system (imports as that metric?)
2 Likes
This model is cool cause you can let clients determine the percentage majority they’re willing to accept before they accept the amended keylist. It could be never in super secure environments or a 51% majority in lax ones.