Date   

Re: Interop meeting - today

Adrian Gropper
 

The Jolocom definition reminds me of WiFi or Bluetooth where seeing the SSI logo would be all one needs to expect a certain level of functionality and where differences in the features of a WiFi or BT implementation are minor and not market differentiators. 

So, your SSI definition approach is fine but would such a narrowing of scope to many be a handful of “profiles” be acceptable to our community.

- Adrian

On Thu, Jul 30, 2020 at 5:17 AM Kai Wagner <kai@...> wrote:

Hello Taylor, @all

thank you very much for picking up the "define interop" discussion again.

At Jolocom, we have been thinking about this for a long time and it is one of our main decision making factor as we move on in developing our SSI technology.

While I hear the points made by Daniel Hardman on building interop only where relevant populations are present, I can not agree with it. In fact, the approach described by Daniel might even lead to a discussion on compatibility, rather than interoperability (see wikipedia citation below).

"interoperability imply Open standards ab-initio, i.e. by definition. Interoperability implies exchanges between a range of products, or similar products from several different vendors, or even between past and future revisions of the same product. Interoperability may be developed post-facto, as a special measure between two products, while excluding the rest, by using Open standards. When a vendor is forced to adapt its system to a dominant system that is not based on Open standards, it is not interoperability but only compatibility."

At Jolocom, we have defined interoperability like this:

"All agents / participants can communicate and interact with each other directly, without intermediaries, regardless of the agent / wallet implementations being used. The participants do so by supporting a common set of interfaces, and communicating using open and well-established specifications. Ideally this communication should not be facilitated by a 3rd party provided / maintained infrastructure, as this bears the risk of a lock in effect and centralization of the larger infrastructure."

With this definition as a starting point, we have tried to operationalize interoperability by describing the result of interop in the following statements:

  • As an Issuer/Verifier I can present one QR code to request interactions, regardless of what wallet/agent is on the other end (I never have to care).
  • As an identity subject/holder I can use any wallet I want, I can move across wallets, including encrypted backups.
  • An identity Holder can present a Verifiable Credential to a Verifier, regardless of which implementation the verifier or issuer uses, or which wallet the Holder uses.
  • As a Verifier, I can resolve DIDs from any DID method and use the DID Document to verify signatures, regardless of which DID method the document is from.
  • As a Verifier, I can check the integrity of the Credential regardless of the implementation used by the issuer of that credential as well as the holder.
  • As a developer, I can use any implementation of SSI tools (i.e. libraries, CLI tools) and expect it to perform its role with other deployments.

The above points are only a start and feedback is much welcomed. Ultimately, we think the discussion on interop need to lead to a modular and open ecosystem where interoperability is achieved by following standards and specifications, rather that "welding things together", which is handled in a "different IIW community".

I hope we can bring the interop-working group to work in that direction.

Looking forward to your thoughts and ideas.

Best

Kai

Kai Wagner
Partnership Development

+49 176 83 588 604


Twitter: @kai_dentity


jolocom.io info@... Our events
Twitter Telegram GitHub YouTube Blog

Jolocom GmbH, Waldemarstrasse 37A, 10999 Berlin, Germany
CEO (Geschäftsführer): Joachim Lokhamp
Amtsgericht Charlottenburg (Berlin): HRB 158758 B
Am 29.07.20 um 17:07 schrieb Taylor Kendal:
As follow-on to the “define interop” discussion. 

Is it possible/reasonable to land on a common denominator (highest level possible) which could broaden/narrow based on groups represented?

The ability of a system to work with or use the component parts of another system.


Or a bit more specific:


The ability for different systems, devices or applications to connect, in a coordinated manner, within and across organizational boundaries to access, exchange and cooperatively use data amongst stakeholders.


Then the inevitable moving targets fall under various sub-domains (foundational, structural, semantic, organizational, etc.) 

Also, as far as “outputs,” I think there’s intangible value in simply having a neutral venue for building/sharing context. 
*Recommended practice: join DIF interop wg :)

