VCWG Recognized Entities

Paul_Dietrich: Nope. You add it to the packet metadata, I think.

Manu_Sporny: Paul, you're not muted. I don't know if you're …

Paul_Dietrich: Thank That was my talking to Claude on it.

Manu_Sporny: I like it. Very very steady.

Benjamin_Young: I'm great at systemic.

Benjamin_Young: I'm hearing lots of people use it these days.

Call Agenda And Introduction

Manu_Sporny: All right, let's go ahead and get started. We've got a good chunk of people here. welcome everyone to the recognized entities call. This is September 29th, 2026. this is a verifiable credential working group task force call. everything is recorded and transcribed. Please let us know if you have an issue with that. for the agenda today, it's a standard agenda which is process just introductions any community news followed by pull requests followed by issues. we have a large set of things to talk about today. So I'm looking for guidance from the group on what they want to talk about.

Threat Model Refactoring

Manu_Sporny: The first thing is there has been a little bit of refactoring on the threat model and we've prepped our static copy of that to be published at the end of next Thursday. Avon has already put that in place. and I did some refactoring to try and make it work for Ping and Sin and we just got confirmation from Joe last call that Singh is happy with it. We haven't heard back from Ping yet. so there's some threat model discussion we can talk about.

Pull Requests For Security Review

Manu_Sporny: In an attempt to move things along with the security review, instead of debating whether or not we want to respond to all of the things that were raised by Singh, the mandatory changes they're asking us for I just raised PRs for them. So, we can discuss those PRs today if folks want. We will eventually have to discuss them. so they're five

Manu_Sporny: one one two three four yeah there are five PRs that we need to discuss and then Steve you raised a doozy of an issue issue 135 questioning many things so we could also talk about that and then on top of that we have the GS1 what is it field match discussion that Phil and Paul are here we might want to focus on that as well so we have way more topics than we can fit into the call today. what are people's preferences? Does anyone have a strong feeling like we should talk about threat model or we should talk about the pull requests or we should talk about issue 135 or we should talk about the GS1 field match thing. So looking for guidance from the group.

Kayode_Ezike: I think we should probably at least have an overview of the PRs because I mean security review to me seems to be probably the most urgent thing to get through. So that's just my two cents.

Manu_Sporny: All Thank you,…

Manu_Sporny: Coyote. Steve, go ahead.

Issue 135 Data Model Revisit

Steve Capell: Yeah, I mean obviously it is a bit of a doozy of an issue and…

Steve Capell: and I was reluctant to raise it…

Steve Capell: but working through all these use cases I felt better to raise it now than to discover after we release something that it doesn't fit needs.

Phil_Archer: Interesting. Can you hear me?

Steve Capell: So, I have a little bit of a time pressure because of, publishing UNP and so, yeah, I have an interest in at least touching on some of the issues if we can.

Manu_Sporny: Go ahead, Barely, but I can hear you.

GS1 Field Match Discussion

Phil_Archer: I've never done a call while I'm driving before this. So my phone is otherwise forgive me. yeah, just because of Paul with you and we realized that there's a problem here. so I contacted and other people as so there's a bunch of stuff there at your discretion which you can talk about this week or next week but it does I think need to be sooner rather later. But I understand there are other things you want to go through.

Phil_Archer: No, it's your answer.

Manu_Sporny: All Thank you, l. and then I'll note in chat that Paul also mentioned the field match thing and the JSON thing. So we've got kind of two preferences to talk about issue 135 which was revisiting the data model. I think we could maybe look at the JSON thing quickly. and then we would end up covering the poll request last. Yes, all of these things are pressing and important. So we'll just go in that order.

Manu_Sporny: and people can change direction if they want to mid call. All right, so all of that said, let's dive into the thing that we had the most support to discuss, which is revisiting the data model. If you would like to start us off, Steve, please go ahead.

Steve Capell: Would you like me to share the screen to go through the issue or…

Benjamin_Young: Steve, you can share it.

Steve Capell: or will everybody just look at it while I talk?

Manu_Sporny: …

Manu_Sporny: I can share if you want. Does that work?

Steve Capell: Or So, yeah, we're fine.

