- From: W3C CCG Chairs <w3c.ccg@gmail.com>
- Date: Fri, 06 Nov 2020 15:58:20 -0800 (PST)
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/2020-11-02-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 2020-11-02 Agenda: https://lists.w3.org/Archives/Public/public-credentials/2020Nov/0000.html Topics: 1. Introductions and Reintroductions 2. PDF Work Items 3. Modeling VC-EDU Organizer: Kim Hamilton Duffy and Wayne Chang and Heather Vescent Scribe: Present: Kim Hamilton Duffy, Kostas Karasavvas, Scott Malley, Simone Ravaoli, Phil Long, Maarten Boender, Anthony Camilleri, Nate Otto, Phil_Barker, Benjamin Young, Brent Shambaugh, Chris Webber, Dmitri Zagidulin, David Ward, Ganesh Annan, Eugen Rochko, James Chartrand, jceb, Jerry Gordon, Jim Goodell, Jim Kelly, Jonathan Holt, Karen O'Donoghue, Stuart Freeman Audio: https://w3c-ccg.github.io/meetings/2020-11-02/audio.ogg Kim Hamilton Duffy: Okay, so let's get started. Kim Hamilton Duffy: Okay, IP note, anyone can participate in these calls. However, all substantive contributors to any CCD work items must be members of the CC G with full IPR agreement signed Kim Hamilton Duffy: All of this information is in the the agenda that we sent out. But this is the link to join the CCE group and you may have to ensure you have a w3 Web Account first none of these require payments just Kim Hamilton Duffy: Setting up the account and then the text of the WCC community contributor license agreement is available at this link. Kim Hamilton Duffy: These minutes and an audio recording of everything set on this call are archived in our GitHub repository at the following location. Kim Hamilton Duffy: But yes, but in general you type the letter q+ to q yourself. Kim Hamilton Duffy: Okay. All attendees should type present+ in IRC to get your name on the attendee list and the transcript. So please do that now you can see an example of how I done it. The word presence and will plus no space. If you're not over there, we'll, we'll figure it out. Kim Hamilton Duffy: Okay. And yes, if you're not on IRC simply asked to be put on the queue. Please be brief. So the rest of the queue gets a chance to chime in. You can always keep plus again. Topic: Introductions and Reintroductions Kim Hamilton Duffy: As frequently or maybe they've been CC G community members for a while. But maybe you're new to this call. Does anyone want to volunteer to introduce themselves. Otherwise, I'll call on a few people. Hi this is Martin from Sphereon. We've been active in the the ID verifiable credentials groups, different groups. We are now active also been for a while in educational credentials, with a couple of projects. So we'd like to contribute to discussions and to the standardization. Kim Hamilton Duffy: Great, thank you for joining. Kim Hamilton Duffy: Kostas we have you next Kostas Karasavvas: Hello everyone, my name is Kostas and I have been working with the University of Virginia to create a platform across digital certificates into blockchain in a blockchain agnostic, but right now it's in bitcoin and we have been in the process of trying to standardize using Cavallo credentials, which is compatible. But there are a couple of issues that we can schedule a little Kim Hamilton Duffy: And Scott Malley. Scott Malley: Yeah, I'm also at Sphereon with Maartin, we've been active in other verifiable credential communities and also to some extent with the CC G and but this is our first time joining the educational group. So I'm interested to listen in. And just see what's going on over here. Kim Hamilton Duffy: Anyone else want to introduce themselves. Simone Ravaoli: This is Simone and I'm calling from Italy. I work for digital, which is a company that has a global footprint in issuing digital credentials in the higher education space. Simone Ravaoli: And that I've done been advocating for open standards and interoperability for a while. Actually, that's the part that I like best about my job and I specifically would like to see Simone Ravaoli: And an uptake and adoption of new record standards that have I guess endorsement or consensus between Simone Ravaoli: You and the US at scale. So that is one thing that I'd like to see that and and would that create a ripple effect globally, but Simone Ravaoli: I think there are some low hanging fruits there and I'm calling on maybe hinting on the European side and depending on the records in the US that already is something that this group, you know, I hope would take into consideration. Kim Hamilton Duffy: Great. Thank you so much. That's something I'm very excited about to I noticed we have Phil on the on the cube, Phil. Phil Long: Thank you. kimhd so long. I'm the community cat Herder for the pilot projects for the T three innovation network and advisor to the teal entity issue and like Simone, and I'm very interested in bringing some harmonization to the different issuing methods that are Phil Long: Becoming quite well established in different parts of the world, but not yet real Phil Long: What well coordinated or coordinated budget all Phil Long: And I'm also very interested in a couple of other domains at this area's addressing the have to do with the kinds of goods that people Phil Long: Issuing credentials for learning education need to be concentrating on and the communication clearly of the value proposition of this to a doctors. Thanks. Topic: PDF Work Items Kim Hamilton Duffy: I think I'd like to start with Kostas to present what he had in mind for the for the PDF standardization approach that he was interested in proposing Kostas Karasavvas: I might give a brief overview, what we have been working on and then go on getting into you know more details for the work I think and how we think about it. Kostas Karasavvas: As said in the introduction, the project started from academia, but it's actually being extended as for now in other other domains. Kostas Karasavvas: The idea is that we use the PDF is the medium of exchange. So if you have a diploma. For example, the PDF itself is the diploma, the digital version of the physical copy of the diploma. So you can actually receive it and to give you a view it and do everything, but what Kostas Karasavvas: You would do anyway. A lot of execution do that. Kostas Karasavvas: Already. So it's a pretty seamless to start using Kostas Karasavvas: Our methodology are mechanism, which is to take these PDFs and the anchor them to the blockchain and then get the blockchain proof, something that proves that this was actually should in a specific book someone specific Roxanne and inserting that into the PDF meta data. Kostas Karasavvas: Within the result being a PDF like Kostas Karasavvas: Students or our they would get any way but the inside. It now has information that can actually validate the PDF itself. So the digital fingerprint so that you can be assured that it goes and tampered with. Kostas Karasavvas: And that's it. So a lot of things to discuss around that but that's that's the basic idea a show you a PDF and then you have an anchor or verifiable PDF Kostas Karasavvas: A everything is open source like the platform to create these is open source in the open source validators that you can host trivially Kostas Karasavvas: And what we would be interested in is to be as compliant as possible, obviously, to this. And of course, I have been following the very bottom credentials for quite some time, and I was lacking the paper and being very active, but I have even partial designs of how that would be accomplished. Kostas Karasavvas: And our interesting Kostas Karasavvas: More specifically, our interest is, as I see it is two separate areas. The first area is Kostas Karasavvas: There, I think that would be needed some to do some extension just accessibility frame that the VC provides and add some extensions on to how to do the anchoring using our approach our mechanism. Kostas Karasavvas: And and the second one is how to Kostas Karasavvas: Standardize how the VCs can then self could be embedded into a PDF and then the result would be that VC universal validate or be able to accept these PDFs and know how to get the specific VC credential and then verify. There's a physical interaction from then on, right. So, usually there's the medium of exchange is a PDF, the container which contains the VC compatible convention. Kim Hamilton Duffy: Great, thank you close us. We have a couple of people on the queue Maarten, you're up first. Maarten Boender: Okay, yeah, I think it makes perfect sense. There will be a transition period in which people will work both with the PDFs that there are expecting nowadays and getting used to. Maarten Boender: And going to fool basically data objects with with credentials in there. Those are quite similar to the approach that I should probably know as be taken by open veggies in the past of basically inserting Jason information into a PNG image. Maarten Boender: And we're up so it makes sense. And we're happy to, to help with that. Just a little bit more background or scary on we come from the field of document processing and we have been working for, I would say 15 years with with PDFs. Maarten Boender: And not as much of course as as Leonard from from Adobe, but we certainly believe we know a lot of it. And we already are doing things like inserting Maarten Boender: Certificates and data into PDFs and also registering these on blockchain and things like that. So I think we could work together on that. And that makes sense. So happy to help with that and dive into it in the community. Kim Hamilton Duffy: Thank you. Anthony Europe. Anthony Camilleri: Um, I just want to say, I understand the, let's say, PDF first approach. Anthony Camilleri: I just wanted to also make people aware that it's a PDF first approach isn't the only approach. I'm someone Anthony Camilleri: Let's say personally project signer presents come from the area of start with an XML or JSON and then represent them in different layers and there is a lot of Anthony Camilleri: Let's say pluses or minuses. They're all for the moment. All I'm saying is I have no problem with both approaches living side by side. But let's say we would have significant pushback. If there was, let's say, a preference for a PDF Kim Hamilton Duffy: Yeah, Anthony. That totally makes sense. I think I'm in a similar boat where. Okay, so I had a few things I wanted to mention. So first, was Kim Hamilton Duffy: Talking about this as it compares contrast to say the LCR approach and that, you know, we will have alternative Kim Hamilton Duffy: Methods of considering what's the envelope. Basically, but I think I'm kind of interested in seeing things play out a little bit to see what which mechanisms we find most useful. Kim Hamilton Duffy: And at least if we can get alignment, even on the incubation side, then I think that's a great win. So first I wanted to mention Kim Hamilton Duffy: I am assuming that what you're doing to embed the, the, the, basically the signature, like say, especially if it's a grid of the blockchain is Kim Hamilton Duffy: Your, your, you must be using JSON LD canonicalization so that's deterministic. Because otherwise, if you modify the PDF after anchoring it to a blockchain or signing it or whatever, then it invalidates the hash. I'm assuming that first of all Kim Hamilton Duffy: And so I think that the mechanism of like that in the general mechanisms of how you're embedding into PDF Kim Hamilton Duffy: You know with with that framing that it is an interesting way to pursue what that envelope structure PDF is envelope structure looks like would be interesting. It's a work item I included in the in the chat basically Kim Hamilton Duffy: Information about how to start work item. So basically, it seems like we're, we would be close to having what's required. So we have this this if you go to that page, we have a template basically that you fill out this information in chat and then now I'll paste in IRC as well. And so essentially what happens is we have a GitHub issue template new work item template and it prompts you to fill out certain information like the abstract your draft or the work item and then the important thing is that we need editors, or basically owners of the work item, and there has to include representation from at least two we say companies, but it seems like we have sufficient support. So basically, you would just fill out this new work item template. Kim Hamilton Duffy: Mention what you want to do at a high level, and you know you can link to you can also link to a Google Doc or markdown page or something, describing your approach if you have it. And then what happens is the chairs will discuss, see if there's any substantive objections in the community and then we'll create a work item and then you can discuss the work item in the CCG including these meetings, specifically Kim Hamilton Duffy: The last thing I wanted to mention was the LER approach, which is, to Anthony's point the LER approach kind of inverts that so it's using the basically a JSON structure as the envelope and then embeds a PDF in there so Kim Hamilton Duffy: I do think for a while. We're going to see a variety of different approaches and while it might drive us a little crazy. In the meantime, trying to keep track of all of them. Kim Hamilton Duffy: It will be interesting to find out which ones we find most usable in the end. I think I see Anthony you added an additional agenda item. Did you, I think we still have Kim Hamilton Duffy: Let me, let me see. Does anyone else have anything they want to add on the PDF discussion or is everything else new topics. Phil Long: Kimhd, this is Phil. I just want to put it in chat. But I put a link to the wrapper wallet spec paper that Jim Goodell and and Jim Kelly and others contributed to that describes the approach with the PDF as a payload. Phil Long: And just to have make sure that everybody's familiar with that and can take a look Topic: Modeling VC-EDU Kim Hamilton Duffy: So Anthony, do you want to talk to your additional item of right now. Anthony Camilleri: Ah, sure, absolutely, I guess, basically I just wanted to try and start some discussion on some of the things we seem to have been say dancing around in the issues. Anthony Camilleri: I also had at least some first chance with Nathan symbol on about this MSI channel but really wanted to bring it to the main group. And let's say move it forward and Anthony Camilleri: One of the things I think we need to reach some kind of agreement on is essentially saying what type of concept Central Market level of granularity. And do we want to go in this task force. Anthony Camilleri: I can essentially say let's say if I look at it from my perspective, there are Mitzi a set of context. I think the visitation one being just being able to represent Gil, which some of the examples we have in there already have Anthony Camilleri: A secondary seconds, being able to represent our let's say more formal education diploma, which implies say something Anthony Camilleri: A lot more detail than which typically has great so Anthony Camilleri: And the third thing would be that I would want to be able to represent what you might call informal education basically just saying, hey, I attended a webinar. And that's it. Are those with let's say be Anthony Camilleri: My idea of the high levels, but basically I was hoping to start a discussion with the group on what are the that's a fairly basic high level concepts that we need Anthony Camilleri: To represent. I'm not sure if that should happen as far as let's say a discussion under an issue and the GitHub, or if it's something we should discuss in the meeting. Anthony Camilleri: But let's say we jump straight into has achieved has credential without having a slightly wider discussion on what are the actual concepts. That's all types of education leave across the spectrum. Kim Hamilton Duffy: I think that's a great point. And so two responses to that. And let me make sure I'm following the queue as well so two responses. One, I do think it's important to discuss here. I think that my understanding of what we want to accomplish with the specification is exactly what you have mentioned, but at the same time, I'm not sure that's been clearly represented at this point. So I would like to have some tracking around it. That would be a good forcing function to move that issue. So we have a few issues in the VC eating models repo that are not specific to to what you described. Right. And so I think we need to be moving those out and I can move those to the Kim Hamilton Duffy: VC-Ed repo like the main repo, as opposed to this repo. So I think basically the idea that we clarify scope on this document and then continue iterating here, but make clear distinction between this artifacts that were producing it versus other artifacts. So that's a great idea. If you wouldn't mind. Kim Hamilton Duffy: Opening an issue on that with with what you said that would be super useful and then I can start, we can discuss there. If anyone has any other scenarios that they definitely want to be in that document, but otherwise I'll be moving everything not related out of this repo. Kim Hamilton Duffy: We do have a Q Kim Hamilton Duffy: Simone I think was yours to discuss a new agenda item or was that related to what Anthony saying Simone Ravaoli: I'd say they're related. Simone Ravaoli: Yeah, this is maybe more general level, the, I guess the issue is to map. And I'm going to maybe abuse this word, what's going on there and a record spec, particularly if we start from Simone Ravaoli: Etc. I would definitely like new but not really new, but certainly very powerful invisible would be even more so. So just whether it's past, whether it's IMS, whether it's sad. I mean, all different learning records the map them to etc. I will maybe create an application profile of that. Simone Ravaoli: Leveraging some of the mapping tool that already exists, the credential engine as one or the work done would add matrix. So, have that Simone Ravaoli: I don't know if that classifies as a new work item, maybe not. But this is an activity that we started as Anthony said, you know, on a sidebar, but Simone Ravaoli: Feel like this is the right place to foster and then eventually that work could be pushed over the fence on to the I triple E IR Recommended Practices document, I would very much like to see that happening. Kim Hamilton Duffy: Yeah, I think that's a great point. And I thought, maybe I'm wrong. I thought that we had some etc i representation currently in this, but I think Kim Hamilton Duffy: Let me actually let me pull that up real fast. Yeah, we have example for EDC i i agree on what you're saying. Like, there, there may be sort of more narrow or small goals we have for VC, Ed. Kim Hamilton Duffy: This, this one draft specification that we're working on. There may be more in depth work that we need to do as a separate work item, but I think that's it's important to have a B CI. Kim Hamilton Duffy: Captured in this and then we can also iterate on. What's the scope of what we want to carry in to this document, you know, maybe it's just some MVP kind of representation of a common Kim Hamilton Duffy: Common scenario with the DCI, or is it the more in depth mapping work that needs to happen. But I think that that's really important to to keep progressing on Kim Hamilton Duffy: So some money. I think Kim Hamilton Duffy: I'm trying to think of how to capture what you're saying. Kim Hamilton Duffy: I think we can probably do it as a spin off or, you know, sort of in the thread of what Anthony was talking about. And, you know, as we find something that seems maybe too specialized or something. We can start moving from their Kim Hamilton Duffy: Margin you're up next. Maarten Boender: That was another an order to for the PDF. So that was answered. Kim Hamilton Duffy: Okay, great. Kim Hamilton Duffy: Simone de to ask when an le R is good question. Um, I cannot keep track of what it means. Even so, it used to be an IR. Does anyone remember I'm guessing Phil would probably know off the top of his head. Phil Long: Good good good guess learning and EMPLOYMENT RECORD. It is the Phil Long: New to n of our three letter acronym to LA for an interoperability learner record I LR Phil Long: And it came about simply from Iowa it morphed simply to be more embracing of the talent workflow pipeline employer community as well. So, so that's what it represents. And I just putting in chat a reference to a tool in development, but it is Phil Long: That's not what I want. It is in fact Phil Long: A mapper between Phil Long: The different standards that has been developed in development, Stuart. Actually, you may be involved in doing work on this as well. Phil Long: But I, I'll put since I have a chance I'll put the URL in the chat. It does map with a Said's backbone to IMS global to a bunch of existing things that are very US centric, but it might be a starting point to consider what the mapping might look like. Kim Hamilton Duffy: Great, thank you. Kim Hamilton Duffy: Okay. And let me check the queue. Kim Hamilton Duffy: I think we worked through everyone apology that my queuing system isn't working. Kim Hamilton Duffy: Okay, so there were a few issues and I want to keep in mind with the framing that Anthony provided us that we do need a much clearer scope of what we want to get out of this modeling verifiable credentials for education document. There were a few things that I've been very eager to discuss is to discuss, especially with the group that we have on the call right now. Kim Hamilton Duffy: Nate and Anthony have been commenting a lot in the issues I think I was curious to hear if they have any sort of issues they want to discuss high higher priority for me some things I was very interested to talk about where Kim Hamilton Duffy: Let's see the image integrity one issue number three and then possibly issues, number one and six, Nate. I'm curious. Did you have a pressing one you wanted to discuss for for the modeling verifiable credentials spec. Nate Otto: Overall, I think that we have plenty of work that we need to do on these items. And I think that if we can make some of the different models, a little bit more consistent and complete, you know, now that they're in GitHub and the examples are here. I think we've got some good opportunity to actually start analyzing what is different about these different things. Nate Otto: What purposes can each of these serve and then potentially we can start resolving differences between the different systems like for example if we all feel that A has schema.org hascredential claim. Is a useful claim to use to express the, the fact that an individual has achieved a credential definition, then we can update a number of the different Nate Otto: Models to that, where they are not just external references to some other spec that is managed by a different group, I really want to move also just talking about Nate Otto: Recipient identification is your identification and which signature proof methods people propose to use and which Nate Otto: Authentication methods people propose to us with various forms of bids that they want to support. Like, what are the did methods that are Nate Otto: Useful for us. And how does a learner approved, they have control of a particular particular did either via an in person challenge across, you know, a desk with an employment manager or logged into a web app. Nate Otto: Those are the other layers of the stack that we should make sure we're considering beyond just the formats of individual records. Kim Hamilton Duffy: Okay, these are great points on the topic of has performed that's that's actually probably a good one to start with that one is kind of critical in the sense of Kim Hamilton Duffy: It's we're using it as a bridge to schema.org and or rather, it's a proposed change the schema.org but it having clarity around that will help ensure that our bridges to definitions like credential engine engine and things like that are more stable. Kim Hamilton Duffy: So with that, let's actually start with number five. Kim Hamilton Duffy: And I made to Anthony if he's able to talk about this. So let me share my screen as well. Kim Hamilton Duffy: So this is the proposal of adding has performed a schema.org Kim Hamilton Duffy: There's some grammatical inconsistency is that none of us are happy with. But basically the ideas that schema.org already has a has credential. Kim Hamilton Duffy: That the the target that the. Let's see. So that is on that's defined on person I need if this is I haven't looked at this and can you refresh our memory on that one. Nate Otto: Yeah, sorry, I just realized I was sitting in a room that had Background music playing. So I had to run to the other room. Um, so yes, the proposal here for number five AD has performed schema.org is a assertion that Nate Otto: Has credential is a useful pattern and we will use that when it makes sense for when there is a credential definition available so much movement definition that has its own criteria. Nate Otto: Etc represents a maybe a learning experience and an assessment regime issue, you know, that is operated by a particular issue or Nate Otto: There's another set of use cases. And one of the examples of them is in the models as the open skills assertion. Nate Otto: Where instead of making an assertion that a learner has achieved a particular set of criteria. Nate Otto: As assessed by a predictable organization, the issuer is making a claim that the learner has achieved a skill or a competency directly Nate Otto: So like Phil has achieved communication and it points direct instead of to Phil has achieved a communication badges criteria. Nate Otto: And so the argument is, maybe it's useful to separate these things in the schema.org vocabulary. Nate Otto: And when you're saying has credential you're pointing to a particular defined credential and when you're saying has performed you're pointing to a specific competency or other underlying learning objective. Does that make sense. Kim Hamilton Duffy: Right. And the one other thing I wanted to add is that if has credential. We're not already there as a proposed. Kim Hamilton Duffy: Addition to schema.org we probably would have wanted has achieved versus has performed, however, has credential is already there. And so I think what we're doing it, you know, we're saying that will keep as credential and then we'll add has performed as this as this new things. So, for example, open skills assertion. Kim Hamilton Duffy: Anthony, you have the last comment on it. So you mentioned rightly has credentials. Still a little bit unclear. I did did Nate's comments address your concerns there. Anthony Camilleri: Wow, so I had to chat with leading up to this actual video on Anthony Camilleri: It. I understand has credential now. Anthony Camilleri: What I would suggest, and I can volunteer to do the first round of this myself is Anthony Camilleri: Before we defined, let's say what the grammatical terms are, um, I think it would be useful just to making this all the definitions, meaning Anthony Camilleri: I in my head I have for definitions that we need to, um, Anthony Camilleri: And I'm very happy to, let's say, add them directly to the bike sheds file already to an issue to open up for discussion. Once we agree what it is we want to describe the naming is nearly secondary Kim Hamilton Duffy: Yeah, that's great. Kim Hamilton Duffy: I'm just updating the spec. So, okay, that's good. It's so I like that we're keeping momentum going on that one. Anthony Camilleri: There's one though. So nobody expects the nasty surprises are everything that people won't have described in this issue so far. He basically agree with. I think we essentially missing one or two more on top of it. And that's what all the Kim Hamilton Duffy: Great. Kim Hamilton Duffy: Anthony since we do have you on the call. There is this Kim Hamilton Duffy: Discussion of image integrity that I'm very, very interested in. Let me. Oh, you know what, I've not been checking the queue. Let me. Okay, so let me before moving on to that. Kim Hamilton Duffy: Call on Phil_Barker. Phil_Barker: Yeah, thank you. Phil_Barker: I just wanted to make the quick point that schema.org is very generic vocabulary. Phil_Barker: And when you put terms into it. They're not going to get used only by the community that you represent they're going to be seen and used by all sorts of communities. Phil_Barker: So I wonder what our response in this community would be if has performed gets used for things like you know I have performed Beethoven's Ninth Symphony. Nate Otto: Sounds great. Phil_Barker: I'm not suggesting it's a problem. I'm just Phil_Barker: Raising it Kim Hamilton Duffy: I'm. Let's see, Anthony. Did you Kim Hamilton Duffy: Did you already go let me call him. Anthony Camilleri: To go. But actually, that's exactly what I want to use as performed for. So it's a wonderful example. Kim Hamilton Duffy: Excellent. Kim Hamilton Duffy: So that is one thing. I mean, it, it would kind of help if we could, you know, so in some, in some cases with schema.org you can define Kim Hamilton Duffy: A range or the domain of types on which something makes sense. And so that's why I'm a little bit confused like so you can say person, you know, we say that this term is defined on person. Kim Hamilton Duffy: But in terms of what it apply what it applies to can you not also restrict Types There are we, that's maybe more question for Phil Phil_Barker: You can, but it's a moving and organic vocabulary. So you might put it in with a restricted type Phil_Barker: But it may well grow after you've put it in. Kim Hamilton Duffy: Yeah, I mean I guess that makes sense with whatever where if we schema.org so but I guess in this case of the example you've given we're all very happy with it. So, but I do want to think about that some more. Kim Hamilton Duffy: In light of what Anthony's going to add the kinds of terms that we are concepts that we will may want to add before we start thinking about terms. Kim Hamilton Duffy: Let me just check real fast. Both Kim Hamilton Duffy: Okay, I think we went through the queue. Kim Hamilton Duffy: Next thing I am eager to discuss is okay again with the framing this may not end up being in scope for VC Ed models, but it's something that's very critical to Kim Hamilton Duffy: To push along and I think there'll be the most momentum in this group is image integrity. So if I'm still sharing my screen which it looks like Kim Hamilton Duffy: Anthony described Kim Hamilton Duffy: This common notion of display properties field and Kim Hamilton Duffy: So I think that the way that he had described it was interesting to me in that it seemed to be adding flexibility to export a verifiable credential as say Kim Hamilton Duffy: Well, export as PDF XML image or a variety of different formats that you would need printing in the pilots that I've come up with Kim Hamilton Duffy: It does seem to make sense to have some general notion of, let's see, how do we say, okay, we don't necessarily want to expect that the image representations of a verifiable credential will be Kim Hamilton Duffy: A specific image encoding format like we can't necessarily expect it will be, you know, just a png or jpeg or even a png or jpeg Kim Hamilton Duffy: I think that it will end up making sense that we describe this as some sort of general disk. I'm calling it display instructions. In fact, instead of display. Let's see display properties. Kim Hamilton Duffy: And I want to propose that we start iterating on what that might look like in the context of this group. And so it won't necessarily just be images, corresponding to the credential itself, but it might be common. Kim Hamilton Duffy: Sort of alternative representations to allow things like say if you have a wallet with a bunch of verifiable credentials and you want you know Kim Hamilton Duffy: Either preview images or images, corresponding to the issue of the claim. So I think that Kim Hamilton Duffy: For all for all of these, it may make sense to align on a common set of metadata, so that we can at least you know implement our wallets, or our Kim Hamilton Duffy: Kind of group displays of these things in similar ways Anthony, can I call on you to add more to discuss sort of what you've seen in the DCI model around images and display parameters. Anthony Camilleri: Yes. Or so they actually update this issue with our latest because we've been iterating a phenomenon. Since then, our first of all the restaurant. Anthony Camilleri: So we've got we've essentially ought to to word design considerations that can lead us down this approach our number one. Anthony Camilleri: Member States are really attached to their display performance. So all over Europe. There's Anthony Camilleri: Laws that says what credit various types of credentials need to look like. And even though you say all the data is if the credential. If you don't display it in a very particular way. It's as good as useless. Anthony Camilleri: So it's something that we need to support Anthony Camilleri: And because of this, we also felt that, let's say the display parameters should be part of the assigned a lot because we want to, let's say, Give some assurance that it's being displayed in the correct format. Anthony Camilleri: But the second part of this is that at least for us. We always try and design for 30 years in the future. Anthony Camilleri: Which means we wanted to, let's say our express those display parameters wisdom, let's say the most future proof for old or text me Anthony Camilleri: Um, what that effectively means for us at the moment is that I this fine parameters is basically a block of HTML expressing how that particular credential should be viewed and then the HTML can be let's say a, you know, anything that's can parse HTML can be used to export the credential. Anthony Camilleri: So yeah, that's basically what there is to say. From our side. So I mean that legally this basically is a container for HTML. Kim Hamilton Duffy: Right. Let me check the queue real fast. Okay, so some questions I have about that. Are you saying that Kim Hamilton Duffy: That HTML is considered Kim Hamilton Duffy: Have you said, are you saying that there's no Kim Hamilton Duffy: No other display options on top of HTML that are required by etc. I at least Anthony Camilleri: Know, so for us, I need a it's all the parameters we have is a one HTML. And I think we have a separate one for the background image, but the HTML is any HTML, we will display basically that's how we've designed the system. Kim Hamilton Duffy: Right. I think my question is that, you know, in general, like at this layer that we're specifying do we need some sort of abstraction on top of that, even Kim Hamilton Duffy: Saying, like we it's I'm calling it display instructions, but it would be something like, you know, one option for it would be displayed. She email and then people could put their HTML in there. Another would be, say, a PDF file or link to a PDF file with content integrity hash. Kim Hamilton Duffy: You know, Kim Hamilton Duffy: As Anthony Camilleri: Well sorry for interrupting all I could say is, are we haven't started with our let's say open batch compatibility yet but Anthony Camilleri: One of the ideas we were playing with was using display properties also to, for example, put the open badge image. So this idea of saying, Listen, this is the different display properties for different formats and systems will be very attracted to us. Kim Hamilton Duffy: Okay, let me see if there's anyone else. Kim Hamilton Duffy: Yeah, in. Let's see, Phil. Yes. So, there Kim Hamilton Duffy: Here's, here's the thing. Kim Hamilton Duffy: There's the there's what might happen at different layers of the spec, basically. So I think what I'm describing may bridge several layers and it probably makes sense to Kim Hamilton Duffy: Tease it apart. But say, for example, I could see value in something at the Le AR rapper or, you know, sort of wallet layer that saying for for earlier wallet implemented is this is the this is where you go to Kim Hamilton Duffy: You know, find the the thumbnail, like you said, or maybe the image corresponding to the issuing entity or something like that, but that it would be a common set of metadata to Kim Hamilton Duffy: Let wallet implemented, you know, sort of display things in it. In a similar way, but that Kim Hamilton Duffy: You know if that's happening at the LCR wallet layer that doesn't necessarily have to be a common standard that other people use Kim Hamilton Duffy: But at the same time, it would be interesting. Also, to see what makes sense at the say universal wallet layer which is not necessarily edu specific but you know. So I think that there's there's several layers at which this Kim Hamilton Duffy: Common image or other metadata might be useful to add. It's just we need to start experimenting with what goes where. Kim Hamilton Duffy: And no one else on the queue for that. There's one other issue that I wanted to get Nate's opinion on specifically in anyone else. So there's this standard definitions of issuers Kim Hamilton Duffy: Issue number six. Kim Hamilton Duffy: One thing that has been useful Open Badges Kim Hamilton Duffy: Sort of definition of an issue or profile. Kim Hamilton Duffy: For a while, actually, was there. I'm not sure if this still remains. But for a while. The definition of issuer that was using Open Badges and the definition used in the verifiable credential data model was pretty much the same. And I think they both are Kim Hamilton Duffy: Sort of extending or they relate in some way to schema.org person, perhaps. Although now I'm not seeing that. So I could be wrong but in terms of wallet metadata. Kim Hamilton Duffy: And any other sort of metadata that you might expose with the with the credential. There's a very useful set of common terms here like well, especially a lot of the first ones that people end up wanting to display as part of wallet sorting and whatever kinds of displays. Kim Hamilton Duffy: I think that Kim Hamilton Duffy: In terms of, you know, if we define a common class or type for issuers Kim Hamilton Duffy: Really the open badge profile that's here is the main one. I've seen. So I've just been using it because it's convenient, but I wonder is it something that would make sense to like all there are, are there alternative types out there. Kim Hamilton Duffy: Is this something that would be convenient to standardize on if possible. So again, this would be something more the LCR rapper or something layer that that we're building as part of this effort, but let me see. Actually, I got to it from here. Kim Hamilton Duffy: But yeah, so are there are there any other issue or types that are interesting. Would there be any problems with aligning on say the Open Badges type definition of issue or profile. I'm curious if there are any thoughts on that. Nate Otto: Is Nate I added myself to the queue to respond about it. Sure. Types Nate Otto: Yeah, so I think Open Badges is a pretty simple and clear approach it. You know, it does use schema.org terms and within the context of Open Badges there. Nate Otto: Are a set of required terms that if you're going to use a profile as an issuer profile. You've got to present a contact email URL that represents yourself. Nate Otto: The you know the actual ID of the assuring a couple of the things Nate Otto: That has been a useful can zap because it does create consistency within some portion of the market. I don't think I mean we're not a standardizing something here, but I think Nate Otto: They're just inevitably will be some more variance, when we break out of the world of just Open Badges into, you know, a broader, more open concept of verifiable credentials used for Nate Otto: Education. One thing we want to enable, of course, is to allow decides to be used as issuer IDs and so expressing a. Did you know it comes down to. Nate Otto: What information is in the did document for that did when you resolve it and would it be possible to even put a schema.org slash name property into Nate Otto: The did document, maybe with some kids. And so we have to choose, you know, what are some did methods that we propose, what are the authentication mechanisms that we propose to connect the issuer profile revealed through the did document to the proof that is Nate Otto: So has signed a particular credential purporting to be by that assure Nate Otto: And we may not have the ability in some scenarios that work for those use cases to require like say these Open Badges properties to appear. Nate Otto: In those days, I think overall, that's fine, let's get to some useful examples, but I think the in the verifiable credentials data model spec. It does express the utility of being able to D reference an identifier for an issuer and that applies to both your eyes and HTTP scheme and dads. Nate Otto: And then being able to get some useful information back that allows you to authenticate whether the signature is real but also just learn more metadata about who the issuer expresses himself back Nate Otto: That's all I'll say on that for now is I think we've got to Nate Otto: Do some experimentation and also line up the other pieces of the tech stack that we want in the place. And one of the other efforts that we might want to take a look at is that trust over IP network, which Nate Otto: Has a whole bunch of work about a stack that enables issuers to be trusted on the hyper ledger Aries blockchain through various different verifiers and I'm not sure what capabilities that particular tech stack has but they are interested in education as well. Kim Hamilton Duffy: Right. Okay, that sounds great. Kim Hamilton Duffy: Um, let me check the key real fast. Okay Phil, Europe. Phil_Barker: And just what it said in the queue really here asked whether the other profiles for describing people who issue credentials credential engine will have minimum requirements for Phil_Barker: Organizations that are offering credentials and I'll take those out to not them to the GitHub issue for you. Kim Hamilton Duffy: Sorry about that, uh, too many windows open couldn't find it. But yes, that would be great would like to see that a lot. And, and we're at time. Thank you everyone for joining and we'll see you next week. Simone Ravaoli: Thank you. Thank you. Simone Ravaoli: Thank you. Simone Ravaoli: Good to see everyone Maarten Boender: Yeah, thanks. Interesting.
Received on Friday, 6 November 2020 23:58:37 UTC