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.
-
|
Few more things: Required fieldsThe proposal says:
But I don't see
|
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.
-
|
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.
-
|
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.
-
|
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.
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