silverpill
@lina @keyoxide @wizzwizz4 @adora
Suggestions:
- Identity server may serve did:web identity documents.
- Instead of identity and publicKey.signature properties, actor object may contain FEP-c390 identity proofs.
This would make your proposal compatible with existing web standards and allow identity system to evolve (it can support different key types and signature algorithms, and identity servers can be replaced with user-owned identities).
Aeliana (Aeli) Isidora
@keyoxide @wizzwizz4 @adora yup, i just finished a draft of the suggestion that should be a bit easier to grasp the idea of as it has everything in one place!
and warning: as i'm a person who doesn't know how cryptography works it might possibly be better to remove that part at all ^^'
https://gist.github.com/nullium21/eefcfa353772a1b5e56f2d91362da979
Keyoxide
@wizzwizz4 always great to see people thinking about identity! The project has been quiet lately but I am very close to releasing a better way of working with Keyoxide, not needing PGP, just pure Ed25519!
And after that, I'd like to experiment with methods based solely on domain ownership, no cryptography.
I don't fully grok OP's envisioned approach yet, but I suppose that's coming somewhat near?
wizzwizz4
@adora Honestly, i wouldn't be surprised if @keyoxide added support for whatever @lina settled on.
Adora (She/Her)
@wizzwizz4 @lina @keyoxide lol i was actually going to mention them as an option, but I didn't want to be overwhelming, because @lina didn't settle on PGP keys specifically.
wizzwizz4
Adora (She/Her)
@lina so first off, i love the idea. this isn't criticism at all, its unfiltered support.
so here's where stuff is getting messy:
I assume the idea is because people can move instances, otherwise you wouldn't need something to "vouch" in the first place.
so putting the implementation specifics aside, we need something thats:
1) centralized and trusted
2) not prone to loss, otherwise when people lose a computer/phone/authenticator/whatever they no longer have their proof
and this takes us back to PGP keyservers and certificate authorities all over again.
so your best bet would be to find a way to leverage something like a CA or PGP keyserver thats been very established and trusted and use it in conjuction with some api translation layer to function the way you need it to.
and yes, i know that answer sounds bad, feels bad and isn't fun at all.
Aeliana (Aeli) Isidora
warning: long post ahead; probably screenreader unfriendly
i wonder would it be possible to add some sort of "identity servers" to fedi so that, let's say i'm @lina@lina.moe even tho i'm using a mastodon instance hosted elsewhere
could see that as a hierarchy? of keypairs
let's say i use tech.lgbt as my mastodon server, meaning it has generated a keypair, perhaps `tech.lgbt/@lina@lina.moe#mainkey`
identity server would then sign the public key, so the Actor object would have this?
```
{
// ...
"identity": "https://lina.moe/lina",
"publicKeyPem": {
"id": "https://tech.lgbt/@lina@lina.moe#mainkey",
"publicKeyPem": "...",
"signature": "..."
}
}
```
and the identity server would be able to verify the signature to say "yes that's lina" or "no she's being impersonated"
please boost so that i get feedback on how weird and impossible this idea is and maybe if someone has actually implemented smth similar before 🥺
GNU social JP is a social network, courtesy of GNU social JP管理人. It runs on GNU social, version 2.0.2-dev, available under the GNU Affero General Public License.
All GNU social JP content and data are available under the Creative Commons Attribution 3.0 license.