I’ve just learnt in this github issue that the name jcs-eddsa-2022 is not fixed. Given the result of my non scientific poll on matrix that about half people don’t know what jcs is, I think that json-eddsa-2022 will actually be the clearer name.
Opinions?
I would prefer a more descriptive name. And if people don’t know about JCS, that’s one more reason to use jcs- prefix because this algorithm needs promotion. As far as I know, there are still no implementations in Ruby, Elixir, C and PHP, so Mastodon, Pleroma and Pixelfed probably won’t support FEP-8b32 or FEP-c390 for a long time.
Well, RUBY might be OK thanks to Gregg from the JSON-LD group but I think the rest of this list is still out of luck:
Oh, nice. Mastodon already supports Linked Data signatures, and they might consider adopting FEP-8b32 now.
I am writing Elixir code that uses the JSON Canonical Scheme and the (maybe experimental) jcs-eddsa-2022 cryptosuite to support this FEP. Here is what I am assuming or need clarification on:
The proof document and proof configuration are built only on the single JSON sub-object in the attachment property values that has the “VerifiableIdentityStatement” type.
Before canonicalization, I add the top-level “@context” to the VerifiableIdentityStatement sub-object (without which it might not be a valid JSON-LD object).
Are these correct assumptions? My code is trying to respect the W3C Verifiable Credential Data Integrity 1.0 algorithms
Yes, the identity proof object is self-contained. Clients should be able to verify it without relying on the server.
I think if you do JCS transformation, this is not needed. But I could be wrong.
I think adding the (see below)@context is needed, even with JCS.
Why?
The Data Integrity spec provides an example of a signed JSON object: Verifiable Credential Data Integrity 1.0. The @context property is not used there. Also, other attachments are not required to have @context.
If some applications need @context, they can add it. The FEP allows this:
The document MAY contain additional properties.
(The first post in this topic contained an outdated version of this proposal, where additional properties were not allowed. I’ve replaced outdated text with a short summary.)
::facepalms: Nope, you are correct, my mistake 
No @context is needed when using JCS.
@silverpill I looked at this (and made a tentative internal proposal to adopt this) for the Discourse Activity Pub plugin. We didn’t include anything along these lines in Phase 2 of work on that plugin, however it may be possible at some point.
I should be clear that CDCK (Discourse.org) hasn’t endorsed any version of this for their plugin, the Discourse Activity Pub Plugin, yet, however in my own, personal, view (as the current developer of the plugin), I think adding support may be feasible down the line a bit.
Where can I see your implementation? Is there any reference implementation in Ruby?
Also, is anyone here familiar with the folks involved in Mastodon and/or have a real (i.e. not just speculation) sense of the likelihood of adoption of the same in Mastodon? Mastodon adoption, at least in principle, would obviously be an advantage in advocating for adoption of this in Discourse’s plugin.
Parts of my implementation in Rust can be found here: https://codeberg.org/silverpill/mitra/src/commit/a145afcee174b25e7ec3f517e904ea6c9dd169fe/src/json_signatures/verify.rs. It is still being worked on.
At the moment my ActivityPub server Mitra supports two types of identity proofs:
did:key + Minisign signatures. This requires Minisign command line tool.did:pkh + EIP-191 signatures. This type of signature requires an Ethereum cryptocurrency wallet.These kinds of proofs are not suitable for an average user. Moreover, the cryptosuites being used are non-standard, there are no official specifications for them. I found a way to generate jcs-eddsa-2022 proof using Minisign, but haven’t implemented it yet. Still, it requires a command line tool, so it is only suitable for power users.
Probably not. However, there’s now an implementation of JCS in Ruby: GitHub - dryruby/json-canonicalization: An implementation of the JSON Canonicalization Scheme for Ruby (it is required for jcs-eddsa-2022).
I don’t think Mastodon would adopt it until UX issues are resolved. I see 3 possible ways to improve the situation:
did:key and develop a browser extension that will manage private keys.did:key but do not require any browser extensions or other apps. Store encrypted private key on a server, decrypt on a client side, ask user to make a backup (afaik matrix is doing something similar).did:web. Keys are managed by 3rd party.I have a “crazy idea”. Consider the following type of identity proof:
{
"type": "VerifiableIdentityStatement",
"subject": "acct:bob@abel.example",
"alsoKnownAs": "https://banach.example/users/bob"
}
So this corresponds to @bob@abel.example having migrated to @bob@banach.example. If abel updates the webfinger entry to return the actor on banach, it is clear that this would be a two way verification.
I think proof is supposed to represent some kind of cryptographic signature. If you don’t need a signature, then alsoKnownAs property is probably all you need
+1 to what silverpill said.
I’ve updated the post by removing proof. It’s probably less confusing this way than me just saying it’s good to not use the proof value. I’m also aware that this is kind of out of scope of FEP-c390 as subject is required to be a did there.
Anyway, thinking about this, I have one more naming comment: Would VerifiableIdentifier be a better name for the type? The advantage is that subject is an identifier that can be verified, either through the proof, or as in the case I wrote above by making a webfinger lookup.
I’m not quite happy with VerifiableIdentityStatement type, but I don’t think VerifiableIdentifier is better. FEP-c390 identity proof establishes a link between the subject and the actor specified by alsoKnownAs property. We’re not verifying the identifier, but a relationship between two identifiers. For this very reason I discarded the Identity type, which was used in earlier FEP-c390 drafts.
VC workgroup changed the name of cryptosuite from jcs-eddsa-2022 to eddsa-jcs-2022. The FEP has been updated accordingly. I also added some minor clarifications and implementation notes.
@helge I just discovered that subject property is already defined in ActivityStreams vocabulary: Activity Vocabulary, so we probably should’t re-define it?
ActivityStreams vocabulary also contains Relationship type:
Describes a relationship between two individuals
Perhaps VerifiableIdentityStatement should be defined as a sub-type of Relationship? In some sense it is a relationship: not between individuals though, but between different IDs belonging to the same individual.
To align this FEP with FEP-888d, I’m going to update c390/context.jsonld file with:
{
"@context": {
"VerifiableIdentityStatement": "https://w3id.org/fep/c390/VerifiableIdentityStatement",
"subject": {
"@id": "https://www.w3.org/ns/activitystreams#subject",
"@type": "@id"
},
"alsoKnownAs": {
"@id": "https://www.w3.org/ns/activitystreams#alsoKnownAs",
"@type": "@id"
}
}
}
@trwnh Is it correct context document?