Snorre Lothar von Gohren Edwin
toggle quoted messageShow quoted text
Are there any rapports or documentation on the diiferent interop work mentioned here? DHS-SVIP fex?
Sorry to jump in late to the conversation but I would like to add a positive interop experience in the context of the DHS-SVIP project.
Interop was defined as a set of specifications, and then a test suite was developed to measure compliance. (The specifications I am referring to are the HTTP-Issuer and HTTP-Verifier APIs in particular).
With the above approach, multiple companies were able to build their implementations and test in their sandbox before having “live” expectations of interoperable cross-implementation functionality. So where ever this group wishes to claim
“interop” I would highly recommend the above approach. It also helps define scope, which Sankarshan is highlighting.
I also want to +1 Daniel’s sentiment below that we should start with ‘pontoon bridges’. I can confirm that the above HTTP- API specs are exactly that (pontoon bridges with twine and duct tape
😉 ). They work, prove a concept, but are far from finished or accepted – but the specs provide a nice context to discuss issues and evolve.
So if we can define the specs the group wishes to implement (or write in order to implement) and then develop a compliance test suite, the scope of interoperability should be clear.
My $0.02, thanks.
I love that Sankarshan asked this nuanced question.
As he implied, I don't think interop is a binary thing (we have it or we don't). It's more on a continuum, and it's a moving target (which implies a carrying cost we should wrestle). Its desirability is a function of the maturity of the ecosystems that are
trying to interoperate, vis-a-vis that carrying cost. Interop is valuable exactly to the extent that it allows business (or individual customer) value to flow between what previously were two isolated lands. Thus, it's important to interop between valuable
island-A and valuable island-B -- but a waste of time to interop with barren territory C if building a bridge there enables no traffic because it has no population. Back in the day, it was important for MS Word and WordPerfect to interoperate, but Wordpad
interop was never worth pursuing. When LibreOffice became a big enough thing, interop with it became worthwhile as well.
In the case of wallets, I think that
today, interop that allows data to migrate is "starting to be desirable" whereas interop of interfaces or UX is "barely relevant." That's because
today, the amount of traffic that would cross a bridge between two islands is tiny, and the amount of valuables they'd carry from one side to another is also tiny. However, if I recast that in a timeframe of
tomorrow, data migration interop becomes "strongly required to validate the value prop of SSI" and the interop of interfaces and UX maybe evolves to "nice to have."
You could make a claim that if we think about interop and standards now instead of later, we'll have the bridge when we need it. I partly believe this claim; knowing that we can plug some things together is important
even in early design. Thus, I participate in these efforts. However, I think there are important caveats we may not acknowledge enough in our enthusiasm for interop. Building a bridge from island A to island B before either island has a mature road system
might lead to bad (=wrong, or suboptimal, or just expensive-to-maintain) guesses about where the bridge should anchor and how much traffic it should plan to hold. In the same way, creating a standard before we have real-world experience to know whether we
like its tradeoffs is likely to produce a lower-quality standard with higher friction to implement, and higher carrying costs, than standardizing once we know which feature pressures matter most to customers. A better approach is often to approach interop
as a pragmatic and ongoing effort for a while (build an ad hoc, floating pontoon bridge), let the ecosystem mature, and then apply the cement and steel of a standard once our confidence is higher. Or, alternatively, throw out a rough-and-ready draft standard
and let people implement against it in experimental mode; keep talking but don't take it to a formal standard for a good long while. I feel like our community is A) too quick to try to standardize; and B) unreasonably impatient with those who don't equate
interop (get a bridge of any kind, and start using it) with standards (steel and concrete bridges).
Sankarshan's question about the utility network layer is a good illustration of this tension. There are different DID methods. They don't have fully equivalent features. We can put them behind a common interface,
but it's a good thing to have them jostle and rub against each other a bit. We learn stuff. Mattr's recent introduction of a ZKP VC mechanism that lacks the dependency on credential definitions on a ledger has convinced me that Indy's support for credential
definitions isn't particularly necessary; thus, its DID method can learn something and change. I'm glad I didn't push for credential defs as a ledger feature to standardize. On the other hand, I think the proof-of-control-from-inception-instead-of-from-registration
feature that Indy and Veres One pioneered, and that KERI has recently articulated with enhanced clarity, are a feature that all DID methods ought to consider. I know that did:ion and did:peer have both adopted that property...
I guess what I'm saying is that I'm most enthusiastic about this DIF effort building pontoon bridges. We're a very young ecosystem, and we need to see how traffic flows between the islands. Let's not think of this as a standards effort. Let's not tell our customers
that they're going to have rock-solid interop right now; I think that's unrealistic and sets expectations unfairly with them. And let's patiently learn from our pontoon bridges, not rush to start a steel-and-concrete standards effort with a ticking countdown.
Editing the subject (because this is as good a thread as any to write this)
I was wondering whether the group would consider a first working
definition of the term "interoperability" in order to better scope the
angles from which to approach this. If I look at the list of work
items they reflect a diverse range of interests but as a whole perhaps
do not indicate to an end user about the nature, extent and scope of
interoperability when considering a design architecture composed of
the items listed in there (and then some more).
As a trivial (and perhaps strawman) example - is interoperability at
the utility network stack desirable or even required? At what level of
abstraction can this be viewed so as to consider interoperability in
terms of a service contract? Do wallets really need to be
interoperable (as in there is a need in the foreseeable future to move
I think what I am attempting to tease out here is the answer to
"interoperability, yes - but to what end?" Which I believe would be a
way to review the progress being accomplished across existing and new
On Wed, 22 Jul 2020 at 22:48, Balázs Némethi <balazs@...> wrote:
> Dear all,
> Thank you for joining the 3rd Interop meeting.
> For more information on the meeting, we are using this Notion page as our Wiki and "product management" tool. You can find the most important documents and meeting minutes/recording there.
> We are aware that setting up a WG might not be the most exciting work. However, if we get it right and make it work for everyone, we will be able to deliver a real impact on the community.
> Action items:
> I would like to ask everyone to reread and comment on the WG charter, so we have everyone's opinion.
> Please attend the coming meeting(s) as active participation will be required to cast a vote.
> Please nominate potential WG chairs using this FORM. - Next meeting, 29th July - Wednesday, we will start the WG chair elections.
> Add potential work items for the Interop WG - These points be used as the base for the work the group will be doing.
> Join the mailing list to simplify communication - all future discussions will take place there.
> If you have any questions or concerns, please reach out to Juan or me.
> Please circulate this email within your communities.
> If someone would like to get a calendar invite, use this form.
> Best regards,
> Balázs Némethi
> Operations @ DIF
This email and any attachments are for the sole use of the intended recipients and may be privileged, confidential or otherwise exempt from disclosure under law. Any distribution, printing or other use by anyone other than the intended recipient is prohibited.
If you are not an intended recipient, please contact the sender immediately, and permanently delete this email and its attachments.
Snorre Lothar von Gohren Edwin