The W3C Credentials Community Group

Verifiable Claims and Digital Verification

Go Back

CCG Verifiable Credentials for Education Task Force Telecon

Minutes for 2021-05-23

<kimhd> Okay welcome So today we are talking about.
<kimhd> A new approach forward to through our schema journey, starting with open badges and carrier walk us through that carry Illinois and so let's.
<kimhd> Do it note anyone can participate in these calls, however, all substantive contributors to any cct work items must be members of the CC EG with full IPR agreement signed here's the link to join CG.
<kimhd> and know that that's also in the agenda that was sent out so before joining you should make sure also will it'll prompt you in fact that you have a w three web account and so that is free and open to the public.
<kimhd> And texts of the Community wc Community contributor license agreement is available at this location.
<kimhd> To call notes these Minutes and audio recording of everything set on this call.
<kimhd> Are archived at the CCG meetings github repo and you can see the html versions at this length that I pasted just to note that i'm a bit behind on meeting post.
<kimhd> archive posting so i'm going to try to get back on top of that, this week.
<kimhd> Okay, during the call if you have something you want to add just type Q plus in the chat so that we can preserve order.

Topic: Introductions and Re-introductions

<kimhd> Is there anyone that would like to introduce themselves start with anyone new to the call or anyone who's sort of undergone a career shift recently that they like to introduce themselves in a new context.
<joonas_trussmann> hi, i'm Joonas Trussmann.
<joonas_trussmann> And somebody from the Estonian education sorry a Heidi seen have working on a educational wallet over abolish limit the amount of moves, we need to just listen in on this call i'll be solid from now on.
<kimhd> Wonderful thanks for joining.
<kimhd> For reintroductions sorry to put you on the spot Tzviya, but if you wouldn't mind reintroducing yourself.
<tzviya_siegman> Sure i'm sorry a segment I work for wiley and I do a little bit of work with wiley's learning management systems and IMS and on on the advisory board at the wcc and I did some work with her viable credentials ended up being three.
<kimhd> hey thanks for joining us Tzviya.
<kimhd> Okay, and, just in case for anyone who did not get the link directly.
Kim Hamilton Duffy: Here is the link to the agenda:

Topic: Announcements and Reminders

<phil-t3> This is phil there's a meeting tomorrow in the early afternoon.
<phil-t3> For the T three innovation network to mark the.
<phil-t3> kickoff of the next round of work from that organization and that will be tomorrow at.
<phil-t3> 10am PDT that would be 1pm edt.
<phil-t3> And it's the launch of their so called network of networks for work group for work channels that encompass the learning and employment record.
<kimhd> But if you fill in for context teacher innovation network has been helping a lot with incubating standards in this space in fact they.
<kimhd> were behind the.
<kimhd> Self sovereign learner employment records work group and paper and then also that lpr rapper standard which.
<kimhd> has basically it's a ll er as verifiable credential so a lot of things that have informed this working group, in fact, so that's a good chance to see what the T three innovation network is up to as it keeps moving forward.
<kimhd> Okay that's all for announcements and reminders I think so, with that I think we're ready to move forward to the main event and.
<kimhd> kerri I was planning to just turn over to you if that's all right to walk through the proposal and I didn't know if you had anything you wanted to share but otherwise just i'll turn it over to you.

Topic: Open Badges v3.0

