W3C home > Mailing lists > Public > public-credentials@w3.org > December 2020

[MINUTES] W3C CCG Verifiable Credentials for Education Task Force Call - 2020-11-16 12pm ET

From: W3C CCG Chairs <w3c.ccg@gmail.com>
Date: Mon, 07 Dec 2020 15:24:09 -0800 (PST)
Message-ID: <5fceb999.1c69fb81.d55cd.4d0d@mx.google.com>
Thanks to  for scribing this week! The minutes
for this week's CCG Verifiable Credentials for Education Task Force telecon are now available:


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-16

  1. Introductions and Reintroductions
  2. Working session
  Wayne Chang and Kim Hamilton Duffy and Heather Vescent
  Jaehoon Shim, Kim Hamilton Duffy, Jacksohne, Phil_Barker, Leonard 
  Rosenthal, Nate Otto, Kerri Lemoie, Marty Reed, Phil Long, Keith 
  Kowal, Dmitri Zagidulin, Adam Lemmon, David Ward, Jim Kelly, 
  Maarten Boender, Niaz Chowdhury, Robbie Jones, James Chartrand, 
  Sharon Leu, Stuart Freeman, Simone Ravaoli, Matt Lisle, Kostas 
  Karasavvas, Juan Caballero, Jerry Ma, Chris Winczewski, Jeanne 

Topic: Introductions and Reintroductions

<jaehoon_shim> Hello folks I'm Jay from LG CNS, I am the host of 
  SSI Meetup Korea. And also, I am the lead translator for the DID 
  1.0 and verifiable credentials 1.0, the official documents into 
  Korean and I am currently interested in VC-edu. From now on, I'll 
  be joining this call regularly. Thank you.
<kimhd> Fantastic in actually if you could eat my email should be 
  available through CCG list I were interested in starting up 
  staggered timezone meetings. So I realized this is probably very 
  inconvenient for you. So I'm curious to hear what what times 
  would work better than others. So great to have you.
<kimhd> Anyone else new to the call.
<kimhd> Okay, let's do some re-introductions real fast.
<kimhd> Jacksón, would you mind reintroducing yourself.
<jacksón> Hi there. Yeah, Jacksón here based out of Washington, 
  DC. CTO and co founder of Learning Economy foundation working to 
  advance 22nd century ready education infrastructures, working 
  with many of the folks on this call so happy to be here.

Topic: Working session

<kimhd> Let's start with issue number 17 because I think that 
  some of the discussions and it will address the other issues. So, 
  this one has to do with the scope of this draft spec and level of 
  granularity. Just for context on this, Anthony Camilleri gave us 
  a PR to talk about some specific use cases. We have some comments 
  in there.  Notice Phil's comment, which I think will address some 
  of my concerns. Specifically, I think the scenario is mentioned 
  in the spec do not seem to address completion of a course. This 
  is the part that we were discussing last week, which is the 
  concepts requiring definition in educational context. So again, 
  our goal with this document is trying to relate verifiable 
  credentials to existing edu standards and really demonstrate just 
  how to use them in verifiable credentials, but we want to ground 
  that in certain use cases and the ones that we've identified so 
  far describes in an activity a person's undertaken, learning 
  outcome or skill, outcome of a formal assessment process, and a 
  membership. So Phil gave a suggestion about let's pull it up 
<kimhd> The thing that I was struggling with is how to relate 
  some of the schema.org entities and I'll show the example that I 
  came up with.
<kimhd> He introduced this entity I was unaware of -- action and 
  it's subtypes. And I was curious to hear more about what we could 
  use this for so Phil, can you talk to your comment here.
<philbarker> Yeah, thank you. KIM VERY HAPPY TO. I mean, first of 
  all, just a little bit of context as to, you know why I made this 
  suggestion. And why I was talking about the things I was talking 
  about on the last call.
<philbarker> And that's that I'm very keen that we don't reinvent 
  anything or any way of doing something that can only be done.
<philbarker> So I think looking at use cases is definitely the 
  right place to start. But as soon as the use cases are 
<philbarker> I'd like to think that we can look at whether it's 
  possible to fulfill those use cases with things that already 
