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

<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 again.

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

<philbarker> I'd like to think that we can look at whether it's possible to fulfill those use cases with things that already exist.

<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 direction.

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

<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 it.

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

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

<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 emerged.

<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 queue.

<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 say.

<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 overlap.

<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 stuff.

<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 recipient.

<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 characteristics.

<kimhd> The other thing is that, long term, you don't want the learner to be blocked in to an issuer platform. d

<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 anything.

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