[MINUTES - UPDATED] W3C CCG Verifiable Credentials for Education Task Force Call - 2021-05-17 12pm ET

Thanks to  for scribing this week! The minutes
for this week's CCG Verifiable Credentials for Education Task Force telecon are now available:

https://w3c-ccg.github.io/meetings/2021-05-17-vc-education 

Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

----------------------------------------------------------------
CCG Verifiable Credentials for Education Task Force Telecon Minutes for 2021-05-17

Agenda:
  undefined
Organizer:
  Heather Vescent and Kim Hamilton Duffy and Wayne Chang
Scribe:
  
Present:
  Kim Hamilton Duffy, Kerri Lemoie, Phil Long, Jim Goodell, 
  Phil_Barker, Adam Lemmon, Nate Otto, Brent Shambaugh, Dmitri 
  Zagidulin, John Gasper, Jeff McCullough, Jim Kelly, Keith Kowal, 
  Juan Caballero, Marty Reed, Simone Ravaoli, Matt Lisle, James 
  Chartrand, Stuart Freeman, Stuart Sutton, Taylor Kendall, David 
  Ward, Jarlath O'Carroll, Nick Hathaway, Kayode Ezike, Balázs 
  Némethi, Victoria Feng, Peter Mackinnon, Andy Miller, Rick 
  Barfoot
Audio:
  https://w3c-ccg.github.io/meetings/2021-05-17/audio.ogg

<kimhd> Okay, and introductions and reintroductions do we have 
  anyone needs today that would like to introduce themselves or 
  reintroductions.
<kimhd> Any announcements and reminders in queer we don't have 
  anything.
<kimhd> That i'm aware of.
<kimhd> Okay, so we can dive into the payloads discussion and 
  i'll mute myself, so that the background noise is minimized.
<kimhd> Oh Kerri so that's next week.
<kimhd> Last week.
<kerri_lemoie> Last week, sorry I have not can't seem to have 
  enough today.
<kimhd> Time travel to.
<kimhd> Your doctor cherry doctor Illinois.
<kerri_lemoie> I am Dr Kerry now yes.
<kerri_lemoie> Unofficially, really, but especially.
<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.
<kerri_lemoie> yeah absolutely and I can also share my screen 
  again.
<kerri_lemoie> Okay um and 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.
<kerri_lemoie> do their own thing.
<kerri_lemoie> Let me share.
<kerri_lemoie> Alright, can you see.
<kimhd> Yes.
<kerri_lemoie> um 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> Is that we look at.
<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 
  um 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> um 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 um 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 um 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> um 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 um 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 um.
<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.
<phil-t3> cheers everyone.
Kim Hamilton Duffy: Additional Notes: pros and cons of different 
  approaches, contributed by meeting attendees (view only) 
  https://docs.google.com/document/d/1RfR7hHY7PUAUDXIIDXMhFgspjj11IZvi5VMnyQtuwFo/edit#heading=h.q1257zfxv2u7

Received on Monday, 24 May 2021 21:52:51 UTC