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

It is not interesting if the bar can find a verifiable claim. What’s interesting if the bar prevents underage kids from presenting claims that fail to satisfy the state licensing bureau. Otherwise they lose their license. 

thx ..tom

From: Stephen Curran
Sent: Sunday, December 16, 2018 6:07 PM
To: Chris Boscolo
Cc: Markus Sabadello; W3C Credentials CG; Nathan Aw; Oliver Terbu
Subject: Re: [Hyperledger Indy] Hyperledger Indy and Ethereum DIDs interoperability through decentralized universal resolvers on Ethereum/Indy- Nathan Aw from Singapore

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

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) | Reply To Sender | Reply To Group | Mute This Topic | New Topic

Your Subscription | Contact Group Owner | Unsubscribe [markus@danubetech.com]

_._,_._,_