Re: [MINUTES] W3C CCG Verifiable Credentials for Education Task Force Call - 2022-10-17

Hi Brian,

Thanks for asking. Here’s the video for the call: https://meet.w3c-ccg.org/archives/w3c-ccg-education-2022-10-17.mp4 <https://meet.w3c-ccg.org/archives/w3c-ccg-education-2022-10-17.mp4>

And here are the slides: https://docs.google.com/presentation/d/1KwEPEOW9QsAm8T9eLiPyhlcOBzt7N3QV5sfoTvfAoeI/edit#slide=id.g16b4da7e4e7_0_8 <https://docs.google.com/presentation/d/1KwEPEOW9QsAm8T9eLiPyhlcOBzt7N3QV5sfoTvfAoeI/edit#slide=id.g16b4da7e4e7_0_8>

K.


——————
Kerri Lemoie, PhD
Director of Technology, Digital Credentials Consortium
https://digitalcredentials.mit.edu
@kayaelle
she/her/hers







> On Oct 19, 2022, at 12:53 AM, Brian Richter <brian@aviary.tech> wrote:
> 
> Hi all,
> 
> Is there a video recording of this meeting available? Hard to follow along with the fields Kerri is talking about without seeing it.
> 
> Thanks,
> Brian
> 
> ---------- Forwarded message ---------
> From: CCG Minutes Bot <minutes@w3c-ccg.org <mailto:minutes@w3c-ccg.org>>
> Date: Mon, Oct 17, 2022 at 2:48 PM
> Subject: [MINUTES] W3C CCG Verifiable Credentials for Education Task Force Call - 2022-10-17
> To: <public-credentials@w3.org <mailto:public-credentials@w3.org>>
> 
> 
> Thanks to Our Robot Overlords and Our Robot Overlords for scribing this week!
> 
> The transcript for the call is now available here:
> 
> https://w3c-ccg.github.io/meetings/2022-10-17-vc-education/ <https://w3c-ccg.github.io/meetings/2022-10-17-vc-education/>
> 
> Full text of the discussion follows for W3C archival purposes.
> Audio of the meeting is available at the following location:
> 
> https://w3c-ccg.github.io/meetings/2022-10-17-vc-education/audio.ogg <https://w3c-ccg.github.io/meetings/2022-10-17-vc-education/audio.ogg>
> 
> ----------------------------------------------------------------
> VC for Education Task Force Transcript for 2022-10-17
> 
> Agenda:
>   https://lists.w3.org/Archives/Public/public-vc-edu/2022Oct/0012.html <https://lists.w3.org/Archives/Public/public-vc-edu/2022Oct/0012.html>
> Topics:
>   1. IP Note
>   2. Call Notes
>   3. Introductions & Reintroductions
>   4. Announcements & Reminders
>   5. Main Topic - Open Badges 3.0 Candidate Release Review
> Organizer:
>   Kerri Lemoie
> Scribe:
>   Our Robot Overlords and Our Robot Overlords
> Present:
>   Kerri Lemoie, TallTed // Ted Thibodeau (he/him) (OpenLinkSw.com), 
>   Sharon Leu, Jeff O - HumanOS, Andy Griebel, xander - ASU/Pocket, 
>   Melissa Clark, Simone Ravaoli, Phil Barker, John Kuo, Akshar 
>   Patel, Dmitri Zagidulin, Chandi Cumaranatunge, Kimberly Linson, 
>   Deepak Kulkarni, Phil L (P1), Mike Peck, David Chadwick, Keith 
>   Kowal, David Ward, Tayken (LEF), Kaliya Young, Angeles, Marty 
>   Reed, James Chartrand, Jim Goodell, francesca pileri (Reiss 
>   Romoli), Jonathan Bethune, Denis Redozubov
> 
> <kerri_lemoie> Hello all - we'll get started in 1 minute
> Our Robot Overlords are scribing.
> Kerri Lemoie:  Okay can everyone hear me okay.
> Kerri Lemoie:  I didn't hear the recording start although I see 
>   it that it did start so I'm going to stop it and start it again.
> Phil_L_(P1): Recording has stopped.
> Our Robot Overlords are scribing.
> <sharon_leu> @Kerri, the recording is on.
> Kerri Lemoie:  Okay everybody think we're good to go here welcome 
>   to the MonDay verifiable verifiable credentials for Education 
>   task force it's October 17th today we're going to review the open 
>   badges 3.0 candidate release.
> Kerri Lemoie:   And first.
> Kerri Lemoie:  You I'm some introduction introductory items.
> <kaliya_identitywoman> sound itsn't working for me on chrome
> 
> Topic: IP Note
> 
> Kerri Lemoie:  Anyone can participate in these calls however any 
>   substitutive contributions to any of the ccg work items must be 
>   done by members of the ccg with full IP are agreements that are 
>   signed the links to this are in the agenda emails that we send 
>   out so please take a look at that if you would like to work on 
>   the standards and participate in this work with us secondly.
> 
> Topic: Call Notes
> 
> Kerri Lemoie:  As you may have noted these.
> <kaliya_identitywoman> I'm coming back.
> Kerri Lemoie:  All recorded and they're archived we also have a 
>   robot transcriber that sometimes understands us and sometimes 
>   interprets Us in other ways if you would like to see any 
>   corrections in the in the transcription that would be very 
>   helpful for us when we publish you can do so by doing a civil reg 
>   ex substitution I'll put it in the chat for you now see you do s 
>   slash wrong-word slash correct-word.
> Kerri Lemoie:  Also we follow a queue system and these calls so 
>   if you have something that you would like to say ask a question 
>   introduce yourself once we get to that part of the agenda you can 
>   just type Q Plus and if you'd like to you can say the reason why 
>   we're adding yourself through that will help us integrate your 
>   you into the conversation a little bit better and then to remove 
>   yourself from the queue just uq-.
> 
> Topic: Introductions & Reintroductions
> 
> Kerri Lemoie:  Okay so with that why don't we start with them 
>   introductions and any reintroductions so is there anyone who's 
>   here today that is new to the call or his rejoin the call or they 
>   give us an update on what they're working on you left you I hear 
>   from you.
> <tallted_//_ted_thibodeau_(he/him)_(openlinksw.com <http://openlinksw.com/>)> :-)
> Kerri Lemoie:  Thank you TallTed for the correction in the 
>   Scribe.
> 
> Topic: Announcements & Reminders
> 
> Kerri Lemoie:  Next is anybody have any announcements and 
>   reminders.
> Kerri Lemoie:  What I typically do here if no one has any other 
>   announcements is put the link to the ccg events calendar so that 
>   you can see what's going on with that.
> <kerri_lemoie> CCG Announcements: 
>   https://w3c-ccg.github.io/announcements/ <https://w3c-ccg.github.io/announcements/>
> Kerri Lemoie:  And then I'm sharing a teacher in the queue for 
>   announcements.
> Sharon Leu:  Thanks Carrie this is just a reminder that if anyone 
>   is participating in plugfest we're having a technical 
>   conversation this coming Wednesday and I'll send a reminder also 
>   on the mailing list.
> 
> Topic: Main Topic - Open Badges 3.0 Candidate Release Review
> 
> Kerri Lemoie:  Awesome thank you Sharon and actually that is an 
>   excellent segue into our main topic for today for part of 
>   plugfest look like that's what we've been doing is implementing 
>   open badges 3.0 as part of stage so in the first book Fest we 
>   implemented A variation of open badges.
> Kerri Lemoie:   3 .0.
> Kerri Lemoie:  I was sort of like in time box for where it was 
>   then because we knew that it was sort of still a moving Target 
>   for plugfest to that I'm we're in the process of right now open 
>   badges 3.0 is in a candidate release and we thought it might be 
>   helpful to review where it is right now because it's not final 
>   yet but it is in release and to tell you you know you know what 
>   is specific to the open badges 3.0 implementation.
> Kerri Lemoie:   In comparison to.
> Kerri Lemoie:  Credentials you know how they how they made 
>   choices to do this alignment and then we can have a discussion 
>   about that and then Wednesday is called the plugfest technical 
>   call we can talk about what the example should be for a plugfest 
>   implementation because we haven't provided those examples yet we 
>   wanted to have this discussion first and then on Wednesday we 
>   could talk about that more and by the way even if you're not 
>   participating in like this you can join us on Wednesday as call 
>   that's why Sharon is sending this to the public.
> Kerri Lemoie:   Mailing list.
> Kerri Lemoie:  Yes okay anybody have anything.
> Kerri Lemoie:  See anybody else in the queue so feel free to jump 
>   in Dimitri or so if you could keep an eye on the cube that would 
>   be great.
> Kerri Lemoie:  I'm just a little bit of History like share my 
>   screen here for you.
> Kerri Lemoie:   I have.
> Kerri Lemoie:  A few basic slides.
> Kerri Lemoie:  Hey I'm still some history last June not last year 
>   in June of last year we met as a group and decided that we're 
>   going to encourage that open badges be aligned natively with 
>   verifiable credentials and by natively what we meant was 
>   integrate with verifiable credentials so that it used the the 
>   structure of the VC data model and also the verification R-Spec 
>   right the the identities the proofs.
> Kerri Lemoie:   And all of that and.
> Kerri Lemoie:  And want to Tech which is used to be called IMS 
>   Global they've been working on that all year and so what we did 
>   as is for VCS use we provide our proposal we said this is how we 
>   think you should do it and then they created a new Charter for 
>   open badges 3.0 and also added a charter for their comprehensive 
>   learning record V2 so that they could align those models along 
>   with aligning with verifiable credentials as you can imagine they 
>   have a pretty substantial.
> Kerri Lemoie:   Set of.
> Kerri Lemoie:  Our standardized way of doing things when I text 
>   so they made some decisions along the way that we should review 
>   today as a group so you can understand what it did what they did 
>   and then we can we can open it up for discussion.
> Kerri Lemoie:  I think you know often times we have those members 
>   of the working groups and IMS who attend these calls so there's 
>   anybody here from those working groups who want to clarify 
>   anything that I say that would be very helpful to us thank you.
> Kerri Lemoie:  Well you know what I'm going to give you the link 
>   to the slides because it'll be a lot more helpful for you to have 
>   this link.
> <phil_l_(p1)> No worries Kerri ;-)
> Kerri Lemoie: Slides: 
>   https://docs.google.com/presentation/d/1KwEPEOW9QsAm8T9eLiPyhlcOBzt7N3QV5sfoTvfAoeI/edit#slide=id.g16b4da7e4e7_0_8 <https://docs.google.com/presentation/d/1KwEPEOW9QsAm8T9eLiPyhlcOBzt7N3QV5sfoTvfAoeI/edit#slide=id.g16b4da7e4e7_0_8>
> Kerri Lemoie:  Yeah I where you can click on things.
> Kerri Lemoie:  Let me just go back to this page to this is the 
>   second page of the slides the first thing is the original 
>   proposal that was done this one was done in the last version of 
>   it was August 11th in 2021 the GitHub repo is an open repo and 
>   you can view if you look in the repository a V3 you can see the 
>   work that's happening in there you can also see prior versions of 
>   open badges.
> Kerri Lemoie:   The candidate released.
> Kerri Lemoie:  Is what we're going to be looking at today and 
>   we're not going to go in through the hole specification we're 
>   going to go through the basic open badges credential there's a 
>   lot more in there that you can look at allow more way more 
>   properties and we're going to be able to cover today but that you 
>   could read in there and also if you have questions about the 
>   specification the open badges repo is public and you can submit 
>   issues you're going to see that we have some issues that we've 
>   submitted already with some questions about 3.0.
> Kerri Lemoie:   The schema link is is.
> Kerri Lemoie:  Basically reflection of the specification and as 
>   you implement a 3.0 you can test against this they from what I 
>   can tell pretty much in sync that they make adjustments to the 
>   schema and they happen in the specification somewhat 
>   automatically I think so I'm this is something worth knowing and 
>   then we're also going to look at the sample open badge this is 
>   their basic very basic sample.
> Kerri Lemoie:  Example that we're going to use for breakfast also 
>   going to be very simple and we're not going to be looking to 
>   adding for instance like alignments to competencies and that type 
>   of thing right we're going to be looking at issuing a verifiable 
>   credential in the form of an open badge from one issuer or from 
>   an issuer to a wallet right so it's about transporting and 
>   displaying an open badge as part of the plugfest.
> Kerri Lemoie:  No question so far so.
> Kerri Lemoie:  Do this here.
> Kerri Lemoie:  So what he did was should have list out the 
>   required elements that are specific to open badges 3.0 that are 
>   different from a verifiable credential like I mentioned before 
>   this isn't everything I this is sort of the main elements that 
>   would be looking at as part of implementing this for breakfast 
>   too so first what I'm going to do is show you the example.
> Kerri Lemoie: 
>   https://imsglobal.github.io/openbadges-specification/ob_v3p0.html#basic-openbadgecredential <https://imsglobal.github.io/openbadges-specification/ob_v3p0.html#basic-openbadgecredential>
> Kerri Lemoie:  And I must give you the link to this right here in 
>   case anybody wants to pull it up.
> Kerri Lemoie:  But this is an example they provided a little from 
>   batch.
> Kerri Lemoie:  You can see from the structure that it looks like 
>   a verifiable credentials so this is what is intended as you know 
>   an alignment with a verifiable credential we have a context we 
>   have a type and ID issuer a date a credential subject and then we 
>   have a proof.
> Kerri Lemoie:  I'm going to do is go through and explain what all 
>   of these elements are in the context of matches so context so a 
>   verifiable credential has context is json-ld and we use this to 
>   determine what the properties are in the credential so minimally 
>   we always have the verifiable credential context at the top open 
>   badges credentials will have their contracts file.
> Kerri Lemoie:  Since about this one I'm not sure why this one is 
>   here so I'm going to ignore that for now.
> Kerri Lemoie:  One thing that they've added so it's verifiable 
>   credentials and ID is optional with open badges they've made this 
>   required and it can be a URI not necessarily a URL as presented 
>   here it could be a uid but it should be as they said in their 
>   spec and unambiguous reference to the crunch so this is a unique 
>   ID / issued credential.
> Kerri Lemoie:  Marty here in the queue.
> Marty Reed:  Yeah I just wanted to speak on the ID being required 
>   just because I know that was a.
> Marty Reed:  Um interesting kind of decision from a verifiable 
>   credential standpoint but the reason why and it was debated 
>   amongst the group significantly was this is a transition.
> Marty Reed:  From very centralized spec to a you know support 
>   decentralized verification so as we kind of transition from 
>   centralized to decentralized some things like ID are very useful 
>   in a centralized format and so and so that was why it can remain 
>   required to provide that kind of transition between specs.
> Marty Reed:  That makes sense.
> <phil_l_(p1)> Just to clarify - list of items in Kerri's slides 
>   are differences between 1EdTech vs. the VC v1.1 data model.
> Kerri Lemoie:  Thanks Marty does anybody have any any points to 
>   make about that.
> Kerri Lemoie:  Thank you Marty and I just you Phil Long's message 
>   in there I had to clarify the list of items that I have in the 
>   slides are the differences between the trade between what one 
>   edtech has implemented and what's in the VC data model.
> Kerri Lemoie:  The next type tape is something very we're 
>   accustomed to and verifiable credentials we have a type of 
>   healthcare Angela and then we have the type open batch 
>   credential.
> Kerri Lemoie:  Which relates to what's in the context.
> Kerri Lemoie:  Super issuer issue or a verifiable credentials an 
>   issuer can be an object or it can be a single ID in this example 
>   that they provided it's an object and the object actually the 
>   issuer from what I can tell must be always be an object because 
>   it has to contain a type this type array which references 
>   profile.
> Kerri Lemoie:  Profile I put a link to in here is a series of 
>   fields that can describe the issue.
> Kerri Lemoie:  Should the profile elements are not required but 
>   the type profile is required.
> Kerri Lemoie:  And sometimes looking at this and calculating this 
>   been pretty sure that this here refers to this ID here.
> <keith_kowal> Can the issuer ID be a DID?
> Kerri Lemoie:  I'm name is not required as part of this year.
> <dmitri_zagidulin> @keith - yes.
> Kerri Lemoie:  But there is a name that is required.
> Kerri Lemoie:   We go.
> Kerri Lemoie:  And hear me close that sorry everybody is human 
>   state is part of the v-spec and that is required as part of the 
>   v-spec the open badges spec requires name and this reference is 
>   the string and references the name of the credential subscribed 
>   for display purposes in the wallets.
> Kerri Lemoie:  Checking the cube okay.
> Kerri Lemoie:  Next we have credential subject credential subject 
>   is part of the v-spec the ID references the subject that the 
>   claim is about.
> Kerri Lemoie:  I'm going to pause there David see you in a few 
>   you're the floor.
> John Kuo: +1
> Kerri Lemoie:  I thank you for bringing that up that's been a 
>   historically sort of question open badges to over the years it's 
>   been interpreted differently what's been happening and I 
>   discussion in the V2 group.
> Kerri Lemoie:  That's great thank you for bringing that up so 
>   long.
> Phil_L_(P1): Yeah that's actually going to become even more 
>   significant as we get to the point of trying to retroactive a 
>   retrospectively convert issued credentials from years past into a 
>   verifiable credential format and and so it's not unreasonable to 
>   think in a relatively short time someone will have credentials 
>   from 10 years ago or eight years ago that an institution issued 
>   as a PDF or whatever and.
> Phil_L_(P1): It is to convert that into a structured.
> Phil_L_(P1): She'll have been developed and that big difference 
>   than will become pretty significant.
> Kerri Lemoie:  Thank you David that's really good to know.
> Kerri Lemoie:  Hey I'm going to move forward so the one the field 
>   we were just up for the conversation was a name teamwork this 
>   example is teamwork badge and this is a required field in the 
>   open badges spec.
> <david_ward> In OB3, there is an activityStartDate and 
>   activityEndDate allowed in the credentialSubject to specify those 
>   dates.
> Kerri Lemoie:  Then we were talking my potential subject I think 
>   what I just said was ID is the subject ID of the claim being made 
>   in the credential subject I'm in the open badges fact they Define 
>   this credential subject as an achievement subject I have 
>   questions that we've submitted about this being an array but the 
>   type of potential subject for an open badge is an achievement 
>   subject and then in the open badges specification.
> Kerri Lemoie:  Spell out the fields that are required in an 
>   achievement.
> Kerri Lemoie:  It's the little bit this is the the schema did I 
>   let me find the chart for you so it's a little bit easier to 
>   read.
> Kerri Lemoie:  And so these are the properties of the achievement 
>   subject.
> Kerri Lemoie: 
>   https://imsglobal.github.io/openbadges-specification/ob_v3p0.html#achievementsubject <https://imsglobal.github.io/openbadges-specification/ob_v3p0.html#achievementsubject>
> Kerri Lemoie:  That you can look at here.
> Kerri Lemoie:  For part of sorry about that so the we have the 
>   type the required type of credential subject is that you've been 
>   subject and then we also have a required achievement and 
>   achievement is interesting human is something we actually 
>   proposed as part of the original proposal for alignment because 
>   we were talking about this at least a year and a half maybe two 
>   years ago about how bcig we are suggesting that this could be.
> Kerri Lemoie:   Has achievement or has credential based on what 
>   is in scheme.
> Kerri Lemoie:  So this was a carryover from that and 
>   coincidentally achievement was being used in the CLR model so it 
>   made sense to I use achievement here rather than has achievement.
> Kerri Lemoie:  I'm you can see here that there's an ID for this 
>   achievement object in the ID is also required as part of the 
>   achievement in the open badges specification much like the 
>   credential ID that Marty and I were referencing earlier this one 
>   can also be a uuid does not have to be a URL and I'm sure Marty 
>   my degree my you could come on in and say this too was also sort 
>   of about bridging to previous versions of open badges.
> Kerri Lemoie:   Where the achievement was actually called the 
>   badge class.
> Kerri Lemoie:  As was hosted at its own URL and so this is a 
>   little bit of a reference to that I I believe.
> Marty Reed:  Yeah I can I can jump in that's exactly right and 
>   there's a concept if you think about the two specs that are that 
>   are currently under development at one attack one being this ob3 
>   the other being the CLR to and so in order to kind of better 
>   align those said that a CLR can actually be a collection of ob/ob 
>   3s this was kind of part of that that transition but you know 
>   we're.
> Marty Reed:   Continuing to you know.
> Marty Reed:  Learned and as people start using the collection.
> Marty Reed:  Generality within CLR I'm sure there will be 
>   there'll be more maturity as it as it goes along but yeah you're 
>   exactly right curious kind of aligning so that CLR can be a 
>   collection of open badges.
> Kerri Lemoie:  Thanks Marie and the other elements that are 
>   listed in the achievement here are the required ones so we have a 
>   criteria we have type achievement and once again I'm not really 
>   sure why this is an array so I've asked this question too because 
>   I don't know what else what other type would go in here criteria 
>   is required although the elements that go in the criteria are not 
>   required so that is also.
> Kerri Lemoie:   An open question.
> Kerri Lemoie:  Have the think seven from IMS already made a 
>   comment that that was the same way in 2.0 so I think I'm going to 
>   start need some clarification that if there's a criteria object 
>   what is is what is required as part of that criteria and then 
>   description and name are also required as part of the 
>   achievement.
> Kerri Lemoie:  You're the key you have the floor.
> <sharon_leu> @Marty, probably an offline convo, but curious what 
>   is the use case for collection (clr2) vs presentation  of badges
> Kerri Lemoie:  Right yeah that's really interesting and that you 
>   know what I think as we get further into VC edu we're like at the 
>   beginning.
> Kerri Lemoie:  In these alignments it'll be interesting to 
>   explore that you specifically to I can see why it could be an 
>   array I don't see why it's required to be an array.
> Kerri Lemoie:  Is my question though.
> Dmitri Zagidulin:  Like I know the answer to that.
> Kerri Lemoie:  Oh yeah that's a good question we should post that 
>   question so feel free to make a an issue about that in the repo 
>   cause that's a good question but Dimitri does he answer to good 
>   Dimitri.
> Dmitri Zagidulin:  So the reason there were already was an issue 
>   in a long argument and somebody was arguing hard for Criterium 
>   and I think the consensus was although that is technically 
>   correct it's sufficiently it's officially exotic that would just 
>   not going to worry about it and make this exception because 
>   everybody interested right area.
> Dmitri Zagidulin:  Yes wreck that was consensus.
> Dmitri Zagidulin:  The other thing I wanted to mention briefly 
>   though is I think the requirement for the irony thing is going to 
>   perform is going to encounter a lot of friction in the verifiable 
>   credential world I know it breaks our libraries as well because.
> <john_kuo>      +1 i recall this discussion.  clarity > accuracy...
> Dmitri Zagidulin:  Breaks but it requires a dish a lot of 
>   additional code because it's valid json-ld to have either a 
>   single element or an array and so what a lot of credentials end 
>   up doing is just having.
> Dmitri Zagidulin:  Litems and which will which will fail against 
>   the obv three schema.
> Dmitri Zagidulin:  So I certainly strongly disagree with over 
>   that design decision.
> Kerri Lemoie:  You think so jbm there's an issue for that 
>   submitted after that discussion.
> Kerri Lemoie:  And I think what I don't have on this list 
>   surprised that I don't is this proof section.
> Kerri Lemoie:  So for a verifiable credentials one proof is 
>   required but with open badges it doesn't require proof that it 
>   does require these elements it seems if the proof exists I have 
>   some confusion about about that so I think it's not it's not 
>   really clear to me and what is going on and what is being 
>   determined by the proof because I know there were some 
>   discussions about what is required for certification of open 
>   badges 3.0 versus the.
> Kerri Lemoie:  I meant with the v-spec there are some things.
> Kerri Lemoie:  The in the schema.
> Kerri Lemoie:  A proof value that is required for proof value is 
>   specific to certain since your methods so I submitted some issues 
>   about that too so on the fourth page of the slides these are some 
>   issues that have been submitted to sort of ask these questions 
>   and and I know some of them they're already being worked on right 
>   now and people are having discussions I'm sure I think there's a 
>   call this week in that group and I'm sure they'll take a look at 
>   this because they're aiming to go in.
> Kerri Lemoie:   Ooh candidate final.
> Kerri Lemoie:  And some of these yeah we'll see where they had 
>   with them I think I've mentioned most of these as we walked 
>   through them already.
> Kerri Lemoie:  Oh this is okay well why don't I just look at the 
>   proof ones real quick here so one was that.
> Kerri Lemoie:  Yes this is what I had mentioned that the spec 
>   doesn't require a proof but VC spect US Open badges 3.0 doesn't 
>   require one but BC spec does however if I'm proof is there it 
>   does require it to be an array.
> Kerri Lemoie:   This is.
> Kerri Lemoie:  Is similar to the other array questions for a 
>   types right proof could be an array but it doesn't should it be 
>   required to be an array and then the other one was a season twice 
>   but the required items that I'm not really clear that I didn't 
>   really understand why these are required specifically because it 
>   seems to be a method specific some of them and also I'm not sure 
>   if they're saying that a specific method is required for open 
>   badges 3.0 or not.
> Kerri Lemoie:   Not so it's um.
> Kerri Lemoie:  Think hey so that's that's what I have for today 
>   in terms of explaining where match 3.0 is so they'd open up the 
>   floor and see if anybody has other questions or wants to talk 
>   about it or I'll do my best answer I haven't been part of the 
>   working group for a little while so I don't have exactly the 
>   answers but Marty's here and we can also pass along questions if 
>   anybody has any.
> <phil_l_(p1)> Perhaps those differences that are salient to the 
>   plugfest might be a good focusing factor?
> Kerri Lemoie:  You have the floor how you doing.
> <marty_reed> yes, they will be discussed in the workgroup this 
>   Thursday
> Keith Kowal:  I just wondered I saw I'm not been in the community 
>   conversations you know a big element of previously of previous 
>   open batch some respects where this the public web page I'm I'm 
>   sure that that's still an option and open Box 3.0 but how does 
>   the community seeing the role of public web pages associated with 
>   achievements moving forward.
> Kerri Lemoie:  I'm going to ask Marty answer your question but 
>   before I do Keith you mean in terms of what used to be called the 
>   badge class those achievements or the entire verifiable 
>   credential.
> Keith Kowal:  Maybe I'll just make it more simple like you know 
>   in open badges 2.0 the you know having a web page displaying your 
>   achievement was a fairly you know fundamental thing that you 
>   could post in your LinkedIn profile or post on your Facebook so 
>   will that still be a key element of these credentials moving 
>   forward.
> Kerri Lemoie:  Right so one of the required items for the 
>   verifiable tarantula probe measures 3.0 is that ID and ID can be 
>   the URL but it doesn't require to be URL it could also just be a 
>   uuid.
> Kerri Lemoie:   And if.
> Kerri Lemoie:  That from my perspective from the point of verify 
>   the credentials learner or person who's earned this credential 
>   should be able to decide what that URL is and it shouldn't be 
>   public unless that individual has decided to make it public which 
>   I think is is the opposite of what 2.0 and other versions of open 
>   badges were which is that open badges data was always public 
>   because that was how it was verified and it was a sort of the 
>   platforms to negotiate that with the learners but not part of the 
>   specification.
> Marty Reed:  Yeah I just I think it's important I just want to 
>   reiterate the the concept of the transition that's occurring 
>   right now with these specs as far as trying to better align with 
>   verifiable credentials but not lose functionality that was 
>   already built into open badge and to CLR and so this this 
>   alignment with verifiable credentials.
> <dmitri_zagidulin> Marty are you saying it'll be fixed in OBv4? 
>   :)
> Marty Reed:  Position but also the idea behind the transition of 
>   the spec was let's not change too much that we've already that 
>   we've already built into the spec that is valuable to the already 
>   existing community.
> <dmitri_zagidulin> awww hahah too bad
> Marty Reed:  And I'm not saying that Dimitri I'm just saying that 
>   this is where we're at today and will learn a lot in between here 
>   and here and there.
> Kerri Lemoie:  I'm ready I this is just my opinion on that is I 
>   appreciate bridging strategies because we're going to need them 
>   for everything and and I appreciate that that is being considered 
>   another bridging strategy that could be considered for those who 
>   are already implementing 2.0 Badges and want to implement 3.0 
>   badges is to do both of them is to keep the 2.0 system they have 
>   going and then add 3.0 to that as another layer for instance 
>   saying to your users on your platform.
> Kerri Lemoie:   Warm hey would you like to put this in a wallet 
>   and then using the.
> Kerri Lemoie:  Functionality but then letting the 3.0 spec live 
>   on in other ways in your platform that that's just another way of 
>   doing bridging so that's like two different ways to really look 
>   at it one is to say okay let's convert to 3.0 and do that and the 
>   other is to keep both going the same time.
> Marty Reed:  And if I could respond that is you know in our open 
>   source project with North Dakota open credential publisher that's 
>   exactly what what is there there's a publishing service that 
>   takes the CLR 1.0 spec but it also applies to OB 2.0 and it 
>   transitions it or packages as a verifiable credential so so it 
>   can be done.
> Marty Reed:   There's a.
> Marty Reed:  There's something out there that does it.
> Kerri Lemoie:  Thank you Maddie and David you are the floor.
> <david_ward> OB3 does still allow for "baking" a badge into an 
>   image as well, so that it could be shared.
> Kerri Lemoie:  That's right that's right thank you David David 
>   word rings ever interesting thing in the chat that I totally 
>   forgot that should definitely be mentioned it's a huge part that 
>   I didn't mention at all which is the image aspect of open badges 
>   historically open badges were portable because they were baked 
>   into an image that was required up to 2.0 is required that the 
>   data.
> Kerri Lemoie:   I be baked into the image so that the image.
> Kerri Lemoie:  Read in that way it wasn't always mostly how 
>   people used it most just put it on a webpage and displayed the 
>   badge which wasn't really actually part of the spec but it was 
>   always sort of required to do the baking and a badge image was 
>   always required but with 3.0 is optional so you can still do the 
>   baking and you could that's really interesting when we should 
>   talk about and BC edging what it means to bake a VC into an image 
>   and then also you can.
> Kerri Lemoie:   It image if you want to as part of as part of.
> Kerri Lemoie:  The lung you have the floor.
> Phil_L_(P1): Yeah well I just wanted to extend what you just said 
>   in that if you included image in the v-spec you're including just 
>   the image in you're not.you're not doing the baking in that by 
>   including the image in the v-spec you're giving an image that 
>   goes along with the data that's in the Json lots of study at that 
>   link to that image is also contained so there is a there are ways 
>   of making or or layering.
> Phil_L_(P1):  the data of a VC into.
> Phil_L_(P1): An image in the context of qr-code but those but 
>   that's a different process.
> <davidc> David_Chadwick pointed out that there are two separate 
>   issues: privacy and validation. In OB2 they were baked together. 
>   With VCs they are separate
> Kerri Lemoie:  If the baking that we're talking about is specific 
>   to how open the open badges specification is saying that it could 
>   be done and also images are URLs they aren't embedded in the in 
>   the in the batch.
> Phil_L_(P1): That's the point.
> Kerri Lemoie:  Anybody else have any questions or things that you 
>   see in the spec that you would you'd like to discuss.
> Kerri Lemoie:  And Transit plugfest we're going to be discussing 
>   it's going to be probably be a very basic open badge and with 
>   issue or information and an achievement information and will work 
>   with the cohort Wednesday to determine you know what that will be 
>   and what the structure of that will be and I think it's really 
>   great that we have a specification that is aligned with 
>   verifiable credentials it is spurred so much conversation over 
>   the past year.
> Kerri Lemoie:  Verifiable credentials and really brought so many 
>   people together.
> Kerri Lemoie:  Topic that had never.
> Kerri Lemoie:  Considered it before and it's really sort of like 
>   shifted the conversation in digital credentials so it's really 
>   great it's really great that we are at the stage where it's 
>   happened and we're going to keep working on it and towards it as 
>   Marty said right the we're not like it's not done right we'll 
>   keep going on this he Keith I see you in the queue and I put you 
>   on the floor there.
> Keith Kowal:  Leonard I guess it's close to the high-level use 
>   cases for open badges 3.0 but you know looking at the schemas I 
>   see the achievement schema which I'm you know which I think we're 
>   pretty used to and then I see also see Lady endorser schema which 
>   I probably am less familiar with ordered using like this scheme 
>   is a framework that we could talk about like the high-level use 
>   cases you see for the I mean people Envision for the for this new 
>   version of the spec.
> Kerri Lemoie:  So I don't know if I'm the best person to speak to 
>   that but I see that Marty put himself in the queue so I'm going 
>   to call him Marty do it the dress so he's question.
> Marty Reed:  Well I can I can speak to I guess some of it not all 
>   of it but I guess the one thing that you mentioned Keith about 
>   the endorsement portion that the use case they're just selfishly 
>   from our application is for Teacher credential there's a 
>   endorsement of that teacher for a specific content area and they 
>   have to be endorsed for a Content area in order for them to speak 
>   and that.
> Marty Reed:   Is just kind of.
> <john_kuo> Phil Long did a presentation some time ago on the 
>   Endorsement use case
> Kerri Lemoie:  X-ray we're another thing that I didn't mention 
>   today because it's not a required element and we're not using it 
>   in the in the plugfest but we did talk about it a long time ago 
>   and people were very happy with it and I think it comes to 
>   addresses these cases question is achievement type.
> Kerri Lemoie:   I'm going to put this.
> Kerri Lemoie:  This link to it in the chat.
> <kerri_lemoie> achievement type: 
>   https://imsglobal.github.io/openbadges-specification/ob_v3p0.html#org.1edtech.ob.v3p0.achievementtype.class <https://imsglobal.github.io/openbadges-specification/ob_v3p0.html#org.1edtech.ob.v3p0.achievementtype.class>
> Kerri Lemoie:  This is the first time in open badges where 
>   achievement type is was was listed I before I was an open bed was 
>   a batch and we always said well open badge could represent 
>   anything and that was always the case but it never explicitly 
>   said hey what is it representing which many people find very 
>   helpful just to know that right we do have to leave it up to 
>   interpretation it specifically says is it it assessments and an 
>   assignment is it a bachelor degree is it is.
> Kerri Lemoie:  You forget and this list that I'll link to in the.
> Kerri Lemoie:  Had is actually.
> Kerri Lemoie:  Aligned with the list I think mostly if not all 
>   atom with the ctd L list with Greg credential engine which is 
>   awesome right so that if a credential engine is these properties 
>   are listed in credential engine it will map to what's in an open 
>   badge which is an incredible accomplishment in terms of aligning 
>   aligning content and sort of understanding and meaning behind the 
>   digital credential.
> Kerri Lemoie: 
>   https://imsglobal.github.io/openbadges-specification/ob_v3p0.html#evidence <https://imsglobal.github.io/openbadges-specification/ob_v3p0.html#evidence>
> Kerri Lemoie:  I mean when other thing I'm going to mention here 
>   to is evidence and I mentioned I just because it's my favorite 
>   part of a Meadows and I think that there's some tremendous there 
>   has been tremendous opportunity with that in previous versions 
>   but also in future versions especially especially considering 
>   verifiable credentials and some of the work that's been happening 
>   with hash linking and how to say I am going to verifiably.
> Kerri Lemoie:   Link to this this content.
> Kerri Lemoie:  Demonstrates this achievement when over badges 
>   first started the evidence was actually a very like primary 
>   discussion is part of all of this because the evidence was deemed 
>   to be like one of the most important parts of demonstrating with 
>   the recognition was but over the years it's just sort of like 
>   falling back because there's a lot to handle in terms of like 
>   media and assets and you know that those are really big questions 
>   that a lot of organizations just really can't tackle but it's 
>   something to consider.
> Kerri Lemoie:   As you're thinking about doing verifiable 
>   credentials as open badges.
> Kerri Lemoie:  I don't see anybody else in the queue we're about 
>   10 minutes to the hour.
> Kerri Lemoie:  I'm glad you brought that up because we talked 
>   about that the spring about about using using the evidence 
>   property and determine the same thing that it was possible to do 
>   that thank you for mentioning it because there is different use a 
>   little bit of different contexts there Dimitri.
> Dmitri Zagidulin:  So the the tricky thing about reusing the 
>   evidence property there is the top-level evidence field is 
>   specifically the evidence of the verifiable potential and the VC 
>   wonder One data model is a little vague on what evidence is 
>   supposed to be for but General consensus is that it's you know 
>   what kind of documents or whatever well what kind of supporting 
>   evidence was submitted at the time of.
> Dmitri Zagidulin:   They showing the credential.
> Dmitri Zagidulin:  But to do what evidence of the achievements 
>   you can just reuse the top level evidence field from the VC data 
>   model the achievement itself has to have an Evidence field so 
>   it's an easy thing to mix up.
> Kerri Lemoie:  Thank you Dimitri.
> Kerri Lemoie:  Okay does anybody else have anything to say on 
>   that topic or.
> Kerri Lemoie:  Matches or bcig you for today.
> <davidc> David_Chadwick pointed out that the VC evidence field is 
>   a set and therefore it can represent the evidence associated with 
>   the open badge credential and, as the NGI Atlantic project is 
>   doing, evidence related to the authentication of the user
> Kerri Lemoie: 
>   https://github.com/IMSGlobal/openbadges-specification/issues <https://github.com/IMSGlobal/openbadges-specification/issues>
> Kerri Lemoie:  One thing I missed was recommended and I think 
>   would be a good idea as if you have any questions that you'd like 
>   to spend about open badges that we may not answer today we have 
>   an inch today or you can submit them here do you go to the 
>   repository and you click on issues and then you click new issue 
>   and all you need to do that for that is a GitHub user account.
> Kerri Lemoie:  Of them as 3.0 because that helps them figure out 
>   that the question is related to this version.
> Kerri Lemoie:  And then they'll take it up in the working group 
>   and discuss it there and let us know how it goes.
> Kerri Lemoie:  Okay thank you everybody we have a good week and I 
>   will see many of you I hope on Wednesdays take off for the 
>   plugfest.
> <john_kuo> Thanks Kerrie!
> <keith_kowal> thank you
> 
>