- From: Chris Boscolo <chris@boscolo.net>
- Date: Sun, 16 Dec 2018 13:21:58 -0800
- To: Markus Sabadello <markus@danubetech.com>, W3C Credentials CG <public-credentials@w3.org>
- Cc: Nathan Aw <nathan.mk.aw@gmail.com>, Oliver Terbu <oliver.terbu@consensys.net>
- Message-ID: <CAByYRhYpyH4jrC8-kJUsMKTcPkZSv1fxpz4r7E9R-rs7Jra30g@mail.gmail.com>
Markus, When you say: "The whole point is that *you* should run your own instance of this Universal Resolver (or other DID resolver implementations)." Who is the "you" in that sentence? For example, let's say that I am running a website where I need to ensure visitors of the site are over the age of 21 to enter. Users of the site can present a VC proving their age. Are you suggesting that the operator of this website would need to run an instance of this open source universal resolver? I think I know the answer to this question, but I am asking to help tease out some of the architectural holes in our approach to SSI, so we can address them and drive adoption. -chrisb On Sun, Dec 16, 2018 at 12:42 PM Markus Sabadello <markus@danubetech.com> wrote: > Nathan, > > One thing to point out is that https://uniresolver.io/ is running one > public instance of the Universal Resolver (I assume that's why you call it > "centralized"). > Of course you should NOT use this public, centralized instance for > anything other than simple testing and debugging, precisely because you > don't want to trust that hosted service with anything important. > > The whole point is that you should run your own instance of this Universal > Resolver (or other DID resolver implementations). It's open source, so you > can deploy it yourself. This makes it "decentralized": > https://github.com/decentralized-identity/universal-resolver/ > > Regarding your point 2.: > - "Getting hold of one's DID" is strictly speaking method dependent. > Typically a DID is controlled by a private key, and if you lose access to > the private key, then you lose control over your DID and DID document. But > "control over a DID" can also be implemented in a more nuanced way, e.g. > there could be different keys with different "capabilities", and if you > lose access to one private key, then there may be ways to still recover > control over your DID and DID document in other ways. Again, this is DID > method dependent. > - The DID document is considered public, anyone in the world can read it, > just like anyone in the world can resolve a domain name to its IP address. > This means you shouldn't have any sensitive/private information in the DID > document anyway. > - Losing control over your DID and DID document does not necessarily have > implications on the services that are discoverable from the DID. For > example, if an attacker "gets hold of your DID", then that attacker may > still not be able to access an ActivityPub service, or XDI service, or > Sovrin agent that is associated with the DID. > > Markus > On 12/16/18 12:19 PM, Nathan Aw wrote: > > Hi Oliver, Markus, > > Many thanks. I took a deep look at the universal resolver and its > specifications at https://uniresolver.io/. It is really great. Some > questions I have. > > 1. Like a DNS system, is there some way that one can contribute to make > the universal resolver a decentralized one? (Based on my limited > understanding, the universal resolver is currently centralized.) > 2. If an attacker gets hold of one's DID, e.g., > did:sov:WRfXPg8dantKVubE3HX8pw, he or she gets all the DID document and its > service endpoint and some public key -- is this potentially troubling? > > Thanks ! > > Regards, > > Nathan Aw > > On Wed, Dec 12, 2018 at 2:47 AM Oliver Terbu <oliver.terbu@consensys.net> > wrote: > >> Hi, >> >> Please note, that ERC 1056 is also supported (did:ethr). >> >> Best, >> Oliver >> >> On 10. Dec 2018, at 21:31, Markus Sabadello <markus@danubetech.com> >> wrote: >> >> Hello Nathan, >> >> You're probably referring to the DIF Universal Resolver: >> https://github.com/decentralized-identity/universal-resolver/ >> >> It uses a set of "drivers" which can resolve different DID methods to >> their DID Documents. >> This is the basis for building ledger-agnostic, interoperable identity >> platforms. >> Sovrin/Indy as well as ERC725 are among the ones that are supported. >> >> See here for more information: >> Blog post: >> https://medium.com/decentralized-identity/a-universal-resolver-for-self-sovereign-identifiers-48e6b4a5cc3c >> Public instance of the Universal Resolver: https://uniresolver.io/ >> Webinar: >> http://ssimeetup.org/did-resolution-given-did-how-do-retrieve-document-markus-sabadello-webinar-13/ >> >> This is not the only implementation of a DID resolver out there, here are >> others: >> - https://github.com/digitalbazaar/did-cli >> - https://github.com/uport-project/did-resolver >> >> Markus >> On 12/10/18 6:04 PM, Nathan Aw wrote: >> >> Hi all, this is Nathan Aw from Singapore. >> >> As one's decentralized identity can and should reside on different >> ledgers/blockchain for maximum resilence and coverage, I am working on >> blockchain interoperability solution between Ethereum and hyperledger indy >> (Sovrin), specifically how DIDs (Decentralized Identifiers) on different >> ledgers/blockchain can be linked, established and implemented (roll out) on >> a planetary scale. >> >> 1. Establishing the link between ethereum account ID (erc 1056, erc 780, >> 725, 735) and Hyperledger Indy DIDs state variables through Hyperledger >> Indy Universal Resolver / Universal Registrar and/or an Ethereum-based >> universal DID resolvers >> >> Is there some way to design and build a decentralized universal DID >> resolvers in Ethereum that interfaces with Hyperledger Indy DIDs Universal >> Resolvers? >> >> Wondering if anyone could provide inputs to the possible ways of >> integration between this 2 major decentralized identity platforms? >> >> Thank you. >> >> Nathan Aw from Singapore >> >> https://sg.linkedin.com/in/awnathan >> >> >> https://datatracker.ietf.org/meeting/103/materials/slides-103-dinrg-decentralized-identity-01 >> >> https://www.hyperledger.org/news/speakersbureau >> >> https://erc725alliance.org/ >> >> https://www.hyperledger.org/community/technical-ambassador >> >> https://www.meetup.com/BlockChain-Dapps-Technology/events/254556114/ >> >> >> https://www.hyperledger.org/blog/2017/12/05/developer-showcase-series-nathan-aw-ntt-data >> >> https://www.meetup.com/Hyperledger-HK/events/248011521/ >> >> https://blockchain.ieee.org/newsletter/editorial-board >> _._,_._,_ >> ------------------------------ >> Links: >> >> You receive all messages sent to this group. >> >> View/Reply Online (#300) >> <https://lists.hyperledger.org/g/indy/message/300> | Reply To Sender >> <Nathan.mk.aw@gmail.com?subject=Private:%20Re:%20%5BHyperledger%20Indy%5D%20Hyperledger%20Indy%20and%20Ethereum%20DIDs%20interoperability%20through%20decentralized%20universal%20resolvers%20on%20Ethereum%2FIndy%20-%20Nathan%20Aw%20from%20Singapore> >> | Reply To Group >> <indy@lists.hyperledger.org?subject=Re:%20%5BHyperledger%20Indy%5D%20Hyperledger%20Indy%20and%20Ethereum%20DIDs%20interoperability%20through%20decentralized%20universal%20resolvers%20on%20Ethereum%2FIndy%20-%20Nathan%20Aw%20from%20Singapore> >> | Mute This Topic <https://lists.hyperledger.org/mt/28715771/952282> | New >> Topic <https://lists.hyperledger.org/g/indy/post> >> >> Your Subscription <https://lists.hyperledger.org/g/indy/editsub/952282> >> | Contact Group Owner <indy+owner@lists.hyperledger.org> | Unsubscribe >> <https://lists.hyperledger.org/g/indy/unsub> [markus@danubetech.com] >> _._,_._,_ >> >> >> >> >
Received on Sunday, 16 December 2018 21:22:33 UTC