theoretical considerations on identity management

Submitted ⁨⁨5⁩ ⁨days⁩ ago⁩ by ⁨gandalf_der_12te@discuss.tchncs.de⁩ to ⁨fediverse@lemmy.world⁩

so, this is a bit of an abstract mathematical post.

I think that a fediverse service consists mostly of three parts: identity provider, data hoster, and feed provider.

The data hoster is the machine that hosts the posts and comments and upvote/downvote stats. The feed provider is the service which gives you a nice, scrollable overview over new content for you. This is today the same system that provides the data, but it could be separated, such as having a custom “search engine” that gives you content, that you use independently of where the data is stored.

The identity provider basically only makes a proof that “you are you” : you give it your login credentials and it gives you a kind of token that authenticates (proves your identity) to other services. like, i’m on discuss.tchncs.de, but i can post to lemmy.world. this is because the discuss.tchncs.de server says to lemmy.world that i indeed have this account on this server. so they prove my identity in a way.

What i argue now is that such an identity providing server is not technically necessary. You could use something like an ~/.ssh/id_rsa file that you generate on your own computer and use that public key to identify yourself on the fediverse. I don’t think that this approach has any inherent advantages over how things are being done today, but it could be done that way and that in itself is fascinating.

source

Comments

Sort:hotnew top

bumblefudge@activitypub.space ⁨16⁩ ⁨hours⁩ ago
See also FEP-e3e9 on DID-like redereferencing from an HTTP server of actor objects-that-are-also-DID-docs

using a did:... as an actor.id prop is a little spicy and isn't exactly backwards compatible with the entirely HTTPS-based fediverse, BUT all web-based did methods (did:web, did:webvh, did:webplus, and even did:plc if you squint a little and hardcode the discovery path to a document cache like plc.directory or a custom resolver like pdsls.dev) let you express a DID not just as a did string but also as a URL. if the server does con-neg and returns the actor object as JSON-LD (or debatably even if it ignores con-neg and just already serves a JSON-LD did doc without the appropriate content-type header) then... you just dereferenced an actor conformantly even though what you got back was a "DID Document" in addition to being an actor object.

source
rimu@piefed.social ⁨5⁩ ⁨days⁩ ago
That is a lot like AT Protocol.

There’s pros and cons to every architecture. Which pros seem important and which cons you can put up with depend on your values and priorities.

source
e0qdk@reddthat.com ⁨5⁩ ⁨days⁩ ago
BlueSky uses AT Protocol which is similar to how you break things down: en.wikipedia.org/wiki/AT_Protocol

source
lambalicious@lemmy.sdf.org ⁨3⁩ ⁨days⁩ ago

What i argue now is that such an identity providing server is not technically necessary. You could use something like an ~/.ssh/id_rsa file that you generate on your own computer and use that public key to identify yourself on the fediverse.

Wouldn’t this require a keyserver anyway, GPG-style, since you need to have a means to guarantee that services all around can see your public key?

source
- gandalf_der_12te@discuss.tchncs.de ⁨3⁩ ⁨days⁩ ago
  yeah i guess so.
  
  basically either a keyserver, or you give your key manually to all your friends with a QR code scan or sth
  
  source
  - lambalicious@lemmy.sdf.org ⁨2⁩ ⁨days⁩ ago
    Finally,
    
    Fediverse Keyparties
    
    (like back in the '80s)
    
    source
silverpill@mitra.social ⁨4⁩ ⁨days⁩ ago
Identity based on a pubic key is already not theoretical, it is supported by services that implement FEP-ef61.
I am not sure whether it makes sense to separate data hosting and feed generation, this will probably require a specific network architecture, similar to Bluesky, which tends to be centralized.
source
Jayjader@jlai.lu ⁨3⁩ ⁨days⁩ ago
Someone is working on something related: soatok.blog/…/announcing-key-transparency-fediver…

The rest of their blog is pretty great, too!

source
- gandalf_der_12te@discuss.tchncs.de ⁨3⁩ ⁨days⁩ ago
  that’s pretty interesting!
  
  source
Pamasich@kbin.earth ⁨4⁩ ⁨days⁩ ago
The big problem with improving how this stuff works on the fediverse is that you want to stay compatible with other software and instances running older versions of your software. In general, ActivityPub projects expect the id of an actor to be dereferenceable. They expect it to point to a valid JSON-LD document describing the actor which they can request. If you break this expected contract by using a local file as your identity, or even just a non-https URI like did:, you're going to lose intercompatibility with other instances that don't handle that.

Also, regarding your description of the three parts, I think you're misunderstanding something that I see people misunderstand often.

The identity provider basically only makes a proof that "you are you" : you give it your login credentials and it gives you a kind of token that authenticates (proves your identity) to other services. like, i'm on discuss.tchncs.de, but i can post to lemmy.world. this is because the discuss.tchncs.de server says to lemmy.world that i indeed have this account on this server. so they prove my identity in a way.

So, I might be wrong here, but I interpret you as saying basically that you're authoring posts on lemmy.world with your account provided by discuss.tchncs.de. That's not really how this works. Your data hoster is the instance you have your account on, not the one the community is on. Your instance just shares the posts you make on it with the community, but all it receives is a copy. The canonical version is on your instance, discuss.tchncs.de.

Again, data hoster and identity provider are currently the same thing. The fediverse is just a bunch of interconnected silos, you do things within your own instance and then other instances receive a copy of the thing you did. You never author things directly on another instance than your own.

The token stuff there sounds like SSO (single sign on), but it doesn't look like either of those instances support that. So not sure what you were referring to there. The public key to verify the signature maybe? That's more meant to ensure that the object is actually authored by you iirc though.

source
- gandalf_der_12te@discuss.tchncs.de ⁨4⁩ ⁨days⁩ ago
  Very interesting!
  
  I agree with your point that a user accou t without a canonical URL to send messages to could nor have an inbox, and therefore never get DMs or notifications if somebody commented on their post.
  
  I had not thought of that before but it seems obvious to me in retrospect. Obviously, to receive messages, you need some kind of machine-address, where these messages will be sent to. And that’s what this is for:
  
  They expect it to point to a valid JSON-LD document describing the actor which they can request.
  
  Because it describes the inbox address.
  
  Your data hoster is the instance you have your account on, not the one the community is on. Your instance just shares the posts you make on it with the community, but all it receives is a copy. The canonical version is on your instance, discuss.tchncs.de.
  
  That’s truly fascinating knowledge, thank you. It makes sense because in the ActivityPub protocol, each user has an outbox, and published posts go there. So of course, other communities simply reference that instead of actually holding the post.
  
  This means, then, that communities aren’t actually so much lists of posts, but lists of references to posts, i.e. when i post to /c/a@lemmy.world, that community simply gets notified about the canonical link to my post, which actually resides in my outbox on this server. Thanks for making me think about all of this!
  
  source

theoretical considerations on identity management

Comments

Fediverse Keyparties