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> 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://github.com/mattrglobal/oidc-client-bound-assertions-spec>) 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,
>>  <https://aus01.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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> 
>>  
>> Tobias Looker
>> MATTR
>> CTO
>> +64 (0) 27 378 0461
>> tobias.looker@mattr.global <mailto:tobias.looker@mattr.global>
>>  <https://aus01.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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0> 
>>  <https://aus01.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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0> 
>>  <https://aus01.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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0> 
>>  <https://aus01.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=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%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
>>