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.)
@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.
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.
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 @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
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.
Added a warning about eddsa-jcs-2022 stability and removed the .feature file because it was not correct (at the time of writing the context injection issue remains unresolved).
looks fine, only thing i’d consider is adding a formal definition for VerifiableIdentityStatement either in a sidecar asset (as the IRI implies) or in the FEP itself (and in such case i’d consider using a fragment id instead of a subpath)
there is an example in 888d of SomeType being defined in fep/fep/888d/SomeType at main - fediverse/fep - Codeberg.org a la http://schema.org/SomeType style definition pages (although i left it as a plaintext file because i didn’t want to bother working out HTML conneg just yet)
I’m currently thinking through what the first version of this might look like in the Discourse ActivityPub plugin. The initial goal for the end-user experience here is
Allow a Discourse user to claim another Discourse user associated with an ActivityPub Actor
This is what happens in the plugin currently
Individual A (i.e. the actual person) uses User A to make a post on Discourse A.
Post A is published as Object A (i.e. Note or Article) attributed to Actor A, associated with User A on Discourse A.
Discourse B receives Object A, and creates User B for Actor A and Post B for Object A.
To achieve the initial goal the following will need to happen
Individual A also controls User C on Discourse B.
User C proves ownership of Actor A by Individual A authenticating User A on Discourse A as User C.
I appreciate that the initial goal can be achieved using standard authentication mechanisms (i.e without identity proofs). What I’m interested in is potentially laying the groundwork for supporting identify verification in a non-Discourse specific way, i.e. so that Individual A could also claim Actor A on other services. This is what I’m currently thinking might be possible to lay that groundwork
Individual A enters the handle of Actor A in the UI
The plugin retrieves Actor A from Discourse A via Webfinger.
Actor A includes a VerifiableIdentityStatement as an attachment with
A DID (in the basic did:key format) generated and managed by Discourse A.
Discourse B presents Actor A’s VerifiableIdentityStatement to Discourse B using the service endpoint.
Discourse A verifies the presentation.
if the presentation is verified, Discourse A asks Individual A to authenticate as User A.
Upon successful verification and authentication, Discourse A returns a verified claim to Discourse B.
Upon receipt of a verified claim, Discourse B allows User C to claim User B.
A version of that could potentially achieve my immediate goal, while also allowing for FEP-c390 support. I appreciate this initial version is imperfect and not decentralized . The goal is not to achieve perfection, but to achieve the immediate goal while building the right structure.
What claiming of a user means for an individual? Is it just a pointer to another account, or you’re planning to add more functionality that will depend on this mechanism?
