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

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/

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

----------------------------------------------------------------
VC for Education Task Force Transcript for 2022-10-17

Agenda:
  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)> :-)
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/
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
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
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
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
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
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
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

Received on Monday, 17 October 2022 21:45:38 UTC