Steve Capell: So this came out of reading an issue that was posted a while back number 85 and listening to GS1 and at the same time working on how to use DIA for a two or three of our important use cases at the UN. So one of them is a business register recognizes a business who is registered. Another one is A national accredititation authority accredits a certification authority and so on and kind of fit that into the model and a few things popped up.

Steve Capell: First of all I mentioned last week that in most cases a recognition comes with of some sort of recognizer issued ID like a national business number or an accredititation number or something like that and that was missing from the standard data model. But then I started looking into the recognized two and recognized in deals and thinking how will I use those and I couldn't find a use case for either of them right and that doesn't mean it doesn't exist but I couldn't find it right so recognized two is basically saying we recognize you to issue this kind of credential defined by this schema

Steve Capell: and in the list here we see that in most cases some sort of recognition doesn't come with that constraint in the real business world right so a business register says we've registered as a business they don't say and you can issue invoices or whatever conformity accredititation does come with a specific recognize in a kind of semantic sense because they're saying we recognize you to issue credentials under ISO such and such standard but the credential schema at least in our case is the same for all and it's not the credential It's the standard against which you're accredited to issue credentials that's important. and so we could use a recognized two in that sense but not for the purpose it was designed which is to issue a schema.

Steve Capell: and then I thought about okay but of course there are other standard use cases like education that's where this came from and then I just put myself in the position of the department of education and a university and thinking about how real business works right a department has a role to play in registering and recognizing educational institutions I'm not sure how frequently they do that but that education institution is going to be potentially issuing

Steve Capell: all kinds of things right like education certificates micro credentials research you can imagine a huge list and also different versions of schema and I just can't imagine a university going back to the department of education every few weeks saying could you give me a new recognized entity credential with this or that schema version in it so that I'm allowed

Steve Capell: to issue them. it doesn't match what the role of the department is. and so even the use cases as documented the spec when I think about them in the real world, they just don't seem to work. And then recognized in when I looked at it originally, I thought, okay, we won't use that because I imagined it as a pointer to a list. When I read it carefully, it says it's a pointer to a list that contains the entity that is being recognized. And the comment in 85, I'm thinking, what's the use case for that be?

Steve Capell: Because the whole purpose of the recognized entity in my mind is to sort of bind the act the behavior of or the credentials that a subject will issue like an invoice or a certificate or whatever to the recognition that they have. and so what I care about most is that the issuer of the invoice or the certificate is the subject of the recognized entity credential and that's where the cryptographic kind of binding is the recognized in might say and here's the list in which you are in which you can find yourself

Steve Capell: But there's no binding there. it feels like just what is A pointer to the website which the accredititation authority already has. I couldn't see any value in a credential there because it's already on the website and that's already bound to the recognizers domain. And if you really want a list of recognized entities as opposed to a singleton, the recognized entity subject of the credential is itself an array, So if you wanted to say I'm recognizing these Wouldn't you just have 17 recognized entities in the list rather than the recognized in pointing to a list?

Steve Capell: So yeah, this is where I ended up and thought about it a bit and in the UNPDIA there's a few things I needed to do there's also a few things I need to do and I thought what's the common pattern here and the word recognized recognition scope is what popped up as something that I could reuse. across business registration and accreditation and so on. And in most cases, I'm not really willing to build into the rules of essentially graph verification beyond just the div matching because it just gets too complicated, right?

Steve Capell: There's so many things a bit like the GS1 use case, it's already yes, we want to do that, but it doesn't quite fit that schema rule, And soon as you go into accreditation space other things you find that really what I want to just do is say here is a URI that represents the scope of your registration and it's up to some other layer to go does that connect if you've issued inside a conformity credential is a scheme against which the conformity is assessed

Steve Capell: and that URI would match the scope list in the DIA. But I wouldn't want to necessarily put a path of sort of validation into the DIA. It feels to me like the DIA's job is to say as a national accredititation authority, I recognize you The scope is defined by this rule that I've published at this URI and it's for a layer above the DIA when that's looking at multiple credentials to say I need to match that field in that credential.