<philbarker> And only when we're should certain that we can't do 
  that, do we start thinking about new properties and new ways of 
  doing things. If you start trying to articulate solutions to use 
  cases, you might settle in a track that leads you to believe in 
  that you need to create something new because what you see that 
  exists doesn't match with the way that you thought about trying 
  to solve the use cases.
<philbarker> When you were articulating them. So I wanted to jump 
  in as soon as possible with, you know what I think is a way of 
  fulfilling the use cases that have been articulated
<philbarker> And that is using the schema.org Actions hierarchy 
  which allows you to talk about things that have been done and 
  that seemed to me to meet the requirements that were being 
  described by Anthony on the last call you and you know I 
  understand that he was very sketchy about what the precise 
  requirements are. And likewise, I have not gone into a great deal 
  of detail in these examples that I've given.
<philbarker> Kim, do you mind if I share my screen because I 
  actually did a little bit more this morning.
<kimhd> Sorry. Yes, please. That would be great.
<philbarker> Okay, so I realized that the example that I put into 
  the GitHub issue used the perform action to show somebody writing 
  a book that's because I was thinking about the example that we've 
  been talking to have, you know, performing	Beethoven's Ninth 
  Symphony or something like that.
<philbarker> If you're actually talking about a book, then the 
  more sensible action to use is the "write" action. To say that, 
  this action has happened where somebody wrote a book, and the 
  somebody who did the action is the agent, the person, and the 
  object that whole of the action. The thing that was done is the 
  book. So that means that as well as having the simple 
  relationship between a book and a person in that the person is 
  the author of the book. You can use this write action to say some 
  other things such as provide a description, say when it was done 
  and say, what language john wrote the book in.
<philbarker> There's a whole hierarchy of these actions. So there 
  are other possibilities that are available. So one of the things 
  we've spoken about is how to say that somebody has a skill.
<philbarker> Where you can say that Asha has achieved a skill 
  using the "achieve" action. And again, you can use the properties 
  of the achieve action to provide a full description of it to 
  provide it -- the date when he achieved it and so on, and also 
  point to tools that she used in achieving that skill.
<philbarker> Another simple example is "achieve" is achieving an 
  educational and occupational credential. So we can say that, you 
  know,	Lee has a particular credential and that credential. Here 
  you can build out the description of what that credential is but 
  you can also use the achieve action to provide more information 
  about how she achieved that.
<philbarker> And I've built out an example, based on some of the 
  things that came suggested over the weekend. For example, you can 
  say that Lee achieved that action using this educational 
  educational program as an instrument. It seems a little bit of a 
  strange term to use instrument.
<philbarker> But when you look at the definition of instrument in 
  schema.org it's the thing that helped somebody to do something so 
  that seemed to fit in that it was this program that helped me 
  achieve the credential that she has.
<philbarker> And again, you know, you could put things like dates 
  or fuller descriptions on to this "achieve" action. So that's 
  just briefly an outline.
<philbarker> You know, just to alert people that there is this 
  hierarchy of actions that can be used to provide the 
  contextualization and summaries of things that have been done, 
  which I think meets the sort of use cases that company was was 
  talking about. So I hope that we don't have to create too much 
  that's new here. The one thing that I think I will point out is 
  that in several of these, the relationship between the action and 
  the person is pointing in the opposite direction. It's, you know, 
  focused on the action and saying, who was the agent, who was it 
  who did that. Whereas I think for verifiable credentials. It's 
  often more natural to point in the other  way. So yeah, I'm not 
  sure what the, what the implications are when it comes to 
  creating instance data that can be wrapped up as a credential.
<philbarker> But I'm sure that there are some minimal solutions 
  to that, even if it's just creating a reverse property for for 
  agent. So I'm stop sharing these, and happy to take any questions 
  about this.
<kimhd> And tested can thank you for introducing that concept we 
  have a Q building up. I'm not sure if Nate or Leonard were first.
<kimhd> Leonard
<leonardr> Um, so I thought that was that was very good. And 
  then, conceptually, you know, certainly I think it's, it's the 
  right answer.
<leonardr> I think my biggest problem with it is to be honest, 
  the use of schema.org terminology, because it's not because 
  unlike its name. There are no schemas associated with it and I 
  worry about something.
<leonardr> You know, especially when we want to have @contexts in 
  our, in our credentials, you know, we need to refer to a specific 
  schema. We need to be able to verify that data.
<leonardr> To use something that's not schema, that's not 
  versioned as the background. So that's my biggest concern and I 
  will point out that there's another just as a another option.
<leonardr> The other standard that we could go with is XMP 
  (putting a link in the chat pod). So there is a similar concept 
  in XMP called the resource event.
<leonardr> And it works very similarly to the way you were 
  describing actions. So it'd be another possible option. So that's 
  just what I wanted to bring up
<philbarker> Yeah, there is a context file for schema.org and 
  there is an RDFS definition of schema.org. But there's no JSON 
  schema definition and you're right that it is somewhat 
  problematic with respect to versioning though there are specific 
  versions that are kept of the RDFS schema
<kimhd> Nate, you're up next.
<ottonomy> I actually feel, you touched on what I was going to 
  talk about right at the very end of of what you're talking about 
  is, is that the arrows are pointing kind of in the wrong 
  direction in your diagram and that in order to package this up as 
  a verifiable credential, we might need to introduce something 
  like a reverse relationship.
<ottonomy> That points to one of those actions from either the EO 
  credential or from the person that they have "have action" or 
  something like that. If that any useful metadata would be 
  included in there.
<ottonomy> Do you have any thoughts -- has that sort of thing 
  been done before is that an easy and recommended path to to go 
  down in order to be able to include data when about a person?
<philbarker> Some schema.org properties have reversed properties 
  that there tends to be a little bit of pushback because
<philbarker> You know, it's, it's not really in the model to try 
  and create a reverse property for every property. Other than 
  that, there's a bit of pushback against doubling the size of what 
  is already a fairly large vocabulary  by creating reverse 
  properties of everything.
<philbarker> But I think if we can show that there's a use case 
  that will require that the property goes in the opposite 
<philbarker> Then we can make that case I toyed with the idea of 
  "did" as the reverse property, you know this person "did" this 
  action. And then I realized that would probably run into problems 
  with the other meaning of did.
<kimhd> Kerri. Why don't you go ahead and then I'll do mine.
<kerri_lemoie> Sure just a couple of things. I think this is 
  really great to think about using existent scheme is I don't have 
  a lot of experience, experience about, with with, you know, using 
  schema.org though, in the past, I've always sort of had this 
  struggle with us trying to like shoehorn education into the 
  schemas that exists.
<kerri_lemoie> Because although I believe in using existing 
  existing schemas, we can you know share that I have that 
  standard. It always seems like a struggle when they were 
  triggered me thinking about this more was like instrument.
<kerri_lemoie> It's a fascinating one because I'm
<kerri_lemoie> There there's things that we use to achieve things 
  -- tools and but there's also skills. Right. So we have certain 
  skills and those contribute to the achievements, not necessarily 
  that we achieve those skills while achieving those achievements . 
  I always just sort of wish we could have like a
<kerri_lemoie> Sort of like when you have a drop down and someone 
  says to choose your industry and you can never choose education 
  technology. I kind of want that. I want a schema for us someday, 
  for this work.
<philbarker> I think you know it's a big part of my life 
  struggling with that problem.
<kerri_lemoie> Oh, I know.
Kim Hamilton Duffy: I'll go next. So actually, for context. I 
  want to share my screen. And this is an example of a bad idea, 
  but this is why I'm finding Phil's proposal, especially helpful. 
  This uses schema.org concepts and, you know, say I have a 
  verifiable credential that's expressing credentialSubject is 
  schema:Person hasCredential schema:EOCred and relate that	this 
  credential was awarded as a result of this program, which has 
  courses and course instances. I wanted to express things about 
  when they attended the program.
<kimhd> Does this mean that we have to reverse that problem. Then 
  also, what does that mean for all of the other concepts that we 
  might want to add. So I like Phil suggestion; action may be the 
  general concept that we want.
<kimhd> My only concern at this point was the navigation problem. 
  But I agree with you, if we can sort of make our structured case 
  to schema.org about what we want to represent maybe that will 
  have a chance of being adopted, and I think this partially 
  relates Kerri, to your point.
<kimhd> So I think I found myself wanting to rely on schema.org 
  as sort of the backbone of verifiable credentials, because it 
  does have really nice properties in that schema.org, if we can 
  make it work, seems like the best neutral candidate. 
<marty_reed> I wanted to share some of the work that we've done 
  in the North Dakota colab where we've actually implemented a 
  framework of the VC wrapping the CLR standard
<marty_reed> Okay, so this is this is the work kind of 
  collaboratively with North Dakota, PCG, IMS global. And so we're 
  using the the open source CLR wallet here, but we have modified 
<marty_reed> Randa team has modified it to then implement the VC 
  rapper as as part of this set of credentials. And so what you'll 
  see here is this is the verifiable credential wrapper.
<marty_reed> With the signature proof. The beauty of it is that 
  in the learner publisher. But the beauty of it is that within the 
  groups of assertions we can actually package, the evidence. And 
  so this is a base64 encoding of the PDF transcript, which is what 
  North Dakota needs to deliver to consumers upstream, but it's 
  completely encapsulated in the JSON. So there's no external 
  references within the set of credentials. Because we're still 
  working through how these individual assertions can also be 
  verifiable credentials, but for the, for the purposes of kind of 
  foundation that project. This is a the entire 66 assertions are 
  wrapped in a single	Verifiable credential.
<marty_reed> So I just wanted to share that as a use case that 
  we're implementing quit North Dakota.
<kimhd> That's great. And are you using I was assuming that 
  you're using the LER wrapper approach that I linked to here.
<kimhd> For wrapping the CLR in the VC.
<kimhd> Let's see if we have anyone else in the queue.
<kimhd> Okay Phil Long
<phil-t3> You can call me P1, if you like.
<phil-t3> That I like the schema.org were possible. The question 
  that it raises that is addressing Kerri's concern and I have it 
  as well as if there are certain uses of concepts that it is 
  ambiguous and the current as schema.org definitions so Phil 
  Barker mentioned using instrument earlier to represent a a course 
  or a program
<phil-t3> And while I get the idea is definable by virtue of the 
  way instrument is described in the schema.org
<phil-t3> It seems, at least in the educational context, very 
  different and has some meaning that we need to disambiguate so 
  that's where
<phil-t3> I like the idea. And the question is, how do you eat 
  where we find these things where a program is actually in your 
  example, Kim a complex set of of stacked ideas in it.
<phil-t3> How do we differentiate that or get that either 
  integrated into schema.org or deal with that problem in the 
  context of schema.org thanks
<kimhd> Well, if I can comment on that too. So I think I only 
  recently started looking into the LER mapping tool, but I think, 
  to your point, and possibly the Nate's point as well. Like, I 
  think that that mapping tool really helps us kind of not worry so 
  much so yes it is nice as schema.org is viewed as as neutral. But 
  I think like say if we like the issuer, the definition of issuer 
  that a certain framework provides. Then we have a means of 
  mapping that around to other frameworks and, you know, so I think 
  it's that will largely be informed by the kinds of use cases that 
  we encounter as well. Nate, was there anything you wanted to add 
  you had a good comment in zoom.
<ottonomy> Thanks, just to just to have the comment beyond the 
  audio channel. And what I'd like to see is one of the things that 
  I thought that this group could work towards sort of from its 
  forming, which is that interested parties who want to play a role 
  in the educational credentials space and want to use the 
  verifiable credentials data model.
<ottonomy> Can put together, sort of a wish list of what they 
  would choose from the verifiable credentials menu one or two 
  selections at each layer of the different	Verifiable credentials 
  sort of tech stack all the different pieces that go in there and 
  that includes the recipient identifier type, you know how we're 
  identifying the recipient, what the claim is, you know, what's 
  the assertion schema, what the defined achievement schema is, if 
  we can agree that this concept of a defined achievement that 
  someone has earned is a useful shared concept.
<ottonomy> For example, you might use choose Open Badges badges 
  class for that,and how the issuer is identified what the proof 
  type is, what the signing key type is that's associated with that 
  proof type, and what's the method of associating that key with 
  the particular	issuer in a somewhat trustworthy way and then of 
  course the larger and maybe harrier problem of how do you 
  associate the issuer identifier with the actual real world brick 
  and mortar institution that that attempts to describe if we can 
  get the use cases in the format of, I would like to do this use 
  case with this menu of selections for each of those layers then I 
  think we can start putting together pilot partnerships, where we 
  actually, you know, put the rubber on the road.
<kimhd> Yes, that's great, and Keith, you're up.
<keith_kowal> Yeah, I said, a question about the gentleman who 
  showed the North Dakota example of using the LER rapper.
<keith_kowal> I was just wondering if you could talk more about 
  what kind of wallet VC wallet, where you're using because I think 
  we'll continue to look at this concept, but I think it runs into 
  other problems in that, you know, in VC world we want to handle 
  things like selective disclosure and then there's all these 
  different methods for proof request response around the, you 
  know, challenges and response. And when you just wrap a third 
  party object like a CLR or an open badge in a VC those things 
  become very difficult to handle. So I was just wondering if they 
  could talk more about how how you're handling that VC.
<marty_reed> Right. So this is kind of the initial version of of 
  what we're presenting. So that's just a web presentation but our 
  goal is to actually individually wrap the assertions within that 
  that CLR package. Our challenge with with a lot of, you know, the 
  wallet architectures out there is that as many assertions that 
  occurred K-12 would be very, very difficult to individually 
  assert to a wallet. So we're trying to basically encapsulate an 
  entire single transaction wrapper of the CLR assertions and then 
  allow the user by signing them individually allow the user to 
  selectively disclose individual assertions. So that is in the 
  path forward.
<marty_reed> We're just not there yet.
<kimhd> So, I think. Let's see.
<kimhd> Well, okay. I'm trying to think of next steps for this. I 
  think I'm definitely interested in pursuing what schema.org 
  action would look like for what we're trying to represent with 
  these use cases. I think
<kimhd> We're, we're still working through getting the list of 
  use cases, we want to address for this document.
<kimhd> So I think that once we feel more confident about that it 
  would be good to come back to our options and revisit that.
<kimhd> Again, not all of the modeling, you know, not all of the 
  examples in the modeling VC-EDU credentials have to use the same 
  approach. I would like at least one that's a solid 
  schema.org-based example because it does seem nice and flexible 
  for time to certain things like certainly credential. Some of the 
  credential definitions and credential engine registry. 
<kimhd> But we'll, we'll keep working on that.
<kimhd> So I think that that other issue was sort of addressed by 
  this discussion.
<kimhd> One thing I wanted to get to this gets more into wallet 
  types of discussions. Let me make sure I pulled up the right one.
<kimhd> And for context, the two remaining issues. I have one was 
  image integrity. The other one was to kick off the discussion 
  around learner DID methods.
<kimhd> the problem of image integrity.
<kimhd> And this one's come up a fair amount in the past So I 
  wanted to sort of refine the requirements here because I realized 
  that we were kind of packing a lot of concerns into what we were 
  calling like display integrity because there's sort of two 
  different things. There's the scenario that human verifiers will 
  want to know that some image does represents, you know, the JSON 
  or whatever payload that God verified.
<kimhd> But then also there's a separate concept of  different 
  visualizations for different form factors like say in a wallet. 
  You might group credentials by an issuer's logo, you might have 
  preview images of the credential. And so there's there's those 
  considerations as well.
<kimhd> Our goal in this task force, I believe it will be 
  impossible to say there is one way to do this because I think 
  we're seeing-- every method that I call out below which I'll talk 
  about briefly is actually in use right now. And I think that 
  they're all valid ways to go about it. I think what would be 
  useful as a work item is giving a general framework to help 
  discover this information. And I think that that's largely useful 
  for things like like wallets.
<kimhd> And so some of this may move into the wallet spec. Some 
  of this may be more domain specific but let me just quickly talk 
  through the, the methods.
<kimhd> And actually I'm realizing already I left one out, which 
  is embedding embedding the VC in a PDF. So these methods are 
  describing VC oriented methods. So those would include embedding 
  an image or HTML directly. So the one that we just saw from the 
  North Dakota example is a base64 encoding of that document. 
  Similarly, that's a way that people use base 64 encoding. And so 
  the main thing is the idea being that	Verifiable credential is 
  signed, so therefore the image by being in the credential or any 
  other display instructions being in the credential are signed to. 
  So if you view that thing that you extracted from the credential. 
  You know that that's what the issuer intended.
<kimhd> The next approach that similar to that is usually using a 
  link or URL with a hash. So there's a work item in CCG that sort 
  of captures that called hash links. And the idea is that you're 
  not necessarily cluttering the VC with all of this stuff but but 
  you can get some kind of notion of yes, that's the thing that the 
  issuer meant to issue because you have the hash in there. So you 
  know if if the image has been tampered with.
<kimhd> The next category is templates. So this would be like, 
  for this kind of credential, these are the fields you expect to 
  be in it or
<kimhd> Within the credential it links to some kind of template 
  definite definition of, this is what one would expect to be in it 
  and then there may be renderings associated with that template. 
  Then the other one I wanted to call out because I think that I 
  saw that Nate had included in later versions of the Open Badges 
  validator, which I think is also very interesting so this is the 
  case where it's like a credential card view. So something that's 
  like not really the image of the credential.
<kimhd> But it's plucking out the key metadata for display to a 
  human verifier in a credential what we call critical card view. 
  And that's sort of like in an apple wallet, just the display of 
  certain fields. So, you know, per credential type, you could say 
  these are the fields that you want to just make sure that the 
  human verifier sees in addition to the image which maybe you're 
  worried could be tampered with.
<kimhd> So again, these are I should clarify these are verifiable 
  credential as container methods, and  yes, there are other 
  methods that sort of embed it all in another container. So like 
  PDFs and everything.
Kim Hamilton Duffy: So I started in this is more to kick off the 
  conversation. So I called out some design considerations. And I 
  think that the work involved with this will exist that at 
  multiple levels. None of them are changes to the verifiable 
  credentials spec. These are just more about: some may be in a 
  wallet, some may be sort of conventions among certain types of 
  credentials, and I included some what I call design inspirations. 
<kimhd> In wallet type scenarios. There's some notion that 
  sometimes designers like constraints. So the idea of, Okay, tell 
  me, tell me how to get my credential in your wallet, give me the 
  information I need to know to work with,
<kimhd> For example, if you're you're designing a pass that goes 
  into an apple wallet.
Kim Hamilton Duffy: They, there's all these conventions about how 
  you bundle it and how you, how you put it in there. And so it's, 
  some constraints, but  it's working on two levels. One is: this 
  is sort of the human experience that we want to deliver, and 
  here's how you get your, your content into that.
<kimhd> The other example, I thought, was fairly interesting was 
  the epub spec that is a w3c draft spec and it defines like you 
  know any well the pub format which could include things like
<kimhd> Certain metadata that will be expected by convention, 
  certain images and navigation. And so this is an example of 
  within a certain kind of use case these are our patterns that 
<kimhd> Some of which will probably live on outside of this 
  group, some we might want to take on here.
<kimhd> So, I wanted to kick off that discussion and sort of add 
  a little bit more structure to it as we go forward. It looks like 
  there are chats happening so let me see. First, if there is a 
<kimhd> Okay, there are comments that I have not caught up on
<leonardr> I mean I'll verbalize what I was typing if you want
<kimhd> Yes, please.
<leonardr> Yes, is Leonard,	I was just commenting that I mean 
  hash links are wonderful. And we use them for a number of things.
<leonardr> But you have to remember that hash links only ensure 
  that the data they point to is unchanged. They don't necessarily 
  ensure that what that data will present to you is unchanged. And 
  my point was simply that if if you have HTML with a script in it, 
  or we're just talking about SVG with a reference to an external 
  image that doesn't go along. There's no transitive property of 
  hash links. So those you know those remote images or external 
  images or the the functionality of the script isn't guaranteed 
  just because the data is unchanged. So that was all I wanted to 
