Conversation

Notices

1. Embed this notice
   silverpill (silverpill@mitra.social)'s status on Monday, 18-Nov-2024 06:45:12 JST silverpill

   FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/447

   The 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

   • Fish of Rage likes this.
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Monday, 18-Nov-2024 22:56:59 JST silverpill

     in reply to

     • Erlend Sogge Heggen

     @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.

   • Embed this notice
     Erlend Sogge Heggen (erlend@writing.exchange)'s status on Monday, 18-Nov-2024 22:57:00 JST Erlend Sogge Heggen

     in reply to

     @silverpill speaking of DID methods, I ran into another promising one recently: https://fedid.me/about/

   • Embed this notice
     Fish of Rage (sun@shitposter.world)'s status on Tuesday, 19-Nov-2024 00:14:47 JST Fish of Rage

     in reply to
     @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
   • Embed this notice
     Fish of Rage (sun@shitposter.world)'s status on Tuesday, 19-Nov-2024 00:15:46 JST Fish of Rage

     in reply to

     • Fish of Rage
     @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
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Nov-2024 00:47:57 JST silverpill

     in reply to

     • Fish of Rage

     @sun Do you use FEP-ef61? I just demoted did:web from a recommended method to a candidate, but can bring it back.

     >webauth

     I haven't heard about it. Did you mean webauthn?

   • Embed this notice
     Fish of Rage (sun@shitposter.world)'s status on Tuesday, 19-Nov-2024 00:54:02 JST Fish of Rage

     in reply to
     @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.
   • Embed this notice
     Fish of Rage (sun@shitposter.world)'s status on Tuesday, 19-Nov-2024 00:58:14 JST Fish of Rage

     in reply to

     • Fish of Rage
     @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.
   • Embed this notice
     Fish of Rage (sun@shitposter.world)'s status on Tuesday, 19-Nov-2024 00:59:59 JST Fish of Rage

     in reply to

     • Fish of Rage
     @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
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Nov-2024 01:48:06 JST silverpill

     in reply to

     • Fish of Rage

     @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).

   • Embed this notice
     Fish of Rage (sun@shitposter.world)'s status on Tuesday, 19-Nov-2024 01:50:34 JST Fish of Rage

     in reply to
     @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
   • Embed this notice
     Fish of Rage (sun@shitposter.world)'s status on Tuesday, 19-Nov-2024 01:51:36 JST Fish of Rage

     in reply to

     • Fish of Rage
     @silverpill I am trying to apply what you're doing with origin checking FEP
   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Nov-2024 03:12:27 JST silverpill

     in reply to

     • Fish of Rage

     @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.

   • Embed this notice
     silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Nov-2024 03:21:55 JST silverpill

     in reply to

     • Fish of Rage

     @sun Is it like CORS for ActivityPub's origin-based security model?

   • Embed this notice
     Dmitri | 🇺🇦 (dmitri@social.coop)'s status on Wednesday, 20-Nov-2024 07:06:14 JST Dmitri | 🇺🇦

     in reply to

     • Fish of Rage

     @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.

     Fish of Rage likes this.
   • Embed this notice
     Fish of Rage (sun@shitposter.world)'s status on Wednesday, 20-Nov-2024 07:08:18 JST Fish of Rage

     in reply to

     • Dmitri | 🇺🇦
     @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!