FEP-c390: Identity Proofs

Standards Fediverse Enhancement Proposals
, ,
41

Just in the system reliability sense, one url can be a single point of failure so I wondered if having another makes any sense and it seems not to.

1 Like
42

@context is the kind of thing where having it resolve is merely a convenience. the only time it matters is if it is referenced for inclusion and you don’t already have a cached copy of it. in such a case, being able to resolve it directly means you don’t have to go track it down and download it from elsewhere.

43

FEP-c390 has been updated:

2 Likes
44

I did an example via my vc-di-eddsa implementation: vc-di-eddsa-python/test_fep_c390.py at main - vc-di-eddsa-python - Codeberg.org

I think the definition of json-eddsa-2022 might still be a bit off, see Is Example 15 / 16 correct? · Issue #38 · w3c/vc-di-eddsa · GitHub

2 Likes
45

I was just clicking through the json-ld playground and stumbled onto

Not sure what I think yet, just thought I’ll share it. It seems to be from the W3C Verified Credentials Working Group. It doesn’t look updated to vc-eddsa yet.

2 Likes
46

Yeah, definitely take a look at it! (And let me know if you have any questions - I did a lot of work on CHAPI).

Re vc-eddsa – so CHAPI itself is just a “dumb pipe”, so if you ask for an eddsa type credential, a wallet that supports it can provide it.

1 Like
47

I’ve noticed several issues with Verifiable Credentials currently and have raised two concerns in the repository today.

In ActivityPub, we have a non-normative vocabulary and a normative context, while today’s discussion in the VC group mentioned a non-normative context and a normative vocabulary.

It is crucial to adhere to established standards unless there is a valid reason to deviate. Straying from these standards in the past seven years has led to problems within the Fediverse.

I suggest that we follow the standards and only diverge from them when we can justify the deviation with specific needs. Unfortunately, in the past, decisions were sometimes made by those not well-versed in the issues, resulting in unnecessary overhead without reaping the benefits.

48

Good. I think mine and @silverpill’s attitude is currently “tracking”. The relevant (to the Fediverse) specifications are not done, but they are getting there.

Second, the editors are responsive :+1: So it’s worthwhile to invest time to see if any issues are to be expected when using the specs for the Fediverse.

One should also note here that standards coming with test cases and test suites are much easier to adhere to than standards without. The current problem is there are no incentives to make the Fediverse testable.

5 Likes
49

I made several corrections to FEP-c390: feps/fep-c390.md at main - feps - Codeberg.org (diff).

Also, I finished my implementation of this proposal. The next step is improving usability and security of account migration process based on FEP-c390. It would be also interesting to experiment with client-side activity signing (AP C2S + FEP-8b32 + FEP-c390).

1 Like
50

I’ll have a suggestion regarding the content of the @context property, hopefully sometime in the next few days.

1 Like
51

First, regarding the example in FEP-c390. You should probably update the proof to use DataIntegrity, e.g.

{
  "@context": [
    "https://raw.codeberg.page/helge/fediverse-vocabulary/output/vocabulary.json",
    "https://www.w3.org/ns/did/v1",
    "https://w3id.org/security/data-integrity/v1"
  ],
  "id": "https://example.com/users/alice",
  "type": "Person",
  "inbox": "https://example.com/users/alice/inbox",
  "attachment": {
    "type": "VerifiableIdentityStatement",
    "subject": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
    "proof": {
      "type": "DataIntegrityProof",
      "created": "2022-11-12T00:00:00Z",
      "cryptosuite": "jcs-rsa-2022",
      "proofPurpose": "assertionMethod",
      "proofValue": "...",
      "verificationMethod": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK"
    },
    "alsoKnownAs": "https://example.com/users/alice"
  }
}

Two additional comments:

  • verificationMethod is now the did. Does this align with your intentions with FEP-8b32? This seems to be what you are doing on mitra.social.
  • I would suggest the definition:
            "subject": {
                "@id": "fep:subject",
                "@type": "xsd:anyURI"
            }

for subject. This has the advantage of not allowing subject to be a set.

52

The latest draft has DataIntegrityProof in the example: feps/fep-c390.md at main - feps - Codeberg.org. I haven’t submitted it to the FEP repo yet.

Yes, “Proof generation” section of FEP-8b32 contains this sentence:

The value of verificationMethod attribute SHOULD be an URL of actor’s public key or a DID associated with an actor.

This means users can sign objects with their own keys. There’s no reference to FEP-c390 because there might be other ways to associate DID with an actor (even actor ID could be a DID).

Sounds good. I’ll create a context file for this FEP.

53

Added context: feps/context.jsonld at main - feps - Codeberg.org

54

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?

1 Like
55

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.

1 Like
56

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:

2 Likes
57

Oh, nice. Mastodon already supports Linked Data signatures, and they might consider adopting FEP-8b32 now.

58

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:

  1. 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.

  2. 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

1 Like
59

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.

1 Like
60

I think adding the @context is needed, even with JCS. (see below)