Meeting minutes
Welcome And Agenda
Manu_Sporny: Hey folks, we will get started in about three minutes.
Manu_Sporny: All right, let's go ahead and get started. And some other people might trickle welcome to the recognized entities task force. this is a task force of the C verifiable credentials working group. this is August 25th, 2026. reminder that this group operates under the W3C code of conduct and intellectual property regime. which basically means you have to be a member of the group to participate and please pe treat people nicely and with respect and all that other good stuff. we have a fairly small agenda for today.
Manu_Sporny: Today there are a couple of discuss items that we need to discuss. April requests that Coyote raised but other than that I don't think much. so let's see if there are any agenda additions any updates or changes to the agenda that would like to All right. If not, anyone new to the call? Victor, I know you've introduced yourself elsewhere before. I don't know if you want to introduce yourself again to, this group.
Victor_Lu: Sure you're an independent journalist been just basically participating in the JSRD group but refer credential there's another community that's talking about credentials and…
Victor_Lu: I thought I'm here to listen a little
Manu_Sporny: Welcome to the call.
Manu_Sporny: You are catching us probably towards the end of our, major work on the specification. It's in pretty good shape. but, it's in good shape. So, if you read it, it's more or less what we intended. agenda for today. I think we can, start off by taking a look at, the poll requests. and then, go into some of the issues, but we're running pretty thin on issues as well, which is a good thing. we may want to talk a little bit about test suite.
Manu_Sporny: But other than that we've got fairly open agenda. So let's see let me get this a bit bigger. we do have one new poll request. So the digest SRRI property is not going to get resolved until W3CT pack which is at the end of October. So the chairs and staff have scheduled a meeting to discuss what happens to rsus digest multibase. there is a lively discussion happening over in the verifiable credential working group on an issue there but I don't think we can't resolve this until that's done. GS1 continues to work on aligning the appendix stuff.
Support For Arbitrary Entity Registry Lists
Manu_Sporny: But we do have a new PR and that is this one that Coyote raised to address issue 71 by adding a support for arbitrary entity registry list. So let's take a look at that. Looks like we've already got two reviews u plus ones there. And I have not had a chance to take a look at this yet. so I'm just going to give some time for people to read
Manu_Sporny: So this looks like it's duplicative of something that's in the spec. So a weird merge. I think this is really the majority of the PR which is defining an external entity list. and saying it should conform to a valid entity registry specification and that URL establishes the root of trust and that if that list is a recognized entity credential you need to use this spec. Hey Coyote, we were just discussing your PR that you raised and…
Manu_Sporny: I have gone through it to review it. I don't know if you want to add anything.
Kayode_Ezike: Okay. Yeah.
Kayode_Ezike: I had just left a comment on it just now. So there was a comment that Dave made about whites space in there. strangely when I tried to copy exactly what's for that paragraph. I think it's the first paragraph on the top. It didn't seem to detect a difference. So, I don't know if we care that there's this awkward diff here. But other than that, if it's good with people, then it's good with me.
Manu_Sporny: And I don't think we care now that you explained it. Yeah, it doesn't matter. It's just deleting the exact same content and readding it, which is, weird, but fine.
Ted_Thibodeau_Jr: that may be introducing the reality of the line end characters.
Manu_Sporny: Yeah. Yeah.
Ted_Thibodeau_Jr: They are invisible until they're a problem.
Manu_Sporny: So, when did this go in? Three days ago, which means Coyote, yours went in before this fix went in. so you could try rebasing it,…
Kayode_Ezike: Right. Right.
Kayode_Ezike: Okay.
Manu_Sporny: but I don't think you might try rebasing it. That's the only thing I can think of.
Kayode_Ezike: Okay. Yeah,…
Kayode_Ezike: I can do that while we're on the call.
Manu_Sporny: Okay. …
Manu_Sporny: I guess the big question is, does this address 71? feels a bit off to it. something feels a bit off, Coyote, but maybe I'm not something.
External Entity Registry Lists
Kayode_Ezike: Mhm. yeah. So, I can see it potentially being confused. So, this is I think what we agreed on, but I can see it potentially being tricky. I guess the assumption here is that every external list is going to basically have the similar format. You're going to need a URL that points to a list of some sort and we're going to use this sort of generic name to get the information for it and whoever understands this then they're able to know what to do for this particular type of registry spec. so yeah, as I was writing it, I also kind of felt like something maybe was missing, but I think we had mentioned This is the name that we wanted to use and text list and that we wanted to basically have that be the anchor into other specifications.
Add support for arbitrary external entity registry lists by kezike · Pull Request #119 · w3c/vc-recognized-entities · GitHub
Kayode_Ezike: I wonder if there's more that can be added here or in a future in another PR. But, yeah, this was roughly what I picked up from that discussion. Yeah.
Manu_Sporny: the thing I think you did the right thing, Coyote. I don't know if I'm trying to understand why we said what we did in determined this is the only thing we need to do. cuz so the thing that is bump jumping into my mind is we're like okay we have this general mechanism why can't we just apply to X50 or9 certificate authority lists and the Etsy trust lists. So let's just delete those because we have a generalized solution now. And so…
Ted_Thibodeau_Jr: Mhm.
Manu_Sporny: how would you use that?
Manu_Sporny: you would still point to the URL like you would in X509 and that does establish the root of trust and you have to know something about it which is true for both X59 or Etsy, the thing that you get when you fetch it, you kind of have to know about the format and the meaning and what the root of trust, is capable of doing. there's just a lot of outofband information in there, But that is true of X59 certificate authority list and Etsy trust list. there's a ton out of stuff that you have to know.
Manu_Sporny: You go and you read their specifications and that sort of thing. Manu Sporny:
Kayode_Ezike: Yeah. …
Kayode_Ezike: And I guess there's also the question of I guess not to jump there's no cube but cuz if I recall correctly what I did here it's not like we're maintaining a registry I know that's a hacky term now but a registry of values that cuz we're just using this type name and then we're using the actual URL I believe is what we come on here. So there's no other additional metadata that's saying the type of schema that it is which means that we have to get off the information we want to get out of the URL field.
Kayode_Ezike: which is that enough or is could that break down if somebody decides to use a URL that doesn't in any way give point to the fact that it's related to a particular specification unless there's another field that I'm missing here but that's the other thing. Yeah, go ahead.
Manu_Sporny: Yeah. I mean looking at the example in the spec. So this is a recognized entity credential. it identifies this is effectively the European Commission and today it's recognized in this list of the lists XML file which you'd have to have special knowledge about and we mark it as an Etsy trust services list so that's the thing that tells you the typing information here but this is kind of not very useful right I mean I would argue that just knowing the type doesn't tell you anything about how to process this
Manu_Sporny: you would have to know the type and then you would have to know an enormous amount out of band information to actually parse this thing and make sense of it. And so I'd argue this type isn't really doing us any good and we might as well just put external trust list and you either know how to process this file or you don't and that's no different than what we have in the spec today. So there's an argument here that we could just remove the Etsy trust service list and the X509 certificate types like we don't need them anymore. And then we can just talk about this supports Etsy trust list and this supports X509 certificate authority lists. and leave it at that.
Manu_Sporny: I don't have a strong opinion one way or…
Manu_Sporny: another whether that's better, or worse.
Kayode_Ezike: Yeah, I guess I hear I think the one thing that I wonder is so do we expect for verifiers or…
Kayode_Ezike: grant to consumers generally to basically for all the different specs that they support? It seems to me that what they would have to do is to the fetch the file and determine what type of list this is without having any other information in the credential itself as to which spec is referring to. So is that the general expectation is that they'd have to figure out hopefully there's something in this list that differentiates it when they fetch so that they know which type they're deal they're dealing currently with the design we have, there's no way for them to know just from this list here or this credential here.
Manu_Sporny: It depends on what you mean If you mean by external entity list yes there's no way for them know Etsy trust lists and X509 certificate authority lists there are types for that and that's how they would know but frankly they could fetch the file and sniff the file and understand immediately whether it's an Etsy trust list or an X59 certificate authority list and they have to know the format in order to process it right so I don't think this is really buying these types
Manu_Sporny: Etsy trust list and X509 certificate authority list are not really buying them much of anything. The reason they're in here is because we had, folks that felt very strongly about Etsy trust lists being mentioned in the specification. And the same thing with X59 certificate authority lists. Are people actually going to use those features of the specification? I highly doubt and if they do want to use it, they could just use external entity list. I don't think anything's lost there.
Kayode_Ezike: Guess the last thing I'll say that
Manu_Sporny: But I'm concerned about, what I mean, David Chadwick wanted the Etsy trust list stuff in here and then I as a group decided if we're putting Etsy trust lists in here as a special case, then we might as well put X509's to good authority list in here as a special case.
Manu_Sporny: Go ahead, Kyle.
Kayode_Ezike: is assuming that nobody is using currently the Etsy or the X509 ones then I would be comfortable removing them and sort of allowing external entity lists subsume those and then doing two things one letting people know that you can still support these two different types we can call out maybe a few others and then also calling out the fact that they would need to which maybe is obvious but maybe it could be good to give guidance to say that they would need to fetch the list to determine which basically to dispatch on which type of list that they're processing so that they know how to proceed with the verification. So those are the two things that I would propose for changes to this PR. Go ahead.
Manu_Sporny: plus one. I think that sounds good to me. Coyote, sorry about the having to do another rev on this, but I don't know…
Kayode_Ezike: worries.
Manu_Sporny: if we really were thinking about what gets replaced if we get this in there. So that's good and that's cleaner and that'll work for just any type of external list, and…
Kayode_Ezike: Oops.
Manu_Sporny: yeah, plus one. I think coyote, we need to have examples of this is exactly how you would refer to an X509 certificate list an Etsy trust lists and we should have non-normative links to them and examples and plus all that stuff. Okay. Thank you Coyote for doing the revision. That is PR19. All right. and that's all of our PRs for this week.
Manu_Sporny: Looking at the issues list, we have just looking at ready for PRs, we have 14 issues that are ready for which means that anyone, on here could jump in and start writing PRs. this one actually exists for this one. It's just blocked. so we have 14 that, need PRs. and hopefully we can get some PRs on those, in the next couple of weeks. Thank you very much, Coyote for, working on, that PR. I am very busy with the render method specification. That's where all my attention's going in.
Manu_Sporny: So, you're probably not going to see PRs from me for this spec for a couple of weeks. we do have a plan on the internationalization stuff, but we need to sort some stuff out in BC data model before that's on around language value objects, which we talked about, last time. So, that' needs to be done. So, let's look at our discuss issues. let's talk about this one. so we talk about who is service and path service in the specification. some of us had an action to discuss this with the did working group.
WhoisService And PathService Discussion
Normative references to WhoisService and PathService · Issue #117 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: And I think the did working group is suggesting that we have three potential options. who is service another one is you to use linked VPs and the other one is to talk about the path approach. There are no normative references for these at this moment. and they're suggesting that we evaluate each one of these. that said that there's nothing for us to point to and I don't think that there's going to be anything for us to point to.
Manu_Sporny: in the next little bit. I think Marcus said, there is a version 10 for the linked VP Pierre Antoine said that we could normatively reference that. and they're tracking the issue. I think one of the concerns I had is this is I don't know we would have to take a look at this, so that's kind of where we are and it's not clear. I think that Steven Kern said he'd much rather look at a path-based approach rather than the linked VP uses a new service type. I don't think that is who is it's something else.
Manu_Sporny: Where is this? Yeah, you have to have a linked verifiable presentation service in your did cume and then that'll take you to a VP that will potentially contain the recognized entity. So, I don't know, Steve, if you have any strong feelings one way or another, on this item. And so I think Stephen was saying Marcus was saying this is consistent with the web VH and…
Steve Capell: I don't know. consistency with web VH or whatever might find its way into a W3C did spec.
Manu_Sporny: Stephen was saying it's not I think and…
Steve Capell: …
Manu_Sporny: that he would like to take a different approach.
Manu_Sporny: But I don't know any of the details and it would be much better to have Stephen, on a call to walk through that and who knows what's going to end up in dead method specs, Because we don't even have an active working group for that yet, which leaves this group in a bit of a weird place,… steve capell:
Steve Capell: if you don't which is I believe
Manu_Sporny: Because we're probably going to be in CR and wreck before any of this other stuff is settled. So not the end. we got our feedback which is we for you unless you use link VP and I believe Stephen was like that is not what WebVH is using. but I might be misremembering.
Manu_Sporny: If Steven comes back and says yes this is exactly what WebVH is using then we can do that. the concern there is that if other DID methods don't use this…
Manu_Sporny: then we're not in a good state right Stephen wanted a mechanism that was unified across did methods not just one in this Yeah.
Steve Capell: Yeah. …
Steve Capell: whatever we do, we're guessing what will come in a future. W3C did method spec. then we just have to make a best guess, don't we? I'm leaning towards whatever Steven Curran says,…
Steve Capell: but not for any strong reason, I have to say.
Manu_Sporny: Yeah, I mean I tend to lean towards whatever Stephen wants to do for whatever the solution is that works across multiple DI methods,…
Steve Capell: Stand I don't know.
Manu_Sporny: that's what I think the right right thing to guess and then that'll kind of force multiple did methods to kind of work together and adopt that path forward. we don't have to guess we can make the entire algorithm non-normative and say it's premature but you should pick whatever you think the right thing to do at that moment in time is and then adjust accordingly as the market matures.
Manu_Sporny: That's a totally per perfectly fine thing to say in a spec people get cranky when you do stuff like that…
Steve Capell: Yeah. Yes.
Manu_Sporny: but if it is not the right time to standardize it then we shouldn't standardize it. So that's another option, Steve. it's don't guess because when we guess it will force the market to implement that thing. And if it's not the ideal good thing,…
Manu_Sporny: then we've just, made a bunch of people implement something that's not good.
Steve Capell: Stop.
Manu_Sporny: This is not bad, it is a VP. You get a recognized entity credential. Problem solved.
Manu_Sporny: But this spec is not broadly deployed across multiple DID methods and…
Manu_Sporny: likely I don't think it's actually going to be implemented across multiple DID methods. whereas the path service might get much more adoption because it's simpler. Okay, that's perfectly fine.
Steve Capell: Right. …
Steve Capell: I have to look at an example of each. I haven't informed myself well enough. that's perfectly,…
Manu_Sporny: I mean, so we got an answer back. They're tracking it. We don't have a normative dependency to point to other than linked VP. which would be, fine.
Steve Capell: fine. Why does Steven not linked VP?
Manu_Sporny: And we could warn people we may be transitioning to something more generalized in the future as an example. And I don't Yeah.
Steve Capell: Because it's not the same as diff webph basically.
Manu_Sporny: Yeah. I don't know.
Steve Capell: I think
Manu_Sporny: Let me see. I don't know if this is the latest thing.
Manu_Sporny: Let's see. Yeah. I mean, it's pathbased one. So that's what's different. It does return back a verifiable presentation, but the way you get to it is you get through a path. You don't get to it through the Using a standard did service that follows the link VP specification. It's just you don't get through slash that's the delta I think.
Steve Capell: with the other approach…
Steve Capell: but with you you do get it through who is I mean there…
Manu_Sporny: Yeah. Yeah.
Steve Capell: here's the name of the thing reveals its purpose right I mean And…
Manu_Sporny: Yeah. Yeah. So the delta is pretty small. So, what we could do is we could just restate what's in the WebVH spec to make it align perfectly with WebVH. And I do expect that the thing that I'm not sure is if other specs are going to do the linked VP thing, but that's just speculation. maybe they do. And then what happens when you have multiple of these?
Steve Capell: then what happens?
Manu_Sporny: Do you go and fetch all of them and what happens when the links are it supports IP IPFS?
Manu_Sporny: Do you have to implement that it okay so I think there's enough here for us to say something normatively.
Steve Capell: I think we just need to determine that this is the normal balance.
Manu_Sporny: We just need to determine if this is the normative thing we want to say. So we can basically say this is…
Steve Capell: So we can basically say this is…
Manu_Sporny: how you get to it.
Steve Capell: how you
Manu_Sporny: You go and you fetch slash who is and you use the link VP spec to get the presentation one or more presentations.
Manu_Sporny: And that's how you do discovery. And we can normatively link to the link VP spec and have a stable reference per W3C. And Pier Antoine said that he can look into it and he's pretty sure we'll be fine there. And if that's the case, then the only new information we're adding is …
Manu_Sporny: how you get to it, which is through slash who is. And while we can't link to the webv spec normatively, we'll just let Steven current know that this is what we're doing. So whatever you do in the future, please make sure that these things line up. and he'll either say yes, I think I can do that or no, you've got a problem. Right?
Manu_Sporny: How about this?
Steve Capell: And when you say we can't link to web VH spec.
Steve Capell: Is that a W3 policy that you can't link to nonW3C specs?
Manu_Sporny: You can't link to things that don't have final versions and is WebVH a version 10? Is there static version of it?
Ted_Thibodeau_Jr: It doesn't have to be a final version. It can be one level of maturity behind whatever that is.
Manu_Sporny: But I don't know what that is at diff, right, Ted? yep.
Ted_Thibodeau_Jr: Yeah. just for clarity.
Manu_Sporny: Yep. Yeah. Yeah. Yeah. Ted is right.
Steve Capell: Hey, that's fine. Okay.
Manu_Sporny: This spec is a version 10. It's got a static thing. The expectation is that the spec's not going to change, Steve. That's what we need to be able to link to anything elsewhere.
Manu_Sporny: you need to make sure that that thing that you link to is not going to change because you're building another spec on top of it. I don't know and this is a diff ratified specification and the presumption is it's under the W3C IP and copyright regime. though it doesn't have anything about patent policy or copyright or anything in it. I don't know If it did exist for WebVH, Steve, we would just link to it directly. but I believe Stephen was on that call and he was at a loss as to what to do as so let me try this just to move this issue forward.
Steve Capell: Wow.
Manu_Sporny: This on the 2026 0825 telecon. So raise a PR that specifies that the way you do discovery is effect is the same way does discovery which is dreference who is path using the linked BP specification V1.0.0
Manu_Sporny: O from diff and then process the resulting presentations according to the algorithm in the recognized entities specification. Does that seem okay to folks?
Steve Capell: Thanks to me anyway.
Manu_Sporny: Any objections if we were to try and do something like that from anyone else in the group? All right.
Manu_Sporny: Then I will mark this as ready for PR. Does not need discussion anymore. and then we'll go from there. All that's that item. all right. Let's take a look at this. And then DigSR we can't talk about this future work. Kevin is not on the call today. Any updates for the UNVD example stuff, Steve, that you wanted to share?
Steve Capell: I'm leaving that to John. So, I don't have any now.
Manu_Sporny: All right.
Manu_Sporny: And then okay,…
Steve Capell: I'll encourage him to get him done and attend the next call.
Manu_Sporny: that sounds good. we did have a discussion about it.
Guidance On Data URLs For Validation
Manu_Sporny: I think we agreed to the first thing and said the second thing was problematic. it's linked in the issue. And then the final issue that we have is provide guidance related data URLs when used with output validation other objects. I was supposed to get back to GS1 on this and I have not done that yet. So that still needs to be done. Paul from GS1 did send along a GS prefix license example.
Steve Capell: God.
Manu_Sporny: And these are helpful and useful not loading. One second. Let me see if I can get this to all a little difficult to see, but let me see if I can share my screen.
Ted_Thibodeau_Jr: Yeah, it's X.
Manu_Sporny: And apologies if this is hard to read. Can folks see that? let me see. Of course, scrolling does not I was trying to zoom scroll, but it's not working. So, this is a GS1 prefix credential, and it's the JSON schema. wait a second. No, this is the prefix credential.
Manu_Sporny: And the good news here is that we can include the vast majority of this stuff in the recognized entity. and the prefix JSON here, let's see, is this one I think. Let me open this So, this is the prefix JSON schema. And this is the thing that would go in the data the important part being right here the license value right. then let me find the ID key credential. is this thing and just note that it's got two zeros for the eight instead of I think one zero or whatever.
Manu_Sporny: But pretty straightforward stuff like this is we B64 encode most of this and then it would go directly in the credential I think is basically what we'd have to show an example of. So that's on me to create that and show it. or anyone else can do that. we should I guess show what both look like using a data URL versus ajson value. But that's kind of that item there. And that is our entire discuss issues list. we said last week that we'd talk a bit about test suite.
Manu_Sporny: This, Coyote, you said, "Do we have an issue to track that?" But I did not see when that came in,…
<Kayode_Ezike> Do we have an issue to track that?
Kayode_Ezike: Sorry, I may have missed it. I was so the prefix credential you said someone has to put up a PR to his own example or something. Is there an issue?
Manu_Sporny: issue 118.
Kayode_Ezike: Okay, great. Thanks.
Provide guidance related to data URLs when used with outputValidation and other object types · Issue #118 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: Sorry, should have put that in there. one second. Let me do this. copy and address. Yeah. So for issue 118, someone needs to create an example of a recognized entity credential for the entire GS1 chain using the example files that they provided. that's what we're waiting on there. And we need to do a data URL version and at JSON value version.
Test Suite Discussion
Manu_Sporny: just to kind of look at both credentials to see if we have any feelings about one way or the other of doing it. okay, so that's 118. Next up is test suite. And for the test suite, this is something we have not talked about before. we do need a test suite for the recognized entity specification. so this is just kind of like to discuss that what it could look like.
Manu_Sporny: One fairly complex way that we could do this is to have implementers create a VCOM workflow that takes in a specification for example the UNCCE credentials or the GS1 credentials.
Test Suite
Manu_Sporny: So you get in a G10 product credential or a valid commercial invoice and your workflow will work through either the recognized entities we have recognized stand in the issuer and the credential or it'll do discovery and then the workflow will only succeed meaning it issues a success credential or something like that if the recognized entity chain is valid. Right?
Manu_Sporny: So the way you test that endpoint is you send it a good credential and a bad one and then that endpoint can tell you yes it worked or no it didn't. and you can basically send an arbitrary number of good and bad credentials and you do that enough times and you can verify that the validation software running in the workflow is doing the right series of checks. So that is one way that we can really test the specification. I can imagine that it's to do that. It's going to be hard to find implementers that have the time to set up a validation flow in a workflow to do that.
Manu_Sporny: I think Dish Bazaar would certainly do that but until we have another organization that's willing to do that I don't think that would be a good path forward. the other approach is to just say do people support the data model and do they swear that they are going to implement this correctly that al that can also be done at W3C. it's not necessarily a good way to do specs because people can lie or they can want to do that but they actually don't end up implementing it correctly and you don't know until it's out in the field and wrong and you've got all kinds of interoperability issues. So those are the two major ways I can see of testing this thing.
Manu_Sporny: Any other thoughts on our ideas about how we test this? If not, of those two approaches, any thoughts or ideas on what we should try and do? Go ahead, K.
Kayode_Ezike: I'm just thinking out loud. I wonder if there's a version of the first solution that is lighter weight that is just I guess I'm thinking a little bit of what was done for plugfest for example was they use validation tool or whatever to check that it fits the schema whatever but I'm wondering if there's something like an endpoint that just returns an example of what they would retrieve even though again this is something that anyone can just generate
Kayode_Ezike: but a lighter weight version than actually performing verification on the credential or anything of that sort. But just that more so just validates the schema of the credential. It's just a thought. Yeah.
Manu_Sporny: The only challenge with that coyote is we have algorithm sections that are supposed to be run that do the discovery and we need multiple independent implementations of those. So the algorithms in the spec are normative. just as a reminder, we have credential based discovery right although I guess we don't really have any maybe we decided explicitly to not put normative language in there which could be a bit Correct. Yeah.
Kayode_Ezike: I guess to that point, don't we usually say with those algorithms that it's more about the out making sure you get the same output as that algorithm than actually executing the exact algorithm that's light laid out.
Manu_Sporny: I mean the important output of the algorithm is like you either get a yes we know…
Manu_Sporny: who we recognize this issuer or no we do not right but it happens during a ver a business rules validation process and the easiest way to do that is a workflow
Kayode_Ezike: Okay.
Manu_Sporny: I'm saying workflows are you have to implement VCOM right but really it's the VCOM thing is basically the way the workflow works is the workflow asks for a product credential with a G10 on it and the test suite driver post the GS1 credential and then the endpoint workflow basically tells you success or failure.
Manu_Sporny: It's just a true false yes this was good you got through the workflow or no rejected you didn't get through the workflow and the test suite is basically going to probe to make sure that you say yes you get through the workflow appropriately u meaning you get through the workflow for something that is a recognized issuer and then you don't for something that's not recognized. So it's a really easy endpoint. literally it's just you do a presentation and you get back whether or not you succeeded.
Manu_Sporny: So it's a single API call. We could create another type of API for it, but we have one already. go ahead, Coyote.
Kayode_Ezike: So I guess the compliance that we're testing for is the flow you described is like you're testing that the holder is able to present sorry might be crossing wires here…
Kayode_Ezike: so you're expecting that different issuers would stand up their own issuers coordinators that can or services that are able to or workflow services rather that have these workflows set up or would it be because at the end of the day I guess all of these trying to think through this a little bit but yeah is your expectation in the first solution that you proposed is that each issuer would design a workflow
Kayode_Ezike: that essentially is the same. You can even give the exact template or workflow design for it and they would just have to have the appropriate software to deploy that or it would be more so we provide the template for the workflow as a whole and they provide the entity credential that would go in that template. Is that what you were thinking?
Manu_Sporny: So this isn't about issuers,…
Manu_Sporny: it's about verifiers, so you just set up a verifier coordinator. that's it. And in fact, this might be super simple, right? Meaning you just set up a verifier coordinator. You don't even have to implement VCOM workflows. You just have to implement a couple of HTTP endpoints. So if you really dislike VCOM or you don't want to implement it, or any of that stuff, like the HTTP call is literally, a host which then returns back you need to present a GS1 G10 credential to me and then you present that G10 credential and then the response back is like thumbs up, you made
Kayode_Ezike: Right, right, right.
Manu_Sporny: or HTTP error code and it's two HTTP posts that the verifiers need to implement and if you have a VCOM thing in a workflow and you can do all of this the right way or if you have something else the only thing that matters is that you took in and you read the credential properly you got all the recognized in things properly and then you executed and looked those entities up and you checked to make sure that the issuer was somewhere in somebody's list.
Manu_Sporny: But all that happens behind the scenes. The only thing that you as the V verifier coordinator return is like it worked or no it didn't.
Kayode_Ezike: …
Kayode_Ezike: since in that case I think then that's fair at the very least if we can require that folks implement those two endpoints and we can even say that it' even VPR can be deco or something else as far as the query language goes but if that doesn't complicate things but if we feel that verifiers wouldn't want to use DPR for whatever reason we could potentially add support for returning different types queries too. But I don't think that that's at the end of the day if you are implementing those are I think tables take things to support anyway as a verifier. So yeah. This one.
Manu_Sporny: Plus one, I agree with that. I don't think we need to put in DAL support unless someone's like, I really want DAL support in there. And at that point, it's like, okay, please implement it, here's the test server, whatever. yeah. it's up to them, it's up to the verifier. So, whatever the verifier, it's really the driver, the thing's testing so We're testing verifiers. So, anyone that wants to implement this spec has to implement a verifier. that does validation on, the recognized entity.
Manu_Sporny: The task force that's writing the test suite is writing a driver and the driver is basically going to post known good and bad verifiable credentials that have recognized entity information in it. We're going to do some for credentialbased discovery and other ones for identifier based discovery. But as the driver of the test suite, all we're going to do is we're just going to post good credentials and bad credentials. And then we're going to see what the verifiers do, if they give us back a success or an error code, and that's it. we don't have to get any fancier than that. And I think that probably gets us to fully
Manu_Sporny: I think that gets us to like something that just works. go ahead,…
Manu_Sporny: Kylie. No,…
Kayode_Ezike: When we say good and…
Kayode_Ezike: bad, we're really just saying that we have determined that this issuer is indeed recognized or are there other outcomes that we'd have to test for as well?
Manu_Sporny: we have to have a positive negative test, we have to have So we tell all the verifiers these are the roots of trust that you need to configure your software for that stuff and…
Manu_Sporny: then we're going to send something that will chain up to that root of trust and we're going to send something else that will not does not right and so we expect the first one to succeed and we expect the second one to fail with an error code as an example like that's I think the minimum viable test suite
Kayode_Ezike: Okay. f***.
Kayode_Ezike: Right. That's kind of…
Manu_Sporny: and then whether or…
Manu_Sporny: not they support, all the properties in here. I'm looking atation.
Kayode_Ezike: what I was wondering if you want to get that deep into those leads. Right.
Manu_Sporny: They have to, output validation needs to be run so we'd want to test that test the output validation we'd want to maybe do something that had test the validity dates so one of the tests could be like here's a credential that has an issue that you should know here's a credential that has an issuer that you should not know and you should fail this
Manu_Sporny: a recognized entity with a validation schema that is good and it should pass. Here's one with output validation that should fail. here's one that is within a good date range. Here's one that is outside the date range. I'm looking through the spec of the tests those are the major tests I think have. So, we only have a handful of these that we need to test. And I think that's largely it.
Kayode_Ezike: And yeah, let's create an issue for if we don't have one already then.
Manu_Sporny: Yeah. Let me new issue.
Manu_Sporny: Create test suite for you see recognized entities right. Let me get this in a topic. All right. And then what did we just say we were going to do? the group
Manu_Sporny: test driver that contains a set of CDs. is that how we do sub? No, that's not
Manu_Sporny: Got to be kidding me.
Create test suite for VC Recognized Entities · Issue #120 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: How do you do nested lists? Thought it was double.
Kayode_Ezike: I think you just do two spaces or something after.
Ted_Thibodeau_Jr: Can't see…
Ted_Thibodeau_Jr: what you're typing. Can't tell you.
Kayode_Ezike: Yeah, that's
Manu_Sporny: Sorry. I thought I was sharing. My bad. Never mind. I got it. Okay. Isn't this…
Manu_Sporny: how you do? One,…
Ted_Thibodeau_Jr: Need one more space on the second one.
Ted_Thibodeau_Jr: Yep. It's easier to see…
Manu_Sporny: two. Yeah. Thank you. gota All right.
Ted_Thibodeau_Jr: if you have a mono space for those text entry boxes.
Manu_Sporny: Let's Create a test driver that contains a set of VCs.
Manu_Sporny: Unknown. Known issuer. with valid What is this thing called? output validation. You see that has an output validation test that passes. You see that
Manu_Sporny: fails. And then add verifier coordinators implementers to the test suite that request AVC.
Manu_Sporny: that contains a recognized custo verify EC validates that the VC is from a known on or shore in
Manu_Sporny: from a known recognized entity or I guess that's just that return successfully if it is return error the sure is so I think does that look right to everyone?
Kayode_Ezike: I think you have to do a similar thing for the output validation for the checks and verify that the issuer is known or unknown and then verify that the output validation passes…
Ted_Thibodeau_Jr: All right.
Kayode_Ezike: if it needs to four and then two sub notes on the floor unless you want to include Yeah,…
Ted_Thibodeau_Jr: What clever thing did you do to make it get you the lowercase Roman numerals and the letters?
Kayode_Ezike: I was wondering too actually.
Manu_Sporny: just went in a little bit more.
Manu_Sporny: Right. Yep,…
Ted_Thibodeau_Jr: So that's just your indenting.
Ted_Thibodeau_Jr: God damn.
Manu_Sporny: that's right. Yep. …
Ted_Thibodeau_Jr: GitHub silently upgraded this because those did not exist a few weeks ago.
Manu_Sporny: there you go. And it might not exist tomorrow. That's the wonderful thing about SAS.
Ted_Thibodeau_Jr: True.
Manu_Sporny: Okay. I'm going to save that. we're over time. thank you everyone for thinking through this. much appreciated in Coyote for your input especially.
Manu_Sporny: We will, I think, meet again next week, but I will note that I think we're almost 100% out of topics. we will start pulling back on these calls when we meet and we don't fill the hour, we'll talk about that next week. hopefully we're able to get through some of the GS1, examples, but we may go into a mode here where we just meet once a month and people work on the test suites and we check in once a month. and this is all a good All right, that's it for the call today. Thank you everyone very much.
Steve Capell: Thanks, mother.
Manu_Sporny: Have a great rest of your week and we will chat again next week. Take care. Bye. Meeting ended after 01:03:31 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.