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

Juan Caballero

This is a great conversation, and I value every contribution to it so far. I would just like to underscore a few points:

Sankarshan asked if we risk turning interop into an end unto itself without defining scopes or use cases against which to judge the degree of portability or bridge-building needed in the short- and medium-term.  I think this is apt, but I also see some merit in Balázs's contrast between working both *backwards* from requirements and working *forward* from principles. It is not either/or-- we need to balance long-term principles against short-term scopes to get enough adoption for there to be a medium-term.  Daniel's framing that interop's value is proportional to maturity hints at how complex the timeline is here. No Gantt chart is possible: instead, mapping interoperability will most likely look more like this:

Adrian, Sankarshan, Daniel and I all seem to agree that "interop" relative to a static or pre-defined stack or layered model (whether in SDS or in the entire stack) is a dangerously broad commitment that risks putting the cart before the horse, or in Daniel's Catan-like extended metaphor of the development archipelago, building concrete bridges to low-value, uninhabited islands. I think we can all agree that a over-broad, ocean-boiling interop profile could waste more time than it saves, particularly if it fails to set priorities and timelines reasonably. That said, breaking down that overbroad commitment into a debatable, mix-and-matchable list of more concrete and narrow goals would be a useful counterbalance to the pragmatism of realistic short-term goals which could lead us to premature standardization if not counterbalanced. (Shout out to Daniel's humility and fairness in describing some points in our shared past where premature standardization was narrowly avoided!)

One of those constituent principles is data portability, which is foremost among my personal ideological commitments. But Adrian is very right to point out that data portability might be the least controversial or least costly to defend of the constituent principles bandied about in this community's manifestos. Data portability is only one kind of portability, and many other kinds of platform or business-model lock-in exist beyond proprietary blockchains and proprietary clouds. Another principle worth balancing against the exigencies of the present are cryptographic agility, or as Nathan George once defined it to me, "forward-compatibility and backwards-security". Less a principle than a duty that might belong on this list is strategies to mitigate cryptographic gatekeeping: needless archipelagos have already been created by key governments enforcing allowlists and blocklists of crypto suites in their budget appropriations. If I can nerd out a little, Connection/contact portability, Wallet portability, policy/control portability, inception-event specification/interop and cloud portability have all been floated in recent weeks as bridges worth specifying or beginning to build, which reflect principles lower down the priority list but not front of mind for most profit-maximizing businesses. These are all items for the interop WG's agenda, even if the result of each discussion could well be "let's discuss again in 6 more months".

I wholeheartedly agree that Orie has been doing an insane amount of work to date trying to get contingent, good-enough-for-now specs in place that lay the groundwork for a truly competitive and open-protocol-driven stack built over the next few years. The Interop WG has high on its short-term priorities:
1. assessing/comparing the definitions/scopes of interop defined by the Aries Interop Profile, SVIP testing suites, etc., with an eye to gaps but not inventing them if none turn up.
2. formalizing its own complementary short- and medium-term goals relative to those gaps

Anyways, I guess I'm supposed to end this rambling jeremiad with a call to action, so here are a few things you can do:
- forward this long email thread to people who might care, and tell them to sign up for this mailing list if they really care:
- contribute to the Glossary WG's discussion of endpoint types here:
- contribute to NIST's call for input

Thanks interopers!

On 7/24/2020 3:16 PM, Mike Varley wrote:

Yes; and I apologize for not attaching links earlier. I’ll do my best to provide references.


The specs I was referring to


The test suite and results (notice they haven’t been run in over a month though):


And here is the archived email from Anil John sent to the w3c-ccg with a presentation that explains the program and the outcomes.


I think that covers most of what I was referring to – happy to answer any other questions. You’ll also see Orie’s name on a lot of this; his efforts really made it happen.


And I will say the above process wasn’t at all perfect (due to a deadline many things were rushed through) but the pattern of spec -> test suite -> implementation -> interop I think was successful, even if it was for ‘pontoon bridges’ :)








From: <> on behalf of "Snorre Lothar von Gohren Edwin via" <snorre@...>
Reply-To: "" <>
Date: Thursday, July 23, 2020 at 5:05 PM
To: "" <>
Cc: Balázs Némethi <balazs@...>
Subject: Re: [InteropProject] Work Items [was:Re: Interoperability WG - follow up/next steps - #3 meeting]


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.




From: <> on behalf of "Daniel Hardman via" <>
Reply-To: "" <>
Date: Thursday, July 23, 2020 at 2:36 PM
To: "" <>
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

Juan Caballero
Communications & Research Lead
Spherity GmbH, Emil-Figge-Straße 80, 44227 Dortmund
Next meetup 18/5:

Berlin-based: +49 1573 5994525 
Signal/whatsapp: +1 415-3101351

Join to automatically receive all group messages.