Steve Capell: It would just seem to me to get too complicated to try to put sort of predictive shackle constraints something like that in a DIA credential that's not even quite aware of the shape of things that might be issued on the basis of it. So yeah, I may not have explained this very well. I tried to write it down, but I just felt like I better bring this up now. And again I apologize for what might feel like a spanner in the works, but yeah, maybe someone can explain the idea that we should include a schema to constrain what the scope of recognition came from and what recognized in is for really.

Steve Capell: Because perhaps there are use cases…

Steve Capell: but I can't find them and I'd rather have a recognized recognition scope. Okay.

Manu_Sporny: Yeah, I'm on the queue to speak to that,…

Recognized Entity Use Cases

Manu_Sporny: So I think that there's a much simpler answer to everything you said. You don't have to put a recognized action into these lists at all. It's only there for people that need it. So it's not a requirement. So that's item one is you don't you don't need to specify recognized action. The base level of the recognition credential is if we go back to Dimmitri's use case right was just here's a list of entities that I know about and that's it.

Manu_Sporny: it doesn't even go into and hear the conformance h criteria or the conformance bodies or the things. so Steve I think you're looking at these fields as mandatory and they're absolutely not mandatory.

Manu_Sporny: They're only there for the use cases that need them. Your use case doesn't sound like it needs it so you don't have to use it. So that's I think the first general bit of feedback.

Steve Capell: Can I just quickly respond to that?

Steve Capell: I would say I realize they're not mandatory, right? And I'm quite happy to ignore them and apply my own stuff. What I'm raising more generally, I suppose, is it's one thing saying these are here and they're not mandatory. It's another thing putting things there that nobody can find a use for. So my concern is not so much what can I do because I can ignore the stuff that's not mandatory and add my own stuff. But if everybody's doing that, then it throws a question on is the data model right?

Steve Capell: That's the question I'm raising.

Manu_Sporny: Yeah, plus one of that. Paul's on the queue. go ahead, Paul. And then I'll follow

Paul_Dietrich: Yeah, Steve, this is Paul from GS1. I just wanted to kind of comment on our use case and how we're using these things. So, the rec you've probably saw the ticket, but just kind of to summarize, global office will issue prefix numbers from those prefixes. An MO, which is a country organization, can issue other ix longer prefixes called company prefixes. And then those companies can issue keys. they can only issue keys from those prefixes. And so what we want to try to do is to use that recognized action meaning what are they recognized to do? They're recognized to issue but only certain types that are bound by that schema. So that's how we're using the recognized action. Now the recognized in field what we're using that for is just a pointer. So some of these credentials might be private and some of these credentials might be resolvable.

Paul_Dietrich: specifically global office only has a few thousand prefixes they issue and they might choose to issue these to country organizations and those might be public information and so you don't necessarily have to pass those around. So we were thinking of that recognized in to be a resolution mechanism like how to go get that credential if you need it. Now we're not requiring that be the case but that's what we were thinking. and just one more thing, Steve, on the complex rules, as you saw what we're doing. Basically, when we did our pilots of this stuff, there's four or five credentials in a chain. The validation rules are complicated. If you don't run these validation rules, our business logic, then you don't really prove anything.

Paul_Dietrich: And what we found from pilots is that if there's a verification platform and every verification platform has to include a custom business logic for every route of trust, this somehow defeats the decentralization purpose of this. Meaning we might as well all just have one authority that has one giant library because it gets complicated if they have to do that for every route of trust. And so we were trying to recognized entities to fit some of that business validation into the schemas that we're putting in these credentials. So right or wrong Steve that's what we're looking at doing here with recognize entities and how we're using both static schemas like you can issue this type of credential and some of these more dynamic things like field match or JSON which is very specific restrictions on this credential chain. Oops. Thanks.

Paul_Dietrich: I'm done.

Manu_Sporny: Great. Thanks,…

Manu_Sporny: Paul. Dave.

Dave Longley: So just real quick, maybe something that we're missing is yet another output validation type that could just express a URI that applications are expected to understand that could optionally have human readable information if you dreerenced it. So you could write something in an application, but that might help cover the case where the validation isn't meant to necessarily be applied as some schema that you understand that you can run through some engine, but instead it's some set of rules that your application can be written up in whatever complex way you need it to be. So it could cover all this, I'm on a business register, so therefore I should be able to do this but that would be identified through some URI that an ecosystem would know Out.

