-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Discussion of LinkedClaims RFC - please comment! #3
Comments
do we need an 'updates_at' field to something like ceramic or aries that is revocable? @dmitrizagidulin suggested this be an 'inbox' with the interface as defined by ActivityPub |
can we connect this to attest.sh - yes https://docs.attest.org/docs/tutorials/ceramic-storage |
Examples for paper: OFP - granular validation of carbon credits on open forest protocol https://atlas.openforestprotocol.org/1700544986382 UI demonstrates the validation, the data is also on chain and should be addressable curious how the decision was made to deny for example - https://atlas.openforestprotocol.org/1711356576770 |
UNTP Traceability events - these are verifiable credentials, the only question is are they themselves addressable see https://uncefact.github.io/spec-untp/docs/specification/DigitalIdentityAnchor and https://uncefact.github.io/spec-untp/docs/specification/IdentityResolver for specs and examples |
This issue is for collecting discussion of the LinkedClaims proposal in the DIF Labs working group
Please refer to
https://github.com/Cooperation-org/LinkedClaims/blob/main/LinkedClaimsRFC.md
and
https://github.com/decentralized-identity/labs/blob/main/proposals/linked_claims/001_proposal.md
In particular the unresolved questions
Is there a need for a specific "glue" vocabulary such as http://cooperation.org/credentials/v1/
How to resolve the tension between using a human-viewable subject URI versus a hashable signed credential as the subject of a claim? Could there be a content type or query parameter that switches, but in this case how to ensure the two are aligned?
Should the canonical identifier of a claim be included in the claim itself?
Review each of the MUST, SHOULD and MAY in the RFC for usefulness and testability
Can we write tests for being a LinkedClaim without a single canonical vocabulary?
and the largest question
What would motivate stakeholders to publish LinkedClaims and expose their claims to external validation? Do non-protocol entities see a use for this?
The text was updated successfully, but these errors were encountered: