Embedded proof in claim

Could we embed our proof in our claim record, please/perhaps?

Right now we have these Proof URL / claimUri's, that require verification to hit some external server to retrieve the proof. I don't see what value there is to having this hosted on external services. It would be more elegant in that someone can just see your record, and, without any internet, see: oh, yeah, this key signing checks out, this person owns this. This would be a crucial win for Local First software for example!

status quo

Currently we upload a proof.txt.asc to a gist etc that has to stay up to be useful/verifiable, and usually requiring online sign in to some service to upload. Verification requires reaching out across the internet to retrieve the record, to verify the record is true, that the data matches.

embedded

There's different ways to tackle this. I'd prefer writing individual fields into the claim record, then creating a bidirectional mapping/bijection between the fields and the proof text. Lower-fi would be to just make a proofText field that directly records the full text from above, but this makes it less useful data. I propose the following optional fields for embedded proofs:

• add a claimPublicKey field for the public key entirely (significant security upgrade over just signing the signature. related: #40)
• add a claimDid
• add a selfAttestation (sigs is already taken by keytrace/the attester)
• claimUri made optional.

flow

The flow is as follows:

• The user would go to keytrace.dev, add a self-signed PGP claim
• User is logged in so we have their claimDid
• User copies in their claimPublicKey in to a field (again, see #40)
• We have user mint a signature for this*, and have a text box for the resulting signature as an input field:

  Verifying my PGP key on keytrace
  
  did: did:plc:dabad00
  

  • note: we don't need to include the public key or signature in the proof text, because we have the public key in the record, and the signature will indicate that indeed the signature corresponds to the record's public key, or validation will fail. adding the public key in to the proof text is verbose & doesn't add real verification.
• we mint record with all fields

bonus

I think this puts us in a great position for #2 alsoKnownAs too.

We just record the alsoKnownAs in order in the record, and again create a bidirectional in-order mapping from the alsoKnownAs to the proof text. We also need to verify that each AKA exists, I believe too, but that's more a matter for that ticket.

No implementation files or tests are named. Start by reviewing the claim record design and related issues #40 and #2, then resolve the embedded-proof schema, field mapping, and verification flow; done means the design is agreed and supports offline verification without requiring claimUri.