RE: How should a resolver actually work

FYI ...CC: the CCG list on this discussion per Markus' suggestion... some good questions and answers.

From: Markus Sabadello <markus@danubetech.com>
Sent: March 11, 2019 3:17 AM
To: Tom Jones <thomasclinganjones@gmail.com>; Michael Herman (Parallelspace) <mwherman@parallelspace.net>
Subject: Re: How should a resolver actually work


Hello Tom,

I agree with everything Michael has said in this thread..

Different DID methods can work very differently in how DIDs are created, resolved, updated, deactivated.

E.g. for DID methods that are based on the Bitcoin blockchain ("btcr") or Ethereum blockchain ("erc725", "jolo", "uport"), yes with access to a full node you could make sure that you have the latest state of a DID and don't miss any updates to it.
There are techniques which in some cases allow you to get more or less reliable data from a distributed ledger, without requiring access to a full node, e.g. using "state proofs" in Indy, or "simple payment verification" in Bitcoin; but I'm not an expert on this.

Like Michael, I also believe Indy is the only one of the Hyperledger projects that supports DIDs, or at least I don't know any other.

BTW I would prefer this conversation to be public on the CCG list. I think Michael has correctly pointed out (on another issue) that transparency is very important in our work.

Markus
On 3/11/19 12:54 AM, Tom Jones wrote:
To be sure that I understand what you have told me.
There is a GitHub instance of a software platform?
Currently there is a single operational instance of that software and this is run by sovereign?
If I want more data, I should talk to that team?
I have already started that process. It sounds like there is nothing else for me to do to test indy?
Peace ..tom

________________________________
From: Michael Herman (Parallelspace) <mwherman@parallelspace.net><mailto:mwherman@parallelspace.net>
Sent: Sunday, March 10, 2019 4:39:15 PM
To: Tom Jones; Markus Sabadello
Subject: RE: How should a resolver actually work

RE: Ahhh, so there is an Indy Platform?

Yes Tom - the official repo is here: https://github.com/hyperledger/indy-sdk

Part of the confudsion is:

  1.  There is the Indy SSI software platform
  2.  There is the Sovrin SSI governance framework
  3.  The Sovrin Foundation hosts/runs an instance of the Indy software platform that implements the "did:sov" DID method governed by the Sovrin governance framework.

I explain these a bit more here (work in progress): https://github.com/mwherman2000/indy-dev/blob/master/python/doc/getting_started-enterpise.md#abstract

Best regards,
Michael Herman (Toronto/Calgary/Seattle)
Independent Blockchain Developer
Hyperonomy Business Blockchain / Parallelspace Corporation

W: http://hyperonomy.com<http://hyperonomy.com/>
C:  +1 416 524-7702


From: Tom Jones <thomasclinganjones@gmail.com><mailto:thomasclinganjones@gmail.com>
Sent: March 10, 2019 3:54 PM
To: Michael Herman (Parallelspace) <mwherman@parallelspace.net><mailto:mwherman@parallelspace.net>; Markus Sabadello <markus@danubetech.com><mailto:markus@danubetech.com>
Subject: RE: How should a resolver actually work

Ahhh, so there is an Indy Platform?
I assume it is not the ones I found for wheelchair lifts, wealth management or chip readers?
Perhaps you could point me to that?  I am looking for code (or implementable algos) that actually can be used as a did method in some way or another. I am trying to determine if any system in deployment can handle the load of an identity ecosystem; as I do intend stress tests.

In the meantime I will investigate did:sov
Peace ..tom

________________________________
From: Michael Herman (Parallelspace) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Sent: Sunday, March 10, 2019 2:43:17 PM
To: Markus Sabadello; Tom Jones
Subject: Re: How should a resolver actually work

Restating your question for clarity Tom as 2 questions...
1. In addition to the HyperLedger Indy project (software platform), on top of which other HyperLedger projects (software platforms) has "DIDs" and a DID Resolver been implemented on? e.g. HyperLedger Fabric, HyperLedger Sawtooth, etc.
Tom, I only know of the Indy platform.
2. Specifically wrt "other DID methods", I only know of the Sovrin DID method ("did:sov") being implemented on top of a HyperLedger project; and it is only implemented on one HyperLedger project: the Indy project (software platform).
Markus?
Get Outlook for Android<https://aka.ms/ghei36>

From: Tom Jones
Sent: Sunday, March 10, 2:56 PM
Subject: RE: How should a resolver actually work
To: Michael Herman (Parallelspace), Markus Sabadello
Right, so I want to move beyond the hyper-design and talk about a real-world example. Should I look to the IBM fabric for a definitive answer? Which of the did methods now support hyperledger?

Peace ..tom

From: Michael Herman (Parallelspace) <mwherman@parallelspace.net<mailto:mwherman@parallelspace.net>>
Sent: Sunday, March 10, 2019 1:41:05 PM
To: Markus Sabadello; Tom Jones
Subject: Re: How should a resolver actually work

Tom, Markus is more knowledgeable than me on this topic.  I can add that a "did" and it's attributes are stored as a series of related transactions in the Indy ledger. Markus does a great job of explaining this at this point in one of his webcasts: https://youtu.be/<https://youtu.be/gf2g4O3yqCc> gf2g4O3yqCc<https://youtu.be/gf2g4O3yqCc> ...time code 6:41.
As Markus explains in his webcast, this is different for different platforms.
Michael
Get Outlook for Android<https://aka.ms/ghei36>
From: Tom Jones <thomasclinganjones@gmail.com<mailto:thomasclinganjones@gmail.com>>
Sent: Sunday, March 10, 2019 2:03:40 PM
To: Markus Sabadello; Michael Herman (Parallelspace)
Subject: How should a resolver actually work

Sorry for excluding the full list but it is just too noisy.
I am not clear on how validation of the liveness of a did would actually proceed. I believe that I just traverse the chain backwards until if find the last block containing the did. I assume now that I don't need to go further back than that if I assume that ant disabling of the did would be the last transaction on the chain. That could be an error, unless that feature was enforced by the chain, which does not, at first glance appear to be the case.
In any case it seems that a bad did can only be discovered by a full scan of the full chain, which is only possible on full nodes. The following article seems to state that I cannot even be sure I can find a full node to allow such a scan, although I could be wrong. I have yet to implement on a ethereum style chain. Apparently I only need to validate blocks that contain the did if I am willing to trust the source, which seems to violate the premise of the did spec.
https://hackernoon.com/the-ethereum-blockchain-size-has-exceeded-1tb-and-yes-its-an-issue-2b650b5f4f62
thx ..Tom (mobile)