Attestation Lexicon

[ngerakines]

The attestation lexicon represents types used for cryptographically verified attestation.

Render community/lexicon/attestation/README.md

Discussion: https://github.com/orgs/lexicon-community/discussions/8

Use Cases

Badges / Awards

The relationship between an issuer of an award, the recipient, and the award itself can be cryptographically verified through a signature.

Given an award:

{
  "$type": "community.lexicon.awards.badge",
  "image": "https://atproto.camp/static/6XXzn32gbU.png",
  "name": "Adventure Awaits!",
  "text": "You're in for an adventure! Log in for the first time to https://atproto.camp/."
}

The issuance of the award can be signed, pointing back to the issuer.

{
  "$type": "community.lexicon.awards.issuance",
  "award": {
    "$type": "community.lexicon.awards.badge",
    "cid": "bafyreifbq7wub6wfuntruagvaaivqsinxyc4mpbfagjka35v4wx7aeu3fe",
    "description": "You're in for an adventure! Log in for the first time to https://atproto.camp/.",
    "name": "Adventure Awaits!",
    "uri": "at://did:plc:puy52u7opoy3gvrv7h7qdy76/community.lexicon.awards.badge/6XXzn32gbU"
  },
  "signatures": [
    {
      "issuer": "did:plc:puy52u7opoy3gvrv7h7qdy76",
      "signature": "2-EaPZELcvu5SL8lS863fta8moqLZcpKlrzFpn7RbUr_B37HZphJa642dJfGNM2BMZGl-YGQync-2pyhoPC4Wg==",
      "issuedAt": "2024-08-26T22:14:02.000Z",
    }
  ]
}

Confirmation of intent

The relationship between a person's intent and the subject of that intent can be validated.

Consider the intention of a user to participate in an event through the creation of an RSVP record:

{
  "$type": "community.lexicon.calendar.rsvp",
  "status": "community.lexicon.calendar.rsvp#going",
  "subject": {
    "uri": "at://did:web:metroparks.org/events/1",
    "cid": "bafyrei...s5ebw7q"
  },
  "signatures": [
    {
      "signature": "85df455...a769ebe",
      "issuer": "did:web:metroparks.org",
      "revocation": "at://did:web:metroparks.org/revocations/3y3ra3rz61",
      "rsvp": "accepted"
    }
  ]
}

The RSVP record is "accepted" by did:web:metroparks.org with the application-specific data { "rsvp": "accepted" }.

Multi-Factor Revocation

Consider the situation where a trusted third party may want to revoke a signature.

{
  "$type": "status",
  "status": "Everything is fine",
  "signatures": [
    {
      "signedAt": "2024-12-07T18:43:27.62Z",
      "revocation": "at://did:web:issuer.com/community.lexicon.attestation.revocation/jhrcw9j73e",
      "headlines": [
        "Global tech crackdown Mon, 20 Dec 2021 14:58:18 +0000",
        "COVID-19 series: The year of the vaccine Tue, 24 Aug 2021 14:09:30 +0000"
      ],
      "issuer": "did:web:issuer.com",
      "signature": "MEUCIQCwGnxFoqCFJ-Jp0q9jAEzLZxHVrLNnaMCekI23E9EARgIgI_D4SZlJ7O6raepAWedpGETLPf0k7ZhHPP_-a2MQTTE="
    }
  ]
}

In this example, the issuer of the signature has a revocation record that could be yanked. The signature includes the issuedAt timestamp as well as multi-factor information used to verify the content of the signature, specifically headlines and publication timestamps from the Reuters "the big picture" RSS feed.

Community Content

When a DID repository may have content created by multiple people, verification of the author of the content may be necessary by whatever controlling system is managing the repository.

{
  "$type": "app.bsky.feed.post",
  "createdAt": "2024-12-07T04:12:57.990Z",
  "langs": [
    "en"
  ],
  "text": "When in the Course of human events, it becomes necessary for one people to dissolve the political bands which have connected them with another, and to assume among the powers of the earth, the separate and equal station to which the Laws of Nature and of Nature's God entitle them, a decent respect to the opinions of mankind requires that they should declare the causes which impel them to the separation.",
  "signatures": [
    {
      "signedAt": "2024-12-07T04:12:57.990Z",
      "authors": "did:web:thomas-jefferson.us",
      "issuer": "did:web:thomas-jefferson.us",
      "signature": "MEUCIHh981CRrEkJFaOw0mtJik59qIKfo1aqhRDyjsnxftoAAiEAsSqoZs6yjPEhjoKAvl9539TwVhgZZU1dQ-OW_YEqMe0="
    }
  ]
}