Food for thought...

Taylor Kendal, CPO


From: Balázs Némethi <balazs@...>
Sent: Wednesday, July 29, 2020 6:00:39 AM
To: interop-wg@dif.groups.io <interop-wg@dif.groups.io>
Subject: Interop meeting - today
 
Dear all,

A few reminders about today's meeting and next week's:
  • The nomination of chairs will close - if you have not, please nominate using this form
  • Election of chairs will happen over email.  You'll receive information after the meeting
  • It will be open for one week
  • Ballots will be checked against the attendance records of this group: 2 of the last four meetings when ballots close, i.e., last two meetings, today, and next week's.
  • During today's meeting, we'll do a little more issue review on the charter, a little discussion of the ballot, and the rest of the time will be to discuss workitems and roadmap
Best regards,
 --

Balázs Némethi
Operations @ DIF


Re: Interop meeting - today

Kai Wagner
 

Hello Taylor, @all

thank you very much for picking up the "define interop" discussion again.

At Jolocom, we have been thinking about this for a long time and it is one of our main decision making factor as we move on in developing our SSI technology.

While I hear the points made by Daniel Hardman on building interop only where relevant populations are present, I can not agree with it. In fact, the approach described by Daniel might even lead to a discussion on compatibility, rather than interoperability (see wikipedia citation below).

"interoperability imply Open standards ab-initio, i.e. by definition. Interoperability implies exchanges between a range of products, or similar products from several different vendors, or even between past and future revisions of the same product. Interoperability may be developed post-facto, as a special measure between two products, while excluding the rest, by using Open standards. When a vendor is forced to adapt its system to a dominant system that is not based on Open standards, it is not interoperability but only compatibility."

At Jolocom, we have defined interoperability like this:

"All agents / participants can communicate and interact with each other directly, without intermediaries, regardless of the agent / wallet implementations being used. The participants do so by supporting a common set of interfaces, and communicating using open and well-established specifications. Ideally this communication should not be facilitated by a 3rd party provided / maintained infrastructure, as this bears the risk of a lock in effect and centralization of the larger infrastructure."

With this definition as a starting point, we have tried to operationalize interoperability by describing the result of interop in the following statements:

  • As an Issuer/Verifier I can present one QR code to request interactions, regardless of what wallet/agent is on the other end (I never have to care).
  • As an identity subject/holder I can use any wallet I want, I can move across wallets, including encrypted backups.
  • An identity Holder can present a Verifiable Credential to a Verifier, regardless of which implementation the verifier or issuer uses, or which wallet the Holder uses.
  • As a Verifier, I can resolve DIDs from any DID method and use the DID Document to verify signatures, regardless of which DID method the document is from.
  • As a Verifier, I can check the integrity of the Credential regardless of the implementation used by the issuer of that credential as well as the holder.
  • As a developer, I can use any implementation of SSI tools (i.e. libraries, CLI tools) and expect it to perform its role with other deployments.

The above points are only a start and feedback is much welcomed. Ultimately, we think the discussion on interop need to lead to a modular and open ecosystem where interoperability is achieved by following standards and specifications, rather that "welding things together", which is handled in a "different IIW community".

I hope we can bring the interop-working group to work in that direction.

Looking forward to your thoughts and ideas.

Best

Kai

Kai Wagner
Partnership Development

+49 176 83 588 604


Twitter: @kai_dentity


jolocom.io info@... Our events
Twitter Telegram GitHub YouTube Blog

Jolocom GmbH, Waldemarstrasse 37A, 10999 Berlin, Germany
CEO (Geschäftsführer): Joachim Lokhamp
Amtsgericht Charlottenburg (Berlin): HRB 158758 B
Am 29.07.20 um 17:07 schrieb Taylor Kendal:
As follow-on to the “define interop” discussion. 

Is it possible/reasonable to land on a common denominator (highest level possible) which could broaden/narrow based on groups represented?

The ability of a system to work with or use the component parts of another system.


Or a bit more specific:


