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

I appreciate the added color on my example, but the purpose of my original
question was to unearth how the software components interact, not to dig in
on the trust-model required to use an over-21 verified claim. I probably
should have used a different example. That is also important to understand,
but I am hoping we can continue to clarify how this universal resolver will
be used in the context of the various deployments.

To make this more concrete, let's image the website in my example receives
VC which contains a DID of the form: "did:acme:xx11yy22zz33".  What steps
does this website use to find the DID document for this DID.  (This is the
first time this website has ever seen the DID method called "acme".)

I think if we can answer this in a way that satisfies the requirements to
preserve the decentralized requirements of SSI as well being scalable and
interoperable, it will go a long way to help bring people onto the SSI
bandwagon.

   -chrisb


On Sun, Dec 16, 2018 at 6:05 PM Stephen Curran <swcurran@cloudcompass.ca>
wrote:

> That example starts as a fairly straight forward use case, but gets quite
> interesting.
>
> The bar has to prove that the Issuer of the VC (e.g. a DMV in the US) used
> to prove their age is one the Bar trusts. If the Base only has customers
> from their own jurisdiction (or even nearby ones), then that's pretty easy
> - they could effectively hard code the checking of the Issuer's DID against
> the local Issuers when doing the Issuer check to verify that the Credential
> was issued by a known party. Assuming their "Age Checker" software can
> interact with the local Issuer's Verifiable Data Registry - all good.
>
> However, if the Bar wants to serve every twenty-something in the world,
> then the Trust check really must be able to interact with any Verifiable
> Data Registry world-wide. Thus, the Bar needs software that interacts with
> any Verifiable Data Registry - hence it needs access to a Universal
> Resolver it trusts. Since this SSI-enabled Bar is running enough software
> that it trusts to verify the Verifiable Claim Presentation it's been given,
> it's not unreasonable that the software include an instance of the
> Universal Resolver, or accesses a hosted version that the Bar trusts. So
> that's the long-winded answer to Chris's question.
>
> Note that what gets more interesting with the last case is when the
> Universal Resolver returns the DID of an Issuer that the Bar has never seen
> before, and the Bar (or more specifically, the people running the Bar) has
> to determine if the Bar is going to trust the Issuer behind the previously
> unknown DID. The Bar has to discover under what authority the Issuer can
> issue an Age Credential about the Holder. Thus, the Bar's software has to
> carry out some process - for example, asking for Verifiable Claims from the
> Issuer about it's authority - so the Bartender can decide if the Issuer
> (not the Holder) can be trusted. The DID owner might be able to prove that
> it's a part of a government of a region of a country. Each VC Issuer in the
> chain might have to be checked - "Do I believe that Issuer"?
>
> This process mimics today's bartender getting a paper Driver's Licence
> from a new place (e.g. a bar in Portland, OR gets it's first ever customer
> from Newfoundland). All the bartender currently has to go on is "does this
> look like a real driver's licence?". The cool thing with the VC process is
> that if there is a group of Newfoundlanders that all have a VC proving
> their age from Credentials issued by the same Issuer, the one check of the
> Issuer's authority is good enough for all Verified Claims to be accepted.
>
> I find the interactive nature of investigating an issuer is interesting.
> While one could think the number of Age-proof issuers is relatively finite,
> think about the University Degree use case - where there is a very high
> number of authorized degree-granting Institutions world-wide - and an
> equally high number of organizations that lack the authority to issue
> degrees.
>
> *Stephen Curran*
> Principal, Cloud Compass Computing, Inc.
> P // 250-857-1096
> W // https://www.cloudcompass.ca
> [image: Twitter] <https://twitter.com/scurranC3I>
> On Dec 16 2018, at 10:21 pm, Chris Boscolo <chris@boscolo.net> wrote:
>
> 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]
>
> _._,_._,_
>
>