michaelsena
commented
4 years ago @oed your eyes would be nice here, particularly on how we describe Oauth accounts. Currently I'm defining this document as an array of JSON objects containing name, namespace, and an array of proof. Alterntively, we could try to do something similar to CAIP standards where we use name@namespace as the key and proof as the value.
Thoughts?
Also if you can create the schema and the example for this one it would be helpful.
Schwartz10
anthonygraignic
oed
Simple Summary
Social Account Links stores a list of a DID's linked social accounts.
Abstract
Oftentimes users may want to publicly associate various identities from social applications to their DID in order to prove to others that all are owned by the same person or entity. This could include Twitter, Github, Discord, Matrix and other similar services. Collectively these account associations can function as a powerful form of identity verification and reputation for DIDs and can serve to add trust to our digital interactions since counter-parties can be sure, with cryptographic proof, that the entity they are interacting with is the authentic owner of another well-known public account.
The Social Account Links document contains a list of a DID's social accounts and links to their proofs. Usually these proofs are issued by third-party account verification services as Verifiable Claim documents (TODO: add link once CIP is written). By standardizing how one or more social accounts are linked to a DID, the Social Account Links document enables applications to have a single, common interface to use for discovering and interacting with those accounts.
The Social Account Links document is usually linked to from an Accounts Index (CIP-14).
Motivation
This specification aims to provide:
Specification
The Social Account Links specification consists of a doctype, schema, and tags.
Doctype
Social Account Links is a Tile Doctype (CIP-8).
Schema
Social Account Links utilizes the Linked Accounts Array (CIP-23) schema, which simply stores an array of JSON objects that are formatted to represent linked accounts. Although the Linked Accounts Array schema can store various types of linked accounts, for the scope of this document you should only store social account links. A reference to this schema should be included in your Social Account Links document when it is created.
Tags
When creating a new Social Account Links document, add
SocialAccountLinksas a tag in the document header.Example
An example Social Account Links document that includes a Twitter, Github, and Matrix account.
(to be updated)
Suggested Usage
Accounts Index: The Social Account Links document stores a list of social accounts linked to a DID. However a DID may also wish to associate other types of accounts to their identity, such as crypto accounts, domain names, other DIDs, etc. The Accounts Index provides an index of accounts lists, and can contain a property called
socialwhich stores a link to a Social Account Links document. The recommended path from a DID to a Social Account Links document is:DID>Root Index>Accounts Index>Social Account Links.Verification Services: For the account links in this document to be verified, they need to have a proof. Proofs are usually Verifiable Credential Doctypes issued by third-party verification services such as the one offered by 3Box.
Rationale
Decentralization & Trust: Linked account data needs to be globally-available, cross-platform, censorship-resistant, and live permissionlessly in the public domain (not on any single server). Additionally this information should be owned by a DID and will need to be updated from time to time. These requirements make Ceramic the most appropriate platform for publishing this content.
Implementation
Linked Accounts Array: Find the version of the Linked Accounts Array schema used for this document here. (TODO: Link after deployed)
Libraries: Not yet available.
Copyright
Copyright and related rights waived via CC0.