Manu_Sporny: And to speak to use cases, Steve, we've got a couple in education. although I'd really like Phil or Dmitri, both of you Nate to speak to the education use case. I'll note that in the first responder and this has to do with identification badges for first responders are very very decentralized organizations. and when there is some kind of event that happens, hurricane, wildfire, flooding, typhoon, whatever, you have a whole bunch of people show up from a whole bunch of different places. and you need to be able to identify them quickly.

Manu_Sporny: for the recognized entities spec what we're looking to recognized action in is to ensure that when these first responder agencies issue identification cards they don't issue them for any other authority. So there is a group that sits over for example paramedics that license them that recognize that these individuals are credentialed in a decentralized manner. They know all the organizations that credential them and they want to make sure that those organizations only credential people for their authority. Right?

Manu_Sporny: And so the recognized action it's really important that you have very strong constraints on it. does it mean that organization can't issue anything else? Absolutely not. they can issue thousands of different other types of credentials. You don't need to show up on a recognized action list So for your university case, Steve, yes, of course, a university can issue student IDs and teacher IDs and access badges for their labs and community workforce credentials and library cards and they don't need to go on a recognized action list recognized entity list to do any of that stuff to do things locally.

Manu_Sporny: It's when the action becomes a little more community-based, state-based that's when you have a regulatory authority over, that area, that's where kind of the recognized action stuff pops up. so again, to speak to Steve, you were saying you couldn't think of a single use case. We definitely have them and we're definitely using recognized action for those use cases. and it's not meant to be limiting in the way that I think you have read the spec. meaning I agree with you, there's a very complex set of credentials that a university could issue, but that doesn't mean that they need to be on a recognized entity list to issue every single one of them. this is open world decentralization. Anyone can issue anything that they want to.

Manu_Sporny: We're trying to give tooling to regulatory bodies and oversight bodies to do an appropriate level of restriction for their market vertical which is going to be different for all these various groups. I haven't touched on recognized in yet. That's a separate item. with respect to what Dave said maybe we have another output validation thing that just points to human readable lists that's what we need I am concerned about that because the European Union in their list of the list stuff took that approach and there is just reams and reams of regulatory stuff that you need to read through and at that point it's a human being

Manu_Sporny: that's actually doing the enforcement. which kind of I don't want to say it defeats the purpose, but it definitely reintroduces a whole bunch of friction into processes that we're trying to automate.

Manu_Sporny: That's it. go ahead, Steve.

Steve Capell: Yeah, just two quick points.

Steve Capell: One on the rules. I agree with you. If you try to put too much in here, it just buries itself in complexity, So the way we seek to handle rules in UNP is to recognize that there are some pretty common rules is the subject of a identity anchor the same as the issuer of the credential they issue and UNP can define what we've done is abstract of any credential and not embedded in any credential just said here's a set of very common graphs

Steve Capell: validation rules. Use them if you wish. And then we say to an industry group that wants to extend UNP in their sector, deforestation or whatever it write your rules this way that apply across your industry. And then we say to any particular implement, you can have whatever rules you want. You don't even have to use the rules we've defined in this layered architecture, but probably you're going to find the UNP ones fairly useful and the ones from your industry group fairly useful. Use them, don't use them, and add your own. So, it's really just an architecture to make it quicker and easier to build validation rules over a graph. But none of those rules are embedded in the credentials because they logically sit above the credentials. Otherwise, you just tie yourself in knots.

Steve Capell: I think so that's why I have an allergic reaction to putting too much rules inside a credential because it again doesn't fit our use cases on the point you made about of course the department of educa sorry not the university can issue all kinds of things and they don't have to have a recognized action if I'm a verifier of a student ID issued by my outside of the university context. So, I've got a student ID. It's a recognized entity credential. and I'm using it in some other context.

Steve Capell: And that verifier looks to the student ID is a VC issued by the university or pardon and the recognized entity credential is issued by the department of education to the university right and the verifier goes is this a valid student ID they're going to find a recognized entity that has a recognized action can issue degree certificates

Steve Capell: what's the behavior now because it is a valid student ID it is from an accredited university but it's not on the recognized entity list does this mean if you looking at a credential that is not in the recognized action list it's okay you can just ignore the recognized action list in which case what's it for in the first place what right because this will be a very common scenario is you just said it yourself. And so to me it still doesn't make sense.

Manu_Sporny: Go ahead, you might be muted, Demetri. Go ahead.

Dmitri_Zagidulin: Whoops. so, Steve, I completely understand, your question there. I think it's important to think about those two things separately, recognized entity versus recognized and also authorized to issue this kind of thing, Think of it to draw a silly analogy as a far pharmaceuticals company. you have the general recognition that this is a pharmaceutical company that's separate and then separately they're controlled substances and they have a license to issue this controlled substance right so in the education example the university is licensed to issue a 4-year degree like a controlled substance kind of thing but also separately they are a recognized university and so all of the student IDs all of the employment all of

Dmitri_Zagidulin: internal and not tightly regulated credentials just go under that first rubric. Not the fact that they're authorized to issue diplomas.

Steve Capell: No, I do understand that. I'm just thinking we're writing a spec that people will implement and when there's a recognized action and it has a schema in it, you typically expect the validation rules. So, I suppose it goes to what you write in the validation rules section of the spec because you would have to write something when validating a credential like a student ID and you find a connected recognized entity credential and there is a mismatch between in the

Steve Capell: recognized action and the credential you're holding. you use your judgment whether you care about it or not. That's the impact, it's kind of like there's a rule here, but in most cases, you can just ignore it essentially. again, so I'll just repeat that feels stupid to me. and you better just take it out and let app apply these rules at a higher level. But I accept that, I'm not here to tell you you must change things. I'm just saying it feels like we're writing a spec that has some weirdness in it that a recognized in doesn't have any validation associated with it. So what's it for? It just may as well be on the website.

Steve Capell: a recognized action rarely used and when it's used it doesn't constrain other actions the party can do which leaves confusion in the hands of the verifier about whether you care about it or not. So what is it enforcing if you can choose to ignore it anyway? In fact, you have to choose to ignore it in most cases. So,

Manu_Sporny: So, we've got a queue. I'm wondering if we can time box for so that we can get to at least one other item on the call today. so let's say time box 10 minutes unless there are objections. Steve, I think we could go at the other direction. if we do what you are suggesting, which is remove the feature entirely. So, let's just drop the feature. Our use cases are dead in the water for education in first responder. we have no mechanism to achieve what we wanted to achieve. So that's the counter going at this from the other direction. Let's say you're advocating for the complete removal. We remove it completely. Now we can't achieve our use cases and recognized entities as useless to us.

Manu_Sporny: So I think that's the concern is okay if we remove it then how is it replaced just to try and explain it from a different direction. but going back to what you said I think it is always true that we can't configure the world right we cannot come up with a configuration that's going to cover every single use case. the way that you were expl explaining how student IDs worked is not how we're planning on actually implementing them. I agree

Manu_Sporny: that makes, we wouldn't do it that way because it doesn't work for the reasons that you just mentioned, our approach to student IDs could be that the student ID that's issued has an issuer field that has a recognized in property that actually identifies a list of universities that issue student IDs. That is how that mechanism it would not work in the way that you explained if we chose to do that, I mean, I think we're still kind of unsure about are you going to use a student ID issued in California and New York to do something? Maybe you get a student discount or something like that. And at that point, it is up verifier to determine what good enough is is for it.

Manu_Sporny: and it may not depend on a recognized entity list to do that. It may have some other kind of bespoke mechanism there. So, just some food for thought. I think we're gonna come back to this, And I don't expect this issue to be, closed today. go ahead, Paul.

Paul_Dietrich: Thanks Bono. I just wanted to pass one piece of information also to you talk about lists and how these are approved lists of issuers. I think in our case for the global office there's only a few thousand prefixes that are authorized by the global office but by MO like a US there's over a million and so it becomes prohibitive to create an authoritative list of these things which is why we want to chain them together. and so that's why it's also important for that recognized infield to help resolve them if we need to go find them. That's it. Thanks,

Manu_Sporny: Thanks both Dave.

