Social Profile Association Verifiable Credential

Because decentralized identifiers (DID's) elect for a design where the identifier itself is not meant to be human memorable, it is crucial that we establish robust mechanisms in which DID's can be associated to some human meaning in order to facilitate discovery and cold calling when they are being used for personal identity use-cases. One way to achieve this is to link DIDs to other human memorable identifiers such as those used in most social networks, examples include

• Github usernames
• Twitter handles
• Facebook profile names

The DID to Domain linkage specification sets out how to do this association between a domain name and decentralized identifier, however there is perhaps a more generalized layer that we could recycle so that these types of assertions can be used to associate a DID to other types of identifiers, such as those listed above.

Relevant Project Example

A relevant project that shows this type of linking to social profiles is keybase, whereby you can use public key cryptography to link a keybase username to other social profile identifiers. For instance the github integration has you sign an assertion from a public key associated to your keybase identifier and upload it to a gist hosted under the github account you wish to claim example keybase gist.

The limitations to keybase's approach that we would be aiming to solve for with DIDs and VC's is:

1. Keybase ends up being the authoritative namespace over keybase usernames, and with that they essentially control what keys map to what usernames, giving them (in theory) the ability to impersonate any keybase user. If instead a similar mechanism is used whereby the keybase username is instead a DID then this security issue is resolved.

2. The assertion format is entirely unique and bespoke to keybase and hence is not conducive to multi-party / multi-vendor interoperability over a common approach. If instead the assertion format was based on a standard such as verifiable credentials, this makes it easy for a collection of vendors to build common tools relying on the integration.

Example VC with Github

The verifiable credential used for a DID to claim association to a github user may look like the following

{
      "@context": [
        "https://www.w3.org/2018/credentials/v1",
        {
            "sameAs": "https://www.w3.org/TR/owl-ref/#sameAs-def"
        }
      ],
      "id": "https//gist.github.com/tplooker/<gist-where-this-vc-is-published>",
      "issuer": "did:key:z6MkjRagNiMu91DduvCvgEsqLZDVzrJzFrwahc4tXLt9DoHd",
      "issuanceDate": "2020-04-13T16:44:52-05:00",
      "type": ["VerifiableCredential"],
      "credentialSubject": {
        "id": "did:key:z6MkjRagNiMu91DduvCvgEsqLZDVzrJzFrwahc4tXLt9DoHd",
        "sameAs": "https://github.com/tplooker"
      },
      "proof": {
        "type": "Ed25519Signature2018",
        "created": "2020-04-14T02:49:42Z",
        "verificationMethod": "did:key:z6MkjRagNiMu91DduvCvgEsqLZDVzrJzFrwahc4tXLt9DoHd#z6MkjRagNiMu91DduvCvgEsqLZDVzrJzFrwahc4tXLt9DoHd",
        "proofPurpose": "assertionMethod",
        "jws": "eyJhbGciOiJFZERTQSIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..WcAEoRHQl0b7ajn7V2fI9s7nO7SJOrsR6aB-p6OZsAd_xUnRlGbmqf3cjMmxUR3v1qSBpPEThS3dhfDt0SD2BA"
      }
}

Which would be hosted as a github gist publicly available at the url https//gist.github.com/tplooker/<gist-where-this-vc-is-published> assumed to be under the control of the github user tplooker to which the issuer is claiming association to therefore validating the by directional link