Re: Work Items [was:Re: Interoperability WG - follow up/next steps - #3 meeting]

Adrian Gropper
 

I was not involved in Phase 1 of the SVIP process. My impression is that interop was defined from the perspective of: “No vendor lock-in for the issuer.” That has some downstream effects on holders and verifiers and next-gen app developers, but it’s indirect. 

It’s hard to reconcile decentralization with business realities in the context of interop. Effective standards and seamless interoperability at the business model level would make digital identity as much of a commodity as our analog identities are. So, investors and entrepreneurs are looking for “platforms” to bundle services that might touch every actor in the digital identity value chain. Cue Sovrin, the Linux Foundation, and a couple of others.

Real decentralization would not support platform business models because platforms and global corporations are about reducing transaction costs through internal and/or tightly managed federations. Interoperability is not their priority and “data portability” is often used to deflect the conversation away from the massive governance problems and stagnant innovation that real interoperability might solve.

My point is that our SSI community is at a crossroads. One fork sees interoperability as a data portability issue: “How can I move my data from one identity platform or hub to another?” The other fork sees interoperability as a self-sovereign technology issue: “How can I reduce lock-in to any corporate or political tech governance institution?”

- Adrian


On Thu, Jul 23, 2020 at 5:05 PM Snorre Lothar von Gohren Edwin <snorre@...> wrote:
Are there any rapports or documentation on the diiferent interop work mentioned here? DHS-SVIP fex?

On Thu, Jul 23, 2020 at 9:44 PM Mike Varley <mike.varley@...> wrote:

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.

 

MV

 

From: <interop-wg@DIF.groups.io> on behalf of "Daniel Hardman via groups.io" <daniel.hardman=evernym.com@groups.io>
Reply-To: "interop-wg@DIF.groups.io" <interop-wg@DIF.groups.io>
Date: Thursday, July 23, 2020 at 2:36 PM
To: "interop-wg@DIF.groups.io" <interop-wg@DIF.groups.io>
Cc: Balázs Némethi <balazs@...>
Subject: Re: [InteropProject] Work Items [was:Re: Interoperability WG - follow up/next steps - #3 meeting]

 

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.

 

On Thu, Jul 23, 2020 at 5:48 AM sankarshan <sankarshan@...> wrote:

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
keys/secrets around)?

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
work items.

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
Co-Founder & CTO, Diwala
+47 411 611 94
www.diwala.io

Join interop-wg@DIF.groups.io to automatically receive all group messages.