The ability for different systems, devices or applications to connect, in a coordinated manner, within and across organizational boundaries to access, exchange and cooperatively use data amongst stakeholders.


Then the inevitable moving targets fall under various sub-domains (foundational, structural, semantic, organizational, etc.) 

Also, as far as “outputs,” I think there’s intangible value in simply having a neutral venue for building/sharing context. 
*Recommended practice: join DIF interop wg :)

Food for thought...

Taylor Kendal, CPO


From: Balázs Némethi <balazs@...>
Sent: Wednesday, July 29, 2020 6:00:39 AM
To: interop-wg@dif.groups.io <interop-wg@dif.groups.io>
Subject: Interop meeting - today
 
Dear all,

A few reminders about today's meeting and next week's:
  • The nomination of chairs will close - if you have not, please nominate using this form
  • Election of chairs will happen over email.  You'll receive information after the meeting
  • It will be open for one week
  • Ballots will be checked against the attendance records of this group: 2 of the last four meetings when ballots close, i.e., last two meetings, today, and next week's.
  • During today's meeting, we'll do a little more issue review on the charter, a little discussion of the ballot, and the rest of the time will be to discuss workitems and roadmap
Best regards,
 --

Balázs Némethi
Operations @ DIF


Re: Interop meeting - today

Adrian Gropper
 

A "Top Down" way to structure the work of the interoperability WG, complementing the ethical imperative, would be to collect the top 10 issues from today's hearings on Google, Amazon, Facebook, and Apple. It would be relatively straightforward to go through this one NYTimes article https://www.nytimes.com/live/2020/07/29/technology/tech-ceos-hearing-testimony and pick out the top 10 issues raised that touch on decentralized identitifiers and verifiable credentials. Once we have those 10, the exercise would have us analyze how interoperability might mitigate those concerns and what the overlap is with DID and VC.

Top Down would be a contrast to the current Bottom Up approach where different groups like DIF and ToIP organize to tackle a dozen or more subsidiary standards like DIDcomm and SDS.

- Adrian


On Wed, Jul 29, 2020 at 3:11 PM orie <orie@...> wrote:
Thanks Agrian, that's very helpful framing.

Regarding the position, the decision by Mike Jones / Daniel Buchner and Microsoft to support a "Pure JSON" data model, by deleting `@context` and destroying interoperability with JSON-LD is clear example of an attempt to create vendor lock in, and reduce choices, and destroy interoperability for political reasons.

I suggest we all be vigilant to the implications of decisions like that, and I would argue that the W3C DID WG should remove the "Pure JSON" data model from consideration, since there are no implementations, and it can be distinguished from JSON-LD, by the lack of an `@context`.... they literally just delete the property to break compatibility.

I'm eager to have this WG formalized so we can start to tackle the tough problems related to interoperability in ongoing standards work, including Open ID Foundations current lack of support for JSON-LD credentials  (including formats used by DIF Members like Transmute and Mattr) and the W3C DID WG JSON and CBOR representations which are entirely dependent on centralized registries, and which break compatibility for political reasons.

If we can't have conversations like this, in this WG, I would like to know sooner, rather than later :)

OS


On Wed, Jul 29, 2020 at 11:20 AM Adrian Gropper <agropper@...> wrote:
I'm a fan of the ethics perspective on interoperability as articulated by Heinz von Foerster: http://www.cybsoc.org/heinz.htm

The Ethical Imperative! "Act always so as to increase the number of choices.". A preferred form is "I always act so as to increase the number of choices."†

In our context, I would extend this to *meaningful* choices. That means individuals and other adopters of SSI should not be locked-in either for lack of standards or for standards that do not promote real-world competition and choice at a practical level. The DHS SVIP program has set a good example so far. I hope we can extend von Foerster's ethics approach more broadly.

- Adrian

On Wed, Jul 29, 2020 at 11:08 AM Taylor Kendal <taylor@...> wrote:
As follow-on to the “define interop” discussion. 

