@canadaduane Hi Duane, thanks for your question!
Here's a broad overview of our approach and solution to decentralized identity management (tried to keep it as concise as possible).
The Jolocom team develops a protocol that enables all types of entities (individuals, organizations, smart agents) to create and interact with self-sovereign digital identities. The Jolocom protocol is open source + implements the DID/DID document specifications from the W3C, as well as open standards for verifiable credentials (see below).
Jolocom is blockchain agnostic, allowing for integration with different distributed ledger technologies and different storage configurations. Currently we use the Rinkeby test network as a trust layer to resolve a DID to a DID document (only a DID and a reference to a DID doc is stored on Ethereum). The DID document is stored on IPFS, where public credentials could be stored in the future.
The jolocom-lib library includes functionalities around identity creation and registration as well as verifiable credentials creation and verification. Key generation is carried out client-side (entropy created by user swiping across device screen). The BIP 32/39/44 standards are used for the hierarchical derivation of Jolocom identity key pairs. Multiple personas can be modeled using HD key derivation, providing anonymous identities. If any child key is compromised, other keys derived from the same master key are unaffected. While we currently rely on entropy generated by a user’s device, but entropy can be proffered by other sources, such as hardware wallets or crypto chips, which provide an even higher quality of entropy. Regarding client-side storage, Jolocom encrypts user data, master key pairs, and derived child key pairs with the user’s passphrase.
All identity attributes, including private keys, are accordingly stored on a client’s device by default, and can only be controlled by the device owner. Users can attach a public profile to a DID document containing human-readable information about the user. Jolocom does not collect any user data; all public user data is stored on the Ethereum network and IPFS. Claims are also subject to expiration dates, so claims can be set up to become inaccessible after a predetermined time.
The system architecture gives individual identities control over their private keys and data, a prerequisite for self-sovereign identity. Furthermore, the system architecture follows existing and emerging standards in the digital identity space, including portability and interoperability as core design factors. Identities created using Jolocom’s solution should be easy to use across multiple devices and work in an unrestricted scope of application environments. Jolocom observes compliance to existing industry standards and best practices concerning decentralized digital identities, specifically the W3C DID/DID doc specification and the BIP 32/39/44 standards for the hierarchical derivation of Jolocom identity key pairs.
Hope that helps, Duane — let us know if you have any follow-up questions.
Also, for some further reading:
-- You can always delve into our documentation (updated regularly as the protocol and code matures)
-- And be sure to check out this recently published paper on self-sovereign identity that aligns especially well with Jolocom’s own approach to decentralized digital identity management and vision for a self-sovereign future of identity; the position paper comes from the German Blockchain Association (Bundesblock), and my colleague Kai Wagner (Jolocom) contributed a great deal to the writing and organization as an active member of the Identity working group
@canadaduane — what a fantastic follow-up! :) We elaborate on selective disclosure of verifiable credentials as well as what measures we take to prevent reverse correlation in our website's FAQ section (starts about halfway down).
I've copied some relevant snippets from our FAQ below which should offer a general overview on these issues (of course, please feel free to share any further questions here or via email to firstname.lastname@example.org).
Why do you use blockchain?
What measures do you take to avoid reverse correlation of anonymous or pseudonymous digital identities to their real world counterpart?
@blazedarwin Thanks, this is useful! It would be helpful if I could outline a system I'm a little more familiar with--Sovrin in this case--and perhaps you can compare/contrast the architecture and correlation protections that Jolocom provides?
Sovrin is working on a way to create unique, pairwise DIDs for each relationship/connection that a person establishes. The benefit here is that if you establish unique DIDs representing yourself to each of your contacts (friends, businesses, governments), these unique identifiers can't be used in a collusion scenario to automatically correlate information about you. (Currently, Sovrin requires registering DIDs on the Indy public ledger, but their future direction is "microledgers." These will allow each individual to keep their own private database of their relationships, so that--while optional and useful in some scenarios to make DIDs public--DIDs need not be shared publicly in most cases).
In addition, verifiable credentials associated with one of your DIDs can still be used by you as proof to someone else who knows you by a separate DID. The magic that enables this is a "Link Secret" (formerly a "master secret") that only you know. This allows you to sign blinded proofs that a verifier can see as a claim/credential about "you," even if the claim was made about a different DID belonging to you.
All of this means that in general, the "default setting" in Sovrin will be to provide correlation protection by default--essentially a new "persona" for every relationship--but all while enabling connecting the many personas' credentials in a useful way. (Apologies if I'm overloading the term "persona" here.)
@katszwn Thanks for your answers. Let me get this together:
In order to issue a claim, a user share a webservice his/her did (e.g. through a QR code showed in the examples). 2) The issuer can create what-ever claim he wants to issue to the user in the form of a QR code which the user 3) scans and accept this claim (in order to use it, or deny it)
A direct issue of a claim (like I thought with the screenshot I provided) to a specifc identity is not possible without a communication (e.g. in form of a QR code).
That is correct! We experimented with encoding entire credentials in QR codes, but eventually the character limits get to us (decreasing the error correction level is a potential solution, but leads to unreliable scans, and does not provide that much space).
We intend to focus on enabling users to issue signed credentials to other users directly (e.g. via NFC / Bluetooth) in a peer to peer / web of trust fashion, but as of now, a middleman / server is required.
2018 has been a great year at Jolocom, we...
👉🏽 doubled our team
👉🏿 launched our SmartWallet Alpha
👉🏻 released our Whitepaper
👉 contributed to the #SSIpaper
👉🏼 expanded our universal identity protocol
& saw a remarkable 👆🏾in activity in the #decentralization community on & offline.
Thx to all who we met along the way, and who helped us get the message for self-sovereign identity and decentralization, at large, across.
Read up on where we were, who we partnered with, and what we're reading in our downtime this holiday break: http://bit.ly/Jolocomin2018
We're giving away 10 tickets to the Deutsche Telekom T-Labs #blockchain #identity hackathon happening 19-20 January here in Berlin - register here using the code JOLOCOM at https://www.universe.com/events/blockchain-identity-hackathon-t-labshack-tlabs-in-berlin-tickets-berlin-2435H6
🥇$3000 🥈$2000 🥉1000
Jolocom devs will be there mentoring on both days so come say hi to Eugeniu, Natascha, Charles and Ira 👋🏼
An update from our devs from January ➡
we helped hack #SSI use cases at #TLabsHACK in Berlin - stay tuned for more #TLabsHACKing from us in Barcelona next month
one of our newest devs, Charles, integrated Jolocom with the DIF universal resolver
we added language support for German & Dutch to the SmartWallet
we onboarded two new members to the dev team, Lukas & Charles
were seen at 5 community events
➡ Take a look: http://bit.ly/januarydigest
An important note to developers working with our libraries:
We are in the process of updating the dependencies of jolocom-lib and this will require node users to use version node 10+. If you are using an older version, you may encounter errors. If you do, please upgrade node.
Hi @BenchToMarket, you can find our deployed contract here.
If you inspect any transaction sent to it (example), and view the
Input Data as
UTF-8, you'll see something along the lines of:
Zµî73>uÊnwOepiN\ýú9¢ªdjî»°ö§´@.QmQiLVrYjtH1nATYdXzEun2JeZnTLt6nXD7Ed2hZhaqCRJ. (The first section is of type
The IPFS hash anchored in this transaction is
You can then query any public ipfs gateway, for instance:
to get the DID Document
Along with above: how can i view my did on Rinkeby Etherscan? ~is there 1 did for me AND 1 for every credential?
Each agent (e.g. user, service, device) has a
did. Credentials contain the
did of the issuer and subject, but are not themselves assigned
Hi. Analogous to @BenchToMarket question, I'd like to know the steps the EthereumConnector and IPFSConnecter takes how to create an identity and anchoring it to the Ethereum Chain und IPFS.
I wrote some Custom Connector for both (Ethereum and IPFS), which just implements the default connectors. I run some console.log() to see, which function gets called why and when. For example, after I call the registry.create(vaultedKeyProvider, password) function to create a new IdentityWallet, I get this output:
Intercepted request for did:jolo:.... -> (which return some 46-length string like 'QmYb...'
Intercepted catJSON IPFS
Intercepted storeJSON IPFS
Intercepted request for did:jolo:... , updating to QmYb...
My question is, what does the 'resolveDID(...)' function excatly do, when it returns a string like 'QmYb...' etc? What is stored on the Ethereum-Blockchain? It is a key-value pair like did:jolo -> QmBy...?