Should one be able to publish a portable object that is repudiable? IIUC, FEP-ef61 portable objects (identified by ‘ap’ URIs) require FEP-8b32 integrity proofs, so they are non-repudiable. On the other hand, FEP-c390 identity proofs establishes links between DIDs and HTTP(S) actors, but they don’t make objects portable. So that seems to be not possible with current proposals.
I’m curious because there are cases where one doesn’t want non-repudiation. For example, you don’t want your private message to be disclosed by the recipient in a publicly verifiable way. But that does not necessarily mean that you don’t want the object to be portable.
this could work but only if the rotation was a “blind rotation”, i.e. without a verifiable log of the old key being associated with the identity. if there is a log of the key rotation, then no.
more pressingly, if the key is your identity, then it cannot be rotated without also fundamentally changing your identity. so key rotation with repudiation requires a non-key identity – in other words, a name (and authoritative name server) or description (and a way of asserting trusted claims that match the description).
from what i understood of the paper, it seems this is just delegating signatures to some authority who can sign things on your behalf. you can then claim the authority forged signatures on your behalf. it’s basically like how fedi uses custodial keys in most cases.
The core idea is replacing HTTP(S) URIs with server-independent identifiers: ap:// URIs that use a Decentralized Identifier (DID) as the authority component, rather than a domain name. An object identified as ap://did:key:z6Mk…/actor can live on multiple servers simultaneously and survives any single server disappearing.
I’m new to this proposal and trying to wrap my head around some of the design choices.
I’m part of a project where we’re planning to implement proper DID-based identities, so this discussion is very relevant for us. There are a few things I’m not quite understanding yet:
1. Why split a user’s activities across several servers?
From an implementation perspective this seems to add quite a bit of complexity. What’s the practical benefit of distributing objects across multiple gateways instead of just having a single hosting server?
2. Which server is authoritative?
If multiple servers can host or serve the same actor or objects, how do other servers know which version is the canonical one if something differs?
3. Why not just point the DID to the user’s current server?
If the goal is portability, it seems like the DID document could simply reference the current hosting server, and when the user migrates the DID document updates to the new one. What problem does the multi-gateway model solve that this simpler approach doesn’t?
Would appreciate any clarification from folks who’ve worked through the tradeoffs here.
This is for redundancy. If one server suddenly goes offline, you can continue posting from another server. Having accounts on multiple servers is not a requirement, though.
The final authority is a client that holds signing keys (which may be integrated into a server).
Among the servers where actor is cloned, the primary gateway is a bit more important than the others. It is the first item in actor’s gateways array.
Not all DID documents can contain arbitrary data. did:key documents can’t.
The ability to use multiple gateways seems to be orthogonal to that, though. You can use a single server and add a reference to it to the DID document (in addition to actor’s gateways), that would still be a compliant implementation.
I’m currently working on a new DID method based on IPFS/IPNS. It doesn’t rely on blockchains or centralized infrastructure like DNS or PLC, and the DID document itself is stored in IPFS.
Reading your answers made me wonder if the architecture in this FEP is partly driven by the fact that it uses did:key.
In other words, if you had a DID method where the DID document can contain arbitrary data (for example service endpoints or the current hosting server), would you still go with the same multi-gateway architecture?
Or would the design look different if the DID document itself could point to the actor’s current server?
The proposed design is indeed significantly influenced by did:key compatibility requirements, but not the multi-gateway part.
Multi-homing was a feature of FEP-ef61 predecessors, Zot and Nomad protocols. My goal was to replicate the strengths of those protocols in ActivityPub.
did:key identities are long-living, so I think FEP-ef61 should offer an option compatible with post-quantum signatures, in addition to Ed25519 which is currently recommended.
I’ve read the current state of this FEP (but not the discussion in this thread) and I have some fundamental questions:
Apart from adding a static fallback to the list of servers that can reply to a message, is there anything else this provides us? What happens once the gateways that are listed go offline?
Why can’t we just add a list of alternative providers to the AP object and call it a day? It seem equivalent to me, but with vastly less complexity involved.
If I understand this correctly, this FEP transitively adds:
Object Signing
which adds json normalization via JWK and a whole host of abstract cryptography standards that need to be supported
multihashes
all of the (very abstract and pretty unhelpfully generic imo) DID spec
probably a few more that I haven’t had the energy to figure out
While solving the problem of “Actor go away” at most superficially. Am I wrong? Why am I wrong?
Most of this is already present in FEP-8b32, which is going to be widely implemented anyway, because it is the only viable replacement for outdated Linked Data signatures.
From DID spec we take did: URIs and DID documents, and ignore the unhelpful stuff (resolvers, services, …).
FEP-ef61 solves the problem completely and has several independent implementations. Throughout the years, a lot of people tried to solve the problem differently, but failed to do so even with much weaker designs.
No it does not! Can you explain why you say that? I’ve read it and there is no such solution to the best of my knowledge.
How? I don’t think that is true.
Which does not mean it’s a good idea in the first place! Just that a different FEP (which you yourself authored as well!) also includes these horrifying deps.
This is exactly what I’m criticizing, huge specs with hundreds of pages and incredible complexity that we implementors have to fully understand before we can filter them down to what is actually required by the FEPs. But we still need to understad all of the genericness and unnecessary conceptual indirection
tl;dr: authentication of a portable object does not require trusting a server, it can even be performed offline. It doesn’t matter what server currently serves an object.
You don’t need to read or understand these specs fully, only the parts that the FEP refers to.
These parts could be copied to FEP-ef61 to make the document more self-contained but I don’t think it is worth the effort.
Okay, then sorry to say, but the FEP is not understandable in its current form. I have read it and I could not figure this out.
If objects self-authenticate, what do we need gateways for?
You have not answered my question what would happen if the gateways go away. Well you asserted that “if the gateways go away you can move them”, but the gateways are embedded in the objects that are signed by your key and served by random gateways, so you have 0 control over them after your release them in the wild! How would you change their gateways?
~~~
Meta-comment: I am slightly worried that I’m asking questions about the document here and the only answer I get is “read the document, harder”.
Honestly, I’m having the same feeling as @profpatsch3. This proposal focuses too much on implementation instead of the actual problem.
The FEP-ef61 reads like, “Just switch to another gateway when the master dies,” until you realize the secret proving the actor’s identity was stored on the master gateway
Sure, you could distribute the secret to every gateway, but then either the master has to replicate it everywhere, or you have to register with every gateway yourself.
At that point, why not just use a domain pointing to a VPS? If the server dies, restore the backup on a new VPS and update the DNS. No distribution, no redundant data. Isn’t that simpler, or am I missing something?
EDIT: I think the gateway concept in this FEP might mislead the discussion easily.
Not sure what you mean. What is the actual problem here?
It does not need to be stored on a gateway. There are three options:
The secret is stored on a gateway. This is the least interesting option, but it is still an improvement over status quo because your identity doesn’t change in the event of migration to a different domain. You can also create clones on different gateways for redundancy.
Delegated signing: activities are generated by a gateway, but the secret is stored by a different service, which receives unsigned activities from the gateway and sends signed activities back for delivery.
Client-side signing: activities are generated and signed by a client, which communicates with gateways via FEP-ae97 API.
Key management is not within the scope of FEP-ef61, but I’ll probably add a section explaining these three options in order to prevent misinterpretations.