In the above example, even though the record may have been created in the did:web:continental-congress.us repository, the author of the content provides an attestation that the content is theirs and the repository owner accepts the record as an acknowledgement of that attestation.

License and Assignment

• I assign all rights of this contribution to Lexicon Community as an open source contribution under the MIT license.

[ngerakines]

This is the python script used to create the examples in the README.md file:

https://gist.github.com/ngerakines/6d0d834f206eb7af0aa798e188d89c36

[rektide]

Just my bailiwick here, but it would be so awesome to be able to translate attestation into an HTTP Message Signature.

https://datatracker.ietf.org/doc/html/draft-ietf-httpbis-message-signatures

[snarfed]

Hmm. HTTP Sigs are very message/request-oriented, not data oriented, eg they generally include HTTP headers like hostnames, timestamps, etc. Not great for long-lived attestations tied to data. Also afaik the HTTP Sigs standard is deprecated in favor of the Verifiable Credentials standards suite, which I'm not familiar with but might be more amenable to data-oriented signing like this.

(More background, fediverse/AP-oriented: https://swicg.github.io/activitypub-http-signature/#so-what-s-the-verdict )

[verdverm]

I'm only passing familiar with attestation. I wonder what prior art you are or we can draw on?

For example, OCI has tools like cosign that use in-toto attestation: https://github.com/sigstore/cosign | https://github.com/in-toto/attestation

What are other systems that are using attestation doing? Are there any evolving standards out there?

[tqwhite]

Speaking of prior art. W3C is working on a standard that probably should be considered in this design.

Verifiable Credentials Data Model v2.0

It appears on the surface that the specifics are different but that the intention is the same. AT Proto PDS definitely supports the role of "holder" in that spec. The credential signing and verification might be different.

[ngerakines]

Speaking of prior art. W3C is working on a standard that probably should be considered in this design.
...

@tqwhite Yeah, I think they do different things, however.

The intention here is to allow DIDs (users and organizations) a way to provide small proofs to other records. Those proofs can be part of a larger structure, but they can also be adhoc.

[tqwhite]

Speaking of prior art. W3C is working on a standard that probably should be considered in this design.
...

@tqwhite Yeah, I think they do different things, however.

The intention here is to allow DIDs (users and organizations) a way to provide small proofs to other records. Those proofs can be part of a larger structure, but they can also be adhoc.

I have since been studying. It is doing much the same thing as this except not of "small proofs". It specifies a data model to support college diplomas and transcripts, professional certifications, job and employment records and pretty much any other fact about a person that anyone would care about having access to in a verifiable way.

Your data model is less comprehensive but has the advantage of being specified in Lexicon and therefore attached to AT Proto. The W3C Verified Credential does not have any connection to the rest of an ecosystem. Further reading has told me that everyone considers it to be part of a W3C Distributed Identity. Unlike this effort, that is not explicit nor is there any standard access protocol suggested. It is written so that any HR or school information system can have a schema that could be exported in a verifiable way.

If I were king of the world and had found out about the Attestation Lexicon earlier, I would have really pushed to have it based on the Verifiable Credential. That would support the "small proofs" goal (although it might turn out to be too complex for this use case) and make a huge contribution to the larger effort that motivates the W3C effort. (Obviously it's too late for that and I mean no disrespect.)

Imagine, this though. Today, to get proof of a college degree, one has to contact the institution and, often still, wait for them to dig into their records, print out a diploma and mail it to you. With an ATP Verified Credential, the alternative could be that, upon graduation the institution emails a verified credential that you load into your Personal Data Store. When you apply for a job, you give them the URL of the diploma in your PDS.

Anyway, sorry to stick my nose in and also to be so longwinded. I am deeply inspired by your work.

[verdverm]

Some questions that just came to my mind

• what if I want to use a different signing key for attestation than from my PDS account? There's an amount of separation of concerns I'd like to have
• labels and community notes are kind of like attestation to the contents of a record? How are the the same / different? How is identity, verification, trustworthiness working for these?
• if similar enough, can attestation piggy back on their implementations?

I'd like to see / know more about Bluesky's plan for community notes, in order to inform the conversation around attestation

[ngerakines]

With the new governance model that emphasizes working groups, I'm closing this PR so that a working group can be formed to own this and see it through.