I think that I don’t have a technical issue, but a usability one. I was scanning the did-core closed issues and found the following:
Because developers will end up doing horrible things if we put a bucket called encryption in the DID Document… where they will store their symmetric encryption keys and dump them to a ledger, pwn’ing data that they encrypt using that same key.
This is to say, I don’t know what exactly a good answer to is
However, I can describe my personal non-expert opinion. Key pairs will will have at least three duties:
A user “Alice”, i.e. a physical human being, holds a EdDSA private key and uses a did document attached to the actor “@Alice” to indicate: “Yes, this is Alice’s account”.
The server the Actor @Alice is on, holds a EdDSA private key and uses a did document attached to the actor for
2.1. Yes, this key identifies the Actor @Alice
2.2. Authenticate communications with other servers.
The user Alice holds a private RSA key, and attaches it to the actor @Alice. Now, Bob can encrypt a message using the public key, and send it to @Alice via @Bob without the servers in the middle being able to read the message.
I would be less confused by the three attached keys to an account and their usage if they had dedicated types. Also one might want to consider easier to use short hands for the keys, e.g. refer to the key in 2 as “@Alice’s id#serverPublicKey”.
I’m no expert on cryptography or attack vectors on public/private key infrastructure. One should probably ask one, before deciding to propose something akin to the above.
Additional thought. I might want to automatically rotate the key in 2. This has all kinds of consequences for using it for signing documents. I’m not comfortable enough on the subject to draft a best practice on how to do this.
Identity document is actually a trimmed down verifiable credential. At the moment I don’t want to complicate FEP-c390 further by adding credentialSubject and issuanceDate properties required by VC spec. However, in the next edition of FEP-c390 I’m going to drop this line:
The document MUST not contain any additional properties.
i don’t think mastodon plans to reimplement identity proofs, so it might be okay to consider? or otherwise, you could define the same term in a different namespace.
unfortunately i don’t yet know enough to comment further.
i am inclined to say you could either reuse alsoKnownAs or perhaps eliminate its usage entirely depending on how you structure this “identity proof” node. but again, i don’t yet know enough to comment further.
Upon reading it, I think, we do not want to use JcsEd25519Signature2020 as
Base58 encode the result and set it as the signatureValue on the document
seems bad. I would prefer to use Multibase to encode the signatureValue, i.e. do exactly the same but add a z at the beginning. This makes the entire thing less ambiguous. This would lead to the algorithm
Take the input document, i.e. the subobject of type LinkedIdentityProof without adding a @context property, embeded with a proof block containing all values except the signatureValue
Canonicalize the document using JCS
Apply the SHA-256 Hash Algorithm.
Sign the result with the private key
Multibase encode the result and set it as the signatureValue on the document
i’m in the process of writing up a more fleshed-out version of / alternative to 2e40, and i may withdraw cb76 if no interest (or otherwise rework it, idk)
currently the “best” way is to use your own domain, but 2e40 or my rewrite would propose using w3id.org/fep to point toward the fediverse/fep repo on codeberg (although the documentation host can be swapped later). where my rewrite differs is mainly in making each fep self-contained instead of having a “common” context that is prone to write conflicts.
the more cb76 route (using a urn) would involve urn:publicid:fep:xxxx:term or urn:sha256:… as currently described. this is not “wrong” per se but it is not favoured among the w3c/jsonld/rdf people, who tend to prefer http(s) uris over urns for ideological reasons (and some practical onces, albeit imo shortsighted)
The disagreement is about how to store the information afterwards. I’m not 100% certain how @trwnh envisions his solution, so I asked him to work out the details. I’m probably still too stuck in my thinking to see it (or judge if it can be better).
The basic result should be hopefully the same, use:
then json-ld magic, then all ActivityStreams 2.0 + FEP terms available.
What do you mean by “redundant”? I really cannot place how it relates to the discussion here.
My personal opinion is that it is too hard to create @context terms at the moment. Otherwise, we would not have the mess of Mastodon abusing summary as a content warning. If Mastodon at least used the name property, the usage of content warnings of titles, would reflect my interpretation of what the property does according to ActivityStreams.