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.
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.
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.)
@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.
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.
I don’t think Mastodon would adopt it until UX issues are resolved. I see 3 possible ways to improve the situation:
Use did:key and develop a browser extension that will manage private keys.
Use 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).
So this corresponds to @firstname.lastname@example.org having migrated to @email@example.com. If abel updates the webfinger entry to return the actor on banach, it is clear that this would be a two way verification.
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.
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.