Post AoAY5npd7WxHOqPyFs by silverpill@mitra.social
(DIR) More posts by silverpill@mitra.social
(DIR) Post #Ao99MJijdOcKvF0jQm by silverpill@mitra.social
2024-11-17T21:44:08.285493Z
1 likes, 0 repeats
FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/447The most important change here is a switch from FEP-c7d3 to FEP-fe34. An algorithm for computing origin of a DID URL has been specified, so now it is possible to do this:is_same_origin(id, proof.verificationMethod)#NomadicIdentity #fep_ef61
(DIR) Post #AoAY5mc7eGYXcf5fYu by erlend@writing.exchange
2024-11-18T00:24:13Z
0 likes, 0 repeats
@silverpill speaking of DID methods, I ran into another promising one recently: https://fedid.me/about/
(DIR) Post #AoAY5npd7WxHOqPyFs by silverpill@mitra.social
2024-11-18T13:56:22.235666Z
1 likes, 0 repeats
@erlend Looks interesting, thanks for sharing. However, it is not clear how users are protected from impersonation by servers, because initial DID document is generated there and user's signature is added later.
(DIR) Post #AoAf2JG52CRDO94Tce by sun@shitposter.world
2024-11-18T15:14:45.849266Z
1 likes, 1 repeats
@silverpill I am trying to make did:web the identity of my homebrew AP implementation where the did.json is compatible with bluesky, currently going awfully
(DIR) Post #AoAf7mhR04kM99TbpA by sun@shitposter.world
2024-11-18T15:15:45.206211Z
1 likes, 1 repeats
@silverpill I am also in the process of writing a storage server for it based on webauth and ACLs using the DID or ap actor ID
(DIR) Post #AoAhzVosAwzfL8hdjs by silverpill@mitra.social
2024-11-18T15:47:31.864593Z
0 likes, 0 repeats
@sun Do you use FEP-ef61? I just demoted did:web from a recommended method to a candidate, but can bring it back.>webauthI haven't heard about it. Did you mean webauthn?
(DIR) Post #AoAiXQfLqJwXCbQEMq by sun@shitposter.world
2024-11-18T15:54:00.182938Z
0 likes, 1 repeats
@silverpill I'm sorry I mean https://solid.github.io/web-access-control-spec/I am stealing a bunch of ideas that leverage web specs from Solid, but I don't like Solid itself.so you can go from a web DID, get the keys and use them to identify a web request using a token created by the key, and using the user's DID as an ACL for some object in the service, you can control access to it. What I was trying to solve was having all my data on a separate domain and have a standard and clear way for someone listed in the object ACL list (basically maps to the to, cc, bcc etc list on the object in most cases) to retrieve that object after the fact if it wasn't already pushed to them.
(DIR) Post #AoAiuhGQIYPNL9rCLo by sun@shitposter.world
2024-11-18T15:58:12.278129Z
0 likes, 1 repeats
@silverpill the reason I am using did:web is because I decided that offloading identity to domain resolution and ownership was an acceptable compromise between instance servers and did:key. it's not "fully decentralized" but it gives you a high degree of sovereignty while also letting you do things without the catastrophic risk of losing access to your key. Like I think did:key is great but it's too risky for a lot of purposes since you need to use the same key for identity and for object signing so every server/client you use that does things on your behalf has to have the keys to the kingdom.
(DIR) Post #AoAj4QFCQqinRyvEf2 by sun@shitposter.world
2024-11-18T15:59:57.723429Z
0 likes, 1 repeats
@silverpill I am also trying to conceptualize "identity" for activitypub inside a much larger ecosystem where a lot of things already rely on dids and did:web is a frequent choice so I feel wary about excluding it. in the future there are going to be people that have an existing did:web identity and they should be able to leverage this existing identity to directly use it with activitypub imo
(DIR) Post #AoAnMYNXKJOxhxisQi by silverpill@mitra.social
2024-11-18T16:47:45.652496Z
0 likes, 0 repeats
@sun Reliance on a domain name is not acceptable for me, so I made did:key support a requirement. But FEP-ef61 doesn't exclude did:web or any other DID method. Actually, supporting a wide range of DID methods is the second primary design goal after did:key compatibility.I can't simply say that implementers are free to choose any DID method, because that would lead to 10 non-interoperable implementations. Some methods have to be "blessed", and right now only did:key has that status. A number of other methods are under review: did:web, did:dns, did:tdw and did:fedi.If you are interested in using did:web with FEP-ef61, I will make it recommended (and that means it will be supported in Mitra).
(DIR) Post #AoAnaNANoH5uzL9yPQ by sun@shitposter.world
2024-11-18T16:50:33.714889Z
0 likes, 1 repeats
@silverpill please at least don't remove it yet, I want to have working did:web in a month and release something just so feps have something working to refer to
(DIR) Post #AoAng1a0ytYrmBqNxA by sun@shitposter.world
2024-11-18T16:51:34.837884Z
0 likes, 1 repeats
@silverpill I am trying to apply what you're doing with origin checking FEP
(DIR) Post #AoAutCWmHvgLAqYmbQ by silverpill@mitra.social
2024-11-18T18:11:34.606344Z
0 likes, 0 repeats
@sun Okay, thanks for letting me know. Just to be clear, I'm not against did:web, it can be one of the blessed methods and I'm willing to support it in Mitra. I demoted it only because I thought no one is working on it.And generally, I'm open to feedback. FEP-ef61 is a work in progress, there are unsolved problems (collections are difficult), and some parts of it will certainly change as we get more feedback from implementers. But not did:key compatibility - this part is very important for me.
(DIR) Post #AoAvjij5osBu5vMaqO by silverpill@mitra.social
2024-11-18T18:21:31.061494Z
0 likes, 0 repeats
@sun Is it like CORS for ActivityPub's origin-based security model?
(DIR) Post #AoDKGu6NKhbS9CWt04 by dmitri@social.coop
2024-11-19T21:58:42Z
1 likes, 0 repeats
@sun @silverpill my recommendation would be to look at did:tdw https://identity.foundation/trustdidweb/ (which may soon be renamed, heh). It's got some of the good features from Bluesky, and is on the way to be standardized.
(DIR) Post #AoDKSDYdKxjFfq8qrw by sun@shitposter.world
2024-11-19T22:08:16.453386Z
0 likes, 1 repeats
@dmitri @silverpill I am currently tied to did:web to maintain compatibility with existing verifiable credential implementations but this did:tdw has properties I want so I will keep paying attention to it and maybe support it in the future, thanks for bringing it to my attention!