To keep things decentralized, control over each identity must be ambiently verifiable. This means that verifying control of the identity can be done anywhere, anytime, without a need to contact a central authority (or ledger!)
Technically this is implemented using Public Key Cryptography. Each identity is named by its associated public key. Each identity declares which other identities it is linked to. A link between two identities is only valid if both identities link to each other. Links can be encoded and discovered in a variety of ways, as appropriate for the use case.
DID is a W3C standard "for A globally unique persistent identifier that does not require a centralized registration authority and is often generated and/or registered cryptographically."
The standard basically formalizes a data structure to add further semantics to Public Keys. Central to the standard is the DID itself and the DID Document.
Each DID has the structure did:[method]:[method-specific-string]. The 'method'
is a unique string that identifies this "type" of DID and is registered in a
section in the DID spec
Each DID method has its own resolution mechanism which should ensure the
security/validity of the resolved document.
Further each DID document has a so called 'controller' and may also have an
alsoKnownAs property which lists a set of DIDs that are controlled by the same
entity.
Verifiable Credential (VC) is another standard that formalizes a data structure which represents statements made by an "issuer" in a tamper-evident and privacy-respecting manner. A VC is basically a cryptographically signed structure which records an issuer's DID, a subject's DID, and a set of claims that the issuer makes about the subject. The issuer and the subject may be the same identity, in which case we call the VC a "self-issued credential"
The proposed VC claim structure is simply to use a self-issued credential that makes an alsoKnownAs claim about the issuer. The VC model allows us also to make claims about other identities and may used in more complex ways such as a trusted third-party declaring an association between 2 other identities.
To prove the validity of a VC, the signer's DID must be resolvable to a DID Document with an associated set of verification methods.
DIDs are meant to be a decentralized identifier but they can of course be used to point to a centralized identity just as well, given that an appropriate DID resolution method is defined. The expected usage pattern is that users generate so called "pairwise" DIDs that are coupled with centralized IDs and used as pointers that can be independently proved later on without the need to further contact the centralized service.
did:twit:mnzakisol:1435689651482857473
To resolve a did:twit we use a tweet ID as the method specific string. The identified tweet object must is expected to point to a tweet that contains another DID (typically an actually decentralized DID).
In the example the
tweet contains the
string did:jun:Eed-kQrnQOCMVS6oPRdCH-W8rHHoKj0WsuBPEA9DC01s which is my
pairwise DID (did:jun based) for Twitter.
did:fb:[username]:[post id]
Similarly for Facebook the user creates a post and the post contains a pairwaise did
did:web:....
For proving control of a website, did:web uses a .well-known location where a DID and a DID document can be found.
did:dns:example.com
There's also a DNS based method which stores DID association metadata in a URI record in a special subdomain _did. For example, the required DNS record in the example.com zone file.
_did.example.net. IN URI 100 10 "did:jolo:1234abcd"
Any Public Key Cryptography based platform can theoretically be integrated trivially by just using the public key of the user as the "method specific string"
did:ssb:....
Scuttlebutt IDs are already public keys, and in this case can be used directly. The method specific string is just the SSB public key. The verification method in this case is a standard signed proof attached to the DID document.
An association between two identites is valid if both sides of the association declare it towards each other. The two-sided proof is of course necessary to avoid a situation in which an identity claims a false association with another identity, which it may do so freely in a truly decentralized system.
Using DIDs to represent different identities we can prove one side of an association in one of two ways:
- By resolving a DID and finding the target association in the
alsoKnownAsfield - By proving the validity of a VC that claims the target association
Given any combination of the above for two proofs, one for each side of the association, we can be cryptographically sure that the two DIDs are associated.
Of course the proofs can be extended to associate groups of identities together
An implementation was made using the Jolocom SDK but demo is underconstruction.
There will be a small demo here: https://mnzaki.com/bluesky
It only implements the did:twit integration.
To use the demo, you will need an Android device and install this version of the Jolocom SmartWallet
First install the wallet, and go through the onboarding process. Then in the main screen scroll to the Twitter section and tap to edit. You will be given a did:jun:.... string to post as a tweet. Post the tweet then copy the link to the tweet and paste it in the SmartWallet.
The wallet will verify the tweet and create a VC that also claims the connection. Note that the tweet must be public as supporting protected tweets will require twitter API integration (left out for demo purpose)
You can now use your wallet to interact with the demo. The demo must be opened from a desktop browser as you will have to scan a QR code (deep linking to be implemented). Tap/press the Social Media Accounts Request button, then scan the QR code with the wallet and go through the interaction of sharing your credentials. In a few moments you should see your twitter username on the demo page (this is per session, not visible to other users, and no interaction data is saved to disk)