Export as verifiable credential

[makew0rld]

Verifiable Credentials are a W3C standard for cryptographically-signed digital credentials.

The UI should support exporting attestations in this format. The issuer would be the signer of the attestation.

This would require base64 encoding binary data in some cases.

[makew0rld]

I have published my notes on the Verifiable Credentials spec here.

[makew0rld]

Not sure if only the frontend export in this format (my original plan) or if the backend should instead/as well.

Edit: Ben says it should be frontend for now

[makew0rld]

As mentioned in my notes, the spec allows for VCs to be serialized in formats other than JSON-LD such as CBOR. Since some attestations include binary data, and we already use DAG-CBOR, it might make sense to encode our VCs as DAG-CBOR (or just CBOR, they are equivalent in this case).

What it comes down to is how accessible we want the output to be: who will be consuming these credentials? This question is also relevant since we are creating our own schema which may or not be public (see notes). Everything is already quite bespoke about this implementation, despite us following the standard. Maybe it's not a big deal to add one more thing to the pile.

[makew0rld]

Should timestamp information go inside the VC as well? It seems not required from a VC spec standpoint, and would definitely inflate the size. But if the idea is for VCs to be fully independently verifiable it maybe should be included.

[makew0rld]

Here is an example VC, using private schema URNs instead of public documents (see notes). Usage of urn:cid: has precedent, see here.

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "urn:authattr:vc-schema:1"
  ],
  // CID of "attestation" field in attestation, the part that gets signed
  // Because the credential is just a transformation of this
  "id": "urn:cid:bafyreietqpflteqz6kj7lmdqz76kzkwdo65o4bhivxrmqvha7pdgixxos4",
  "type": ["VerifiableCredential", "AuthAttrCredential"],
  // Maybe like this? Or author name could be used
  "issuer": "urn:authattr:pubkey:82zNiAAng99HblAvTe2mjsC3fQ-gI416b0fNLiNmS8s=",
  // Timestamp from attestation, not timestamp of VC creation
  "issuanceDate": "2023-07-13T14:34:17Z",
  "credentialSubject": {
    // CID of the file, as that is what the claims in this credential are about
    "id": "urn:cid:bafkreif7gtpfl7dwi5nflge2rsfp6vq6q5kkwfm7uvxyyezxhsnde5ly3y",
    // Fields copied from attestation schema:
    "attribute": "description",
    "value": "Web archive foo bar",
    "encrypted": false,
    // Set to true when "value" is base64-encoded DAG-CBOR bytes instead of a
    // regular JSON value. If "encrypted" is set to true then this field is
    // irrelevant as "value" is always base64-encoded as the *encrypted*
    // DAG-CBOR bytes.
    "binary": false
  },
  "proof": {
    "type": "authattr_ed25519_v1",  // Something unique
    "pubKey": "<base64-encoded public key>",
    "signature": "<base64-encoded signature>"
  }
}

[makew0rld]

PR now exists: #39

[makew0rld]

Multiple attestations in a single file

• credentialSubject can be an array of objects
• But proof cannot, so you can't hold the proof for each attestation
• Also the top-level id refers to the specific attestation and can't be an array
• The solution (if this is needed) is to create a VerifiablePresentation instead, or a bespoke thing like a simple array of VC objects

[dmitrizagidulin]

Oh cool! The examples remind me of Golda's and others' whitepaper on Linked Trust Credentials, https://github.com/WebOfTrustInfo/rwot11-the-hague/blob/master/final-documents/composable-credentials.md (she was also dealing with web archive attestations etc).

credentialSubject can be an array of objects

While technically true, I don't think any existing VC implementations use more than one credentialSubject.

But proof cannot, so you can't hold the proof for each attestation

So interestingly enough, proof CAN be an array of objects. But the proofs are for the overall VC "envelope", and not for individual attestations inside credentialSubject.

If you're doing that, it probably makes sense to /embed/ smaller VCs inside a larger VC (this is a pattern that CLRv2 (Comprehensive Learner Record) follows, for example).

Also the top-level id refers to the specific attestation and can't be an array

Yeah, the top level id (optional) refers to the whole VC (again, the envelope), not individual claims/attestations. But there's nothing stopping the attestations from having their own IDs!

The solution (if this is needed) is to create a VerifiablePresentation instead, or a bespoke thing like a simple array of VC objects

Yeah, agreed! These are the way to go. Either embed full (if minimal) VCs in a larger object (like an outer VC or a VP), OR have an array of claims/attestations in credentialSubject. (and I'm happy to chat more about when to do which one)