Identity proofs

[aumetra]

There is FEP-C390 that describes identity proofs based on DIDs that are linked to actors, practically allowing somewhat nomadic identities by providing proofs that all of these different accounts are indeed one and the same person.
It's not complete yet but definitely an interesting point for exploration.

One thing I'm not entirely fond of is the forced usage of Base58 for the key methods as defined in the did:key Method draft v0.7. Since it is still experimental, I will take the liberty and ignore the Base58 requirement.
Since the draft also defines usage of Multibase and Multicodec, means a relaxation of this requirement will still be backwards compatible with already existing DIDs. It will only present an issue if Kitsune would use a different encoding than Base58 and an existing implementation tried to retrieve the verifying key material.

[erlend-sh]

Nomadic Identity discussions on SocialHub:

• https://socialhub.activitypub.rocks/t/defining-alsoknownas/907
• https://socialhub.activitypub.rocks/t/nomadic-identity-for-the-fediverse/2101/
• https://codeberg.org/fediverse/fep/src/branch/main/feps/fep-c390.md

Example implementation of fep-c390: https://codeberg.org/silverpill/mitra

Implementing this fep for Kitsune to be compatible with Mitra would set a strong precedent for a stable fep proposal, ready for wider adoption.

---

Two new FEPs related to nomadic identity and data portability:

• FEP-7628: Move actor
• FEP-ae97: Client-side activity signing

[erlend-sh]

Matrix also has a long-standing discussion evaluating different forms of nomadic identity, recently narrowing in on DIDs:

• Decentralised user accounts matrix-org/matrix-spec#246
• Decentralised user accounts matrix-org/matrix-spec#246 (comment)
• https://www.w3.org/TR/vc-data-model/

[erlend-sh]

It’s also worth following ATproto’s own development of this feature:

• ID design and replaceability bluesky-social/atproto#401
• ATproto / Bluesky interop #366

In response to doubts about using Bluesky as a reference, I’ve said the following:

While I agree that there’s every reason to be cautious about Bluesky’s centralized approach, I think it’s worth noting that private-key identities solve two distinct problems:

1. Instance-independent identity with credible exit
2. Self-sovereign identity with no 3rd party authority

Personally I don’t actually want to be 100% responsible for the safeguarding of my private identity key, for the same reason I use a bank instead of storing my money in a safe at home.

I want to fully own my identity, but I don’t need exclusive custodianship over it. I have a much more urgent need for (1) than (2), so I’m okay with solving the former first as long as there’s a clear path from there to the latter.

Bluesky’s approach is in principle fine with me, provided their promise of credible exit can be substantiated. However I might only be willing to trust such a third party if it was Mozilla or some other similarly established open-web institution.

[erlend-sh]

OIDC also has a draft spec extension taking DIDs into account:
https://openid.net/specs/openid-connect-self-issued-v2-1_0.html