FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/447
-
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) -
@silverpill speaking of DID methods, I ran into another promising one recently: https://fedid.me/about/
-
@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.
-
Yes, but I've seen error messages about the certificate, so it could be a one-way federation
-
@silverpill the certificate is ok, maybe cleaning some cache?
-
@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 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
-
@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?
-
@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. -
@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 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
-
@elvecio The certificate returned by your server is for
aprendendofisica.net, not forunio.diversispiritus.net.br, and apparently this is because my HTTP client doesn't properly do SNI. I'll try to fix that -
@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).
-
@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 I am trying to apply what you're doing with origin checking FEP
-
@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. -
@sun Is it like CORS for ActivityPub's origin-based security model?
-
@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
