FEP-ef61 update: https://codeberg.org/fediverse/fep/pulls/447
-
@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
-