Dave Longley: Yeah, I just want to say I think something we might need to work on a little bit is talking about the mental model for how this works. If my mental model for this is I'm thinking about verifiers having their own set of rules that they allow to be extended by others and the way in which they allow them to be extended by others might also have a set of rules a policy around it. And so either those others extend those rules, they specify you're allowed to issue that or they don't. and so whenever you're verifying some credential and you're looking to see whether or not you should recognize or accept it, either it meets your rules and you're good or it meets some rules that can be extended or it doesn't. And I think if you think about it like that and then I think the data model that we have is supportive of

Manu_Sporny: All right. let's see. Steve, I'm looking to you to see if you feel like we've had a good enough discussion for this week.

Steve Capell: All right. Yeah.

Manu_Sporny: And then kind of some next steps and the next steps could be just like everyone go away and think about this and we'll come back and discuss. but I'm looking to you to kind of close out the time box. Phil's on the queue and then you go ahead,

Phillip Long: Yeah, I just wanted to point out that at least in the ed education and higher education space, there's often overlapping entities and authorizations such that a university may have degrees of various sorts. But any given degree there's often professional associations which also off recognize that particular degree because of attributes of the way in which things are included and dealt with and these overlapping entities that are doing u recognition of subsets of things allow I think is nicely enabled with recognized in list as a subsection of the overall recognized activity

Phillip Long: or action. And I just wanted to point out that the complexity of it, which is just a result of humans being less logically consistent than they might have otherwise been, is the way this is put together allows us to cover those sorts of interactions and overlay overly jurisdictions. Thanks.

Manu_Sporny: All right. Thanks, Over to you, Steve, for some last thoughts for this week on this topic, and we'll bring it up again next week.

Steve Capell: So I think the comment about mental model goes to the heart of it here,…

Steve Capell: right? in every single one without exception of our use cases for DIA of which there are many what we call recognized entity its entire purpose is to anchor a chain right it's not a thing that ever serves much purpose on its own it's only to connect let's say an invoice to a registered

Steve Capell: business or a certificate to an accreditated c accredited certification body and so on and so that's the sole use case so that there's no sense of any list and every sense of action has complexities that don't cover so is there another mental model for this thing that I'm not aware of because I thought it was only that and in that mental model there's no place in no use and no ability to use the recognized two as written. so perhaps it is a mental model issue. for me all I can do now

Steve Capell: is to write on UNP, do not use that, but use this instead. that's what I'll have to do, And I'm feeling like I'm still unconvinced, but I'm happy to time box and close this. And my whilst I can go away and do whatever I want, what I'm trying to feed back is, are we sure we're doing the right thing here? because collectively as the W3C I know I can do what I want but I want us collectively to write something that's genuinely meaningful and valuable and if I find myself going no I can't use that can't use that I need this and it's not there so I'll add it then isn't there a misfit right that's the issue I'm raising so let's time box it for now but I'm leaving this conversation thinking

Steve Capell: We're talking past each other, I think.

Manu_Sporny: All right. Thanks thanks Steve and thanks for raising the issue. I mean this is a part of the standardsm process is to debate things like this and try to figure out a shared mental model for the spec and a way through it and all that kind of stuff. So even at this point in the process it's totally healthy and fine to raise things that we haven't discussed before. All right. that was 135. let's very quickly go to the field match item from GS1 because that was the other item that folks wanted to discuss. So Paul, why don't you lead us off with kind of…

Manu_Sporny: where you got to and then Dave, if you have anything to add. over to you Paul.

Paul_Dietrich: Yeah, thanks Manu.

Paul_Dietrich: So where we got to I think Dave had suggested trying something like JSON. So I went into our examples and then I wrote those basically as two output validations a static schema and then a JSON which basically that JSON auto generator generates a schema. and so if you click on one of those, Jason, I think it's the last link there, If you want to click on one of those, click that. And then just go do say prefix to GCP, the last one there. So the JSON is basically building a schema that So this is the pattern match that we put into our field match proposal.

Paul_Dietrich: And instead of generating that through a field match element, which one's a custom reax, we're generating that through this JSON audit transformation. So I think where we stood with that monu that seems like that supports our use case meaning of all the test cases I validated negative test cases that can work so that property works but where I ended up was basically like I wasn't sure the group's appetite for this because I think once you do this JSON auto you're talking about a fairly big space of things you could do the field match was kind of the minimum we needed but this JSON auto has a much richer