<kimhd> You're talking about the
<kimhd> So say like so hash link. It's a URL with hash of the 
  content that it's pointing to, but certainly within the 
  continents pointing to, ou'd have to do extra work to make sure 
  the transitive links are also hashed is what you're saying.
<leonardr> Exactly. Yeah, exactly.
<leonardr> Or in the case of SVG. I was pointing out that there's 
  a reduced profile called SVG native which has no scripting or no 
  external references. So if you did like SVG native hash link to 
  that than that. Yes, absolutely. You know, it was a guaranteed 
  verifiable presentation.
<kimhd> Exactly, yeah.
<kimhd> Dimitri, you're on the queue.
<dmitriz> Thanks. I just wanted to. So I agree with what Leonard 
  said, I went to underscore what you mentioned a little bit 
  earlier about, I think best thing for us as a group is to focus 
  on a general purpose mechanism, basically a link and a content 
  type or a way to embed and then
<dmitriz> The group and ecosystem can explore
<dmitriz> What do we want to do for static visualizations. Do we 
  want to just link or embed a PNG. What do we want to do for 
  dynamic ones, meaning a template based. do we want to do SVG, do 
  we want to do PDF or anything else. Right.
<dmitriz> But as far as the data model, it'll still be the same 
  object. It's like, where's the content. There's the content type.
<kimhd> Yeah, I do think there's value in having some kind of 
  generalized notion for that. Just, it seems like a lot of people 
  are starting to stumble into that individually.
<kimhd> I think that this is a really large problem to solve, in 
  its entirety. So we just have to pick what's most blocking our 
  use cases here.
<kimhd> Overlays, Keith. Do you want to talk to that.
<keith_kowal> Yeah, I mean, I think, I think as wallet designers, 
  I think often we can we can actually determine how credentials 
  are viewed how VCs are viewed within wallets. If you know as long 
  as there's some standardization among the VCs, I think.
<keith_kowal> What comes very helpful is things like you your 
  overlays, because I think as soon as you start running into 
  things like localization and stuff like that.
<keith_kowal> Some of those problems become very difficult. So, I 
  mean, I think you I overlays is the direction we've gone to where 
  we thought back and help standardize how you view stuff, 
  especially across countries and stuff like that.
<kimhd> Yeah, go ahead.
<dmitriz> To interrupt you say a few words. What is the UI 
<keith_kowal> Basic, you know, metadata on top of the credential, 
  which kind of defines. I mean, if you look at Paul knows 
  architecture there. I mean, it's quite in depth.
<keith_kowal> I mean for our architecture is just more like
<keith_kowal> You know you can customize a tribute labels within 
  a standardized VC. You can you can do localization of attribute 
  labels, you can. I mean, it's more of the simple things. But 
  also, you know, you can choose like
<keith_kowal> You can show preferences, like when you display 
  this you should use this title as title 1, title 2, that kind of 
<kimhd> I think I've seen it use like in some Sovrin-based 
  implementations and specifically the blinding identity taxonomy, 
  which was kind of an interesting
<kimhd> Thing you know saying these fields are constitute PII. 
  And so depending on the use case that would be blinded.
<kimhd> Let's see. I don't think there's anyone else on the 
  queue. So let's keep going on that one to feel free to add your 
  comments in the issues. And then the last one I wanted to get to 
  today is learner did methods and I was glad to see that the DHS 
  SVIP program is also working on that.
<kimhd> Okay DID methods in edu use cases. This was proposed by 
  multiple people as a valuable thing that this group can work on
<kimhd> Explore which does can be useful and edu use cases in in 
  different scenarios, like say for the issuer and for the 
<kimhd> Marcus Sabadello pointed out that there was further work 
  on a did rubric document -- criteria for evaluating did methods 
  in the area of security and privacy.
<kimhd> So I want to encourage people to look at that, if you've 
  not seen it before. I also added some notes on the digital 
  credentials consortium design notes from when we were exploring 
  learner identity options. I think that this is possibly not super 
  well organized. But I think one thing I wanted to call out was 
  they've also observed in the SVIP program that DID methods that 
  you might want to use on the issuer side, things that represent 
  organizations might be different from what you want on the 
  learner side, where you might want more privacy preserving 
<kimhd> The other thing is that, long term, you don't want the 
  learner to be blocked in to an issuer platform. d
Kim Hamilton Duffy: So basically, a lot of this builds up towards 
  did:web might be a good method to use for issuers and that's when 
  I say good, that's also factoring what can you use right now as 
  opposed to something that's maybe more in development.
<kimhd> Versus learner identity, you know, you don't necessarily, 
  not, it's not necessarily the case that learners are maintaining 
  their own website that tey want to keep running. And, you know, 
  so there might be another set of options. And I wanted to orient 
  everyone to
<kimhd> Think maybe in another meeting, we could sort of go 
  through more structured presentation of what people are saying so 
  far about different did methods, but I wanted to call attention 
  to this. Let me see if there's any discussion.
<kimhd> Marcus has pointed to this DID rubric document and I've 
  included some links on design the design discussion notes from 
  the DCC around learner identity and it also includes our notes on 
  issuee identity. So I wanted to include all this information for 
  people to get familiar with. And I think we'll come back to this 
  in a future meeting to discuss in depth.
<keith_kowal> So Kim, what is the problem you're trying to 
  address because you know i know that there's like 70 DID methods 
  up there right now, but my own intuition is that will stabilize 
  over time and it will consolidate down to like a few there will 
  be a few DID methods are going to win over the rest so is the 
  concern that you just don't want to exclude did methods that you 
  feel don't meet certain parameters that are needed by education 
  credentials or
<kimhd> No, I think the problem that we've run into is that 
  implementors just don't know how to start evaluating them. So I 
  think that in the did rubric document it calls out, it starts to 
  lay out a way for evaluating them. I think in these these notes 
  down here, the DCC notes specifically our just our personal 
  interpretations, like what we're deciding at different phases of 
  development not meant to none of these are meant to exclude 
<kimhd> But one thing that is interesting is that some DIDs like 
  did peer are not necessarily even meant to serve as the subject 
  of a verifiable credential. So there are some things like that to 
  sort of reduce the search space.	Some just aren't meant for 
  educate longer-lived educational verifiable credentials. So I 
  think that people in this group are looking for a way to evaluate 
  did methods, not to come to consensus on necessarily come to 
  consensus on a set of did methods to use or to exclude
<kimhd> Let me see if there's any other comments.
<kimhd> Phil you're up, P1.
<phil-t3> First of all, to your comment Kim i agree with the 
  sentiment that you're expressing pardon me, I run across people 
  in the context of the LER projects, who are asking for guidance 
  of that filtering process of the DIDs.
<phil-t3> In terms of give me the subset, amongst which I should 
  choose among the 70 or plus that are out there. And so I think 
  that's exactly the right orientation to take this is it's not to 
  choose one, but it's at least to limit yhe breadth of choice for 
  the particular use case of representing an individual or 
  something else.
<phil-t3> The second point I wanted to make is in regard to the 
  transitive process problem of record of image representation. And 
  that is, I think, the way that Marty is approaching representing 
  with a base64 encoded image of his case of transcript that if 
  that was preceded by a quick examination of document as a to 
  determine if there was embedded URLs in it that that does two 
  things.  one, it can preserve the integrity of the of the 
  representation and two, it keeps it in a relatively slim package 
  within the JSON of the of the credential itself. So I just wanted 
  to point that out.
<kimhd> I am not seeing anyone else on the queue. I think we 
  could, and a few minutes early so thank you so much, everyone. 
  And as you've noticed, we're meeting weekly now and if there ever 
  any topics you want to add to the agenda, feel free to message me 
  in advance. I think next week we
<kimhd> Next week we might either do a more wallet focused 
  discussion or we might pull in some DCC specific you know some of 
  the DCC pilots that we're working on.  Thanks everyone.
Received on Monday, 7 December 2020 23:24:26 UTC

This archive was generated by hypermail 2.4.0 : Monday, 7 December 2020 23:24:27 UTC