<kerri_lemoie> Sure, morning everybody.
<kerri_lemoie> And I don't have sides to share, I have some points to talk over, and then a couple of things to show.
<kerri_lemoie> you hear.
<kerri_lemoie> me is here cool.
<kerri_lemoie> Because he has a chart they.
<kerri_lemoie> can show us to so over the past few weeks we have been discussing.
<kerri_lemoie> know how to essential pillars right we're spending a pillar in the context of learning a public record.
<kerri_lemoie> And then we started talking about open badges and what are the potential opportunities for open badges and if you know if that is the best way best my best opportunity right now.
<kerri_lemoie> And i'm after you having other conversations outside of this call, and then, with many of you, which by the way, thank you for for taking time to talk to me about all of this.
<kerri_lemoie> The most consistent proposal that came across from everyone is to focus on open badges because it is the simplest use case it is already in json ld.
<kerri_lemoie> And also that.
<kerri_lemoie> By implementing a full lifecycle I wonder if I will put into as a badge we can actually see you know, maybe what happens, what can happen for other.
<kerri_lemoie> Potential other standards, and we want to implement as verifiable credentials, so the goal would be to sort of shift the focus to badges are as a native were looking into and then complete a cycle like from a Co pilot cycles from issuance replication and with your at least a wallet.
<kerri_lemoie> And then i'm see what we learned from that so that we can inform how other verifiable credentials and education could work.
<kerri_lemoie> Now what we what we think we probably have been struggling with all along, is that we have all these many use cases and it gets very complex and as we get down in a certain way, like Oh, what about this, what about this thing.
<kerri_lemoie> And, but if open badges themselves can be very complicated, even just either on simple.
<kerri_lemoie> approach it, and I say simple release to the madness and some other potential opportunities in doing this could be that we look at open badges.
<kerri_lemoie> As a native verifiable financial so instead of looking at other options that we looked at last week, the week before instead.
<kerri_lemoie> We just say hey what is an open badge as a verifiable financial and just go for it.
<kerri_lemoie> And then, while doing now, we have other opportunities for the matches, we could do things differently, like distinguish the difference between a crater and an issuer.
<kerri_lemoie> We could add a credential type and we could also that that property is from to to enhance the properties that could be in a batch.
<kerri_lemoie> So I wanted to start there with this proposal and to see what folks think and and see if we can reach a consensus on nine so, then we can sort of look at.
<kerri_lemoie> You know what direction, this would go in and maybe it's either a very early example of what a no magic the quake as a native vc.
<kerri_lemoie> so you have a question, so why don't we start there oh.
<phil_barker> yeah.
<phil_barker> I think this is a good idea I think it's a good idea to start with.
<phil_barker> Open badges for the reasons that you laid out and but what I think we should keep an eye on.
<phil_barker> All of those complicated use cases that whole sort of mess of things that have been knocking off because of course we shouldn't let it let them knock us off course.
<phil_barker> But I think we should look at some of the things that might be problematic with open badges before we go into too much depth of how you model, an open badges a native verifiable credential shirt so.
<phil_barker> We should.
<phil_barker> try and get Anthony back on one of these columns to talk about his use cases of multiple issues and how you can address that with.
<phil_barker> The open badges we should look at the different types of things that you might want to credit, you know the.
<phil_barker> The three top level concepts, is it three anyway, the top level concepts that we worked through over the last few weeks, and I think we should look at those before we go into too much depth on you know small little england's to be open badges models.
<kerri_lemoie> yeah absolutely.
<kerri_lemoie> I don't want to abandon the more complex use cases I just don't want to get bogged down with them.
<kerri_lemoie> I think that, like, for instance, open badges they have one issue or verifiable potential has one issue or could they be multiple issues that are like combined into one issue I mean I might happen to go badges now but.
<kerri_lemoie> we're still there's only one issuer and the credential, and so there are some similarities already between open badges assertion and a verifiable financial assertion, I also think that this many ways can inform how we can approach CLS as verifiable credentials.
<kerri_lemoie> i'm looking at the chat here.
<kerri_lemoie> A year later.
<kerri_lemoie> yeah i'm sorry i'm excited to see phil on.
<phil-t3> nate's up i'm just saying.
<kerri_lemoie> Oh Nice.
<kerri_lemoie> Okay.
<ottomomy> yeah I was just saying a multiple assures sounds like a verifiable credential level concern, and so we can elevate that back up to the full Community group.
<ottomomy> This is not in the scope of education to offer really like a what is the conical.
<ottomomy> verifiable credentials way to do something concepts such as multiple issuers, we can describe other more limited scope problems here, probably and then eventually model them like an issuer that has a relationship to a parent organization something like that.
<ottomomy> And I don't think that wouldn't necessarily block consideration of any particular modeling.
<ottomomy> A path forward but yeah we can consider some more advanced cases I think that allowing ourselves to be bogged down with and stop ourselves from pursuing a model would be an Anti pattern.
<kerri_lemoie> Thanks, I put one of the give every place in the chat.
<kerri_lemoie> Yes, totally agree with that i'm Kimberly you had a question about full issuers.
<kimhd> yeah I wanted to also talk to multiple issues and carriers my co chair, I encourage you to shut down conversation on me if I get too long winded so.
<kimhd> My my thought is absolutely what made is saying, and I think we have discussed multiple issuers already in the document the vc ED models document.
<kimhd> we've talked about an approach to multiple issuers at the vc at the verifiable credential level, I think the one other thing that.
<kimhd> You know, we could consider is just clarity around what we mean by issuer because I think frequently when we get bogged down in multiple issues we're talking about all different kind of.
<kimhd> sort of I don't know certification bodies or something that we don't actually mean by a verifiable credential issuer, so I would actually I don't think we need to block on that, I think.
<kimhd> Maybe that's a good idea for a focus group if okay if maybe here's a proposal if if people think that that's very important or they don't and they are sort of.
<kimhd> You know I think in my mind, I see that it is a.
<kimhd> question that doesn't need to bog down further discussion, however, I get that not everyone would accept that so.
<kimhd> If people would like to move forward on that, I think that might make sense to do a breakout group to come back with a proposal and clarity, otherwise that's something that i'd rather just leave that be, for now, because we've given a lot of attention to it.
<kerri_lemoie> Like the idea of a breakout group is there anybody on the call right now, that would be interested in leading a breakout group to discuss multiple issues they would like to bring it back to us.
<kerri_lemoie> In a future call.
<phil-t3> i'd be happy to be on that group i'm not sure I have bandwidth to lead it leading it also means summarizing all the work.
<phil_barker> yep similar here it's Anthony who's raised this as an issue a couple of times and I don't think we should discuss it now, I think the opposite, I think we should get something solid as a proposal for dealing with.
<phil_barker> Open badges and then see how we can address multiple issues within that framework, and I think it does need, we do need to go back to Anthony to get better a fuller description of him some concrete examples of where multiple issues and needed.
<kerri_lemoie> On this call right now.
<kimhd> No he's not been for a while, so I think that you know it's it's on him to sort of follow the output of the group, and you know, make sure it's abby so I don't think that he needs to be a gatekeeper here.
<kerri_lemoie> and
<phil-t3> Marty I don't want to put you on the spot, but I know that you're dealt with this problem and.
<marty_reed> You certainly would be a voice that would be.
<phil-t3> My question is, is there a way that the definition of an issue or can be sufficiently bound, that the issues, corresponding to those that have what seemed to be more of an administrative political need to delegate legal responsibility in a chain.
<phil-t3> Is it possible to deal with those outside of the scope of the actual code that's that's defining the issue or of the particular badge in question.
<kerri_lemoie> I think bill, that is all of those things really why we want to set it aside as a separate conversations to maybe we put this in our back pocket, for now, and then we revisit it, because if folks think it's important we should address it, but also.
<kerri_lemoie> I don't think it is the simplest use case that we can tackle first right at the simplest use case is that we have.
<kerri_lemoie> An issue shooting a badge and recipient, and you know it can go to a wallet and then they the badge gets sent from the wallet to a presentation to verify.
<kerri_lemoie> It we really like to just tackle well we don't have it's funny you on this call last week and.
<kerri_lemoie> It was like all these complex cases of like wallets and how are they all going to use the word he had to prove that even wonder if I will financial education can be moved around in this way.
<kerri_lemoie> That we all feel very good about and so why don't we just happen like that really easy space.
<kerri_lemoie> And then, yes, come back in and take care of this complex use cases and I think we're talking pretty fast right, I think we would like to get through the simple use case like until the early fall and then really see what we've done with this and then move on from there.
<marty_reed> So i'll throw my hat in the ring for the breakout group I was debating on if I had bandwidth, but this is very important topic so all right don't.
<phil-t3> count on it to then Marty help you and phil Parker, would you be willing.
<marty_reed> Those are those that are being me.
<marty_reed> to join that breakout.
<kerri_lemoie> As great money Thank you and then maybe we paid a report, but could you let us know, maybe like after you on mute once when you'd like to sort of come back to us with it and we'll make sure that we include that.
<kerri_lemoie> On one of the calls when we will feature what you're doing.
<kerri_lemoie> Thank you.
<kerri_lemoie> Okay, so I guess like I said open this up a little bit more of a discussion to see there's any other concerns about taking this approach.
<kerri_lemoie> And not him i'd like to make a proposal that we see we have consensus on this approach.
<kerri_lemoie> Here is any objections.
<kimhd> In the chat type well last one, if you want to endorse minus one with the comment if you're actually just minus one and then we'll call on you, if you have any objections.
<kimhd> To terry's proposal so that proposal just let me write that down so proposal was move forward with open badges as actually can you say that again.
<kerri_lemoie> Oh yes, the proposal is to move forward with a simple example a full cycle education example of open badges as a verifiable financial has that.
<kimhd> Okay, that looks good.
<kimhd> So mark, this is a resolution.
<kimhd> Here accepted that.
<kimhd> The exception being the breakout group i'm imagining Marty.
<kimhd> yeah.
<kimhd> I have that noted to.
<kimhd> Okay excellent he just joined by the way.
<kimhd> Alright, so I guess, we can keep moving forward.
<kimhd> kerri what was the sort of next part after that you mentioned that perhaps nate had something that he wanted to cover.
<kerri_lemoie> yeah so i'm going to be meeting some Venus child, so I am going to screen share it then i'm going to hand it over to need to sort of explain it through.
<kerri_lemoie> And then, what I have is a very, very rough example of what an open badge as a verified look look look look like as a beta verify looking at.
<kerri_lemoie> i'm going to share my screen right now.
<kerri_lemoie> All right, can you see it.
<kimhd> Yes.
<kerri_lemoie> Okay, did you explain your chart for.
<ottomomy> Sure, so we've talked about the idea of open badges a number of times before, and you know, the idea that had been implemented by open badges it's a generic concept that we've talked about a lot with the idea of a defined.
<ottomomy> achievement that is a bundle of information provided by a specific issue or about a learning opportunity, maybe, an assessment.
<ottomomy> An image that represents the the achievement, a description and specific criteria of what it means for an individual to have earned it.
<ottomomy> And that, in order to fit this already json ld structure as it's been implemented an open madness and other you know linked data structures, like, for example with education occupational credential.
<ottomomy> into a verifiable graduate, we need to find one that particular essential claim, which is what does the credential subjects relationship to this concept of the defined the achievement that they have earned look look like, and so in this diagram that.
<ottomomy> This is a verifiable credential up at the top, and in the box here between the credential subject has been identified with a did and that.
<ottomomy> definition of the achievement, there is a you know, has credential property of some sort and house credential.
<ottomomy> That can be can be used, you know our decisions here in this group are almost limited to what's has credential look like and then, if we look at the other types of data that are present in assertions of this type, you know open badges being an example.
<ottomomy> There is a concept of evidence there's the concept of you know, an issue date an identifier for the the overall assertion itself.
<ottomomy> there's the concept of an issuer, that is, the issuer of that assertion and so it's a matter.
<ottomomy> of just sorting all these different properties that exist within our conceptual model into where they go in the verifiable credentials model, a bunch of them fit right at the root of the verifiable credential notably issuer.
<ottomomy> The issue dates.
<ottomomy> The overall ID of the credential and some form of proof.
<ottomomy> Those are all concepts that were in open badges two point O in the assertion model those can live at the verifiable credential level, and then the other set of properties that you're filtering out are at the.
<ottomomy> claim level is what are you saying about the recipient, and the only tricky one I think is is evidence that's idea that there is supporting evidence of portfolio item it's all modeled on the schema that are creative work class.
<ottomomy> there's a piece of work or multiple pieces of work that represent why the recipient has earned the criteria of the grandchild, and that makes perfect sense as a.
<ottomomy> claim of some sort about the recipient, so the idea here is you're saying the recipient has a credential and they have evidence as sort of parallel claims that you're making in this one bundle or sorry I say, has an achievement.
<ottomomy> Has a credential property a couple other things on this chart.
<ottomomy> In there's a good handful of other variants on this that we could talk through but all i'll stop here and and ask for questions is that there's this idea of a result against a skill.
<ottomomy> So there's a concept from that we've talked about here as well, the open the skills assertion, the idea that many different issuers might.
<ottomomy> want to make a claim about the achievement of a particular result that might not have been defined by the issuer but let's there's some other examples that will talk to that a little bit more precisely so i'll stop here and turn it back over to okay.
<kerri_lemoie> sorry about that yeah we.
<kerri_lemoie> will leave this up for a segment, while we see if anybody has any further questions or wants to discuss this at all.
<kerri_lemoie> anyone have any thoughts on this so far.
<tzviya_siegman> Can just ask for a little bit more clarification about the evidence and creative work.
<ottomomy> Yes.
<tzviya_siegman> So what that is.
<ottomomy> Sure, so, for example in open badges The idea is that i'm going to award an assertion to carry and i'm going to.
<ottomomy> The main essential part of that assertion is just which badges it for which badge definition and then there is a section that allows evidence to be.
<ottomomy> claimed as well, so I can say, as the issuer Okay, I have seen good evidence that that kerri is is deserving of this badge and so i'm going to describe a little bit of that evidence here in.
<ottomomy> In the assertion and the evidence class that as its defined by open badges it's based on creative work in that it has a name description a URL and a lot, you know just basically lets me describe what evidence i've seen that.
<ottomomy> convinced me that very deserved will have a particular badge, and this is included in the assertion and kerri can carry it with her.
<ottomomy> And Whenever she shows off the air and assertion that you've got links to the evidence, are there so that the verifiers.
<ottomomy> can take a look at what it is that she's done it's not embedded files, although some people have come up with clever ways to be 64 encoded stuff and train jam entire pdfs inside a.
<ottomomy> badge json but it's just the idea is it's a description of a piece of portfolio item, essentially in terms of the URL where you might find it and or descriptive metadata like a name and a narrative.
<tzviya_siegman> The reason I was particularly asking is that I, one of my job's is chairing the publishing working group and there's a lot that when you get into things like bibliographic metadata it gets complicated and I just wanted to make sure we weren't going down that path.
<ottomomy> Evidence identified by a URL link here, in most cases, and sometimes just description.
<> Will.
<kerri_lemoie> Have a question.
<phil-t3> Both of us to.
<> Are in the queue.
<phil-t3> But.
<phil-t3> Let me yes i'm in the queue.
<phil-t3> And I just wanted to clarify it helps at least when I describe it to folks typically describe the evidence as as neat correctly noted, it is a your your eye that points to something.
<phil-t3> That may be a directory that may be a file that may be, whatever whatever the the target happens to be, but the point of it the intention of it is to provide the person who is reviewing an assertion or a claim, not only the opportunity to know how the the claim was was.
<phil-t3> determined that is associated with some kind of rubric, which is also usually a part of a badge but also the methods of assessing how that rubric led to whatever the level of performance is.
<phil-t3> that's being asserted, and then you have the person's own work for independent set of eyes to say I see here's pieces of evidence that correspond to doing very well on these math using these methods of assessment to determine the assertion this person knows how to ride a bicycle.
<> Thanks.
<kerri_lemoie> For barking.
<phil_barker> There can only be one achievement recipient right, otherwise you don't know which evidence goes with Richard treatment correct yes.
<phil_barker> That remains true if you take this data, out of the sort of the json ld rapper and put it into a graph of some so you've got to keep them associated to sort of single atomic yes or no, you know isolated graphs you can merge the graph can't merge this graph with a graph for another credential.
<phil-t3> Just to clarify So if you there can be multiple at the pieces of work that correspond to demonstrating that one achievement right, yes, yes, yes Okay, if you wanted.
<phil_barker> To have to correspond to the one on one.
<phil-t3> And where there's a circumstance, one could credibly make that it's an exam, it is a contributor to more than one achievements, can it be.
<phil-t3> reproduced in each of them.
<phil_barker> I think it's more of a problem if you've got more than one achievement right different evidence yeah yeah that's I seen a snake wants to respond, sir.
<ottomomy> yeah only to say exactly right.
<ottomomy> If you are running a system that is doing some json ld processing on the graph and sort of constructing a graph of claims about the.
<ottomomy> recipient here that's identified by I did, one of the things that you might do is bundle all of the House credential claims together and say this recipient has 45.
<ottomomy> credential has credential defined credential achievements and then you might bundle all the evidence claims together, you say this person has 30 portfolio items that have been declared about them as as evidence for.
<ottomomy> As credential claims, but in order to be able to figure out which goes with which you would have to maintain the original pairings you know the original.
<ottomomy> unit here that's defined on the screen this particular set of claims pairing the has credential claim and the evidence claim and all those types of processing are completely reasonable to do.
<ottomomy> And if an inspector does want to break them out, they would have to understand that when you're defining a credential that has multiple properties like this sometimes it's useful to be able to track.
<ottomomy> Those things together as a single credential with different claims that go together and sometimes it might be useful to track just.
<ottomomy> This one particular claim.
<ottomomy> across.
<phil_barker> Multiple credentials So yes.
<ottomomy> What are all that has potential relationships this subject as.
<kerri_lemoie> I said I can has a chance to.
<kerri_lemoie> respond to that before she's in the queue please.
<kimhd> Let can go ahead because mine is it a separate thread.
<kerri_lemoie> Okay, thanks for the heads over.
<phil_barker> The children to serve the achievement is essentially a bunch of classes, no.
<ottomomy> that's right yeah okay.
<phil_barker> yeah I was.
<phil_barker> just trying to think if there's anything else you can attach the you know that the evidence and the result to that doesn't lead to that sort of.
<phil_barker> dissociation between.
<phil_barker> What they've done and.
<phil_barker> What the evidence is that provided for doing it.
<ottomomy> kerri after you kim's Fred maybe we go look at the skill assertion example in the top right.
<ottomomy> To answer that question.
<> Sir.
<kimhd> So mine is is probably a little basic because I was dealing with a pug freak out momentarily and I may have missed some of nate's framing.
<kimhd> So I think I was getting hung up on things like I was expecting to see terms like badge class and everything, and I was wondering was this is this meant is sort of a conceptual diagram like because I guess what I was wondering is like.
<kimhd> Taking that diagram at face value, it seemed.
<kimhd> Pretty disruptive on top of the current open badges model, so I was just wondering if it was you know in in maybe we can get away with that, but I was just wondering about the framing of it which you probably mentioned already and I.
<ottomomy> didn't mention that but that's a very good question so i've used in this diagram of use generic terms such as achievement that kind of speak to if you actually go back to the previous one, that we were looking at in the middle.
<ottomomy> The.
<ottomomy> So i've used generic terms like achievement, instead of open badges specific terms like badge class it's also worth noting that car, which is another IMS spec.
<ottomomy> adopted the open badges assertion badge class and profile classes and they renamed batch class to achievement there, so this is actually a CSR term to see achievement.
<ottomomy> Here, just like actually this example contains something called a result as a result description which also our terms used in I msc lr but.
<ottomomy> As we get more specific I don't think i'm proposing any necessary, but any name change to those classes necessarily occur, but this is not an IMS working group here and the vc EDU Paul, this is a.
<ottomomy> w three see space, and so I thought it was probably better to use some generic terms to talk about the generic concepts that were wrestling.
<kimhd> Thanks nate that looks great.
<kerri_lemoie> And then, before I get to what I had before need to enter your address your saying about the skill skill session here.
<ottomomy> Sure yeah another concept that we've talked about for the last year and a half or so in this group is the idea of an open the skill assertion, where there is a defined.
<ottomomy> skill of some sort or competency, perhaps a learning target that exists in the world it's been published, with a unique URL the open skills network is doing.
<ottomomy> defining a concept called rst or rich skills descriptor which is generic pattern that could be implemented in several different link data friendly.
<ottomomy> standards that just means that there is a skill definition or competency definition, it has a unique URL and when you fetch that URL, it is possible to get.
<ottomomy> machine readable metadata about the skill, so we can treat it as Oh, there is a skill definition authorship of that skill definition is an important concept that skill has been defined by a particular author.
<ottomomy> Once that skills out there, you could imagine, maybe a industry organization professional association or something like that might be one organization that would define skills educational institutions are another common one state.
<ottomomy> boards of education play in that space as well we've talked a lot about the definition of.
<ottomomy> Skills and competencies and frameworks of those things, but now we can talk about the assertion of what it looks like when a particular individual has that skill.
<ottomomy> has achieved it at some level, and I have what would that would look like in a verifiable credential, and so this is pretty similar and.
<ottomomy> compatible graph with the other one that there's a verifiable credential with all the properties there and it a credential subject identified by a did.
<ottomomy> But here, in this case, we can make a slightly different claim about this skill, by saying that the.
<ottomomy> holder here has achieved a particular result against a skill what I mean we could have constructed a direct relation to skill like has scale or something like that, but I think this intermediate model.
<ottomomy> places a gives us several other use cases that we've talked about within the scale assertion model, such as the ability to maybe express at which level.
<ottomomy> In the skill did the individual perform and is my do I have a degree of confidence about that.
<ottomomy> It allows the author, the issuer of this credential to make some some more detailed claims about the achievement.
<ottomomy> And the other cool thing about doing it this way is this fits really nicely with a achievement.
<ottomomy> claim as well, so Kim if you could look at their Kim kerri if you could scroll to the left one slide and look at the combination graph where there is both a has credential relationship and the skill result relationship in the same.
<ottomomy> chart these things can can go together sometimes the skill that you're.
<ottomomy> Recognizing independently is also something that the achievement has aligned to so you could say this achievement aligns to this skill and then you could say.
<ottomomy> And there is a specific result about that skill that i'd like to record for this individual so that I can express concepts such as level and confidence.
<ottomomy> So we've got a couple couple different options here, but overall there's two main use cases being represented in.
<ottomomy> These graphs here's how with a verifiable credential we could express that individuals have.
<ottomomy> A particular credential but they've met the criteria of a defined achievement, where the issuer of the verifiable credential is the assure or is clearly authorized by the issuer of the.
<ottomomy> defined achievement to make that claim, and then the separate type of claim, where we are saying that.
<ottomomy> A individual has a particular skill or competency and the skill or competency may be defined by a different organization than the issuer of the credential itself is making this claim today.
<kerri_lemoie> Okay, thank you i'm Anthony you have a question.
<anthony_camilleri> Oh yes, oh I like this conceptual model and what i'm wondering is i'm looking at people achieved result and the evidence arrows.
<anthony_camilleri> And i'm wondering why these not extend from achievement, rather than from the ID recipient.
<anthony_camilleri> For example, the evidence is not evidence of your identity it's evidence of your achievement so conceptually speaking, it would seem that it belongs nested under treatment, rather than nested under recipients.
<ottomomy> Well what's important to understand about this achievement model is that this is a achievement definition that might apply to any learner This is like the bachelor's degree in science it's not nate's bachelor's degree in like not to be yes, I have a BA.
<ottomomy> it's not nate's degree, this is me this is the credential that would be awarded to any.
<ottomomy> person, so the claim that we're actually making for the sort of core claim of the graph here is that this particular holder has achieved the criteria of a generic achievement that many holders.
<ottomomy> have achieved, and then the claim that we're making with a particular result is that this holder has a particular you know, has achieved a particular result against some kind of target maybe a skill.
<ottomomy> And then, a evidence claim that we're making is that this particular holder has a piece of portfolio.
<ottomomy> Item another way to do this chart absolutely would be to have the assertion model be kind of an intermediate thing in the graph here where we're saying that.
<ottomomy> The central claim would be this recipient has an assertion.
<ottomomy> And then that assertion has a number of relationships to other things that assertion is associated with evidence that assertion is associated with skill claims and with a particular defined achievement.
<ottomomy> I think that this structure, without that intermediate model is cleaner and allows us to do some of the cool.
<ottomomy> You know, breaking these things out as direct claims again for the recipient, but other people might feel that a sort of has assertion model would be a better way to go, and this group is a great place to discuss that.
<phil_barker> Can I jump in.
<> Leslie.
<phil_barker> And I just want to confirm what I think I heard you say that the skill result is specific to the subject to the person it's what that person achieved that might make.
<ottomomy> that's what i'm proposing is that we say a person achieves a skill result and that's you know you can say that they have a skill through that result.
<phil_barker> So why not attached the evidence to the skin result.
<phil_barker> Because it's evidence that they have that result.
<ottomomy> Not doing it this way is just a little bit more granular it allows you to the evidence is associated with both of the claims in this credential the chief resolve and the House credential claim.
<phil_barker> I mean, I guess, I guess, we could have had it.
<ottomomy> Well, if you want to issue two different credentials to in order to make that more specific go ahead yeah like I said on that chart on the right.
<ottomomy> There is another option for this position doesn't have that has potential in it, and so, if you want to make that.
<ottomomy> claim the claim that there is a skill result that has evidence cool just do this chart and then, if you want to make the claim that the person has defined achievement and there's evidence separate make that claim as a separate potential as.
<phil_barker> Well, what.
<phil_barker> What i'd like is for the claims for the evidence in the claims not to fall apart, when you aggregate this data so Kim wants to interrupt a letter.
<kimhd> Oh thanks yeah I think that's a good conversation, but I was also thinking that sounded like something we could.
<kimhd> It sounds like a revision of the model that maybe we could come back to later, I think that there's it sounds like there's alignment that this is a promising approach but.
<kimhd> We have feedback to it, and so I would propose that maybe we come back to it because I thought that maybe I saw some other things like maybe I thought I saw some samples as well, so I thought that might be helpful to look look at that too.
<kerri_lemoie> I mean, I do think this is what we should connect these conversations, and this is why.
<kerri_lemoie> Why, even the most simple digital credentials specs has all had a conversation associated with it.
<kimhd> So Nick fury actually like if if you'd rather I was just sort of trying to sort of keep track of time and everything So if you think that's the priority right now.
<kimhd> I just thought I saw a few other things that might be useful for the well rounded perspective, but then otherwise i'll let you to sort of guide this.
<kerri_lemoie> No, no, I think you're right, I think we don't want to get into too many details right now and, in fact.
<kerri_lemoie> The one thing I have to show you is not we really don't want to get you tell some because I literally threw this together, like right before the call.
<kerri_lemoie> Like I had some of these, but I wanted to get a get together an example to show all of you, but i'm sure it is not correct.
<kerri_lemoie> And I don't want us to like spin on this at all, I just wanted to sort of give you a sense of what it could look like for an open badge to be a verifiable credential.
<kerri_lemoie> it's actually not so different from what Neil has been proposing and chemists and proposing in the past, and this was sort of emerged of the many options we discuss, which was to.
<kerri_lemoie> You to have the verifiable potential right to be the the essentially replaced the assertion of an open batch.
<kerri_lemoie> Where we would have the issuer be part of the verifiable credential and the issuance date, and then we have the parents are subject and I don't have any of this matches what on the chart right now, so please keep that in mind, but we have like an identity for the recipient.
<kerri_lemoie> We may also want to consider like what do we do with an email right approach and badges and it's been used for so long, so that's, not even in here that discussion, yet not that it's been left out on purpose just said, I hadn't put it in yet.
<kerri_lemoie> But this example that has crenshaw does have a badge and that badge has an ID and it has a name and a creator.
<kerri_lemoie> I was messing around with this concept of you know, the creator of the badge classes some allowed issuers just just playing around with what that could look like very lightly.
<kerri_lemoie> i'm a bad image description care what I sort of like about all of this, though, which you don't see is like a big batch or you don't see an image anywhere like a required admin chicken.
<kerri_lemoie> I mean, I know for badge always has required this image and that data was baked into the image.
<kerri_lemoie> This could we could change this entirely with badges as vcs we can still include an image, the image doesn't need to be required, which will be pretty huge right i've been a different approach, but also give you the saver French.
<kerri_lemoie> So people could still have an image that they wanted to take a still baked into the image that they wanted to but it's not required.
<kerri_lemoie> These are just some thoughts here some opportunities that we have to discuss and then here's where evidences and I think I typed it in where I thought it should be, which is under has potential that you can always look at that later.
<kerri_lemoie> Where it's even richer than just what's in evidence badges now but it's like includes creative work where we can do more than just what we had in evidence, so this also gives us an opportunity to introduce new.
<kerri_lemoie> Additional schema to have met is that we didn't have poor terms of making it more rich set.
<kerri_lemoie> Okay i'm going to pause there was a whole bunch of things going on in the chat so take a look at this.
<kerri_lemoie> See.
<kimhd> i'm late.
<kimhd> I was following kerri kerri maybe i'll TEE up certain people whose comments like it might be good to say them out loud i'm.
<phil-t3> arrogant.
<kimhd> He won on multiple trust anchors.
<phil-t3> yeah i'm just saying that this is actually I think as much a digital identity group discussion and getting groups getting their their perspective on ways to handle that particular.
<phil-t3> problem might be useful on there, I know there are people working on this, who are coming up with ways of associating different levels of confidence to.
<phil-t3> To representations of identity in a key chain like fashion and i'd wanted to replicate that work because it's it's it's challenging by itself just suggested we we reach out to some of those and get some input.
<kerri_lemoie> yeah that sounds good yep.
<kimhd> So I want to keep in mind first Kerry said this was she did this right before the meeting so with with the understanding that.
<kimhd> You know we'll probably go through some revisions on this Keith did have a question around should this example, include the assertion or public page URL I think that's interesting because this gets to some comment that.
<kimhd> Naming carry both in mentioning around links versus data in line badges so i'm wondering if Keith or sorry if nate or carry have anything to add on that sort of URLs versus in line data.
<kerri_lemoie> Well it's funny because in all it needs to be talked about in some detail a little bit anyway, and I would say a lot.
<kerri_lemoie> I had actually even left the ID out of the badge when I first was talking tonight about this and you know, there are good reasons why you would want to have like a very specific canonical URL for a badge meaning the batch class in terms of the assertion having an ID I don't know.
<kerri_lemoie> If it's going to be a verifiable credential do we want to have hosted versions of verifiable credential and I think that is another another conversation to have i'm there are reasons why you would want to have a simple hosted badge versus a badge as a verifiable credential.
<kerri_lemoie> So I think that's that's a discussion, we need to have that that anything that's my answer to that right now.
<kerri_lemoie> may have a year.
<ottomomy> So I think the reuse ability of a defined achievement is a critical capability that that open badges has.
<ottomomy> In particular, as a standard that implements this generic concept has done really well, I mean it didn't it wasn't always that way, so there was 0.5 badges that did not have unique ids for the defined achievement class.
<ottomomy> Batch class and then that was added in 1.0 as a method of sort of normalizing the data and I don't know that the architects who worked on one point O necessarily.
<ottomomy> really thought through a lot of the consequences of that change.
<ottomomy> They were kind of like it's more efficient if we only publish this data once and, but the fact that it's uniquely identified gives it a lot of power, and so the platform that we build badger.
<ottomomy> is an example of why that's important which we have a concept called learning pathways in our product, where you can require that a learner completes three of these five badges in order to.
<ottomomy> be measured as complete on a particular step of a learning pathway, and without a unique identifier for the badge class.
<ottomomy> it's not possible or it's not practical to say that the learner must complete these you know, three of these specific five badges there's just nothing to attach that that.
<ottomomy> request to that rule to and so unique identification of a defined achievement, I think, is a really important part of defining achievement achievement.
<ottomomy> Open badges or Point five are really good sort of storytelling tool they show the data, you know you can render it into html templates if you want for human eyeballs but they don't do very well for building.
<ottomomy> Business logic around like the meaning of digital credential having unique identification, for that is essential and we can go even into further rabbit holes around like are there, different versions of the data with with this ID.
<ottomomy> etc, but we can grow in that capability i'd rather not sure that capability away as to the key question around the idea of the assertion itself and whether that idea would be like an http.
<ottomomy> identifier, that would be essentially a public page for this credential I think that is a implementation option that.
<ottomomy> would definitely be open to organisations and how the privacy and access control would be managed on such a page up to the employment do is to determine and maybe some spec office to recommend.
<kerri_lemoie> Kim you had a question or statement and not my question.
<kimhd> So I I wrote down this topic to come back to the idea of you know links for the badge class versus links for the assertion is something that has come up a lot in terms of.
<kimhd> You know the assertion can contain pii or maybe you want it to be able to have something, and so I think.
<kimhd> That the badge class is frequently something that you want to maybe attach more data to over time, for example, and you want people to be able to refer to, so I think like that's a really good.
<kimhd> discussion, we can come back to introduce making badges more badges via this vc alignment kind of more usable and flexible for different kinds of.
<kimhd> You know, sensitive data kinds of claims, so I think the other one that's interesting, you mentioned the fact that they bad the baked in this is not.
<kimhd> Here, but that also seems like an interesting thing to come back to so i've added this you know just in terms of how we deal with the idea of you know.
<kimhd> aligning the image image with the tamper evident payload and all the many problems that come up with that, so we have an opportunity to if we want revisit baking and sort of how that comes about, but so that's all things that I think of is appropriate for down the road discussion so.
<kerri_lemoie> Thank you, he was up next yep.
<keith_kowal> To start, I mean it's just a higher level comment that the beauty of open badges is that you can use them in today's world, so I mean.
<keith_kowal> If you go to a pure vc model than you are stuck with chicken and egg problem so they're not being a verified ecosystem to.
<keith_kowal> to consume those vcs so by putting in the links to a public page or to an assertion URL it allows you to you know, to have a middle ground where you can continue to like share that link on linkedin or Facebook.
<keith_kowal> And again to what nate said, you know it can be optional, they just added will be good and examples, just to show it because I think in the interim phase when there's no relying party system ecosystem to consume verifiable credentials.
<keith_kowal> To me, this is the one of the great reasons why I really support putting open badges and vcs because it gives you something you can actually do with the vc while we're waiting for ecosystems to step up.
<kerri_lemoie> yeah that is awesome I agree i'm an idiot and I know we're going to save this for later and I just have one more other thought on the the assertion URL is that right now.
<kerri_lemoie> We don't really have systems consuming who are like assertion data either, and all the sharing that can happen from platforms doesn't require an assertion.
<kerri_lemoie> That this requires a webpage that is hosting the badge it doesn't require an actual assertion, so I just want to put a pin in that for future we have that future discussion on that.
<kerri_lemoie> Because I will forget holly between now and then.
<kerri_lemoie> The yes, thank you for bringing that up and then because we do want to make sure we're bridging right, we do not want to like move a lot of agile happening right now, so we want to make sure that continues and continues to support that ecosystem that exists.
<kerri_lemoie> Do you see Is there anyone else here in the chat that has something with the sake that point or any other point.
<kerri_lemoie> Alright, well, I think we already have some topics for future call skin.
<kerri_lemoie> I don't think I have too much else to share at this time.
<kimhd> yeah I think that's great Thank you kerri for leading that and I think that let's see yeah so I don't think that we had anything else from the chat to add, so we can we're getting close to time, so we can wrap here.
<kimhd> Thank you everyone and i'm going to try to make some progress on publishing the backlog of minutes this week.
<kerri_lemoie> yeah Thank you to all of you for these discussions.
<kimhd> Following are from notes Kim and Kerri took during the meeting
PROPOSAL: breakout group on multiple issuers
RESOLUTION: Marty Reed, Phil Long, and Phil Barker to lead breakout group on multiple issuers
PROPOSAL: move forward with full cycle implementation sample of Open Badges as a VC
RESOLUTION: Accepted with breakout group
Kim Hamilton Duffy: Topics to return to:
<kimhd> 1. link to defined achievement vs link to assertion
<kimhd> 2. baking in v3
<kimhd> 3. bridging with existing deployments vs current proposed design
<kerri_lemoie> 4. Review, present, categorize existing use cases related to Open Badges
Kerri Lemoie: 5. Open Badges VC Instances vs Assertions: Comparison of Use Cases
Kerri Lemoie: 6. Open Badges VC Images: Who Needs them?
Kerri Lemoie: 7. Open Badges VC: credentialSubject recipient
Kerri Lemoie: 8. Open Badges VC: hasCredential (badge: name, description, criteria, image, alignment)
Kerri Lemoie: 9. Open Badges VC: creator & validated issuers
Kerri Lemoie: 10. Open Badges VC: evidence
Kerri Lemoie: 11. Open Badges VC: Open Badges as a Skill Assertion & Achieved Result
Kerri Lemoie: 12. Open Badges VC: credentialStatus
Kerri Lemoie: 13. Open Badges VC: proof