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

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>
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>


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