Paul_Dietrich: things it can do and I'm not really the one who can say whether is that palatable to the group or is that objectionable to the group and so I think where we're at is we would be happy with that Jason a proposal but we want to get the temper of the group before we kind of move forward to try to finish out our examples

Manu_Sporny: Thank you. so I think yeah, my question was going to be would this work for GS1? And I'm hearing yes, it would. and now the only question is JSON too complex or problematic. I'll note that on the render method call today, JSON came up as a potential solution. and on that call, I also said it looks like we're looking at Jason to address, both of these use cases. If this is something that's going to be in the verifiable credential toolkit, then, it might not be a big deal. me meaning we're looking at the same thing in two different places for two different specs.

Manu_Sporny: sort of solving mildly different things, but the end result is you want to produce a bunch of JSON, which is what JSON does. so, I wouldn't be opposed to saying okay, let's do this because we're also I think limiting the blast radius here. we're basically saying there is an output validation type that is JSON and we suggest implementers implement it right and if they do that then we address not only the GS1 use case but any more complicated kind of what is it attenuation of responsibility down a recognized entity chain

Manu_Sporny: The challenge I have with this is that it becomes very meta, right? So I'm noting, Phil is like, hey, explain the mental model. I'm going to hand it over to Dave to explain the mental model because it's easy, but when you get into the details, I feel like it gets complex. I would be fine with us just saying, "Hey, we're going to define a JSON on a type as an output validator and…

Manu_Sporny: that solves GS1's use case and potentially other use cases as to the queue.

Phil_Archer: I'm sort of in the middle here and…

Phil_Archer: on the fence and it's quite painful. Jason can't be a normative reference. It's done some digging on this. It's essentially a oneman project. It may be a very good project maybe used and everything else and there are lots of one person projects around the world but it couldn't be a normative reference and so I think the group is going to need to think okay how do we say something you may have something you may use something like this as an example of what you could do but I don't think it can be a normative must Sorry. Yep.

Manu_Sporny: Thanks, We've got some thinking going on there as well. We should probably bring this up in the main call. And this is a challenge we had, as Phil, we hit this challenge every year at W3C. How do we talk about this thing that doesn't have a stable reference? one thing that's fairly new, Phil, and I don't know if you've experienced this yet, is archival at publishing it at a static location. to create that stable reference, sometimes we go and we check on the community and ask them hey, is this community longived? is there any way it Could you publish something at questions like that but I think we'd have to look at the JSON and the spec but I think it's small enough static enough that we could archive it and…

Phil_Archer: Okay.

Manu_Sporny: use that for the permanent link.

Manu_Sporny: Go ahead Ted and then Ted, you might be muted.

Ted_Thibodeau_Jr: Sorry about that. yeah, as Phil was saying, this is currently at least problematic for a normative citation. I'm not sure I agree that it's that problematic, but further digging will be necessary. it does not look to me as a one-man show. it has institutional support at least by IBM who's got two people who call themselves JSON audit developers. it has a reasonable number of forks on GitHub. I don't see a particular reason why it couldn't be forked again by us and put in a useful place whatever that might be. Whether that fork then branches away from the original or does it own thing sticks closed that doesn't matter to me. I think either one is workable. and I would think sufficient

Ted_Thibodeau_Jr: to make it a W3C project. It's MIT license, blah blah blah. that's as much as I get in my head.

Manu_Sporny: Great. Thanks, Ted. Dave

Dave Longley: So I think once again as we have in two other specs that are considering use of this technology I don't think we need this to be normative. it's great if it can be but I think every place where this tool is used I'll just speak to where we potentially be using the tool here. we have this idea of an output validation that can use a JSON schema. All that JSON does is dynamically generate that schema from a JSON template plus the chain that you has been obtained through the algorithm that is in the spec. So the combination of those two things produce the JSON schema that you then use to validate other aspects of things in that chain.

Dave Longley: So, this is particularly useful for things like, dynamically generating a schema when the length of the chain of the already verified chain and now you're trying to dig into what specifically is inside of that chain.

