Re: Work Items [was:Re: Interoperability WG - follow up/next steps - #3 meeting]
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.
<interop-wg@DIF.groups.io> on behalf of "Daniel Hardman via groups.io" <daniel.hardman@...>
I love that Sankarshan asked this nuanced question.
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...
On Thu, Jul 23, 2020 at 5:48 AM sankarshan <sankarshan@...> wrote:
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.