- From: W3C CCG Chairs <w3c.ccg@gmail.com>
- Date: Mon, 24 May 2021 13:04:45 -0700 (PDT)
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-10-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-10 Agenda: https://lists.w3.org/Archives/Public/public-credentials/2021May/0053.html Topics: 1. IP Notes 2. Introductions and Re-introductions 3. announcements and reminders. 4. The Problem with Payloads Organizer: Wayne Chang and Kim Hamilton Duffy and Heather Vescent Scribe: Present: Kim Hamilton Duffy, Phil Long, Simone Ravaoli, Kerri Lemoie, Jim Goodell, Nate Otto, Phil_Barker, Adrian Gropper, Anthony Camilleri, Adam Lemmon, Brent Shambaugh, Dmitri Zagidulin, John Gasper, Jeff McCullough, Jim Kelly, Keith Kowal, Juan Caballero, Marty Reed, 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, Eric Kuhn Audio: https://w3c-ccg.github.io/meetings/2021-05-10/audio.ogg Topic: IP Notes <kimhd> Okay IP note anyone can participate in these calls, however, all substantive contributors to any cct work items must be members of the cce with full IPR agreement signed. <kimhd> And i'll include a link to the w three Community group. <kimhd> credentials Community group site to join and you need to ensure, you have a w three web account this is free. <kimhd> And then, lastly, the text of the Community contributor license agreement is available at this location. <kimhd> Call notes the these Minutes in an audio recording of everything set on this call are archived at the CC G github meetings repo. Topic: Introductions and Re-introductions <kimhd> introductions in reintroductions Is there anyone new to the call that would like to introduce themselves. <kimhd> Okay, I see a bunch of regulars here, which is great. <kimhd> Would anyone like to reintroduce themselves. Topic: announcements and reminders. <kimhd> I don't really have anything does anyone have any announcements reminders for the group. <phil-t3> I have one. There is a T3 network kickoff may 25 for the new. <phil-t3> New tranche of work that is going forward so it's out there and I will endeavor to put a link in the chat. <kimhd> Thanks phil. <simone_ravaioli> Kim this is some on it, I don't know if it's a reminder, but just. <simone_ravaioli> pointing out that last week we had a good chat and indeed the product manager calls around the theme open badges are very five look financials, which is very connected to. <simone_ravaioli> The topic that we're dealing with here and i'll share the link to the recording in the chat and then this Thursday in the ieee i'll our call, we also we are going to be addressing also another Bay related team, which is a payload quote unquote so more on that later thanks. <kimhd> Okay, we made it through all the beginning stuff which is great, because we have a nice meaty presentation from carrie i'll include the link to it in chat. Topic: The Problem with Payloads Kim Hamilton Duffy: Presentation: https://docs.google.com/presentation/d/1HL4y3ciEubw90Qta94nkwFynTi3F6z5ih5WbtmC8y_Y/edit?usp=sharing <kimhd> And i'll turn over to Kerri you should have permission to share your screen and she will present the problem with payloads and it was. <kimhd> Basically, the timing of this is to help us make progress on the rest of the work carry a lot of effort into sort of aligning different definitions of how we think about credentials and so thanks carrie for for getting this together. <kerri_lemoie> Sure, I don't need it right now right. <kerri_lemoie> morning everybody or afternoon or early evening I think for some folks um I i've been spending a lot of time thinking about you know what we're doing in this group and. <kerri_lemoie> The work we're doing, and the work that's commodity the LCR to what I did was I started putting together all of these notes. <kerri_lemoie> And then I wanted to like chunk these notes up into a way that made sense, so I could like get to where I was trying to get to you, and then I realized well I might as well just put it into a sideshow and then other people can see it too, and I can suggest that I bring this here today. <kerri_lemoie> That I don't really think there's a problem with that, by the way the PR work at all i'm i'm a fan of alliteration so and it gets a lot of attention so when I see the problem with payloads I really just opening up discussion with some alliteration. <kerri_lemoie> You can all see my slides right. <kimhd> Yes, we can see it okay. <kerri_lemoie> There is a ton of content in these slides so i'm there, the content is there i'm going to breeze through the content, primarily, so we can get to this discussion. <kerri_lemoie> To at the end, which I think is more important than all of the slides before so think of the slides as sort of a resource that we can get back to later, you can read later. <kerri_lemoie> And also, there are folks on this call, who have way more knowledge about le ar and also vc So if I have something wrong in here, something that you think should be. <kerri_lemoie> updated either, let me know today or like you know drop me a line, so we can make the changes or go into the slides and add your own comments that's totally fine. <kerri_lemoie> here's what we're going to go through is um So what is the car and what are payloads, what are the self contained education standards as payloads I kind of made up that term self contained and you'll see what I mean what are some examples of education content standards payloads. <kerri_lemoie> A comparison review of like le ar and vc and then some vc EDU assumptions that we've been making, I think, or that i've made and we'll see if other people have made these two. <kerri_lemoie> And then some the challenges we're facing with the education occupational payloads and then discussion on like you know how to go from here and Kim i'm not only going to be keeping an eye on the chat So do you mind interrupting me if something comes up that I should. <kerri_lemoie> Okay, so I took this content specifically right off of the earlier. <kerri_lemoie> Earlier rapper and wallet document which there's a link to at the bottom of the slide. <kerri_lemoie> To an earlier is a digital record of learning and work that can be linked to an individual and combined with other digital records for use in pursuing educational and employment opportunities. <kerri_lemoie> And that specifies a universal across genders container for us to provide guidance implemented lpr using vc structure. <kerri_lemoie> And this creates an open architecture for any given to me to use it extend upon their their use case. <kerri_lemoie> And essentially what what this says, in a nutshell, is that is it expansion of or extension of verifiable credentials in a way to insert. <kerri_lemoie> What we're going to refer to in this call anyways payloads which are other standards that can fit inside of a verifiable credential right it's focused on global approach. <kerri_lemoie> And the payload kind of goes inside the envelope of the vc and has it on its own properties, to define it so that you can do things that support or make the verify APP understand what that payload might be. <kerri_lemoie> To the rapper has seen properties as a verifiable credential is, essentially, it is a verifiable financial aid, it requires a context and type in a proof. <kerri_lemoie> um it does have a credential subject, although it has an alias called the record, there is an ID in the subject but it's referred to as an alias of a PSC ID. <kerri_lemoie> There is an issuer called an issuer ID in the car and there's issuance date the car is a date. <kerri_lemoie> It also has some optional properties that are not in vcs just named description and image. <kerri_lemoie> So the record property. <kerri_lemoie> Which is also the credential subject in a vc contains this payload property and the payload property requires tape. <kerri_lemoie> And format and encoding compression encryption and payload record, which is where the content of the payload goes um I do see that i'm pure see I don't know a P O stands for the PLC ID. <kimhd> Proof of control. <kimhd> Oh yeah. <kerri_lemoie> Also. <kerri_lemoie> It contain multiple pilots. <kerri_lemoie> Okay you'll hear me OK, so my headphones for button wonky. <jim_goodell> sounds but it sounds fine. <kerri_lemoie> i'm back. <kerri_lemoie> On you hear me better now. <kimhd> yeah. <kerri_lemoie> That sounds good okay good Thank you. <kimhd> And maybe I should add some more context, some proof of control that is meant to enables a decentralized identifiers or anything any identifier, that is amenable to proof of control like an authentication ceremonies were relying party we give a challenge and. <kimhd> ask you to sign control over some identifier that's in a credential and then you could you know sign it sign a claim with the challenge and the private key corresponding to that decentralized identifier or similar identifier. <kerri_lemoie> Can that be the case for Santa in a presentation of our pilot presentation that key would map to that proof control ID. <kimhd> commonly in a verifiable presentation, for in the holder equal subjects scenario is the the holder Well, this is for non minimizing disclosure kind of signature sweets. <kimhd> The holder ID would match some ids that are subjects in the verifiable credentials in that presentation I don't know if that made it diagrams might help there but yeah typically so. <kimhd> that's meant to be holder versus subject but frequently in in the scenarios we're talking about holder is the subject, except for things like. <kimhd> which I don't want to open this can of worms like see till our is is often not holder equal subject is what it appears in at that level of concern, but we'll get to that later much, much later. <kerri_lemoie> yeah and, in fact, a we probably won't get into the details ocr or or presentations either. <kerri_lemoie> Right we're gonna we're going to stick to what we have here, for now, because we can easily get down some kind of a rabbit hole there. <kerri_lemoie> So here we have we have this like ler and it can have a payload the payload can have they can be multiple payloads and they have these these required properties. <kerri_lemoie> And it sort of looks like this. <kerri_lemoie> The payload is inside of the record and then we have this payload type the form encoding question so type, I think I have this define. <kerri_lemoie> sort of here, and this next slide i'll just stay there for a minute just to make sure folks and sort of see this document is in the. <kerri_lemoie> rapper documents I just pulled it from there, so you can go there and look at it later and read this section and detail if you weren't sure like what we're discussing today. <kerri_lemoie> i'm just a few more details about the payload property so it's intended to be compatible with any standard whether it's you know xml or json or xml D or a PDF. <kerri_lemoie> And this can be encoded for transport, so it could be native json ld it can be multi base like basically, for it can be json it can be compressed and then display label and encrypted once again there's a link at the bottom, if you want to go to that section and look into that more. <kerri_lemoie> In this section what I wrote about was. <kerri_lemoie> What these payloads are right so some payloads are self contained credentials and they contain content that describes a an achievement i'm gonna use like words loosely here but achievement. <kerri_lemoie> And issued instance of that achievement, and also how it's verified some contain only like content description or reference competencies or skills, but if they're not the actual instance to have the credential. <kerri_lemoie> And some contain an array of suppose contain both medical kind of descriptions and some issued instances and push it there's like multiple payloads. <kerri_lemoie> And, as I said in the previous slide there's various formats and multi formats and, in some cases, all of this is combined. <kerri_lemoie> which the reason why I started going through all of this, by the way, folks on the call is that if i'm building a verification APP or a wallet or. <kerri_lemoie> or something that wants to understand this it's a lot to wrap my head around what, if I am new to this i'm like What is all this stuff and what does it all mean and how do I do something with all of this data, which is what we really want to encourage in the long term right. <kerri_lemoie> Okay, so some examples of self contained standards. <kerri_lemoie> And these are the seven right, these are the three that I know of the most one is IMS global from badges which is json ld and it's a single issued instance typically. <kerri_lemoie> is little car, which is an array of issued instances from one or more issues issuers. <kerri_lemoie> And the incident issues may be different from the CLS publisher some of those instances could be open badges. <kerri_lemoie> And then I have passed down here, which is a single transcript permissions I don't know that much about past i'm going to pause here for a second you see and Jim do you have a second to talk about passing by asking a couple questions if not we can come back to it. <jim_goodell> assume you mean Jim_Kelly. <kerri_lemoie> I do i'm sorry, yes I didn't look at the participants list sorry. <kerri_lemoie> hey what I do understand is that there is a json ld group working and i'm past and I don't know the standing of that but i'm gonna be included on the self contained list for now, and we can we can get to that at some other point. <jim_goodell> yeah been plugged in a little bit into that and there. <jim_goodell> So there will eventually be a json ld version of the transcript pass transcript i'm not sure when that cookie. <jim_kelly> This is Jim Kelly, yes i'm here and i'm listening i'm trying to talk um. <jim_kelly> There is a JSON group meeting it's it's very active right now we're pulling in resources to. <jim_kelly> To help us better understand make some choices. <jim_kelly> On json ld vs Jason and and what those use cases and advantages and disadvantages might be to that's happening right now to try and move the Jason ball forward with with pests and we're we're looking at. <jim_kelly> A wide variety of things right now, so do trying to be tired trying to take a complete approach to to how we think this is kind of getting used going forward so that's. <jim_kelly> that's happening right now, obviously, there is the the existing xml standard which has been in place for many years and is fairly robust and mature. <jim_kelly> So. <jim_kelly> You had a question mark about single transcript per issue yeah. <jim_kelly> I you know what I meant by this sort of a note to be. <kerri_lemoie> Jim but there's more about. <kerri_lemoie> I use I guess what i'm referencing there is, are you. <kerri_lemoie> Is the group looking into doing. <kerri_lemoie> sort of a vc native version of past. <kerri_lemoie> Where maybe the. <kerri_lemoie> Student information. <jim_kelly> Is is more in the verifiable credential or in the subject. <kerri_lemoie> And then say the past is the rest of the content about. <kerri_lemoie> The achievements, or the transcript. <jim_kelly> We haven't been looking at that it's been it's been we have been looking at this purely as a payload. <jim_kelly> But that's an interesting idea arm, it is so when you say single issuance their transcript can include multiple. <jim_kelly> Achievements so so it could include multiple degrees, so the transcript can be more than just a single thing. <kerri_lemoie> I think it'd be great so we do a call about pests, we cannot understand it a little bit better but that's okay. <jim_kelly> Okay, what am I have to pull in someone with a little more payload expertise on that, but but. <jim_kelly> Education and expertise split up. <kerri_lemoie> Great awesome i'll drop you a line about it, thank you. <kerri_lemoie> So these are list of some of the education content standards as payloads and I pulled this list, out of the car unless, but I know that there's more than this, but these are some of the ones that are included in that document. <kerri_lemoie> Okay, so now we're going to just talk a little bit or I missed a little bit about. <kerri_lemoie> differences, and this is where like if I got anything wrong, please feel free to chime in, and let me know. <kerri_lemoie> Okay, one has to do with a payload and clear properties, so the rapper has the record payload it has those properties that despite the type of format and coding and compression and encryption but. <kerri_lemoie> The BC credential subject assume json ld it does not have implicit properties, to explain formats it's very loose. <kerri_lemoie> But it allows the flexibility for a context file to be provided to explains properties and, as I noted after I like le R is a verifiable credential and it has its own context file that does this. <kerri_lemoie> And can do you take a second just to explain how the aliases work I didn't really put anything in here about that yet. <kimhd> um yeah so actually i'll dig up some links to share it effectively. <kimhd> This the way that the LCR. <kimhd> Standard did it was use json ld to alias or kind of rename some fields, but this context defines this context link right here the. <kimhd> scribe some mapping to. <kimhd> Those names to verify the credential data model names, so that it's the same in terms of rdf graph. <kimhd> context can be an array at the beginning of the file and so by pointing to this that's what enabled them to sort of rename. <kimhd> or rename critical subject to record and things like that, and so the ability to do that comes from the json ld spec. <kimhd> it's kind of obscure I don't think that it wasn't clear if the people behind json-ld verified credentials were especially happy that that we came up with this clever idea but. <jim_goodell> Can I just interject that there were some. <jim_goodell> good reasons from the standpoint of the LER work group for doing this that and we did discuss, do we really want to alias things, but it was, it was important to those participating that. <jim_goodell> This we didn't that would given the impression that this is broader kinds of records and credentials so using terms like record. <kerri_lemoie> Okay issuer. <kerri_lemoie> start at the bottom dippin for later because been talking about this with Anthony he brought up some some concerns about issuer and. <kerri_lemoie> I just want to make sure we didn't get into those now, so we can move on, but I do think we need to talk a little bit more about what issuer means in terms of verify look credentials and education, especially in terms of a movie of publishers to. <kerri_lemoie> um so the rapper does not imply that the issuer is the same as the issuer is contained in the pilot so for their self contained standards, like a car or a badge that could be conflicts or misunderstandings. <kerri_lemoie> Because you can, if you put in full manage our car in there, they could have different issuers, it will be very hard for a consuming application to really understand which, which is which. <kerri_lemoie> And then vcs implied there's one issuer for all of the claims that might be in a credential subject. <kerri_lemoie> And some of the self contained standards, like the car do you contain records that have different issues like I said said above. <kerri_lemoie> And then there's differences between recipient and learner approach so i'm for the rapper record is issue to a single individual in learner. <kerri_lemoie> And there may be multiple payloads but only one record that's really associated associated with that a PSC ID, which is a learner and now I know proof of control it. <kerri_lemoie> A vc credentials object actually may contain claims about more than one individual vc edgy we've talked about not doing that. <kerri_lemoie> But it's possible to do that a verifiable credential can be issued to more than one person, at the same time. <kerri_lemoie> And then revoking so I could not find anything in the documentation and mentioned revoking in terms of the credential status, which is a verifiable credential property. <kerri_lemoie> um I assume it could use that the one or two because it is a verifiable credential. <kerri_lemoie> And then the the vc does have that critical status that can be used to see whether or not a vcs suspended or about. <kerri_lemoie> Jim_Goodell do you want to say anything about revoking and ellie our stuff. <kerri_lemoie> In the car work. <jim_goodell> I don't recall the discussion about that, but i'm sure that we didn't i'm sure that that was. <jim_goodell> So something that we didn't want to exclude. <jim_kelly> tmi I recall that discussion as as kind of something that we thought we didn't have time to to get into. <jim_kelly> we didn't have the time to work through completely and that we wanted to push it off and let you know, let the Standards Organization who picked it up later handle it. <jim_goodell> I think you're right Kerri that the group didn't do anything to exclude the concept of status. <jim_goodell> yeah we didn't want to explicitly say here's how you handle status . <kerri_lemoie> Okay cool, thank you, I want to just clarify my understanding of where all that stood so that's very helpful. <kerri_lemoie> Okay, those are the different major differences that I could find aren't really that many right um. <kerri_lemoie> I, made a list of assumptions i'm going to go through these and you feel free to jump in anybody and correct me on this, this is about vc edgy i'm not vc it's. <kerri_lemoie> Not about earlier, this is just sort of if we were just looking at vc edgy without le ar we're thinking about what we were doing with the verifiable critical for education. <kerri_lemoie> To number one is that it's intended to be a verifiable instance of a single awarded issued education or occupational credential. <kerri_lemoie> That it must have only one issue identity, although there are any could represent more than one issuer that's come up like a did could represent a group of issuers a consortium of some kind. <kerri_lemoie> i'm making that up, but I think that they use case came up at some point i'm 30 of us have one recipient identity. <kerri_lemoie> And that's what we had decided at some point in PCA do I don't know if it's documented but i'm pretty sure that that's what was decided at some point. <kerri_lemoie> However, that identity, the recipient, it could be more than one person, just like with the issue, it could be a group or any did could be a group. <kerri_lemoie> A URL could represent a group even I mean i've had it says, an open badges were an email, I presented it live or not. <kerri_lemoie> And number for the claim the claim within the. <kerri_lemoie> credential subject must contain only one achievement, or one one payload as we've been talking about this, but a vc at you credentials make him more than one claim. <kerri_lemoie> The claim has only one achieve him, but it can have multiple claims. <kerri_lemoie> And this is an assumption that the claims are made by the same issuing identity to 10s of an issue to the same identity. <kerri_lemoie> You can ignore see that's a note that I don't know what I was saying there. <kerri_lemoie> And D, if one claim is revoked they're all revoke so the credential status, you know, like someone clicks on a URL for credential status and it's gone. <kerri_lemoie> Then it's gone for you know all of them are gone, at the same time and then six is just a reminder note that we have been looking at this has potential property. <kerri_lemoie> which has one values the schema.org property has one value, which is education, no occupational credential which looks very much like the content description right it's not about the instance it's about it's more global definition about the credential. <kerri_lemoie> Okay, so some challenges. <kimhd> slide yeah phil mentioned see probably it's just issued on the same date, and that makes. <kerri_lemoie> that's good to call the date. <kimhd> The outer thing which yeah so how did those dates all together. <kerri_lemoie> I don't know why, but I, you know honestly you look at something a million times and you misspell something, yes, that is exactly what I meant here right Thank you. <kerri_lemoie> Okay we're almost done getting through the steps we get the discussion. <kerri_lemoie> Okay, so some of the challenges we've already gone through this really some pillars are self contained content credentials and they contain. <kerri_lemoie> Everything the content issued instance and the verification, and this is a challenge for vcs and ellie os because the vcs really are the instance right there, like the envelope that describes the instance itself. <kerri_lemoie> And the second one is that. <kerri_lemoie> Some contain an array of both content descriptions and issued instances so that's like a clo, for instance, or possibly like a pass transcript. <kerri_lemoie> This means we have problems because there isn't a verifiable instance between the relationship of the issuer and to the claims. <kerri_lemoie> And then, lastly, and the varied formats and the option to contain multi formats. <kerri_lemoie> And this is the challenge for vcs because vcs are structured only be in json ld and don't really have these properties to describe these various formats on their own unless we're using the context to have those properties. <kerri_lemoie> Okay, here we are discussion, I mean. <kerri_lemoie> Okay, so I have, I have an idea, but I just want to bring to the group first and then a few we agree, we can move on to the next, slides. <kerri_lemoie> And this is to work on the self contained payloads first, and that includes of badges and then see lr and then and then pass as far as we can get while they're doing their work in parallel. <kerri_lemoie> And then get to the work that we've kind of been doing all along, which is back to vcs you credentials that aren't self contained payloads and how much we will lean on le RS and that work. <kerri_lemoie> And, and the reason for that is this is that the self contained payloads already have their own verification methods right and we can't change that vcs like they are what they are in those standards they verify the way they do. <kerri_lemoie> Ideally, we hope that suffering students would create vc native versions. <kerri_lemoie> Without having their own verification methods, because that way we can really use the other valuable properties of those standards and let the vcs handle the verification aspect. <kerri_lemoie> But in the meantime, if we want to really get out the vc versions of these things like open badges and CLS then we're going to just make some compromises to get that happen. <kerri_lemoie> And then we can move on to the other work, I think that we stall here for too long, then it's really hard to get other things done and there's a lot of people who are already using the standards and try to implement them as vcs and I really struggling with it. <kerri_lemoie> And then my my biggest suggestion here, and this is where we get to the deeper discussion with all of you is start with open badges. <kerri_lemoie> And that's because it's the simplest because car is based on badges and because past because you know they're busy working on the json ld version right now. <kerri_lemoie> So what I put together in the slides are five different approaches that have been discussed it's some point or another about doing this. <kerri_lemoie> A budgeting of badges as json ld. <kerri_lemoie> let's see what should we should, how should we go about this part can. <kerri_lemoie> Say open up each one maybe we can look at them. <kimhd> yeah That would be good. <kerri_lemoie> To this first approach. <kerri_lemoie> Is the rapper listen, a new type approach. <kerri_lemoie> This is one that I am so they have the least amount of experience with and can maybe you have more knowledgeable knowledge about this one, and I do within the model. <kimhd> let's see probably nate would be the most authoritative on. <kimhd> The I think sort of drove a lot of the open badge paste examples here mind. <ottonomy> First, I can briefly talk to this one, which is that. <kerri_lemoie> When certain eight before you get started, you know what maybe you want to talk to the first three mind. <kerri_lemoie> No, no i'm still on one so. <ottonomy> Number One. <kerri_lemoie> All right, all right. <ottonomy> Number one is you saw carrie talk a little bit about the aliases that were present in the Le our. <ottonomy> context that appears here up at the top, and so this is essentially a. <ottonomy> claim that users that vocabulary to and it open badges as the value, so the payload is a piece of json ld which is. <ottonomy> You can see the payload type alumni json ld 3.0 application ld plus json and then the data is the json of the actual assertion so. <ottonomy> Where you see the data line, all the way there through the curly brace that sort of closes the batch that just is an open badges to point out blob of json and I believe at the top, if this is done correctly, that would mean that the. <ottonomy> context for open badges appears somewhere, so I don't see the context so things like a badge property yeah so if this were done correctly, there would be the open badges context would probably appear within the data. <ottonomy> payload the payload data section, so what. <kimhd> happened with this was, I think that we were having problems loading account like so we were actually. <kimhd> reusing these contexts across something else that was doing using them in code and we were having problems loading the open badges content, so it just pop removes, so it should be back there so yeah. <ottonomy> Sure yeah yeah absolutely no criticism of how this came together, whatever just so people can understand what it would mean to embed json ld inside a payload is you'd have that context. <kerri_lemoie> So, essentially, this is like an open badge. <kerri_lemoie> Within the wrapper recommendation. <kerri_lemoie> that's that's The intention of this one. <kerri_lemoie> Does that make sense. <kimhd> yeah that's right okay. <kerri_lemoie> Nate you still there. <ottonomy> Oh yeah sorry I muted myself exactly right. <kerri_lemoie> Okay okay well I listed some pros and cons here to this approach, so we could discuss it, this is not a finite list of pros and cons it's what I came up with. <kerri_lemoie> The pro is that a contain all the assertion a badge last property, so all of the data can be accessible and in that that envelope of the vc firms and it's pretty complex is unclear of the role of the issue of the vc and the issue of the badge assertion. <kerri_lemoie> Sorry. <kerri_lemoie> there's a question of how the PLC ID results with the bad recipients and. <kerri_lemoie> I don't know I put this in X it's clearly a vc, but I also listed Is this a vc or verifiable presentation and maybe maybe because there's some confusion as to what what that is. <kerri_lemoie> Okay option 2. <kerri_lemoie> You know i'm going to pull out any quality for this. <kerri_lemoie> So this is one of the first approaches to say to an open badge as a verifiable credential This is also currently in the modeling Doc and, I believe, also in the. <kerri_lemoie> Review of CREST paper and in. <kerri_lemoie> Open badges. <kerri_lemoie> Issues. <ottonomy> yeah Okay, so this one, the credential subject area, the idea is that it has has an ID have a credential subject here. <ottonomy> Did and then there is a property and we've been talking a lot about schema.org has credential property that makes the claim that this recipient. <ottonomy> has met the criteria of a particular define the achievement, so they have the credential that as a badge class That means that the outer vc itself is. <ottonomy> functioning in the same role as the open badges assertion and, in fact, you see the ID of the vc is example.com slash assertions. <ottonomy> 1001 and essentially saying this is the assertion this entire thing. <ottonomy> And then, it has an issue where it has a type, it has a credential subject the claim the central claim that the assertion makes is that the subject to the learner has met the criteria of a defined achievement and therefore has a credential. <kerri_lemoie> Excellent Thank you um that you'll see when we get to number three of the options that we have so far, it looks very similar to this one. <kerri_lemoie> And the pros of this is much less complex, it has the idea that references the assertion. <kerri_lemoie> Look at this the cons, is that it doesn't contain vc proof in the example, but I think that just might be what the example is right now. <kerri_lemoie> Or, or it might be relying on the assertion, but that might just be how the example is set up. <kerri_lemoie> And then also it links to the assertion, so the so it's positive it's that has an idea, the assertion but also links to the assertion and if the data doesn't match, then you know, there may be some misaligned values between the two. <kerri_lemoie> Okay um next one has to be, which is also another approach of matches a verifiable financial and then one more here for you. <ottonomy> All right, I have the challenge of these are the first time that i've actually click these links in a few months so quickly rocking it and presenting at the same time, so. <ottonomy> Oh yeah indeed. <ottonomy> Actually, this looks really similar, what is the difference here. <ottonomy> Is the schema has credential to a badge class again. <ottonomy> It has an issue or an issue and state issued on etc, this one also actually has the open badges assertion content mixed in here somewhat duplicative Lee with the. <ottonomy> verifiable credentials content So you see that the type at the top of this file is a verifiable credential comma assertion. <ottonomy> Meaning that it is both an open badges two point O assertion and a verifiable credential and So you see, like issuance date and issued on it shouldn't state comes from the vc vocabulary and issued on comes from the open badges vocabulary, the recipient. <ottonomy> component comes from the open badges vocabulary and it identifies a recipient of type email, with a particular identity. <ottonomy> The credential subject comes from verifiable credentials and is basically exactly as we had just St looked at. <ottonomy> This case we look like schema has achieved instead of house credential I don't think that any material difference between the last example in this one in terms of which schema.org proposed term would be selected as material here. <ottonomy> But then, you also see below the credential subject area there's the badge property, which is the open badges way of identifying which. <ottonomy> define the achievement has been conferred and then there's a proof, which is the vc method and the verification property, which is the imagined method. <ottonomy> This is a interesting franken hybrid a piece of json ld that is both a valid verifiable credential and a valid open badges assertion that makes the same claim at the cost of some duplication. <kerri_lemoie> Excellent freakin hybrid is an excellent way to call it, you should rename it later. <kerri_lemoie> Some of the pros and cons or just would need to say that it contains pros it contains all of the assertion a badge properties somewhere in the envelope, and it could also be verified as as a hosted assertion, in addition to the vc but it duplicates the properties duplicates of verification. <kerri_lemoie> Also, once again, like the other way that links to a hosted assertion to as this potential for misaligned values and also I don't have it on here, but it is much more complex. <kerri_lemoie> And there's a lot of like potential for or for like errors and typos and things between the duplicate properties. <kerri_lemoie> Okay, so the next one, has not been proposed, yet this is three, this is one that. <kerri_lemoie> I talked to one who, I think, is on the call and Wayne on Friday. <kerri_lemoie> And we started talking about this approach is very close to. <kerri_lemoie> The first approach of open badges and i'll discuss this one so essentially What it does is it says. <kerri_lemoie> It puts the information of the badge in here, so it has the badge class and, by the way, this is not good, I don't know if this is correct. <kerri_lemoie> I ran into the payload but that's not like critique Jason mostly it's just be illustrated so it has the batch class information and it does reference the assertion. <kerri_lemoie> What it doesn't do is duplicate things like the date and the issuer and the verification, the proof it assumes that the verifiable credential is the instance. <kerri_lemoie> And that the badge class information is the content, but it does include the assertion, so that if you know the verify or wanted to go retrieve the assertion, they could. <kerri_lemoie> That is the main difference between now and and and and the other so it's very close to to a except that it contains. <kerri_lemoie> It contains a difference there's a difference, I can remember, I now sorry. <kerri_lemoie> Oh, I know what it is it's instead of including ID appear for the assertion linked to the assertion it actually includes assertion within the credentials object that's really the only difference between this and to a. <kerri_lemoie> And so the pros, for this is that it contains all the verify looking for properties to verify to receive it contains the batch class and the assertion data. <kerri_lemoie> The wallet wallet, so this is what came up in the discussion with me and one is that while it's don't need to understand. <kerri_lemoie> How to go retrieve and understand in a batch it can just put has the data right there, and if that's all they want to display that's what they can display and then What it does is it puts the verification on on. <kerri_lemoie> Like gives the onus to the actual verify of the credential from the wallet not to the wallet itself. <kerri_lemoie> If the world wants to they can verify the host assertion, but they don't need to. <kerri_lemoie> But once again, like the other ones, the cons, is that it links to a hosted assertion that you know that it could be different, it could be that by the time the verify looks at the credential it's in the wallet things have changed on a hosted assertion. <kerri_lemoie> Okay, and this last one. <kerri_lemoie> This one was my am and now I look at it seems a little silly, but we should pretty much talk about it anyway, this is the very simplest approach. <kerri_lemoie> This doesn't include anything except it says, who the recipient is and it gives a link to the assertion. <kerri_lemoie> And it says hey everybody here's a verifiable credential it goes to this person has been issued by this issuer here's how you can prove it, if you want any of the other data, then just go pull it out of the assertion. <kerri_lemoie> This is probably the laziest approach, and you know i'm a lifelong web developer pretty much at this tip So this is the approach that I took it still kind of like it honestly, but I think it puts a lot more work on the wallets then we want to do. <kerri_lemoie> That So those are the total five approaches, so what I was wondering, is what if folks think about any of these approaches what other approaches are we missing and then what are, what are the next steps. <kerri_lemoie> So it came from there, I just want to open it up to discussion, I think. <kimhd> yeah so everyone feel free please add yourself to the queue I wanted to start with something carry on the lazy approach like I the last one I think that has advantages and the drift. <kimhd> We can do something with that just by say like content integrity hashes of the link to content, something like that, so you know, there are ways to make sure that they. <kimhd> are, at least if they do drift that it can be noticed and. <kimhd> yeah I don't know I sort of like that in terms of people's ability to just get started with with that. <kimhd> i'll go through i'll moderate or run through the Q Keith you're up next. <keith kowal> yeah great Thank you so i've been following this work for a while and I think. <keith kowal> My perspective always is, I think we we do a good job of looking at it from this from the issue or the holder perspective i'm always very curious how this is going to work from the verify or perspective so. <keith kowal> let's say someone has like 100 badges in their wallet representing all sorts of different things, I mean the nice thing about the vc architecture is like presentation exchanges, I can say. <keith kowal> Please give me all of your course badges or all of your degree badges and you know and that's supported through things like. <keith kowal> Common schema is in the vc world that kind of breaks down when you talk about badge classes just the way that open badges are designed at every issue or has different badge classes, so I mean I just think. <keith kowal> Maybe my feedback is we don't look look at these problems enough from the verify your perspective, how this fits in with the standard like presentation exchange where you can do things like selective disclosure things like that. <keith kowal> Or maybe i'm just missing, something I guess that's one of my my feedback. <kerri_lemoie> that's totally true case and we do need to do more of that. <kerri_lemoie> across the board, I don't think we do that enough in credentials I don't I think what am I goals was to get some verification use cases in our list, but I haven't gotten there yet. <kerri_lemoie> I would like to look at this from the approach outerwear fire, though, if your application is trying to absorb this data consumers data. <kerri_lemoie> Your what what is easiest and also by the way, I think these all of these solutions are in terms I don't think this is forever, I think this is what we look at for now. <kerri_lemoie> And right now there is damage verification going on, unfortunately, but I think we should still keep that angle as a critical one. <kimhd> Definitely let's see we have phil next he wrote it out so wait King phil can you read that Phil_Barker. <phil_barker> yeah it was just a simple question that we did these are looking at the special cases of open badges but you know we'd like to have something I think that's generalizable to other cases, so my question is which do you think of which of these approaches, do you think is the most generalizable. <kerri_lemoie> I don't know I mean. <kerri_lemoie> Last one really is as general as you can get really in terms of it open match that could be anything. <kimhd> And everyone feel free to add yourself to the queue if you. <kerri_lemoie> Have others have answers to these questions yeah please jump in. <kimhd> Adrian. <agropper> I sorry I only come to these very occasionally but I love this conversation, because I am a broken record in the Community, saying that we have to elevate the authorization component of the protocols that we're using. <agropper> And the discussion we're having about the difference between you know self contained and hosted credentials in the real world is exactly the discussion that I think we should be having in the broader context. <agropper> Because of well everything that's been said so far. <agropper> So, in other words, I do not consider the fact that there could be a mismatch between the. <agropper> The The self contained and the hosted thing to be a bug I consider it to be a feature the bug is that we, as a community are combining the control layer with the data layer <agropper> And this is not sustainable and I think the presentation today shows why we need to design for separating the control or the authorization layer from the data layer while using the vcs and dates and everything else, thank you. <kerri_lemoie> Great. <kimhd> Thanks Adrian. <kimhd> And let's see nate is on the queue next. <ottonomy> I think phil's question about what's most generalizable from these examples is a great one, and I also really want to elevate what Kerry mentioned is, we should be thinking about these. <ottonomy> options, from the perspective of the verifiers those who need to consume this data and need to write software that will. <ottonomy> Go rocket and and implement whatever verification components are necessary in order to get the full meaning of the of the claim at its core open badges assertions make a. <ottonomy> claim that we've been talking about in this group, a lot, which is the has achieved or has credential claim, and so, if if I were going to answer the question about which of these approaches is most generalizable I would definitely lean toward the approaches that use the. <ottonomy> You know the product claims like that, where we have a credential subject that identifies a credential by or recipient by a. <ottonomy> Did or some other form of IRI identifier, and then makes a claim that that recipient subject has. <ottonomy> met the criteria and has been conferred a credential definition that works for all open badges claims, as well as others i've been taking a look at some of the the other properties that are like to present and I am slr around how we might. <ottonomy> Specifically, do the other use case that's been really close to my heart, which is a skill claim that any issue or might make. <ottonomy> And I think that can be accomplished in a very similar manner to this using some properties from the car which is around like a result, the idea that there's a result description in the defined credential and a result in the. <ottonomy> credential itself that's getting a little bit off track which approach is most generalizable. <ottonomy> Specifically, from the perspective of air fire, I think the has credential type claim is the one that best stands. <ottonomy> The test of time and i'm really excited that that we have so many implementations in the open badges community that are thirsting for vcs that we might. <ottonomy> really be able to get some pilots, or something off the ground where we do a coordinated approach to achieve these open badges use cases pretty soon. <kimhd> Thank you in yes, I was actually so we have Adrian on the queue twice, I was going to ask, as well, because I think Adrian you just described it in a way that made it. <kimhd> Clearer I think i've wanted to sort of reduce drift, but as long as it's clear, as long as the schema is sort of separate who's responsible for what I mean that's that's great with me it's just not it's not been clear to me. <kimhd> Until now, which part the vc is responsible for on that issuer field versus whatever else, so I was just wondering if you can will will queue up Adrian for a few comments that he has. <agropper> Well it's really just one comment that it is the answer to brent's. <agropper> In my solution if you were to my perspective, is that the subject needs to be always be given the choice, both at issuance and the verification. <agropper> of saying, I want to self contained or hosted credential or both, and the issuer's and the verifiers can choose to only respect one of those options. <agropper> But by separating the control from the content layer, that is what I mean is, do not by design presume that it has to be one at the issuer or the verify or level that it has to be one or the other, always give the self sovereign subject the choice first. <kimhd> Right and I guess just a note on that, so the ideas which which seems like a path that we had been Okay, with all along, if we're just saying the issuer is. <kimhd> You know, issuing this or making this claim about a subject just keeping it very vc data model than what you're calling the content that can have its own. <kimhd> You know sort of trust implications, based on whatever reference schema that that wants to use which we're not, I think, like that's the part that we're saying. <kimhd> Might vary per different target schema that we're using here we're not forcing one at one understanding on all of these, which I think has been some of the what's bog us down in the discussion so far as trying to push everything out to the vc issue or layer <kimhd> I don't know if that's accurate, though. <kimhd> But just in terms of like what is that issuer and you know sort of how did, how does it relate to the payload. <kerri_lemoie> Do you think that is I put in the chat that I think this is what we've come close to with versions to a and three. <kimhd> yep Is that correct. <kimhd> I think, so I need to look at them again P one Europe. <phil-t3> yeah thanks I just wanted to. <phil-t3> express that the having the perspective of both the verifiers and the holder and looking at things from those different lenses I think is really important we've really concentrated on the issue or today, which I understand but. <phil-t3> When it comes to the issue of drift is the concern I have is that the holder needs to know if a credential their packaging and sending to be to a relying party has in fact been invalidated or not. <phil-t3> I liked the idea of separating out those two but there needs to be a way for the holder to get. <phil-t3> And relatively instantaneous notification that something that they're holding has changed, and so I just want to make sure that we do take that step back and look at each of the examples from those three parts. <kimhd> yeah carrie will close with you carry. <kerri_lemoie> Oh yeah so I was going to say that um the the drift is one of my biggest concerns that I agree with separating the authentication from the content, except that the recipient could never know if the hosted values change. <kerri_lemoie> So they wouldn't necessarily be able to know which one to share that has what they want in there, which is actually how I got to. <kerri_lemoie> The very last concept, which was just present the assertion, which makes it harder for the wallet but you know does present I think separates the two simply and potentially prevents you know them getting on not like you know i'm saying. <kerri_lemoie> i'm sorry so we're at noon Kim i'm thinking of one of all of you could sort of review these we can get to the size and review them this week and next week, maybe we can really just. <kerri_lemoie> discuss these examples again and see if we can reach a consensus on which way we'd like to go for ready to do that by next week. <kimhd> that's great Thank you so much Gary and have a great week everyone. <kerri_lemoie> And thank you everybody. <phil-t3> girl good very nicely done. <kerri_lemoie> Thank you.
Received on Monday, 24 May 2021 20:05:04 UTC