Is it possible/reasonable to land on a common denominator (highest level possible) which could broaden/narrow based on groups represented?

The ability of a system to work with or use the component parts of another system.


Or a bit more specific:


The ability for different systems, devices or applications to connect, in a coordinated manner, within and across organizational boundaries to access, exchange and cooperatively use data amongst stakeholders.


Then the inevitable moving targets fall under various sub-domains (foundational, structural, semantic, organizational, etc.) 

Also, as far as “outputs,” I think there’s intangible value in simply having a neutral venue for building/sharing context. 
*Recommended practice: join DIF interop wg :)

Food for thought...

Taylor Kendal, CPO


From: Balázs Némethi <balazs@...>
Sent: Wednesday, July 29, 2020 6:00:39 AM
To: interop-wg@dif.groups.io <interop-wg@dif.groups.io>
Subject: Interop meeting - today
 
Dear all,

A few reminders about today's meeting and next week's:
  • The nomination of chairs will close - if you have not, please nominate using this form
  • Election of chairs will happen over email.  You'll receive information after the meeting
  • It will be open for one week
  • Ballots will be checked against the attendance records of this group: 2 of the last four meetings when ballots close, i.e., last two meetings, today, and next week's.
  • During today's meeting, we'll do a little more issue review on the charter, a little discussion of the ballot, and the rest of the time will be to discuss workitems and roadmap
Best regards,
 --

Balázs Némethi
Operations @ DIF



--
ORIE STEELE
Chief Technical Officer
www.transmute.industries



Re: Interop meeting - today

orie
 

Thanks Agrian, that's very helpful framing.

Regarding the position, the decision by Mike Jones / Daniel Buchner and Microsoft to support a "Pure JSON" data model, by deleting `@context` and destroying interoperability with JSON-LD is clear example of an attempt to create vendor lock in, and reduce choices, and destroy interoperability for political reasons.

I suggest we all be vigilant to the implications of decisions like that, and I would argue that the W3C DID WG should remove the "Pure JSON" data model from consideration, since there are no implementations, and it can be distinguished from JSON-LD, by the lack of an `@context`.... they literally just delete the property to break compatibility.

I'm eager to have this WG formalized so we can start to tackle the tough problems related to interoperability in ongoing standards work, including Open ID Foundations current lack of support for JSON-LD credentials  (including formats used by DIF Members like Transmute and Mattr) and the W3C DID WG JSON and CBOR representations which are entirely dependent on centralized registries, and which break compatibility for political reasons.

If we can't have conversations like this, in this WG, I would like to know sooner, rather than later :)

OS


On Wed, Jul 29, 2020 at 11:20 AM Adrian Gropper <agropper@...> wrote:
I'm a fan of the ethics perspective on interoperability as articulated by Heinz von Foerster: http://www.cybsoc.org/heinz.htm

The Ethical Imperative! "Act always so as to increase the number of choices.". A preferred form is "I always act so as to increase the number of choices."†

In our context, I would extend this to *meaningful* choices. That means individuals and other adopters of SSI should not be locked-in either for lack of standards or for standards that do not promote real-world competition and choice at a practical level. The DHS SVIP program has set a good example so far. I hope we can extend von Foerster's ethics approach more broadly.

- Adrian

On Wed, Jul 29, 2020 at 11:08 AM Taylor Kendal <taylor@...> wrote:
As follow-on to the “define interop” discussion. 

Is it possible/reasonable to land on a common denominator (highest level possible) which could broaden/narrow based on groups represented?

The ability of a system to work with or use the component parts of another system.


Or a bit more specific:


The ability for different systems, devices or applications to connect, in a coordinated manner, within and across organizational boundaries to access, exchange and cooperatively use data amongst stakeholders.


Then the inevitable moving targets fall under various sub-domains (foundational, structural, semantic, organizational, etc.) 

Also, as far as “outputs,” I think there’s intangible value in simply having a neutral venue for building/sharing context. 
*Recommended practice: join DIF interop wg :)

Food for thought...

Taylor Kendal, CPO


From: Balázs Némethi <balazs@...>
Sent: Wednesday, July 29, 2020 6:00:39 AM
To: interop-wg@dif.groups.io <interop-wg@dif.groups.io>
Subject: Interop meeting - today
 
Dear all,

A few reminders about today's meeting and next week's:
  • The nomination of chairs will close - if you have not, please nominate using this form
  • Election of chairs will happen over email.  You'll receive information after the meeting
  • It will be open for one week
  • Ballots will be checked against the attendance records of this group: 2 of the last four meetings when ballots close, i.e., last two meetings, today, and next week's.
  • During today's meeting, we'll do a little more issue review on the charter, a little discussion of the ballot, and the rest of the time will be to discuss workitems and roadmap
Best regards,
 --

Balázs Némethi
Operations @ DIF



--
ORIE STEELE
Chief Technical Officer
www.transmute.industries



Re: Interop meeting - today

Adrian Gropper
 

I'm a fan of the ethics perspective on interoperability as articulated by Heinz von Foerster: http://www.cybsoc.org/heinz.htm

The Ethical Imperative! "Act always so as to increase the number of choices.". A preferred form is "I always act so as to increase the number of choices."†

In our context, I would extend this to *meaningful* choices. That means individuals and other adopters of SSI should not be locked-in either for lack of standards or for standards that do not promote real-world competition and choice at a practical level. The DHS SVIP program has set a good example so far. I hope we can extend von Foerster's ethics approach more broadly.

- Adrian

On Wed, Jul 29, 2020 at 11:08 AM Taylor Kendal <taylor@...> wrote:
As follow-on to the “define interop” discussion. 

Is it possible/reasonable to land on a common denominator (highest level possible) which could broaden/narrow based on groups represented?

The ability of a system to work with or use the component parts of another system.


Or a bit more specific:


The ability for different systems, devices or applications to connect, in a coordinated manner, within and across organizational boundaries to access, exchange and cooperatively use data amongst stakeholders.


Then the inevitable moving targets fall under various sub-domains (foundational, structural, semantic, organizational, etc.) 

Also, as far as “outputs,” I think there’s intangible value in simply having a neutral venue for building/sharing context. 
*Recommended practice: join DIF interop wg :)

Food for thought...

Taylor Kendal, CPO


From: Balázs Némethi <balazs@...>
Sent: Wednesday, July 29, 2020 6:00:39 AM
To: interop-wg@dif.groups.io <interop-wg@dif.groups.io>
Subject: Interop meeting - today
 
Dear all,

A few reminders about today's meeting and next week's:
  • The nomination of chairs will close - if you have not, please nominate using this form
  • Election of chairs will happen over email.  You'll receive information after the meeting
  • It will be open for one week
  • Ballots will be checked against the attendance records of this group: 2 of the last four meetings when ballots close, i.e., last two meetings, today, and next week's.
  • During today's meeting, we'll do a little more issue review on the charter, a little discussion of the ballot, and the rest of the time will be to discuss workitems and roadmap
Best regards,
 --

Balázs Némethi
Operations @ DIF


Re: Interop meeting - today

Taylor Kendal <taylor@...>
 

As follow-on to the “define interop” discussion. 

Is it possible/reasonable to land on a common denominator (highest level possible) which could broaden/narrow based on groups represented?

The ability of a system to work with or use the component parts of another system.


Or a bit more specific:


The ability for different systems, devices or applications to connect, in a coordinated manner, within and across organizational boundaries to access, exchange and cooperatively use data amongst stakeholders.


Then the inevitable moving targets fall under various sub-domains (foundational, structural, semantic, organizational, etc.) 

Also, as far as “outputs,” I think there’s intangible value in simply having a neutral venue for building/sharing context. 
*Recommended practice: join DIF interop wg :)

Food for thought...

Taylor Kendal, CPO


From: Balázs Némethi <balazs@...>
Sent: Wednesday, July 29, 2020 6:00:39 AM
To: interop-wg@dif.groups.io <interop-wg@dif.groups.io>
Subject: Interop meeting - today
 
Dear all,

A few reminders about today's meeting and next week's:
  • The nomination of chairs will close - if you have not, please nominate using this form
  • Election of chairs will happen over email.  You'll receive information after the meeting
  • It will be open for one week
  • Ballots will be checked against the attendance records of this group: 2 of the last four meetings when ballots close, i.e., last two meetings, today, and next week's.
  • During today's meeting, we'll do a little more issue review on the charter, a little discussion of the ballot, and the rest of the time will be to discuss workitems and roadmap
Best regards,
 --

Balázs Némethi
Operations @ DIF


Interop meeting - today

Balázs Némethi
 

Dear all,

A few reminders about today's meeting and next week's:
  • The nomination of chairs will close - if you have not, please nominate using this form
  • Election of chairs will happen over email.  You'll receive information after the meeting
  • It will be open for one week
  • Ballots will be checked against the attendance records of this group: 2 of the last four meetings when ballots close, i.e., last two meetings, today, and next week's.
  • During today's meeting, we'll do a little more issue review on the charter, a little discussion of the ballot, and the rest of the time will be to discuss workitems and roadmap
Best regards,
 --

Balázs Némethi
Operations @ DIF


Re: Interoperability WG - follow up/next steps - #3 meeting

Balázs Némethi
 

Dear all,

This email is a friendly reminder of to-dos before our meeting on Wednesday. 

Please go through this list: 
  1. Nominate potential WG chairs using this FORM.  - Next meeting, 29th July - Wednesday, we will start the WG chair elections. 
  2.  comment on the WG charter - we are planning to finalize it this week
  3. Add potential work items for the Interop WG  
  4. and  Join the mailing list

In the meantime, I am glad to see the lively discussion that started on the mailing list! 

Talk to everyone on Wednesday, 

best regards,


On Wed, Jul 22, 2020 at 7:18 PM 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: 
  1.  I would like to ask everyone to reread and comment on the WG charter, so we have everyone's opinion. 
    1. Please attend the coming meeting(s) as active participation will be required to cast a vote. 
  2. Please nominate potential WG chairs using this FORM - Next meeting, 29th July - Wednesday, we will start the WG chair elections.   
  3. Add potential work items for the Interop WG - These points be used as the base for the work the group will be doing.
  4. 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


--

Balázs Némethi
Operations @ DIF


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

Taylor Kendal <taylor@...>
 

Echoing thanks for everyone’s approach to this thread. Often, we end up deep in the weeds (which I can’t help but read as chest pounding) without the consideration for those who may be on the outside lookin in. 

The reiterating, reframing, contextualizing, and ...metaphoring (sp.) is appreciated. Also, the durability (and portability) of the thinking increases exponentially—pontoon bridges for the people!

I did mistakingly read Juan’s signoff as ‘interlopers’ ...ironically antithetical to the goals of interopers :)

Taylor Kendal, CPO


From: interop-wg@DIF.groups.io <interop-wg@DIF.groups.io> on behalf of Juan Caballero <juan.caballero@...>
Sent: Friday, July 24, 2020 8:18 AM
To: interop-wg@DIF.groups.io
Cc: Balázs Némethi
Subject: Re: [InteropProject] Work Items [was:Re: Interoperability WG - follow up/next steps - #3 meeting]
 

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:
https://media.phillyvoice.com/media/images/tumblr_mlp72jf4Ev1rvcvbio1_500.2e16d0ba.fill-735x490.jpg

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: https://dif.groups.io/g/interop-wg
- contribute to the Glossary WG's discussion of endpoint types here: https://docs.google.com/forms/d/e/1FAIpQLSc8Z8FklORke1iPRoyo90GNWqqXkmdbgQLNvHvU-v4XvLxO0A/viewform
- contribute to NIST's call for input https://csrc.nist.gov/publications/detail/sp/800-63/4/draft

Thanks interopers!
__juan

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

https://github.com/w3c-ccg/vc-verifier-http-api

https://github.com/w3c-ccg/vc-issuer-http-api

 

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

https://github.com/w3c-ccg/vc-examples/tree/master/plugfest-2020

https://w3c-ccg.github.io/vc-examples/plugfest-2020.html

 

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

https://lists.w3.org/Archives/Public/public-credentials/2020Jun/0011.html

 

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’ :)

 

Cheers,

 

MV

 

 

 

From: <interop-wg@DIF.groups.io> on behalf of "Snorre Lothar von Gohren Edwin via groups.io" <snorre@...>
Reply-To: "interop-wg@DIF.groups.io" <interop-wg@DIF.groups.io>
Date: Thursday, July 23, 2020 at 5:05 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]

 

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

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

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


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

Mike Varley
 

Yes, well put.

My intention was not to distract from the targets and goals, only provide input on a method that successfully produced results in a short timeframe.

“Your Mileage May Vary” as they say ;)

 

Thanks,

 

MV

 

From: <interop-wg@DIF.groups.io> on behalf of "Juan Caballero via groups.io" <juan.caballero@...>
Reply-To: "interop-wg@DIF.groups.io" <interop-wg@DIF.groups.io>
Date: Friday, July 24, 2020 at 10:18 AM
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]

 

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:
https://media.phillyvoice.com/media/images/tumblr_mlp72jf4Ev1rvcvbio1_500.2e16d0ba.fill-735x490.jpg

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: https://dif.groups.io/g/interop-wg
- contribute to the Glossary WG's discussion of endpoint types here: https://docs.google.com/forms/d/e/1FAIpQLSc8Z8FklORke1iPRoyo90GNWqqXkmdbgQLNvHvU-v4XvLxO0A/viewform
- contribute to NIST's call for input https://csrc.nist.gov/publications/detail/sp/800-63/4/draft

Thanks interopers!
__juan

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

https://github.com/w3c-ccg/vc-verifier-http-api

https://github.com/w3c-ccg/vc-issuer-http-api

 

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

https://github.com/w3c-ccg/vc-examples/tree/master/plugfest-2020

https://w3c-ccg.github.io/vc-examples/plugfest-2020.html

 

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

https://lists.w3.org/Archives/Public/public-credentials/2020Jun/0011.html

 

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’ :)

 

Cheers,

 

MV

 

 

 

From: <interop-wg@DIF.groups.io> on behalf of "Snorre Lothar von Gohren Edwin via groups.io" <snorre@...>
Reply-To: "interop-wg@DIF.groups.io" <interop-wg@DIF.groups.io>
Date: Thursday, July 23, 2020 at 5:05 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]

 

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

-- 
-----------------
Juan Caballero
Communications & Research Lead
Spherity GmbH, Emil-Figge-Straße 80, 44227 Dortmund
Next meetup 18/5: https://spherity_open_office2.eventbrite.com/
 
Berlin-based: +49 1573 5994525 
Signal/whatsapp: +1 415-3101351


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:
https://media.phillyvoice.com/media/images/tumblr_mlp72jf4Ev1rvcvbio1_500.2e16d0ba.fill-735x490.jpg

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: https://dif.groups.io/g/interop-wg
- contribute to the Glossary WG's discussion of endpoint types here: https://docs.google.com/forms/d/e/1FAIpQLSc8Z8FklORke1iPRoyo90GNWqqXkmdbgQLNvHvU-v4XvLxO0A/viewform
- contribute to NIST's call for input https://csrc.nist.gov/publications/detail/sp/800-63/4/draft

Thanks interopers!
__juan

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

https://github.com/w3c-ccg/vc-verifier-http-api

https://github.com/w3c-ccg/vc-issuer-http-api

 

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

https://github.com/w3c-ccg/vc-examples/tree/master/plugfest-2020

https://w3c-ccg.github.io/vc-examples/plugfest-2020.html

 

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

https://lists.w3.org/Archives/Public/public-credentials/2020Jun/0011.html

 

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’ :)

 

Cheers,

 

MV

 

 

 

From: <interop-wg@DIF.groups.io> on behalf of "Snorre Lothar von Gohren Edwin via groups.io" <snorre@...>
Reply-To: "interop-wg@DIF.groups.io" <interop-wg@DIF.groups.io>
Date: Thursday, July 23, 2020 at 5:05 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]

 

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

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

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


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


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

Mike Varley
 

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

 

The specs I was referring to

https://github.com/w3c-ccg/vc-verifier-http-api

https://github.com/w3c-ccg/vc-issuer-http-api

 

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

https://github.com/w3c-ccg/vc-examples/tree/master/plugfest-2020

https://w3c-ccg.github.io/vc-examples/plugfest-2020.html

 

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

https://lists.w3.org/Archives/Public/public-credentials/2020Jun/0011.html

 

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’ :)

 

Cheers,

 

MV

 

 

 

From: <interop-wg@DIF.groups.io> on behalf of "Snorre Lothar von Gohren Edwin via groups.io" <snorre@...>
Reply-To: "interop-wg@DIF.groups.io" <interop-wg@DIF.groups.io>
Date: Thursday, July 23, 2020 at 5:05 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]

 

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


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

Snorre Lothar von Gohren Edwin
 

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


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

Mike Varley
 

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@...>
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.


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

Daniel Hardman
 

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




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

Adrian Gropper
 

I appreciate Sankarshan's framing.

I'm hesitant to agree with @Balázs Némethi when he says"

"You cover multiple layers in your question but in general, I think if we are able to achieve interop requirements across the stack, scaling that down to use cases will always be possible (where interop is not required), however, this process is not possible the other way around."

At least in the SDS context, putting the layers discussion up front seems to be a cumbersome way to reach consensus on *anything*. The discussions have been worthwhile and informative, but I'm not sure we're that much farther along than we were in Prague. Rather than just complain, I started https://github.com/decentralized-identity/secure-data-store/issues/90 as an alternative to the layers first framing.

Wallets are different from Stores but I see Sankarshan's suggestion as a way to open the discussions in this WG.

- Adrian

On Thu, Jul 23, 2020 at 9:31 AM Balázs Némethi <balazs@...> wrote:
Hi Sankarshan,

Good topic, and thanks for the subject change :) 

I added your question to our list of items that the WG could/should tackle once it's properly up and running. 

You cover multiple layers in your question but in general, I think if we are able to achieve interop requirements across the stack, scaling that down to use cases will always be possible (where interop is not required), however, this process is not possible the other way around. 

The group should find its description of Interoperability, but more as a parallel effort as the group also focuses on coordination and alignment. 

Best,

On Thu, Jul 23, 2020 at 1:48 PM 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


--

Balázs Némethi
Operations @ DIF


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

Balázs Némethi
 

Hi Sankarshan,

Good topic, and thanks for the subject change :) 

I added your question to our list of items that the WG could/should tackle once it's properly up and running. 

You cover multiple layers in your question but in general, I think if we are able to achieve interop requirements across the stack, scaling that down to use cases will always be possible (where interop is not required), however, this process is not possible the other way around. 

The group should find its description of Interoperability, but more as a parallel effort as the group also focuses on coordination and alignment. 

Best,

On Thu, Jul 23, 2020 at 1:48 PM 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


--

Balázs Némethi
Operations @ DIF


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

sankarshan
 

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


Interoperability WG - follow up/next steps - #3 meeting

Balázs Némethi
 

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: 
  1.  I would like to ask everyone to reread and comment on the WG charter, so we have everyone's opinion. 
    1. Please attend the coming meeting(s) as active participation will be required to cast a vote. 
  2. Please nominate potential WG chairs using this FORM - Next meeting, 29th July - Wednesday, we will start the WG chair elections.   
  3. Add potential work items for the Interop WG - These points be used as the base for the work the group will be doing.
  4. 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