W3C home > Mailing lists > Public > public-credentials@w3.org > December 2018

Re: [Hyperledger Indy] Hyperledger Indy and Ethereum DIDs interoperability through decentralized universal resolvers on Ethereum/Indy - Nathan Aw from Singapore

From: Chris Boscolo <chris@boscolo.net>
Date: Sun, 16 Dec 2018 13:21:58 -0800
Message-ID: <CAByYRhYpyH4jrC8-kJUsMKTcPkZSv1fxpz4r7E9R-rs7Jra30g@mail.gmail.com>
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>
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

This archive was generated by hypermail 2.3.1 : Sunday, 16 December 2018 21:22:34 UTC