Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Justas Ažna
    @reederz
    Hi there. Quick feedback: Whitepaper link on jolocom-lib is broken
    Kasia Szawan
    @katszwn
    Thanks @reederz ! Just fixed it :)
    Ellie Stephens
    @EllieStephens
    Hi folks, a few updates! The first – we have consolidated our other Gitter channels into this one so now all info regarding library releases, the app, and other questions can come here.
    The second, is that our devs just released an updated version of the jolocom library (https://github.com/jolocom/jolocom-lib). Below are some of the changes you'll see:
    • refactored the code around interaction flows (previously just single sign-on flow)
    • extracted a JSON Web Token class, which now contains all the common functionalities for interaction flow, and a set of payload classes, which encapsulates flow-specific functionality
    • Introduced credentials receiving and authentication flows
    • Added default context and used credential types from newly extracted npm package - credential-types-jolocom-core
    • Added the possibility of creating nested claims
    Third and final, is that you shouldn't be shocked to receive some updates here from me ;) I'm the newest member of the Jolocom team and will be helping out in terms of comms and content
    Ellie Stephens
    @EllieStephens

    For any devs interested in taking a look at the newly released #SSIpaper "Self-sovereign Identity: A position paper on blockchain enabled identity and the road ahead," let us know what you think – http://bit.ly/ssi_paper 🎉

    As part of Bundesblock, Jolocom worked together with 20+ leading groups in the identity field to provide a clear description of SSI, the problems that motivate it, its potential use cases and questions evolving around its implementation.

    See what others are saying about it: http://bit.ly/ssipaper_feedback
    Download the paper directly: http://bit.ly/ssi_paper

    Jefferson Sofarelli
    @jmsofarelli
    Hi all, I have started to read the jolocom-lib documentation and in the section "Getting Started" it's stated that "The master key itself is never used for anything outside of derivation". But I don't see in the code anything related to the master key. Is the same of the identity key, or the identity key is already considered a derived key?
    Kasia Szawan
    @katszwn
    Hi @jmsofarelli! The identity is already a derived key. You can see the details here: https://github.com/jolocom/jolocom-lib/blob/master/ts/identityManager/identityManager.ts - master key pair is created from the seed, and then from that we derive keys based on the specific paths
    Ellie Stephens
    @EllieStephens
    We're hosting a hackathon as part of IPDB along with Riddle&Code and Ocean Protocol. All participants will get a free ticket to Revision Summit (+ a grand prize for the winning team!) 👉 apply here to join us on Nov 19 or find out more 👉 http://bit.ly/codeforpurpose_eventbrite
    Jefferson Magno
    @jmagno
    @katszwn Hi Kasia, it looks like the link is broken :(
    Cameron Sajedi
    @csajedi
    Hi everyone, I was wondering what the situation is with Jolocom's copyrighted github repo? Is there intention to open-source it or allow third party integrations in the future?
    Charly
    @charleenfei
    Hi Cameron, our code base is currently all open-source. If you check out the licensing terms for the github repo, you'll see that redistribution and modification of the Jolocom Library are handled under MIT licensing terms!
    (ie: permission granted for third party integrations already!)
    Ellie Stephens
    @EllieStephens
    @jmagno Sorry about any broken links - I believe this one will take you where you need to go :) https://github.com/jolocom/jolocom-lib/tree/master/ts
    Kannan Reghu
    @kannancet
    @EllieStephens - I am getting started with exploring Jolocom for integration of SSI with a mobile app project. I would like to get in touch for some technical queries around the integration. Would you be open for a call ?
    Ellie Stephens
    @EllieStephens
    Hi @kannancet - most definitely, though one of our devs would be a better resource for you. Shoot me an email at ellie@jolocom.com and I'd be happy to make it happen.
    Kannan Reghu
    @kannancet
    @EllieStephens - Yup sure. Will do so.
    Duane Johnson
    @canadaduane
    Hello! @peacekeeper mentioned jolocom at the Internet Identity Workshop in Mountain View, CA last month and I've been curious about your project since then. I work at Mainframe and we're building a browser/OS for fully decentralized apps. I've investigated Sovrin, uPort, & Iden3 as potential SSI solutions for our platform and I'd like to know more about jolocom. I've read the jolocom whitepaper. Where should I look next to compare and contrast what jolocom is doing differently?
    Ellie Stephens
    @EllieStephens
    Hi @canadaduane, so sorry for our team's delayed reply! We were slammed in the front half of this week co-hosting an IPDB hackathon w/ Riddle&Code and Ocean Protocol, and then with slots in the Revision conference. You've already done the recommended reading on our side, so one of our team members is currently compiling a list of helpful resources for you outside of the whitepaper. We'll be in touch with those later today/tomorrow latest. Thanks again for reaching out!
    Sean
    @blazedarwin

    @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

    Duane Johnson
    @canadaduane
    @blazedarwin and @EllieStephens Thank you very much! Excellent summary. I do have a follow-up question: One of the primary concerns we have around identity is putting control over correlation in the hands of the person (i.e. governments, advertisers, and businesses are all in an adversarial role with regard to a person's right to selective disclosure--these large institutions want maximal correlation of your data exhaust so they "know everything about you.") For instance, we want our users to be able to selectively disclose verifiable claims, without risk of revealing all claims or even a list of people who have made claims about the user. Additionally, it seems difficult to create a self-sovereign identity that is economically sustainable, while also protecting against data correlation--most systems are anonymous until the payment step is introduced, at which point ethereum or other more traditional payment methods leak identity information about the user. What are your thoughts on this aspect of identity and privacy?
    Sean
    @blazedarwin

    @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 sean@jolocom.com).

    General
    Why do you use blockchain?

    • Decentralized, trustable storage solutions like those enabled by (public, permissionless) blockchains are ideal for structuring registries that encode a conceptual shift toward self-sovereign identity. Separating the act of registering an identity from the (subsequent) act of building up trust on that identity is a novel technique made possible thanks to blockchain. This methodological maneuver is a milestone in digital identity management and brings us closer toward a pragmatic self-sovereign identity solution. Still, we think blockchains ought to be used only where appropriate, and not every part of the self-sovereign identity ecosystem we envision necessarily requires incorporating a blockchain.
    • With regard to the claims used to manage your attributes and make them verifiable, we do not see blockchain as the right type of storage solution. Our architecture reflects this belief: we use blockchain solely for registering and making the identity reference available (i.e. selectively accessible); for the storage of identity attributes such as your name, age, or address, we currently use IPFS or the secure, encrypted storage on the identity holder’s personal device. Doing things in this way gets us much closer to full data ownership and control by individuals and smart agents, and we achieve compliance with the European Union’s General Data Protection Regulation (GDPR).

    System Architecture
    What measures do you take to avoid reverse correlation of anonymous or pseudonymous digital identities to their real world counterpart?

    • Ultimately, there will always be a certain trade-off between reputation and privacy. An identity builds up a reputation based on a history of good behavior, so there can be no reputation building without knowledge of that history. That being said, the Jolocom model of identity decouples different personas of an identity (the different child DIDs of a master key pair), allowing for selective disclosure and avoiding unwanted correlation between personas.
    Duane Johnson
    @canadaduane

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

    Sean
    @blazedarwin
    @canadaduane I'd be happy to provide some detailed info regarding how our approach to digital identity management aligns and stands out from similar solutions — will share that here as soon as I find some time in my schedule to follow-up on the specific areas you mentioned!
    Duane Johnson
    @canadaduane
    Sounds good, thanks! (Based on the pace of our conversation, I think we must be on opposite sides of the planet :)
    samsmitt
    @samsmitt
    Hi there!
    I'm writing a small test application with jolocom to add custom claims to my identity. I registered an identity using the jolocom app. Now, to unterstand how I can add claims (issued by another identity through a script e.g.) I need to know the DID of my identity which I created with your app. How can I do that?
    samsmitt
    @samsmitt
    Another question: If i created an identity like you showed in your Getting Started guide, can I access this identity through your mobile app?
    Kasia Szawan
    @katszwn
    @samsmitt Currently in order to get custom claims, you would have to have them issued by another identity - for example a web service. In future that will be possible to add your own custom claims from the level of the Smartwallet
    The process of issuing claims happens as a part of the communication protocol between two identities - your Smartwallet and for example a web service. You can demo the process on https://avalon.jolocom.com/ - first you need to sign in, and from that interaction the web service knows your DID. Then a web service assembles a claim for you and presents it as a QR code, which you consume using your smartwallet.
    Kasia Szawan
    @katszwn
    You can find the details of the API for these communication flows in our documentation - part 5 and 6 https://jolocom-lib.readthedocs.io/en/latest/
    And you can take a look at an example of implementation of the single sign on mechanism here https://github.com/jolocom/demo-sso
    To answer your last question - no, this part of documentation serves the purpose of creating an identity for a web service, with which you interact. The Smartwallet already implements the creation of your identity and serves as an entry point for everything related to your identity.
    samsmitt
    @samsmitt

    So the only way (for now) to issue and 'save' a claim into my wallet is to scan a specific QR code and accept it?

    Isn't it possible to issue a claim to another identity without him accepting the claim, like you showed in your guide on section 3.1?

    image.png
    Kasia Szawan
    @katszwn
    @samsmitt you can generate a claim knowing someone's DID, and sign it, but it's not equal to issuing a claim - because in order to issue a claim, you actually need to give it to someone so that they could accept it.
    You can generate all kinds of claims about anyone using our API, the difference here is whether you communicate it or not :) we recommend communication using QR codes, because it's quite handy, but we're working on other ways as well.
    Yes, for now that is the only way (for custom claims that you can't just enter from the level of the Smartwallet)
    samsmitt
    @samsmitt

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

    Eugeniu Rusu
    @Exulansis

    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.

    samsmitt
    @samsmitt
    Thanks for your explanation!
    Ellie Stephens
    @EllieStephens
    We're happy to share some good news - Jolocom won the Blockchain on the Move bid and will be working with the Flemish government, City of Antwerp, Digipolis, and V-ICT-OR to pilot an SSI solution for e-government 🍾 http://bit.ly/Blockchainonthemove
    Ellie Stephens
    @EllieStephens

    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

    Ellie Stephens
    @EllieStephens
    T-Labs Hack Berlin Poster .png

    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 👋🏼

    Ellie Stephens
    @EllieStephens
    In case you missed the T-Labs Hackathon this past weekend, a few really exciting use cases came out of it for self-sovereign identity using the Jolocom protocol & SmartWallet (2/3 winners were using Jolocom!) – car sharing, ecommerce, health +++ Take a look ➡ http://bit.ly/SSIusecases
    TLabsHACK PiDee team.jpeg
    TLabsHACK team Helia.jpeg
    Ellie Stephens
    @EllieStephens

    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

    Ellie Stephens
    @EllieStephens

    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.

    Eric Petruzzelli
    @BenchToMarket
    I am attempting to test the demo-sso on localhost, interfacing with smartwallet (app from googleplay). when i send my name credential to the localhost from my mobile, nothing happens, it is not received, i do not get the question, no receiving event is fired in demo-sso. I tried the default serviceUrl in config.ts & also changed to 'http://192.168.1.12:9000/'. I kept seed & password as defaults. ~I know there is a script to test, but want to use the device. Am I missing something simple?