My quick search unfortunately, did not reveal a good description of the context. It was introduced in Verifiable Credentials Data Model v2.0 . The good news is that the context allows for adding an āexpiresā term. This is important as we will want to encourage usage of ātime to liveā for ActivityPub.
@helge Iām happy to report that my implementation of jcs-eddsa-2022 cryptosuite produces the same signed document as yours!
Iām not deploying it to production though. It would be prudent to wait until workgroup fixes the vc-di-eddsa spec.
jcs-eddsa-2022 description was fixed a couple of days ago (PR). I proceeded with implementation of the algorithm and incorporated it into my software (here is the signing function). However, Iām not sure how to distribute EdDSA keys. The most logical place for them seems to be publicKey property, which can take the form of array where the first item represents RSA key and the second item represents EdDSA key. But servers may expect publicKey to be an object and fail to process an array, making gradual upgrade impossible. So we need to either use some new property (authentication?) or keep RSA as the recommended signature algorithm.
I donāt see any disadvantages in this approach compared to using a āpublicKeyā property or similar. I see some advantages in this approach, thatās why the above fep discusses it.
I think this conflicts with the usage of alsoKnownAs property in the Fediverse (things controlled by the same entity). As I pointed out in another thread, there are two possible meanings of the word āaliasā, and I think we should not conflate them. If alsoKnowAs is used to describe things controlled by the same entity, aliases should be used to describe different identifiers of the same thing. The definition of xrd:Alias seems to support this:
The <Alias> element does not identify additional resources the XRD is describing, but rather provides additional identifiers for the same resource.
acct:ben@chatty.social and did:key:z6MkekwC6R9bj9ErToB7AiZJfyCSDhaZe1UxhDbCqJrhqpS5 are not additional identifiers of the same resource. The first one points to AP actor, the second one to DID document. Therefore, alsoKnownAs would be more appropriate here.
Or we can flip these properties and use aliases to describe different things controlled by the same entity. This would conflict with the usage of alsoKnownAs property but coincide with the usage of āAliasā in Mastodon documentation.
In the context of FEP-8b32, however, I would prefer to use different property. Maybe even Multikey attachment
One should explain the distinction between an identifier and a public key. This is not a technical distinction (both can be considered as points on Curve 25519) but a distinction of purpose.
An Identifier identifies an actor
A Public Key is used by the actor to prove he did something, i.e. by signing it. (Awful sentence)
There are more key types see
Given their use, one can rotate public keys quite frequently. For example, I could issue a new public key every week with a 2 week expiry. Once the public key is expired, I publish the private key. This means that signatures donāt make it impossible to delete objects.
Iām unsure if I like the name āMultiKeyā. āMultiā might be taken to mean āmultipurposeā instead of being a format. It might be better to specify the use as āSigningKeyā. Maybe, one can invent a naming scheme that also covers fep-c390 and uses such as
@codenamedmitriproposed to use properties like authentication, keyAgreement etc to make the purpose of the key clear. I support this.
FEP-521a allows actor to have multiple keys, so you can add a new key without removing the expired one (just mark it as āexpiredā somehow).
I took it from āEdDSA Cryptosuite v2022ā document. Thereās a warning about moving it to Data Integrity spec, so we can expect it to become standard. If we replace attachment with authentication, the ambiguity will disappear.
Thereās no dedicated topic for it, so Iāll list possible improvements here:
Extend the scope of proposal to cover all types of verification relationships: authentication, assertion, key agreement, capability invocation, capability delegation.
Iāve already implemented FEP-521a and the latest version of FEP-8b32. My actor https://mitra.social/users/silverpill contains both RSA and Ed25519 keys, represented as Multikey verification methods. Outgoing activities are still signed with RSA key, but I can enable jcs-eddsa-2022 to perform federation tests at any time.
I want to add test vectors for FEP-8b32, but I am not sure how to do it. Gherkin syntax looks nice. It is human readable, and it is definitely better than plain JSON files. However, I think it would be better to put test vectors alongside the FEP, and not in a separate repo.
My current plan is to locate all my Gherkin features in that repository. This includes both FEP and ones that test other aspects of the Fediverse.
I have no idea if different repositories for features and docs are a good split. As having a features repository already means that I split code and tests, it doesnāt seem like a big deal to me.
I probably wonāt have a firm opinion on what a good structure looks like in the next few weeks.
After updating ājson-eddsa-2022ā to ājcs-eddsa-2022ā my tests pass with the new feature.
I just realized Gherkin might not be as well-known as I expected. Have you integrated something like cucumber-rs into Mitra to run this test?
The essential point for me to use Gherkin is that the feature files can be shared across implementations. So in an ideal world, everybody runs the same tests [1]. This will lead to greater interoperability, simply by eliminating one of the points where applications can diverge. I consider Gherkin tests a technical implementation of what @aschrijver calls ācommon substrateā.
[1]: Various unimportant caveats apply, e.g. every implementation needs to define steps.