Mallory_Dwinal-Palisch: Sure thanks so much hi everyone my name is Mallory Gwen all Palin I'm the chancellor of reach University we do apprenticeship degrees originally just in teaching but as we think about apprenticeship degrees across other Industries are looking to learning and employment records that meet best practices and Industry standards so really excited to be here. ✪
Rebecca_Busacca: And my name is Rebekah abused sock'em with Territorial and we provide comprehensive learning records and digital wallets and our CTO is on the call with us as well his name is Gerardo. ✪
Phil_L_(P1): Can you hear me carry quick announcement I don't have details of this other than a date but it looks like there will be a meeting in DC in July on the 14th regarding the use of of national language NLP AI + ml techniques to extract both. ✪
Phil_L_(P1): See data from unstructured sources as well as to look at unstructured representations of credentials and consider their mapping to verifiable credential data models so the best I can tell you at the moment is that it will be in d.c. on the 14th of July at the Microsoft DC facility but keep an eye on both T3 and. ✪
<deb_everhart> you're a contributor, not a stalker!
<deb_everhart> the first community interoperability demonstration event on Monday, June 6, 2022, from 1 PM to 5 PM CT, as a pre-conference event preceding the JFF Horizons conference. You can register for this event separately at https://cvent.me/A2ov3L
Brandon_Muramatsu: Does this mean that today the open bass V3 specification is publicly and openly available to anyone that wants to look at it and use it for this poke plugfest or is it still proprietary. ✪
<kerri_lemoie> Thanks for link @Deb!
<dmitri_zagidulin> (I can say a few words about wallet protocol)
<kerri_lemoie> Will call on Dmitri_Zagidulin next (then Phil)
Phil_L_(P1): Yeah I just most of the conversation just now has addressed the clarification that I was hoping to hear the one thing that I wanted to double check is that is the expectation that an issue will need to be able to issue their credential to at least two different vendor wallets that are in the sweet. ✪
Nate_Otto_(he/him): All right thanks let me know if my microphone doesn't sound good these Bluetooth headphones are not right I actually - one the maybe suggestion that we insist on issuer and wallet provider being separate entities for this phase if we're talking about baby steps we may find that there is a wallet provider that wants to participate and you know they want to focus most of their effort on building the display logic within their wallet and maybe you know essentially we're just using an example credential. ✪
<dmitri_zagidulin> @Nate - wait, an issuer interoping /with their own wallet/ is going to happen anyway. how is that actual interop? :)
Nate_Otto_(he/him): All blob of signed json-ld anyway so the presence of a particular issuing software that is a separate entity from them I don't think is absolutely critical to this phase of the work certainly it's great when we can do it and I encourage all participants to work with multiple entities you know one representing issuer and one representing wallet for interoperability but it may not make sense as a requirement and then a in the future you know. ✪
Nate_Otto_(he/him): I would say that also to David's. ✪
Nate_Otto_(he/him): Around the number of issuers we've seen in the open badges ecosystem so far that there are hundreds of thousands of issuers in the world as well it's not a very limited supply for every single individual credential of course there is only the issuer that has defined it but for all of the credentials in total there are many. ✪
<manu_sporny> I wonder if there is a miscommunication... feels like there is... can't put my finger on what it is just now.
<dmitri_zagidulin> @John_Kuo - the whole point is that it /shouldn't/ be a custom API
<deb_everhart> maybe there are multiple layers of scope- this is a short timeframe and not all engaged parties will get to a higher layer right now
<dmitri_zagidulin> we're using a standard API
<davidc> There is no single standard API
<dmitri_zagidulin> @DavidC - so let's see which wallets support which standard APIs
<manu_sporny> There is VC API and there is CHAPI -- and we have seen interop using those two APIs (though early days, of course)
<davidc> OIDC4VCI is defining a standard protocol for issuing VCs
<deb_everhart> all providers should be able to articulate their interop intentions and next steps
<davidc> I suspect OIDC4VCI will become the defacto standard
Brandon_Muramatsu: This is sort of on the same topic and maybe it's not necessary based off what Dimitri and motto have been saying in chat but the data request or the information request that's included as part of Sharon's call focuses I read is focusing on primarily the wallet I think that we need issuer and the issuer and the wallet to be different entities are from different. ✪
Brandon_Muramatsu: Support the baby steps argument that that's maybe the next step but I don't it's the interesting step to me and if we go that route that I think there needs to be an information request for the issuer's as well to provide information to either information to the Sharon and jmf like she's requested for the wallet or. ✪
<david_chadwick> How many of you support the OIDC4VCI spec for issuing VCs?
<phil_l_(p1)> It's true the interop is hard and complicated. But the scope has been narrowed to just one other wallet than the issuer may already have. So this is minimally requires a different wallet than issuer.
Brandon_Muramatsu: Conversely jff needs to say these are the things the issuers must do like informed to the VCA API and. ✪
Brandon_Muramatsu: The other things that mono end up chappie that mono and Demetria can talk about chat. ✪
<manu_sporny> We don't support OIDC4VCI at this moment -- too green to implement, AFAICT.
<manu_sporny> We can support CHAPI and VC API
<simone_ravaioli_(digitary)> Should there be a call out to issuers or we just define one dumb “hello world”OB3 and use that to be displayed by any numbers of wallet providers ?
<deb_everhart> I think that's part of what people need to understand, that the underlying data is reliably the same regardless of the display
<deb_everhart> imo this is an important turning point for Open Badges to be literally seen differently, not focus on the badge image
<brandon_muramatsu> I would argue for display of fields and not baking the info into a single image, both could be supported (and probably should be), but I think we want to be able to operate on the data
<deb_everhart> the vast majority of the market still thinks about Open Badges as tokens/display images and they don't know there's critically important underlying data
<deb_everhart> we might need a little alarm
<deb_everhart> for people to think differently
Nate_Otto_(he/him): Choice sure just very briefly a Sharon suggested a mechanism for the cohort to decide on you know what specific nitty-gritty things are required once you kind of sign up and get involved in the program and display agreements is kind of exactly the type of thing that it makes sense for that I think it'll be really easy to be able to select a certain set of fields that are important that represent kind of the core of the badge itself such as its name maybe the description. ✪
Nate_Otto_(he/him): Exist in the badge I think it should be displayed badges for a long time have been visual symbols of achievement and just because they are now optional in the spec doesn't mean that we don't want to see them very prominently when they exist so I think it'll be really easy for the cohort members themselves to decide on what should be displayed and if we get a little bit of variation that's probably okay. ✪
<deb_everhart> I would consider that a secondary display/presentation
<dmitri_zagidulin> @DavidC - yeah, that's a hugely important use case. (for the issuer to be able to suggest or dictate the display)
<dmitri_zagidulin> (though not for this first interop fest)
<phil_l_(p1)> @David so that means for this plugfest it will be easier to display data than your licensing professional org.
Mutuzo_Irene_Esther: You could just call me Irene yes my comments are yes one around the visualization of the credential particularly for the African Market that's something you the the team that's working on this might want to also think about because it's not so much around in stages at em around you know that enter information in the credential so also linking that. ✪
Mutuzo_Irene_Esther: So that we are able to get. ✪
<deb_everhart> see the way Velocity Network has agreed upon primary and secondary schemas and display options-- primary is the same for all credentials and secondary meets the use cases of specific communities of practice
Mutuzo_Irene_Esther: African perspective then my question is around quickly of course once the team works on this I asked him that they'll probably be certain people that are going to test this out and try it out how we thought deliberately thought about the sensitization on this cuz that's all okay. ✪
<deb_everhart> super rich discussion, looking forward to slugfest!
<sharon_leu> This is great, thanks!
Phil_L_(P1): Thanks Carrie and Sharon terrific stuff. ✪