Conversation

Notices

1. silverpill (silverpill@mitra.social)'s status on Monday, 18-Nov-2024 06:46:17 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

   • silverpill (silverpill@mitra.social)'s status on Monday, 18-Nov-2024 22:58:04 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.

   • Erlend Sogge Heggen (erlend@writing.exchange)'s status on Monday, 18-Nov-2024 22:58:05 JST Erlend Sogge Heggen

     in reply to

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

   • silverpill (silverpill@mitra.social)'s status on Monday, 18-Nov-2024 23:02:22 JST silverpill

     in reply to

     • Giac El Vecio
     • elvecio
     • El veciet emergency
     • el tenso

     @eltenso

     Yes, but I've seen error messages about the certificate, so it could be a one-way federation

     cc @giacelvecio @elvecio @elvecietemergency

   • el tenso (eltenso@unio.diversispiritus.net.br)'s status on Monday, 18-Nov-2024 23:02:28 JST el tenso

     in reply to
     Can you see my comment from my clone?
   • Angry Sun (sun@shitposter.world)'s status on Tuesday, 19-Nov-2024 00:49:06 JST Angry Sun

     in reply to

     • Angry Sun
     @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
   • silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Nov-2024 00:49:06 JST silverpill

     in reply to

     • Angry Sun

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

   • Angry Sun (sun@shitposter.world)'s status on Tuesday, 19-Nov-2024 00:49:07 JST Angry Sun

     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
   • silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Nov-2024 01:29:57 JST silverpill

     in reply to

     • elvecio

     @elvecio The certificate returned by your server is for aprendendofisica.net, not for unio.diversispiritus.net.br, and apparently this is because my HTTP client doesn't properly do SNI. I'll try to fix that

   • elvecio (elvecio@wizard.casa)'s status on Tuesday, 19-Nov-2024 01:29:58 JST elvecio

     in reply to

     @silverpill the certificate is ok, maybe cleaning some cache?

   • Angry Sun (sun@shitposter.world)'s status on Tuesday, 19-Nov-2024 01:49:11 JST Angry Sun

     in reply to

     • Angry Sun
     @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
   • silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Nov-2024 01:49:11 JST silverpill

     in reply to

     • Angry Sun

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

   • Angry Sun (sun@shitposter.world)'s status on Tuesday, 19-Nov-2024 01:49:12 JST Angry Sun

     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.
   • Angry Sun (sun@shitposter.world)'s status on Tuesday, 19-Nov-2024 01:49:12 JST Angry Sun

     in reply to

     • Angry Sun
     @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.
   • silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Nov-2024 03:13:35 JST silverpill

     in reply to

     • Angry Sun

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

   • Angry Sun (sun@shitposter.world)'s status on Tuesday, 19-Nov-2024 03:13:36 JST Angry Sun

     in reply to

     • Angry Sun
     @silverpill I am trying to apply what you're doing with origin checking FEP
   • Angry Sun (sun@shitposter.world)'s status on Tuesday, 19-Nov-2024 03:13:37 JST Angry Sun

     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
   • silverpill (silverpill@mitra.social)'s status on Tuesday, 19-Nov-2024 03:22:56 JST silverpill

     in reply to

     • Angry Sun

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

   • silverpill (silverpill@mitra.social)'s status on Thursday, 21-Nov-2024 01:55:41 JST silverpill

     in reply to

     • elvecio

     @elvecio This is probably a bug in one of the libraries I'm using. I will try to update to a newer version, but that will take some time