Manu_Sporny: Did that explanation help, Phil? Okay,…

Phil_Archer: Yes, very much. Thank you, Dave.

Manu_Sporny: all let's see. We have seven minutes left. is there so I guess what are the next steps here?

Paul_Dietrich: Thanks, This question was for Dave, are you saying that if this is not normative in there, then validation of this output would be optional? or would the rules still say you do it? I'm not quite sure what you're saying there.

Dave Longley: mon you so …

Manu_Sporny: No, go ahead. I'll go Free.

Dave Longley: what we can explore is there are two paths forward one of them is you could decide that you have to reject something if you don't understand the type of validation the type of schema so you don't know how to process it so you would reject it or andor we can explore if you don't know what the type of thing it is, pick one that you do know and then we can make it so both of these things are available in the model. And I think we've already talked about having expressing recognize two properties, one that has the schema, one that doesn't. maybe that one has just JSON schema, one doesn't have it. So there are options for what we would do there.

Manu_Sporny: And I guess it is very important that W3C has the requirements on normative references that it does. but We should not necessarily let those get in the way of us solving real problems that people have that we need to solve in these specifications, we have a number of people that have been in the space for a while here including our illustrious chairs. We will figure out a way to make this work if this is of use to the group.

Manu_Sporny: So all that to say if this solves GS1's problem and it makes it so that it's easy for you to adopt this mechanism and we can move forward and we're seeing usage of JSON auto in VCOM and render method right I totally forgot about VCOM use a bit so in VCOM and render method we now have three specifications that the VCWG is working on that depends on the technology and no matter what the spec says

Manu_Sporny: implementers are going to use it if it's useful to them, So, it's our job as editors and chairs and W3C staff to find a way to make this work. that's it. so Paul, I wouldn't, and again, very important what you said, Phil. Yes, we need to figure out a way to make this work, but number one of importance is we fix real problems for implementers so they use the technology. so with that thoughts on next steps here from anyone? I mean my proposal would be a PR that raises support for Jason. It feels like we're there unless anyone would object to that. All right. And I'm not hearing any objections.

Manu_Sporny: And of course, people can always object later when the PR is raised, and they can always object after that before we go to CR and they can always object to that before we go to Rex. So there are plenty of opportunities to stop the train if we become uncomfortable with this later on. All right, that is our call for today. Thank you everyone very much for the great discussion. next week, we will circle back around to, the issue 135, the data model discussion. Steve, we'll spend a bit more time on it next week. In the meantime, please read these security threat model related PRs.

Manu_Sporny: If we merge all of these, we will have responded to security's review of our spec and our security review will be complete. I will note that privacy closed their review on us. They were like, "We're done. They raised two issues and they were basically like, "Yeah, it looks good to us. They need to respond to these two issues. we provided a response and said, "Hey, we tried to address your issue. Are you okay with it?" but the privacy review is done at this point as far as they're concerned as long as we address these ones and the security one will be done if we process the PR.

Manu_Sporny: So, please go in and do a review and approve if you agree. we will cover these next week. And I'm just remembering I am not going to be here next week. So, I'm going to need your help, Benjamin, to just run the call and get us through these poll requests and… the discussion next week. Steep, last word before we Manu Sporny:

Steve Capell: Yes, thank you so much.

Steve Capell: I just wanted to ask if there's anything the group wants me to do beyond having the winch in the ticket that I've already had. Is there anything I can usefully do to contribute further to the discussion?

Manu_Sporny: Yes. what concrete changes do you think you're going to need to make to understanding what you're getting ready to write I think would help the group figure out…

Steve Capell: Okay,…

Manu_Sporny: what we might write instead to make it so you don't have to write those things if that makes sense.

Steve Capell: that's fine.

Manu_Sporny: So yeah that concretely…

Steve Capell: Thank you.

Manu_Sporny: what changes do you feel you're going to have to make in DIA as a result of 135. All right, with that, thank you everyone. Have a wonderful rest of your week, and weekend and we will meet again next week. Take care. Bye.

Phil_Archer: Thanks.

Paul_Dietrich: Bye-bye. Meeting ended after 00:59:02 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.