lexicon.community
Attestation Lexicon #8
Replies: 6 comments 18 replies
-
|
The general concept here is great! Would love to see this as a step towards a community badge proposal :) A couple questions:
Thank you for leading this! |
Beta Was this translation helpful? Give feedback.
-
The
Correct. This attestation / signature type and process can be applied to badges, awards, certificates, etc. but isn't specific to it. |
Beta Was this translation helpful? Give feedback.
-
Yeah, I really like the verifiable credentials spec and think it has a time and place. I also think it is trying to do a very specific thing, whereby this attestation lexicon is trying to do something more broad. I would love to hop on a call with anyone that has real-world experience either minting or consuming verifiable credentials to get their take. |
Beta Was this translation helpful? Give feedback.
-
Yeah, that's an interesting idea for badge records. Might be a good idea to invert it to minimize record edits. The new badge would refer to the old badge and if consuming systems care about it, they can update their indexes. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry for the delay in answering these! I've been, as you know, busy :)
Does this mean that applications should treat any field in
I'm aware of this repo that seems to have a bunch of people that might be interested in helping. I don't mind cold-"opening an issue" to ask if anyone would be willing to help us here, let me know what you think about that.
Yeah, I like the inversion! |
Beta Was this translation helpful? Give feedback.
-
Yes, basically any additional fields inside the |
Beta Was this translation helpful? Give feedback.
-
|
Few more things: Required fieldsThe proposal says:
But I don't see
|
Beta Was this translation helpful? Give feedback.
-
Correct and this might be a clarity of documentation issue. The
The verification method in this case is static. To verify a signature, you take the whole record, remove the
I'm not sure that an additional salt is needed because every signature will be unique to the content of the record, including the |
Beta Was this translation helpful? Give feedback.
-
Do we have a story for documenting these lexicons? If we don't, maybe we could add an edit to the initial proposal to clarify what this means?
This might be a "I know the theory but haven't done much practical work with signatures" thing, but is there an algorithm that's considered the default? What do you mean "the computed value", how do I compute it? |
Beta Was this translation helpful? Give feedback.
-
|
I was thinking that it would be interesting and useful to have an open review system (like for product reviews) and the idea of attestation comes up (like verified purchasers) My question is actually, do attestations, or more generally derivative records, play well with the plug-n-play algo feeds and stackable moderation? |
Beta Was this translation helpful? Give feedback.
-
|
That is a really good use case. |
Beta Was this translation helpful? Give feedback.
-
|
I think there is a general theme in society of lost trust and my belief is that we need more transparency and reproducibility as the foundation for rebuilding it across society. ATProto has some great features to support this when the data is related to the social graph that is both IRL and online |
Beta Was this translation helpful? Give feedback.
-
|
Since many gov DBs are at risk, many people are archiving pages and DBs, but it would be nice if we also had people storing the hashes independently, which doesn't require them to store the whole thing, which could be Petabytes of data (like for the SRAdb on the NIH), and allows many more people to participate in atleast attesting the authenticity of the data by storing a signed hash. That effort could be made additionally even easier if there was a simple ATProto App that allowed people to quickly login, and then store the hashes for select data sets in their ATProto repo. Do you think this Lexicon would be useful for that case? Or Should a different lexicon be made? or some sort of "sub"lexicon structure? Because pages have already started to go down, and there are many differing parallel efforts to archive and preserve it, so another layer that could be useful is that it doesnt just store a signed hash of the data, but also the source of the data, so if your source isnt actually the website or gov db itself before it went down, it would be transparent where in the chain or tree that you got your data, and can attest to atleast that link being intact. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah, absolutely. Consider the did
{
"$type": "community.lexicon.archive.file",
"fileName": "project_2026.zip",
"parts": [
{
"$type": "blob",
"ref": {
"$link": "9b45f43ff94f24950ce70c9e46cd6562f71ae948224fcc2b1826f42a947"
},
"mimeType": "application/octet-stream",
"size": 64000000
}
]
}If another DID wanted to lend "proof" that the file archive is valid, they could provide a signature to that record (without changing the blobs that make up the archive distribution). {
"$type": "community.lexicon.archive.file",
"fileName": "project_2026.zip",
"parts": [
{
"$type": "blob",
"ref": {
"$link": "9b45f43ff94f24950ce70c9e46cd6562f71ae948224fcc2b1826f42a947"
},
"mimeType": "application/octet-stream",
"size": 64000000
}
],
"sigs": [
{
"issuer": "did:plc:87ae1ceff8cee4bb53e8d850",
"signature": "MTY1NDBmMjk0ODA0MGNlMjlkZGVmNWJhYzJiZWFkZThhMTRmYzhhOWU4YjAzYzhkMWVkZDBiMmY4NWU2NjkyOCAgLQo=",
"issuedAt": "2025-02-03T11:07:01.000Z"
}
]
} |
Beta Was this translation helpful? Give feedback.
-
|
Is DID B publishing a separate record? This example looks like the DID A record has had extra data added How would DID B modifying the record in the repo of DID A work? |
Beta Was this translation helpful? Give feedback.
-
|
@verdverm I'd assume everything here is people writing records to their own repos. ATProto right now (v1) doesn't support cross-repo writes or shared records. The team has said they'd like to work on that, but it would be a big change, probably in ATProto v2, not before. I think anything that needs shared records or repos should probably be out of scope for lexicon.community right now. |
Beta Was this translation helpful? Give feedback.
-
|
I thought the example above was an example of the proposal's lexicon and usage. Knowing that
How would the attestation signature be added to the record, in relation to this statement between the example's code blocks? (that's what I'm wondering, or perhaps this example is not related to the proposal here, or it is not made clear that the two json objects are in fact different records because of omitted fields?)
|
Beta Was this translation helpful? Give feedback.
-
The original example with https://atproto.camp/ has the application directly writing their own attested records (badges) to repositories. I think an equally interesting and useful concept would be an escrow service where an issuer can declare a record, notify an escrow service, and then a user can auth into the escrow service to have the record written to their repository. |
Beta Was this translation helpful? Give feedback.
-
|
What other attestation works are out there that we should be learning from & citing? What can we crib from elsewhere? I don't know what the software BOM people are doing (or I've forgotten). Chain something... What's a good reader/explainer for c2pa? https://c2pa.org/ There's a meta-idsue to be had that all proposals should strive to gather & present literature of the others who have attempted the problems. I love reading someone's take on what we could do, what might work for atproto, but I'll never feel good about adopting any system unless I have some other examples out there to compare against. |
Beta Was this translation helpful? Give feedback.
-
|
https://in-toto.io/ and https://www.sigstore.dev/ is some prior art we can crib from, there are more projects like this in software development. Almost certainly some stuff in blockchain, though I left that industry a while ago and don't know specific projects by name |
Beta Was this translation helpful? Give feedback.
-
|
Found this section of docs from what I would imagine is the number one source of attestations in software development (docker/buildkit/OCI). Storage is interesting because it might inform how we store the information in new records when attesting to records we cannot change ourselves https://github.com/moby/buildkit/tree/master/docs/attestations |
Beta Was this translation helpful? Give feedback.
-
|
Scenario to be considered
The record contents from step 1 are now gone. Can we still verify User B's attestation if the record contents are no longer available, i.e. we are unable to reproduce. Certainly we can detect that the attestation no longer applies to the current record, but in many cases we would want to know the contents of what was attested to when looking at what & why something changed Thoughts? |
Beta Was this translation helpful? Give feedback.
-
|
If User A updates the record in such a way that the signature is no longer valid, then validation of the signature would fail. That is an expected and intentional behavior. |
Beta Was this translation helpful? Give feedback.
-
|
Seems trivial to wipe out all existing attestations on purpose or by accident, by updating a record, yea? Or is the attestation correct, but the data has been corrupted...? How does one differentiate? |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
The attestation lexicon represents types used for cryptographically verified attestation.
Intent and Rationale
Some records represent content or intention that involve a third party, but that third party has no way of signalling the authenticity of the record.
This can take several forms:
Example Uses
Badges and Achievements
In the scenario where a third party defines a "badge" and awards it to individuals and organizations, this lexicon would be used to attest to the validity of the award.
The @atproto.camp identity defines the "badge" that is given out:
{ "$type": "blue.badge.definition", "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/." }With this attestation type, the "award" record contains the
sigsfield that contains a signature from the issuer (at://atproto.camp).{ "$type": "blue.badge.award", "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/blue.badge.definition/6XXzn32gbU" }, "did": "did:plc:cbkjy5n7bk3ax2wplmtjofq2", "issued": "2024-08-26T22:14:02.000Z", "sigs": [ { "issuer": "did:plc:puy52u7opoy3gvrv7h7qdy76", "signature": "2-EaPZELcvu5SL8lS863fta8moqLZcpKlrzFpn7RbUr_B37HZphJa642dJfGNM2BMZGl-YGQync-2pyhoPC4Wg==", "issuedAt": "2024-08-26T22:14:02.000Z", } ] }When the award record is viewed, the signature can be verified as authentic.
Smoke Signal RSVPs
Smoke Signal allows users to RSVP to events. Although most public events are free and open to the public, some events may have limited seats. In those cases, an event organizer may want to approve reservations.
The event at://metro-parks/events/1 is created as "Goat Yoga" with 10 spots open. Smoke Signal has a securely stored copy of the verification method signing key for
@metro-parks.Later, the RSVP at://yoga-dude/rsvps/200 is created. Smoke Signal is configured to automatically accept the first 10 people, thus signing the RSVP on
@metro-park's behalf.The original RSVP record looks like this:
{ "$type": "events.smokesignal.calendar.rsvp", "status": "events.smokesignal.calendar.rsvp#going", "subject": { "uri": "at://metro-parks/events/1", "cid": "bafyrei...s5ebw7q" }, "sigs": [ { "signature": "85df455...a769ebe", "issuer": "did:plc:metro_parks_did#smokesignal", "revocation": "at://did:plc:metro_parks_did/revocations/3y3ra3rz61", "rsvp": "accepted" } ] }Creating Signatures
A signature is generated by taking a DAG-CBOR representation of the record and applying the signing function described in the verification method.
The signed content does not include the "sigs" attribute and also includes a "$sig" object containing additional information used to secure the signature. The "issuer," "did," and "collection" attributes are required to provide scope to the signature and prevent duplication of the signature in other repositories or collections. The "issuer" element is specifically used to resolve the verification method to validate the signature.
Additional optional signing elements supported include:
Signatures are appended with the last signature of an issuer being validated. This behavior allows issuers to append and replace signatures with a fixed time window for each to be valid. Applications decide whether or not to keep signature histories on records.
Verifying Signatures
Any application or system using the record to make decisions must validate signatures using this process:
Lexicon
community.lexicon.attestation
{ "lexicon": 1, "id": "community.lexicon.attestation.signature", "defs": { "main": { "type": "record", "description": "A signed record. This is a trait that is applied on top of an existing type.", "key": "tid", "record": { "type": "object", "properties": { "sigs": { "type": "ref", "ref": "#collection" } }, "required": [ "sigs" ] } }, "collection": { "type": "array", "items": { "type": "ref", "ref": "#signature" } }, "signature": { "type": "object", "properties": { "signature": { "type": "string" }, "issuer": { "type": "string", "format": "did" }, "did": { "type": "string", "format": "did" }, "collection": { "type": "string", "format": "nsid" }, "notBefore": { "type": "string", "format": "datetime" }, "notAfter": { "type": "string", "format": "datetime" }, "revocation": { "type": "string", "format": "uri" } }, "required": [ "signature", "issuer" ] }, "revocation": { "type": "record", "description": "A record of revocation of a signature", "key": "tid", "record": { "type": "object", "properties": { "revoked": { "type": "boolean" }, "message": { "type": "string" } }, "required": [ "revoked" ] } } } }Beta Was this translation helpful? Give feedback.
All reactions