<kimhd> Okay, so we can dive into the payloads discussion and i'll mute myself, so that the background noise is minimized.
<kimhd> So let's see we can start can we can continue the discussion from from last week I included the link to this to the slides we had last week Kerri.
<kimhd> And I have a lot of background noise and expect to today, so can it show just turn over to you to.
<kimhd> Keep the discussion going.
Topic: Payloads Discussion, continued
<kerri_lemoie> yeah absolutely and I can also share my screen again.
<kerri_lemoie> Okay just sort of walk back to where we were last week.
<kerri_lemoie> During the shall share the link of the sites in the chat just so we have them do their own thing.
<kerri_lemoie> so we went through these examples kind of briefly last week oops sorry I stopped sharing my mistake once again man, I really need some coffee today I don't know what my problem is i'm so here are the slides from last week.
<kerri_lemoie> And I think what we were trying to accomplish or what I was suggesting we accomplished last week.
<kerri_lemoie> Work on the self contained payloads first and get these things out of the way and no badges, we know that there's still work going on on these the 17 payloads at that.
<kerri_lemoie> You know what we really just want to do is get this part of the modeling Doc done so that we can get to other you know the other issues about a lighting BC edgy with the earlier.
<kerri_lemoie> So I think you can or somewhere else, maybe around what we could do is maybe look at these again.
<kerri_lemoie> And then discuss you know what we like about all of these, and maybe come to a consensus about whether all of them go into the modeling dark or one of them are a couple know what kind of consensus we can agree to that How does that sound.
<kimhd> yeah sounds great okay.
<phil-t3> Kerri yet give some underlying sort of sense of.
<phil-t3> What would be the character is ideal characteristics, to look for as we go through these.
<phil-t3> or least the points of differentiation that need to be paid particular attention.
<kerri_lemoie> To them, and I can point out the differentiation.
<phil-t3> yeah okay.
<kerri_lemoie> yeah you know, I was that's a really good question I was looking through our use cases this morning and I feel like we need to do some work their overall gathering or use cases.
<kerri_lemoie> So this is a little bit actually cart before the horse, although I feel like also we've been staring at this same course in part for a really long time so it's both here they mean.
<kerri_lemoie> So I feel as though.
<kerri_lemoie> Maybe we should look these over as a group and reach some kind of consensus, or you could all tell me that no no let's just set the society move on.
<kerri_lemoie> I you know it's very good just to get us somewhere help us get somewhere with all of this.
<kerri_lemoie> Maybe even today we just talked about what we like and don't like about.
<kerri_lemoie> know all of these examples.
<kerri_lemoie> So how about I just go through the examples, one by one, and then.
<kerri_lemoie> We could talk about them, maybe spend a few minutes on each so we can start with this, but this is the LCR example car rappers apple.
<kerri_lemoie> And what we can see what this one is it contains the verifiable credential.
<kerri_lemoie> properties, but it also contains some additional ones that are provided by the which is this context.
<kerri_lemoie> file up here is that we have as a learner record rapper which allows you know the understanding for verify reflection perspective of name description.
<kerri_lemoie> And I think those are the additional ones here, and then the learner record hey we have this proven control ID of this payload and, from this perspective, a verified could come in and say Okay, this is a learner record I understand I can understand this data, because it's here.
<kerri_lemoie> But the things that we learned, as we started analyzing the different like how this approach was that.
<kerri_lemoie> there's some system things where we have like the issuer up here and we don't necessarily know if that issue will be aligned with Miller and a record if you get yours to teach here.
<kerri_lemoie> So we have like an issue date we don't have an issue disappear, we do we have the date, and then we have this issue on in here.
<kerri_lemoie> So there are some things that don't line up exactly really, this is a really great first draft of there are some things that still need to be updated and it's also you know a lot of additional fields, they may not be necessary, unless it is a payload that has a different type of format.
<phil-t3> isn't evidence, at least in the context of Ob I evidence redundant to the actual will be I define them the model itself.
<kerri_lemoie> yeah and evidence evidence is part of like an instance to and not.
<kerri_lemoie> So that's another issue right we have this learning to record that the payload the payload itself contains instance information, including the.
<kerri_lemoie> A trip, so this, this is one of the concerns like why it might be challenging for verify or to understand.
<kerri_lemoie> This this model with an open batch specifically they just looking at this from an open batch perspective right now.
<kimhd> Actually linger on that for a SEC i'm not sure I got that, so why.
<kerri_lemoie> Only because we're looking at this from an open badge perspective right now.
<kimhd> is, how is that, like How would open badges generally do it, I forget.
<kerri_lemoie> So it may be more like the examples down below.
<kerri_lemoie> So we have we have five different Examples of these are all the different examples, so this is the one where i'm.
<kerri_lemoie> Sorry Oh, where we have some of the properties that are in the has potential yeah we have.
<kerri_lemoie> We are we are using primarily the vc.
<kerri_lemoie> properties here so we're treating the vcs the instance and the credential subject and the schema as like a badge class.
<kimhd> Okay, in and i'm putting myself on the queue after nate to because as we're talking I.
<phil-t3> Have a tentative with.
<kimhd> pros and cons so far.
<kimhd> nate you're talking about this example, so can you go ahead and go next.
<ottomomy> Sure, I just two Kerris point Miranda investigating the characteristics of these various different examples, the the idea of this rapper if we just look at it, what claim is being made, we have learned a record.
<ottomomy> There is a learner that I.
<ottomomy> was identified by a particular did here, and then the claim is that this learner has a payload and then the payload has evidence and the payload has an issue date.
<ottomomy> That potentially is separate from the wrapping date at the verifiable credential level so as we compare this to other.
<ottomomy> Examples sort of restating what we're seeing in the data in English like this learner has a payload that payload has evidence that payload has a issue or or, I guess, a type of data that that could be a useful comparison to what we see next.
<phil-t3> neda's if the payload itself has those capabilities in it does the rapper need to restate that or does it need to tell.
<phil-t3> The relying party or the recipient that's processing it what it what it needs to treat the payload and nothing more.
<ottomomy> i'm not sure I didn't mean I always tried to think about this from the perspective of what would it take to build software that consumes this data.
<ottomomy> and
<ottomomy> If we're trying to consume the claim this learner has a payload of a certain type, then you just build handling for that type and as long as that type is.
<ottomomy> standardized enough, you can get away with the sort of extra layer that you've you've placed into the structure here, but we may find other.
<ottomomy> examples that have similar capabilities, without needing the extra layer and then the other thing to think about is with this rapper idea is that there's many possible different payload types and in order to be able to train going by very inconvenient.
<ottomomy> In order to be able to build software that consumes us, you need to be able to understand all of the different types.
<ottomomy> That might exist that you want to consume, otherwise you need to be able to make it clear to users, that they have a one in 10 chance of you being able to parse this payload.
<ottomomy> or something like that, if there's 10 different options and your software only consumes one so building an ecosystem around very payloads is quite a bit more challenging from a user experience perspective, because how often you might run into user frustration due to embedded.
<phil-t3> Good Thank you so what i'm expecting wanted to make sure was clear.
<jim_goodell> I like the way that you explain that the layers nate.
<jim_goodell> And if if we lived in a world where there was only one kind of record to exchange, then we don't need the extra layer, but if we're building towards a world where.
<jim_goodell> Many different kinds of records need to be processed and the kinds of payloads need to be identified so that the system can figure out do I know how to interpret this payload or, can I just read present it and then.
<jim_goodell> The extra layer is helpful.
<kimhd> In gym you are actually I was going to propose that you jump the queue ahead of me because I wanted to start a summary of pros and cons so go ahead.
<jim_goodell> yeah so I guess part of where I understand that there's there's tension around this because.
<jim_goodell> The lie, our approach is not as simple as it could be, and maybe there's we can find ways of simplifying it but there I don't know that we can get around the notion of a layer that says.
<jim_goodell> That identifies what payloads are there were payload or payloads.
<jim_goodell> And then you have a way of unpacking that I I envision that we can get to a place where we have.
<jim_goodell> translators that.
<jim_goodell> kind of that can either plug into something like a learner wallet or be web services that.
<jim_goodell> That are consuming system may say I can I know how to interpret these five different kinds of payloads.
<jim_goodell> If you have something in a different format that can be translated into one of these five.
<jim_goodell> Then, then I can go to a web service that can do the translation for me and get the data back and in one of the five that I know how to.
<phil-t3> That some part of me.
<phil-t3> Go ahead, I was gonna say that sounds very much like kind of having on the one hand, a manifest and then a a.
<phil-t3> pointer to resolve that if something does not in fact.
<phil-t3> list in the manifest.
<kimhd> Let me start through a tentative list of pros and cons and if if we need to start iterating on them i'll dump them into a shared document.
<kimhd> In simoni that's a great question about verifiable presentation i'm going to propose that we move that towards the end of the discussion because.
<kimhd> We I don't know i'm starting to we're starting to get instincts for her when we get off the rails in.
<kimhd> In that that's one of them, so so coming back to the pros and cons.
<kimhd> Okay, so I think that this is easy to bootstrap in terms of it's easy to understand how to jam existing credentials in there.
<kimhd> And that also means it's pretty easy to get started from an issuer perspective, so I think past open badges all these different payloads you know the the Elio rapper aspect makes it really clear how to get started.
<kimhd> Cons so.
<kimhd> At some level all consumers have it need an interpreter to make sense of the payload so that could exist in different ways that could be.
<kimhd> web service, it could be, you know plugins or drivers in no wallet or something you know so they can be achieved in different ways, but in order to really understand the data.
<kimhd> For all of these different payload types that needs to exist, somewhere, I have another con as being evidence is confusing from an open badges perspective which will.
<kimhd> let's not linger on that because we're getting into that in the subsequent sections and then Lastly, I had as a question mark that the issuer role is confusing.
<kimhd> But there's also that park it's kind of weird because, like it seems like each payload could also have a concept of.
<kimhd> Its own you know authoritative entities so maybe that's still confusing because those roles are unclear, so that that con i'm less confident with.
<kimhd> Before turning overall also say that I think it's still possible, that we have that we do both like you know, so I get what Jim is saying that we could have these translators, to help make sense of it, and you know it's it's really seeming like a.
<kimhd> ridiculous amount of work for a given the effort we're going through to open badges and you know, so I think the thing is like.
<kimhd> Maybe maybe we're we persevere on open badges and a few ones, but we can't necessarily expect all issuers to do this exercise so maybe we need a path for both like the backwards can pat one and ones who are doing verifiable credentials native.
<kimhd> formats, which would be you know, certainly Anthony is saying that in his use cases they're just going to be native verifiable credulous is not going to be need for a backpack path, those are my summary of pros and cons Kerri do you have anything that you want to add.
<kerri_lemoie> Do excuse me I think the issuer.
<kerri_lemoie> is a big one, and I think, because with the verifiable credential we have this context of like this authority it's a, how do we know how to verify or know.
<kerri_lemoie> Who the authority is authority of music very loosely here so we'll see because no coffee.
<kerri_lemoie> Or is it the information and the lender records, so this was an open badge and there's your information in here this issue or here.
<kerri_lemoie> And there's an issue date here, and if she didn't hear you know there's a conflict there at the verify APP I would know how to resolve, and I think that's a big calm and this approach, avoid the self contained ones, I think.
<jim_goodell> yeah that the rapper can contain contain more than one thing, so that each each of those items could have separate dates that I okay.
<kerri_lemoie> Within that somebody else I think phil Berger put that in the chat too, and then I guess how do we don't want to get into today was do we want to have multiple records right and the vc vc pegasi both allow for that, or do we just want presentations to have them.
<kimhd> Okay let's see so i'm going to add backs it actually Let me share this link that we can iterate on.
<kimhd> pros and cons so feel free to add your own an adding back confusing issue role.
<kimhd> So I noticed, we have a q, kerri I want to ask you like, should we work through the Q first, or should we like i'm kind of tempted to keep looking at a couple more examples of payloads and then work through the queue because some of these will be questions that apply to all.
<kimhd> So maybe I guess what.
<kimhd> might be like if your questions are specific to the proposal then go ahead, but otherwise we're will work through them and then we'll get we'll start working through the queue.
<kimhd> So that we can you know sort of see the breadth of the examples first.
<kerri_lemoie> Why don't we why don't we get back to the chat.
<kerri_lemoie> The next example.
<kerri_lemoie> this example, right here badges as verifiable credentials is very similar to.
<kerri_lemoie> This one right here that I wrote up, which is a prioritize of badge as a vc.
<kerri_lemoie> Which is a good number, it was in the slides, but it is basically saying pair that the verifiable credential is the this is as close to the native approaches you're kind of forced to get.
<kerri_lemoie> Without the rapper, so this is, we have we are relying on the verify what potential properties.
<kerri_lemoie> And straight up and then we're saying in the credential subject there's a has credentials in schema and in here is a is a batch class.
<kerri_lemoie> Which references the issuer which there is still that issuer like confusion, but you'll see that there the other information, the instance date is in here.
<kerri_lemoie> And if there was evidence my assumption is that the evidence would be outside or maybe within the credential subject about sure what that would be, but that would be not part of the.
<kerri_lemoie> The badge class description, so this is the second one and the other one i'll show you at the same time, but it's very similar.
<kerri_lemoie> I did put it inside here sort of simpler.
<kerri_lemoie> more complicated, with all the embedded information, but still.
<kerri_lemoie> has realized the verifiable credential and then it has a badge class data inside of it.
<kerri_lemoie> Once again, just a reminder from last week that these examples of json ld are not perfect by any means they're they're just sort of set up as examples.
<kerri_lemoie> So I don't I pause there and see like let's talk about like this, like an open badge using a more vc native approach.
<kerri_lemoie> is like our second example.
<kimhd> need, can I ask you to sort of give some discussion of that I know you've you've sort of done it before Thank you.
<kimhd> Europe.
<ottomomy> Excellent and admitted same time.
<ottomomy> This is the approach that I would probably most like to see in the world and then ultimately may be blessed by.
<ottomomy> A standards body for medicine IMS global particularly.
<ottomomy> Because I think it does a great job at avoiding the information duplication and it fits most naturally with the idea.
<ottomomy> Of a verifiable credential this approach, you know would be compatible, you know complimentary to other approaches potentially as well, but for this use case of.
<ottomomy> A recipient has met the criteria of a defined credential I think this does a great job and it's much better than.
<ottomomy> Say saying with this user has an assertion of a defined credential which is kind of one of the other main branches of alternative for open badges because the idea of an issue date is already sort of.
<ottomomy> You know it's a native thing to verifiable credentials, the idea of that there is an issue where.
<ottomomy> that's native to verifiable credentials, if we go with this route it every all the pieces just fall into place, naturally, and we could make say a parallel claim that.
<ottomomy> This learner has met the criteria of badge class a and this learner has evidence be and those are just two separate claims that go into the single credential that shows why this learner has met.
<ottomomy> This example any other questions that you want me to dive into right away on came on to sort of the construction of what we're seeing here.
<kimhd> And she can you just clarify where evidence would be in this example.
<ottomomy> yeah, so I think that has credential claim is one claim that you make about a learner and then a evidence claim would go right parallel next to it.
<ottomomy> And so that this the the block of the credential subject actual you know set of claims of the credential is.
<ottomomy> The assertion essentially and the assertion makes a couple key claims about the learner one that they have met the criteria of a particular batch class and another that they have portfolio items that demonstrate.
<ottomomy> That they have.
<phil-t3> The other key attributes in the badge things like the alignment to.
<phil-t3> Or to an assessment rubric assessments set of assessment methods or the rubric and all that that would be also down there, along with the evidence.
<ottomomy> Right, so one of the new features of car.
<ottomomy> Which is IMS yes expect that has slightly leapfrogged open badges in terms of release date it has a data model release that's more recent.
<ottomomy> To now they added a feature where you can put a rubric in a badge class basically and then from within the assertion, you can point to.
<ottomomy> What for each criteria and on the rubric what was the criterion level at which the learner performed, and so, if we wanted to have that.
<ottomomy> capability, then i'd see there would be sort of three claims one is just the basic you have earned to this particular batch class and other would be you've got a particular piece of evidence and a third would be.
<ottomomy> that you have a result against the the requirements in the criteria of the batch class a particular rubric that you haven't result against.
<phil-t3> Right so it's the degree to which you achieve that that performance.
<ottomomy> Right, and I think the same the other use case that's really near and dear to my heart and education is this skill claim use case where many different issuers might.
<ottomomy> claim a person has achieved to some degree, a particular skill and I think that construction of this learner has a result against a particular target would fit pretty nicely for the still claim this case as well, but it's not exactly the conversation for today.
<kimhd> I want to bring out something from the chat does this pattern allow for multiple issues phil Barker asked Kerry said it doesn't.
<kimhd> So then, in terms of the issue at the outer layer and the inner layer that does that basically mean we just have duplicate there's a duplication and it's just annoying that that's all sort of thing.
<kerri_lemoie> Let me elaborate but I was yes, so we have the issue in the batch class which described really matters right now described who created this badge.
<kerri_lemoie> know what the email address with their logo, is it there's all of this information, so it is more than just the did that's being pictured here.
<kerri_lemoie> So they could be different, there could be that scenario where that happens, right now, with this would you say that's right.
<kerri_lemoie> It could happen.
<ottomomy> Yes, so in open by just to point out, there is no ability to have the assertion be issued by a different entity from the badge class, the only entity that is trusted to.
<ottomomy> The authority on searching, so this batch class is the batch classes creator and at some point in the future, of course, the capability could be added, where.
<ottomomy> We update that extend that trust model to have things like I author I you know I the school district, who has defined this.
<ottomomy> Achievement authorize this building to it, you know this facility and its staff to recognize the sections of it and then tracking that that capabilities chain somehow out of band of an individual credential would have to come along with it.
<> yeah.
<kerri_lemoie> And I am putting some cons and, by the way, under example to they're not necessarily cons they're just sort of like.
<kerri_lemoie> I don't know, like, for instance, I put this recording I consequences when anything like this one requires an understanding of of badges properties which really that's true for any of the self contained once or any of these but.
<kerri_lemoie> listed there as a reminder.
<kimhd> I will we will come back to the discussions in the chat there's a lot of good stuff in there there's sort of cross cutting concerns, we want to get to but.
<kimhd> If it's okay we'll just keep plowing through and come go on to example three and and then after we get through example for we'll come back to the more cross cutting things.
<kerri_lemoie> Perfect things, this is actually like to a right, so this is also another model of a vc mad as a vc.
<kerri_lemoie> And what this does is it actually inserts the open badges properties sort of within the vc container part of the json ld.
<kerri_lemoie> That makes any sense seeing see here we have like to be able to do to create properties, so we have issued on an issue date issuance date the recipient up here, but we also have a recipient in here.
<kerri_lemoie> So that's one of the upper just sort of like include all of the open badges information with other verifiable credential information and then.
<kerri_lemoie> yeah that's not a Christian this one.
<ottomomy> and carry the other thing here to note is that this credential this blob of json is attempting, I wrote this one it's attempting to be an example of a blob of json.
<ottomomy> That is a valid open badges two point O existing version assertion, at the same time at which it expresses the same information in a vc so.
<ottomomy> If say the open badges spec advances and there isn't really a need to present a fully valid open badges a 2.0 like hosted assertion or something like that.
<ottomomy> Then we don't necessarily need to go to this extra effort, but if that's a use case that someone wants to do, I think it would be possible to do in the day, so i'm hoping.
<kerri_lemoie> Maybe that's my clarifying and how I just had this perfect, I made a big red circle around like the proof as an example of how it could be verified, either as a hosted or assigned badge right in this case in this example.
<kerri_lemoie> But either would make it a valid batch.
<kimhd> Okay, I would imagine that that property makes may lead to some kind of sources of confusion as well.
<kimhd> i'm struggling to articulate that.
<kerri_lemoie> I think what I might have put on the slide this one, let me see if I can get this.
<kerri_lemoie> yeah so the duplicates verification duplicates properties, as it as a potential for misaligned values is how I I was stating that I think.
<kimhd> Okay i'll make sure to copy in your.
<kimhd> pros and cons from the slide I forgot that you have those in there as well.
<kimhd> In Nice needs just a reminder, I think that uh right i'm pretty sure that to a to A to B were the ones in that paper rewrote ages ago right.
<ottomomy> I think so Okay, in general, the two approaches that we had in that paper one was.
<ottomomy> A claim that the assertion exists there is an idea of the assertion and that assertion is this, and then the other claim is what we just looked at, basically, which is.
<ottomomy> That here is a learner identified by some ID and they have a credential, which is the batch class of the reasonable part of the credential excellent.
<kerri_lemoie> yeah you know, and I actually I looked at that paper prior to looking at the modeling Doc and I think the modeling doctors just a little bit more modern pretty modern, but more credit.
<kerri_lemoie> than the White Paper you guys right, where it has like has credential and other properties has been discussed, since the White Paper.
<kerri_lemoie> But they were very similar.
<kimhd> Okay, shall we go through to example for yes.
<kerri_lemoie> i'm going to skip just just briefly again show the next example, which was the one that was very close to the other one who is prioritizing the match as a vc and that's what this one was this is very similar to the first of matches when we looked at.
<kerri_lemoie> So you might be able to combine this too.
<kerri_lemoie> And then i'll just go to the fourth reference, so you can skip that and and talk about it, some more so the fourth fourth one.
<kerri_lemoie> Was the simplest of them all.
<kerri_lemoie> And and require some work on the part of a wallet to actually go in and grab the data from the assertion.
<kerri_lemoie> So the fourth one just says hey post this assertion, this is a verifiable credential and it's pointing to this assertion, you can go grab all the data and the assertion.
<kerri_lemoie> And then, whatever you want about about this verifiable credential so it essentially says hey, this is a verifiable credential these are like who authorized this so it gives that party and then it says the rest of the data could be here.
<kerri_lemoie> In comparison, let me just go back up to this one to this one, where it has all of the data in here, so, while it wouldn't necessarily need to.
<kerri_lemoie> Go and grab that data, the wallet could grab all of the information and then the verify could decide if the information in the wallet is as current as the information in the assertion URL so in this way, you would have both.
<kerri_lemoie> versus the wallet having to understand how to go get the data.
<kimhd> Okay, so this is really helpful i'm still catching up going through and getting the pros and cons in there, but.
<kimhd> Now might be a good time to start working through some of the on you let's see Okay, let me go back first to fill barker's point on multiple payloads you'd kill yourself for that a while back, can you talk to that.
<phil_barker> Kerry did a good job of summarizing what I wanted to ask just based on what I put in the text.
<phil_barker> There are multiple payloads within scope.
<phil_barker> How would they be handled within if they are within scope and also you know just a little bit of consideration for each of these examples, what the consequences would be if they were in scope.
<phil_barker> So I don't know if it's something that can be answered now, it was more.
<phil_barker> So a question as to whether it is possible to consider them just yet.
<kimhd> let's see any discussion on that looks like.
<kimhd> O P one.
<kimhd> P one if you're talking you're muted.
<phil-t3> My apologies, I was thinking with my eyes closed without thinking.
<kimhd> What people should do that that's great.
<phil-t3> I know we wanted to put off the discussion about.
<phil-t3> about what a presentation does versus what an issuer does.
<phil-t3> But one of the challenges that's emerging is the.
<phil-t3> Is the issue itself, creating a combined multi component credential the CEO is obviously one example of that, but I can imagine others might want to do something similar.
<phil-t3> For their own particular domain i'm thinking in the HR space, for example.
<phil-t3> And the one of the questions it raises is if that's what ends up getting created as a multi component issued credential that is signed.
<phil-t3> Then one of the thought principles of the of the wallet, which was to give greater agency to the holder to be able to pick and choose how their capabilities.
<phil-t3> are best representing themselves from their own perspective starts to get compromised, because if they're already packaged up in various combined ways, then they can't really do that.
<phil-t3> So I just wanted to highlight, there is a connection between how the issue we're.
<phil-t3> creates their their credentials as as.
<phil-t3> unique and and focused.
<phil-t3> Statements on a particular topic, and maybe they create multiple of these at the time that.
<phil-t3> For the for the holder, but that they don't necessarily combine them into a common single credential in the process versus giving that common a tutorial capability, leaving that for the holder to do themselves.
<kimhd> Okay, these are good points i'm just making a quick section at the beginning of the things that we that we wanted, justice and we can start going through them soon, I just want to make sure we understand this sort of breadth of.
<kimhd> Topics first so multiple issuer.
<kimhd> I think we had a question from David So the issue on the outside and inside.
<kimhd> nate.
<kimhd> wrote a clarification, it does mean Okay, the inner issuer is the creator of the badge class versus the outer one is the assertion.
<kimhd> What else Okay, I think we got to fill carry I think you're up next.
<kerri_lemoie> I was thinking about the multiple credentials versus multiple issuers.
<kerri_lemoie> In regulated vcs are not using the learner rapper we can have multiple credentials, they can go to multiple recipients, which we don't I don't think we wanted to recommend the PC and new.
<kerri_lemoie> But there is only one issuer in the verifiable credential I feel so that is the big fat is a distinction and it's challenging I know because we have these these examples of self contained credentials and it's imperfect.
<kerri_lemoie> But it seems, though, in the short term, it might be easier on folks if we just say hey one payload one is sure.
<kerri_lemoie> To help clarify, you know that they should be the same, or if we decide to do that, that the issue is in the pillars should be the same as the.
<kerri_lemoie> The authenticating ensure I know only if the car is this gets much more complicated, as the same too, but my understanding of CLS is that that's more of a publisher of.
<kerri_lemoie> transcript of critical list of whatever impressive array of achievements that could be from different ensures that that is different than what.
<kerri_lemoie> an array of open badges would be okay and i've heard if I look credential because you could link a bunch of open badges from one issue or inside verifiable credential if you wanted to, but it.
<kerri_lemoie> may be, that is the case right that is case but also there should be a verifiable presentation pays for the earner who wants to do that themselves.
<kerri_lemoie> Out there.
<phil-t3> Can I respond to that.
<kimhd> Please.
<phil-t3> yeah, I think, where i'm really concerned about.
<phil-t3> is bringing together multiple distinct types of issuers, excuse me, multiple distinct types of.
<phil-t3> payloads I see the badge is one kind of payload.
<phil-t3> A skills and or competency as.
<phil-t3> As a second payload a transcript as a third, and I can understand how they are clearly intimately related as they all represent different aspects of.
<phil-t3> This particular learners experience and and performance in a complex Program.
<phil-t3> But the question that comes up is if they are all presented inside what is effectively the same payload then.
<phil-t3> that's where the issue we're basically, is telling the holder, this is how you have to present yourself from our perspective and I don't believe that that's inappropriate as long as the ability.
<phil-t3> Is there for them to also be able to pick and choose and that's the Agency question i'm sort of concerned about Thank you.
<kimhd> So I think in order of kind of how we should tackle them let's see i'm thinking of Kerry made some points that I think are interesting.
<kimhd> let's see in terms of okay it vc data model allows certain kind of combinations you know the credential subject array could have multiple recipients, but, but do we actually care about those in our use cases.
<kimhd> That you know and that's something we can go back and check our actual use case to see what's going on.
<kimhd> Multiple issuers, we can clarify exactly what we mean by that and I think some of this is what has been alluded to, I think that is a discussion that's interesting before we get to verifiable presentation so multiple issuers.
<kimhd> interruptions past conversations what's caused a lot of problems is that we're talking about a lot of different kinds of entities, so we already okay let's talk about quickly about multiple issues.
<kimhd> We already talked about from a you know sort of like.
<kimhd> Okay, given the vc data model, as it is right now, what are different kinds of things that you could express so in the ish in the vc data model, there is let's see where it is let's let's pull up our examples.
<kimhd> Let me pull up the link after I talked to it okay so.
<kimhd> There are ways to express multiple issuers, one of them is to okay issuers identified by did or by your eyes, so they can be a did so one way like if it's a long term relationship among multiple issuing authorities.
<kimhd> You know, you can create a hybrid did that that applies to both of them and then within.
<kimhd> The sort of did document, there can be different signing keys for each issuer and you can say things like what the relation.
<kimhd> things about like what's expected of the issuing authorities like do you expect all issuing all issues.
<kimhd> associated with that did to actually sign the credential is it one of them things like that the other path that we talked about and.
<kimhd> i'll pull up the example, for this is that there is talk at the vc data model spec layer for sort of more dynamic associations of issuers where.
<kimhd> Within the issuer data structure, there would be a new type that would be like sort of some dynamic issuers hype and then within that you could express who those issues are.
<kimhd> Okay, so that's just sort of like sort of.
<kimhd> How you say, following your new nose, you know connecting connecting the pieces I think beyond that we get into a discussion of.
<kimhd> sort of meaning of what we're trying to express there, so I think that a large part of our confusion or sort of this tension could be addressed by.
<kimhd> Just being very precise about what we mean by issuer and then teasing apart, all these other roles that we're talking about.
<kimhd> Because I think many of them are not actually meant to be that vc issuer in the sense at least that I think about it.
<kimhd> And so I think, maybe just being very precise about what this emergent definition that many of us working on vcs are thinking of.
<kimhd> You know, so that we can clarify that role, compared to all the other roles that that might be applicable would be a good way to go.
<kimhd> At that point let's see Okay, while I pull up the example let's start Kerri do you mind switching to moderator go through any of the chat that might be discussion points.
<kerri_lemoie> i'm not sure where to start here.
<kerri_lemoie> You must share.
<kerri_lemoie> With someone in the chat like to start, maybe with somebody you know we have a lot going on in here okay.
<kerri_lemoie> definitely be drinking more coffee this morning i'm saying.
<kimhd> Well, actually, I do have the example, let me.
<kimhd> But I also need coffee too so Okay, so we, we have already in the you know this document.
<kimhd> This sort of joint issuer thing, so we talked to about Okay, one issue, or we didn't get into defining exactly what it means so there's Okay, create a merged entity, comprising multiple issues that's the merge really sort of lovely joint issuing.
<kimhd> The idea, the other one is this.
<kimhd> joined issue or type, which is being discussed at the vc data model layer because it's not just us, you know so there's I guess.
<kimhd> is totally separate issue of you know, do we take this on here, or do we sort of join in the broader discussion so okay issuer and then, in that case, it would be sort of like this.
<kimhd> You know, a type.
<kimhd> Oh yeah actually this name doesn't make sense, it would be something more like some joint degree issuer.
<kimhd> And then this could be something that that we define and then we say like who the participants are, but the difference between this in bullet point one is that this allows sort of more dynamic formations of issues.
<kimhd> Okay, let me go back then to.
<kimhd> The discussion which I enter.
<kerri_lemoie> Sorry i'm going to mix up just in response to this just before you move from this page, I want to make sure that I understand it, so my understanding from this is that the joint issues could be.
<kerri_lemoie> Like a consortium of issues, who have decided together that they are going to issue these credentials, but not that it's different issuers for the credentials themselves.
<kerri_lemoie> Meaning that there could be separate credentials and each one is a different issue but that's not what is meant by this night.
<kimhd> Actually, that what you described this more relevant for the first example where it's like.
<kimhd> let's see I think in let's pull this one up actually because I think the intent of this one is that.
<kimhd> let's see oh Anthony Anthony are you here.
<kimhd> i'm not sure if anthony's here today.
<kerri_lemoie> I don't see him on here yeah.
<kerri_lemoie> Okay today.
<kimhd> My thought is that the intent of this is that you know so, so I think that you could do that but I thought the intensive it was for something where multiple signatures are in fact provided on in the proof array.
<kimhd> So it doesn't nothing at the vc data model then talks about okay so here here's another angle to get into.
<kimhd> The vc data model just doesn't care they don't care about us so so that's fine because they, let us do whatever he wants some extent, so if we did this, you know something like this that's all linked data we get.
<kimhd> To find what that is, we can say things like okay in this issue or type that we're defining you know through data.
<kimhd> This is the sort of role like here's who you would expect to see in the participant right it's right to meet sure you don't care.
<kimhd> So yeah you can say like would expect both of these signatories, one of them, you might say things like it might get into topics that they well this isn't exactly what Kerry mentioned but.
<kimhd> You might end up saying like adding new types or new terms on it's saying here all of the authorities, it went through before the actual issuance so like while these.
<kimhd> While their signatures may not be on it, it might express something about like the trust group or the the processes through which it got to the final point that it could be signed.
<kimhd> So I think that there's that whole workflow around like what happens before it gets to the issuing stage that the vc data model is really letting us do whatever we want so so that's where I think that.
<kimhd> let's see I think that's where we can just afford to be a lot more kind of.
<kimhd> focus on the use cases a bit as opposed to trying to come up with some blanket structural thing because really we.
<kimhd> It can vary, we have a lot of control, so I think like the problem that we've gotten into is is we try to say, well, what about this, but we're not being precise when we say what about this.
<kimhd> Then, we end up chasing all different examples so that's just my take on it.
<kimhd> So i'd rather us kind of get into some specific like when we get into multiple issues i'd rather us just say like what about this us, what about these use cases with multiple issues, and then we can start going through exactly what that means.
<kimhd> So that's just my take on it, because I don't think we're making progress on the multiple issues, otherwise.
<phil-t3> Go ahead, well, I was just gonna say it in many ways, one of the challenges, is that we can't know all the different kinds of complexities of issue or type that will that we will likely run into and for reasons outside of our control political or otherwise.
<phil-t3> we'll have to somehow be represented.
<phil-t3> And so I like the idea of of some kind of much like we were talking about in terms of credential types, that you can point to and have a a.
<phil-t3> definition that for each of the ones that emerged that is relevant and can be incorporated into the.
<phil-t3> into the credential as a as a way of making that a dynamic thing but but start with a couple of clear use cases that reflect known credential types or excuse me issue or types were issue or patterns, as you describe them.
<phil-t3> So that we handle the things that people are kind of sensitive to and are needing to see themselves representative without closing the door on things we can anticipate.
<kimhd> we're getting close to time, I think that Next, I think we are at a state where next meeting, we should definitely go over verifiable presentations because I think that now it's appearing that.
<kimhd> Some of these discussions are just kind of blocked on the idea of the assumptions around publisher versus you know what sort of verifiable presentations does.
<kimhd> didn't Jim goodell mentioned if we explore other approaches to rapper making sure different types of payloads can be handled, I think the The thing that I think a decision, we can make, as of today, because it will.
<kimhd> improve our way of thinking, a lot would be saying it's a rapper and other things, so I think la la rapper is fine as a catch all it's out in the world.
<kimhd> it handles different payloads, but I think that you know there's this other paths that we're talking about for say open badges so it has the downsides that we're.
<kimhd> That we're talking about, and you know for something like open badges maybe we want some more first class open badge vc integration and maybe other standards do too, I think that that's fine.
<kimhd> You know, and I think that we don't need to make decisions that like we're not using le are rapper anymore, I think we just need to be very precise about when which are useful and relevant I would be very curious to hear if if that's caught, I mean I realized that comes at the cost of.
<kimhd> You know there's more there's maybe that's more confusing in the world like to say, like Okay, this one is acceptable in these use cases otherwise, but I think that we will need that sort of other payload exists.
<kimhd> Other like non JSON-ld payload type and we should just you know we have a way to address it already unless we want to come up with some other approach that sort of competes with the rapper I would say that we just use la rapper.
<kimhd> So in that that's a good way to make sure that there's no discussion on those decisions that I just threw out just now, but maybe over the next week let's let's talk about those statements.
<kimhd> and work through the verifiable in next week we'll talk about verifiable presentations.
<kimhd> And I think we can continue to start teasing apart, what are the paths that we want to support.
<kerri_lemoie> sounds great.
<kimhd> Okay, thanks everyone thanks Kerri This is very helpful.
<kerri_lemoie> yeah I really appreciate the discussion everybody, thank you.