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

Hi,

I have a question. Has anyone done a "failure analysis" by gaming out 
how a professional phishing operation might penetrate the DID system and 
create a system that would redirect users to enter passwords into a 
phishing site, harvest info during key recovery, hack social recovery, 
or falsify VCs?

And if we figured how to handle such situations, how do we share this 
knowledge without enabling untrustable parties from learning from it?

Moses



On 12/16/18 12:41 PM, Markus Sabadello 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
>
>
>

-- 

*Moses Ma | Managing Partner*

moses.ma@futurelabconsulting.com | moses@ngenven.com

v+1.415.568.1068 | skype mosesma | /linktr.ee/moses.tao/ 
<http://linktr.ee/moses.tao>

FutureLab provides strategy, ideation and technology for breakthrough 
innovation and third generation blockchains.

Learn more at /www.futurelabconsulting.com/ 
<http://futurelabconsulting.com>. For calendar invites, please cc: 
mosesma@gmail.com


Or whet your appetite by reading /Agile Innovation/ 
<http://www.amazon.com/Agile-Innovation-Revolutionary-Accelerate-Engagement/dp/B00SSRSZ9A> 
| /Blockchain Design Sprint/ 
<https://www.amazon.com/Blockchain-Design-Sprint-Workbook-Implement/dp/1548592714> 
| my blog at /psychologytoday.com/ 
<http://www.psychologytoday.com/blog/the-tao-innovation>.