Social Account Links

[michaelsena]

cip: 22
title: Social Account Links
author: Michael Sena (http://github.com/michaelsena), Joel Thorstensson (http://github.com/oed)
status: Draft
category: Standards
type: RFC
created: 2020-06-15
requires: Tile Doctype (CIP-8), Linked Accounts Array (CIP-23)

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).

If you want to link other types of accounts to your DID such as crypto accounts, domain names and more, check out the Accounts Index.

Motivation

This specification aims to provide:

• The ability to link a DID to one or more social accounts
• A standard interface for interacting with a DID's linked social accounts
• Improved identity verification and reputation for DIDs through links to social accounts with existing reputation
• A single, predicable location and schema for verifications
• Decentralized Keybase-like functionality for DIDs

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 SocialAccountLinks as a tag in the document header.

Example

An example Social Account Links document that includes a Twitter, Github, and Matrix account.

(to be updated)

"doctype": "tile"
"schema": "<insert canonical schema and current version for Linked Accounts Array>"
"tags": ["SocialAccountLinks", "LinkedAccountsArray"]
"content": {
        
"protocol": "https"
"host": "https://twitter.com"
"id": "https://twitter.com/marysmith"
"claim": "https://twitter.com/marysmith/status/1274020265417076736"             // ID of tweet containing the user's DID
"attestations": ["ceramic://bafy123...", "ceramic://bafy456..."]

"protocol": "https"
"host": "https://github.com"
"id": "https://github.com/marysmith"
"claim": "https://gist.github.com/marysmith/5c48debdb7089b3c8f86cca31739572c"   // ID of Gist containing the user's DID
"attestations": ["ceramic://bafy123..."]

"protocol": "matrix"
"host": "matrix.org"                                                           // Matrix homeserver
"id": "@marysmith:matrix.org"
"claim": "$bTa0eSTPecwj7obhfKQkfarQ5OyMDOX78AhBFaJdLpk"                        // event_ID of a post containing the user's DID
"proofs": ["ceramic://bafy123..."]

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 social which 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.

[michaelsena]

@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]

Does email address fit in here? Also, how would email address proofs be "resolved"? Or does this go under #55?

[anthonygraignic]

Hi,
Are Social Account Links just links to social platforms that were verified once by the user or should it be considered as Verified Social Accounts with renewal of verification depending on platform in a more OAuth2 way?

[oed]

Hey @anthonygraignic this CIP has been replaced by CIP-23.
To answer your question, the verifiable credential will contain a timestamp of when it was issued. It's up to the consumer of this VC to decide if they want to trust it or now. The consumer also has to decide if they trust the issuer or not.