You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This proposal introduces attribute sets and provides a means of linking attestation of attributes to DSNP entities. We describe specification changes and usage examples as well as implications for DSNP applications and services.
Motivation
The motivation for including attributes and attestation for social networking identities is summarized in §3.3 ("Attributes") of the DSNP White Paper:
People using social media often choose to expose parts of their identity, or at least the identity that they inhabit on social media. Users can attach claims and metadata to their Social Identity. The most common metadata used on social media are display name and avatar, but can extend to claims about the user’s real-world identity, such as name, age, or professional certifications. By using this mechanism, services may be created that verify a user’s real identity, similar to Twitter’s verified accounts, except open for all to use rather than only those who Twitter has “determined to be an account of public interest.”
Additionally, the need for capturing claims and attestation about online content (not just people) has become a key priority for ensuring the safety and veracity of social media. Fact checking—particularly for material related to politically and ideologically motivated posts, health and medicine, and other types of content that can become targets for disinformation—has emerged as an important vector for promoting trusted environments.
Changes are backwards compatible. There is no requirement for applications to use these announcement types or format extensions.
Reference Implementation and/or Tests
What could this look like implemented or what tests could be provided to assist in validation of implementations? - TBD
Security Considerations
Much of the trust model is left to applications and/or users. This proposal does not dictate or mandate any specific form of shared schemas, reputation mechanisms, etc. These services will need to take into account the possibility of a Sybil attack and other adversarial usage.
While Attribute Set Announcements can always be authenticated, the ability for a consuming application to verify proofs found in Verifiable Credential documents may be limited if the signer (issuer) is not a DSNP user.
The text was updated successfully, but these errors were encountered:
wesbiggs
changed the title
DIP-[Replace with Issue Number] Attribute Set Announcements and attestation
DIP-257 Attribute Set Announcements and attestation
Jul 19, 2023
Problem
=======
Link to GitHub Issue(s): #257
Solution
========
Adds affordances for Attribute Sets via the Verifiable Credentials
format.
Adds three new announcement types for Attribute Sets.
Specifies DSNP compliance criteria for use of VCs, and includes DSNP
extensions for chains of trust and display of credentials.
Extends DSNP Activity Content usage to enable Attestations as
attachments.
---------
Co-authored-by: Wes Biggs <wes.biggs@amplica.io>
Abstract
This proposal introduces attribute sets and provides a means of linking attestation of attributes to DSNP entities. We describe specification changes and usage examples as well as implications for DSNP applications and services.
Motivation
The motivation for including attributes and attestation for social networking identities is summarized in §3.3 ("Attributes") of the DSNP White Paper:
Additionally, the need for capturing claims and attestation about online content (not just people) has become a key priority for ensuring the safety and veracity of social media. Fact checking—particularly for material related to politically and ideologically motivated posts, health and medicine, and other types of content that can become targets for disinformation—has emerged as an important vector for promoting trusted environments.
Specification Pull Request
Current change pull request: #275
Rationale
Please see the proposal document.
Backwards Compatibility
Changes are backwards compatible. There is no requirement for applications to use these announcement types or format extensions.
Reference Implementation and/or Tests
What could this look like implemented or what tests could be provided to assist in validation of implementations? - TBD
Security Considerations
Much of the trust model is left to applications and/or users. This proposal does not dictate or mandate any specific form of shared schemas, reputation mechanisms, etc. These services will need to take into account the possibility of a Sybil attack and other adversarial usage.
While Attribute Set Announcements can always be authenticated, the ability for a consuming application to verify proofs found in Verifiable Credential documents may be limited if the signer (issuer) is not a DSNP user.
Dependencies
Builds on DSNP v1.2 (support for public keys).
References
Shared document for this proposal
Copyright
Copyright and related rights waived via CC0.
The text was updated successfully, but these errors were encountered: