Re: JFF plugfest next steps

Thanks to everyone for a great discussion.  In case you missed it, Kerri recently posted a roundup of the first event: https://kayaelle.medium.com/jff-vc-edu-plugfest-1-892b6f2c9dfb.  Over the next couple of months, JFF and NGA will also put out a few which include reactions and questions from non-technical observers to this community.  We are really excited by the conversations that this collaboration has generated.  Now that the June 24 deadline for updated demos has passed, we will plan to issue the JFF badge beginning mid-July.

Moving forward:

  1.  Logistics.  We plan to host Plugfest #2 on November 14.  This event will be held IN PERSON in Mountain View, CA ahead of the Internet Identity Workshop.  We think this is an event that most of this community would attend, and it also gives us an opportunity to engage a wider audience.
  2.  Awards.  We plan to offer awards for successful demonstration of interop.  The exact amounts are TBD at the moment and will be dependent on the level of complexity.
  3.  Interop.  Really appreciate the discussion below.  Our team has tossed this around and spoken with a number of people and offer this as a thought on sequence.

Based on the demos from PF1, it seems like many people were able to achieve badge verification (green check) in this exercise, it seems plausible that establishing interoperability re verification might be the logical next step.  However, in the education/workforce use case, there are some nuances of verification that present an interesting opportunity to establish the functional utility of VCs through integrations with relying parties, especially those that are not themselves verifiers.  This will take some time to explore and much discussion both in this community and in developing use cases with willing, relying parties.  For this next plugfest, we will focus on interoperability re issuer.  The exact nature of this exercise is still being developed but we want to do it with everyone together, so we will be hosting a plugfest 2 technical discussion either as part of one of the vc-edu scheduled calls or most likely, at a separate time.  This is important and exciting and we want to scope it right, with your help, so please continue to provide your thoughts to this discussion.

  1.  Next steps.  Stay tuned for info on a technical call in July.  We will share our proposal ahead of this call to give everyone time to give thoughtful feedback, but we want to keep this moving in light of the November target.  We will also be developing instructions for anyone who did not participate in this first plugfest but would like to join the second.

We hope everyone continues to engage!
sharon


From: Kerri Lemoie <kerri@openworksgrp.com>
Date: Friday, June 10, 2022 at 10:54 AM
To: public-vc-edu@w3.org <public-vc-edu@w3.org>
Cc: Tobias Looker <tobias.looker@mattr.global>, Sharon Leu <sleu@jff.org>, ayo@ioxayo.com <ayo@ioxayo.com>, Markus Sabadello <markus@danubetech.com>, tim@entrustient.com <tim@entrustient.com>, Timothy Summers <tcsummers@asu.edu>, gsaenz@territorium.com <gsaenz@territorium.com>, leon@iq4.com <leon@iq4.com>, dave@idatafy.com <dave@idatafy.com>, Oliver Terbu <oliver.terbu@spruceid.com>, Kimberly Linson <kimberly.linson@randasolutions.com>, gdidonato@ebsco.com <gdidonato@ebsco.com>, Brian Richter <brian@aviary.tech>, Dmitri Zagidulin <dzagidulin@gmail.com>, Jacksón Smith <jackson@learningeconomy.io>, Evan Lally <elally@digitalbazaar.com>, Ninh Tran <ninh@snapbrillia.com>, Joan <jlee@jfflabs.org>, David Chadwick <david.chadwick@crosswordcybersecurity.com>
Subject: Re: JFF plugfest next steps
Hello all,

I’m moving this thread over to the vc-edu email list so we can work on these next steps in the open community.

Thanks!

Kerri


On Jun 8, 2022, at 11:53 AM, David Chadwick <david.chadwick@crosswordcybersecurity.com<mailto:david.chadwick@crosswordcybersecurity.com>> wrote:

Hi Tobias
comments below

On 07/06/2022 21:54, Tobias Looker wrote:
Hi,

I'd like to offer another opinion based on some of the thoughts shared by David.

> There are orders of magnitude more relying parties (verifiers) than issuers. Consequently it is far more important to have interoperability between wallets and RPs than between wallets and issuers.

While I agree that verification protocols are very important to standardize as that is where most of the value in VC's are realized (when they are presented to a relying party or verifier). By focusing on verification first it presumes some issuance protocol must exist for the wallet to get the VC's into the wallet and without that being a standard, it means its likely proprietary.
That is correct. But I expect most products to migrate to a (or the) standard once it is finalised.

This is significant because if you try to standardize this later the conversation changes for infrastructure providers because they already have something that works e2e. Put another way IMO interop-ing/standardizing issuance becomes harder if you focus on verification first.
I don't see why this is true. There is no standard for issuing today. So everyone is having to use their own protocol for issuing. If you require everyone to move to some intercept standard now (which you must because no standard yet exists) then you are requiring vendors to make two transitions, from proprietary to intercept, and intercept to final standard. This is going to be much more costly and require more churn than moving from proprietary to final standard in one go.


> ISO mobile driving licenses (mDL) has several standard protocols for verification, but none for issuing

This actually highlights why issuance is often more important to do first,
only if a definitive standard exists that everyone buys into.
If not, then forcing people to use a non-standard is more divisive than leaving them to use what they already use today.

there are numerous deployments of mDL now rolling out with proprietary protocols for issuance that stifle competition in the wallet space and create vendor lock-in for issuers,
To my mind this is a non-sequitir. If there are numerous deployments of mDL rolling out this means there must be good competition between suppliers.

something we are trying to help to rectify with OIDC4VCI supporting mDL issuance.

> OIDC4VCs started the standardisation of verification before the standardisation of issuing, and the former is more advanced than the latter.

As a core contributor to the whole family of specifications being developed at OIDF, I disagree.
Then this where we have to disagree, because I am also contributing to the OIDF specifications. If you take a look at what OIDF has published as the first implementers drafts you will see that verification is ahead of issuing, and that issuing has changed quite significantly recently.

The origins of the issuance protocol work pre-dates the verification protocol significantly, see here we originally published a draft two years ago (https://github.com/mattrglobal/oidc-client-bound-assertions-spec<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fmattrglobal%2Foidc-client-bound-assertions-spec&data=05%7C01%7Csleu%40jff.org%7Cb65171f5b2554127f47c08da4af96d67%7C3bddf584e8d746c49804a0f3cdf0b0ca%7C0%7C0%7C637904732401991573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Acf8rslAqX%2BCpfTRJ4ox9AXTvy8OJRlKnYFA7Hfufzw%3D&reserved=0>) and there have been multiple implementations and overall, in my opinion the issuance draft is simpler and easier to implement then verification.
It depends upon what you implement for issuing. There are many optional protocol elements in the current draft, such as requesting VCs from the wallet, which if chosen, make issuing more complex than verification.

Verification is also being simplified as we speak, by producing an alternative to having to implement DIF PE, and removing the requirement for an id_token.

So to summarise, neither issuing or verification have stabilised in OIDF yet, but as you agree, verification is more useful and value-add than issuing, so we should work on this first, and provide our insights back to OIDF (assuming that OIDC4VCs is the protocol we opt for) or W3C or whoever

Kind regards
David
p.s. We both agree that both are needed. It's simply a question of ordering priorities that give vendors the least churn and overall implementation effort.



 Thanks,
[Image removed by sender. Mattr website]<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=05%7C01%7Csleu%40jff.org%7Cb65171f5b2554127f47c08da4af96d67%7C3bddf584e8d746c49804a0f3cdf0b0ca%7C0%7C0%7C637904732401991573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xtlB5Oo23teSnkKyToahZpuGlO4EzGPaFW%2Fexp429C4%3D&reserved=0>

Tobias Looker
MATTR
CTO
+64 (0) 27 378 0461
tobias.looker@mattr.global<mailto:tobias.looker@mattr.global>
[Image removed by sender. Mattr                                                        website]<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=05%7C01%7Csleu%40jff.org%7Cb65171f5b2554127f47c08da4af96d67%7C3bddf584e8d746c49804a0f3cdf0b0ca%7C0%7C0%7C637904732401991573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=xtlB5Oo23teSnkKyToahZpuGlO4EzGPaFW%2Fexp429C4%3D&reserved=0>
[Image removed by sender. Mattr on                                                        LinkedIn]<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=05%7C01%7Csleu%40jff.org%7Cb65171f5b2554127f47c08da4af96d67%7C3bddf584e8d746c49804a0f3cdf0b0ca%7C0%7C0%7C637904732401991573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=nb0wtj90bUJTsLKLUNSd43wKsNl8pjgCYNwEI1P5M9g%3D&reserved=0>
[Image removed by sender. Mattr on                                                        Twitter]<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=05%7C01%7Csleu%40jff.org%7Cb65171f5b2554127f47c08da4af96d67%7C3bddf584e8d746c49804a0f3cdf0b0ca%7C0%7C0%7C637904732401991573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=loGV%2B4an49oXy5zI2vrLwPU7aXfm%2Bap4hNfBvuJIadQ%3D&reserved=0>
[Image removed by sender. Mattr on                                                        Github]<https://nam10.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=05%7C01%7Csleu%40jff.org%7Cb65171f5b2554127f47c08da4af96d67%7C3bddf584e8d746c49804a0f3cdf0b0ca%7C0%7C0%7C637904732401991573%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=yktCYxjVDI4w27VY3kVZnt%2Bv6PEqhS%2FnoLL%2Fa9d4%2B40%3D&reserved=0>

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

________________________________
From: Sharon Leu <sleu@jff.org><mailto:sleu@jff.org>
Sent: 08 June 2022 00:03
To: David Chadwick <david.chadwick@crosswordcybersecurity.com><mailto:david.chadwick@crosswordcybersecurity.com>; ayo@ioxayo.com<mailto:ayo@ioxayo.com> <ayo@ioxayo.com><mailto:ayo@ioxayo.com>; markus@danubetech.com<mailto:markus@danubetech.com> <markus@danubetech.com><mailto:markus@danubetech.com>; tim@entrustient.com<mailto:tim@entrustient.com> <tim@entrustient.com><mailto:tim@entrustient.com>; tcsummers@asu.edu<mailto:tcsummers@asu.edu><tcsummers@asu.edu><mailto:tcsummers@asu.edu>; gsaenz@territorium.com<mailto:gsaenz@territorium.com> <gsaenz@territorium.com><mailto:gsaenz@territorium.com>; leon@iq4.com<mailto:leon@iq4.com> <leon@iq4.com><mailto:leon@iq4.com>; dave@idatafy.com<mailto:dave@idatafy.com> <dave@idatafy.com><mailto:dave@idatafy.com>; oliver.terbu@spruceid.com<mailto:oliver.terbu@spruceid.com> <oliver.terbu@spruceid.com><mailto:oliver.terbu@spruceid.com>;kimberly.linson@randasolutions.com<mailto:kimberly.linson@randasolutions.com> <kimberly.linson@randasolutions.com><mailto:kimberly.linson@randasolutions.com>; gdidonato@ebsco.com<mailto:gdidonato@ebsco.com><gdidonato@ebsco.com><mailto:gdidonato@ebsco.com>; brian@aviary.tech<mailto:brian@aviary.tech> <brian@aviary.tech><mailto:brian@aviary.tech>; dzagidulin@gmail.com<mailto:dzagidulin@gmail.com> <dzagidulin@gmail.com><mailto:dzagidulin@gmail.com>;jackson@learningeconomy.io<mailto:jackson@learningeconomy.io> <jackson@learningeconomy.io><mailto:jackson@learningeconomy.io>; Evan Lally <elally@digitalbazaar.com><mailto:elally@digitalbazaar.com>; Tobias Looker<tobias.looker@mattr.global><mailto:tobias.looker@mattr.global>; Ninh Tran <ninh@snapbrillia.com><mailto:ninh@snapbrillia.com>
Cc: Kerri Lemoie <kerri@openworksgrp.com><mailto:kerri@openworksgrp.com>; Joan Lee <jlee@jfflabs.org><mailto:jlee@jfflabs.org>
Subject: Re: JFF plugfest next steps

EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.

Thanks, David!  We were just debriefing and discussing the order of these things.  Whether we should focus on issuers or verifiers first since both are critical, is a great conversation that we might have during one of the upcoming calls, since a strong case could be made either way.  But both need to be done in the end.


We will be in touch later today with instructions for sending us your preferred did so we can issue the JFF Plugfest badges.


Thanks again everyone for engaging in this process.  We were all so pleased with the outcome.


sharon



From: David Chadwick <david.chadwick@crosswordcybersecurity.com><mailto:david.chadwick@crosswordcybersecurity.com>
Date: Tuesday, June 7, 2022 at 4:30 AM
To: Sharon Leu <sleu@jff.org><mailto:sleu@jff.org>, ayo@ioxayo.com<mailto:ayo@ioxayo.com> <ayo@ioxayo.com><mailto:ayo@ioxayo.com>, markus@danubetech.com<mailto:markus@danubetech.com><markus@danubetech.com><mailto:markus@danubetech.com>, tim@entrustient.com<mailto:tim@entrustient.com> <tim@entrustient.com><mailto:tim@entrustient.com>, tcsummers@asu.edu<mailto:tcsummers@asu.edu><tcsummers@asu.edu><mailto:tcsummers@asu.edu>, gsaenz@territorium.com<mailto:gsaenz@territorium.com> <gsaenz@territorium.com><mailto:gsaenz@territorium.com>, leon@iq4.com<mailto:leon@iq4.com> <leon@iq4.com><mailto:leon@iq4.com>, dave@idatafy.com<mailto:dave@idatafy.com> <dave@idatafy.com><mailto:dave@idatafy.com>, oliver.terbu@spruceid.com<mailto:oliver.terbu@spruceid.com> <oliver.terbu@spruceid.com><mailto:oliver.terbu@spruceid.com>,kimberly.linson@randasolutions.com<mailto:kimberly.linson@randasolutions.com> <kimberly.linson@randasolutions.com><mailto:kimberly.linson@randasolutions.com>, gdidonato@ebsco.com<mailto:gdidonato@ebsco.com><gdidonato@ebsco.com><mailto:gdidonato@ebsco.com>, brian@aviary.tech<mailto:brian@aviary.tech> <brian@aviary.tech><mailto:brian@aviary.tech>, dzagidulin@gmail.com<mailto:dzagidulin@gmail.com> <dzagidulin@gmail.com><mailto:dzagidulin@gmail.com>,jackson@learningeconomy.io<mailto:jackson@learningeconomy.io> <jackson@learningeconomy.io><mailto:jackson@learningeconomy.io>, Evan Lally <elally@digitalbazaar.com><mailto:elally@digitalbazaar.com>, Tobias Looker<tobias.looker@mattr.global><mailto:tobias.looker@mattr.global>, Ninh Tran <ninh@snapbrillia.com><mailto:ninh@snapbrillia.com>
Cc: Kerri Lemoie <kerri@openworksgrp.com><mailto:kerri@openworksgrp.com>, Joan Lee <jlee@jfflabs.org><mailto:jlee@jfflabs.org>
Subject: JFF plugfest next steps
Hi Sharon
I attach my thoughts on the next step for the JFF Plugfest, for you and the community to consider.
I welcome feedback and comments from everyone
Kind regards
David