Meeting minutes
Manu_Sporny: Hey Paul, good to see you here today. we're gonna hold for another couple of minutes and…
Paul_Dietrich: Hang on.
Manu_Sporny: then get started. But since we have you today, I think maybe what we do is start off with the issue you raised and then get some discussion and thoughts from the group on it. and when then we have nine poll requests that we have to process today as does that work for you? does that work for you?
Paul_Dietrich: Yeah, that's fine. Manu, I'm traveling and so I'm just parked here on the call, so I can't get on chat or other things that might make it easier, but I could at least have a discussion with the group who kind of read through that document and give a little background as to what we're trying to do.
Manu_Sporny: Yeah, No problem. And yeah, not an issue. this system doesn't require you to be on anything other than voice.
Paul_Dietrich: All right, perfect.
Manu_Sporny: So we'll hold for a couple of more minutes. I know we had a lot of people on the other call. we're probably taking a two-minut break and then they'll show up here. So, we'll get started in a couple minutes.
Manu_Sporny: All right, I think we've got quorums. So, let's go ahead and get started. let me go ahead and share my screen. welcome everyone to the recognized entities weekly call task force call. This is an official W3C verifiable credential working group all audio is recorded and transcribed. please let us know if that is not okay with we do have an agenda today. we have Paul Dietrich joining us.
Manu_Sporny: And so we're going to focus on one of the GS1 use cases or issues that Paul raised get some discussion going on that any of the remaining time that we have will be used to go over the nine pull requests that we have open on the specification. that is the proposed agenda. Are there any updates or changes to the agenda or anything else that people would like to cover today? All right. If not, let's go ahead and jump right into it.
Add support for FieldMatch (transitive output validations) · Issue #121 · w3c/vc-recognized-entities · GitHub
Addressing Transitive Behavior In Recognized Entities
Manu_Sporny: Phil Archer raised an issue last week around this concept let me share my window around this concept of effectively needing to do in a recognized entity chain where one entity further up the chain who's recognizing someone downchain needs to limit what they can do. so for example in the GS1 use case you've got the GS1 global office issuing a prefix to the member organization and they're saying it must start with the number nine or something like that.
Manu_Sporny: and then the member organization delegates down to a company that their prefix starts with a 98 or something like that. Right? So both I think GS1 is looking for a way to do that kind of restriction. and that is I believe what we're going to talk about today. I will note that and thank you very much Paul for doing this. you put together a full proposal for us to kind of take a look through. so maybe you could start with just a general explanation of the class problem you're trying to address and then we can go through your field match proposal just a high level. would that work for you, Paul? Okay.
<Dave Longley> "limit what is recognized" (is better than "limit what they can do")
Paul_Dietrich: Yeah, that's fine. Thanks, Manu.
<Manu_Sporny> GS1DigitalLicenses/jsons/recognized-entities-field/FieldMatch.md at pfd_re_update_1 · gs1/GS1DigitalLicenses · GitHub
Manu_Sporny: All right.
Paul_Dietrich: So, Manu gave a very good description of what's going on here. GS1 wants to use verifiable credentials to recognize sub entities to issue either prefixes, which are kind of the root of GS1 numbering systems or numbers themselves. and then that's kind of delegated through multiple parties because we're a hierarchical organization. There's a global office. there's countries and there's member companies and then those member companies are the ones that are actually making the keys. And so in our previous instance of our data model, we had some proprietary fields within the credential that would link these things together and then we had a library to help validate these things that would basically just go through the chain and make sure these pattern matches across credentials were valid.
Paul_Dietrich: we want to move to recognized entities everyone agrees on the GS1 level we want to move to this because it's a standard model and we understand from all our pilots that supporting libraries to verify credentials just doesn't scale meaning if everybody needs a library to verify it doesn't really feel standard now because you have custom components loaded into code and so we spent the last few weeks trying to use the existing recognize entity spec to force this chain and it almost worked. So, it was very close. because we're only issuing certain types of credentials at certain levels, we could use that credential type with a few minor modifications to the spec to go enforce our rules. in addition to what we called these dynamic schemas where we'd link in a schema into the recognized action and that schema would be specific to that particular member we were issuing to.
Paul_Dietrich: But that fell apart in one specific case where a member issues a key credential say for a G10. So creates a G10 which was a product identifier and then wants to delegate an authority over a specific piece of data for that identifier or for a specific batch lot to somebody else. And it's in that model where a key kind of extends a key credential where the current recognize entity spec doesn't work for us because there's no transitive behaviors. And ultimately what we really do in our credential is validate fields across credentials and make sure there's some pattern matching. And so there's two things we want to do that pattern matching.
Paul_Dietrich: we could work around that with these complicated dynamic schemas which have its own challenges but we couldn't solve the problem totally for the data model but we also believe with this field match proposal which basically says inside the recognized action in addition to checking a schema if there's multiple sorry I forgot what they're called output validation steps that those validation steps are essentially anded meaning that both output validations within a recognized action if there's multiples have to succeed one of those would be a schema validation on the recognized credential and the other would be a field match pattern and that they would both have to match and so in the spec it
Paul_Dietrich: unclear when there were multiple output validations whether that was or we assumed it was want to re propose that it's and then in addition this new method that's not a schema match but a field pattern match would allow us to cross validate the fields that were important now I'll take questions on that but then I want to elaborate just one more bit Manu on why this provides transitive behavior because it's not necessarily straightforward That's
Manu_Sporny: Thank you. That was very very clear, Paul. the use case need I'm sharing your field match proposal on screen and can scroll to whatever if you want me to scroll to any particular place while you're talking I can do that. I wanted to mention I was in the spec this weekend and I believe what the algorithms do today is So your presumption that it and is correct. I believe I don't know if we ever decided that as a group. So I'm just flagging that as if we have multiple output validations does the group feel like we are ending all of those things together?
Manu_Sporny: Paul in some issue somewhere on the issue tracker said if we want to support or we can do that as a separate recognized action which I agree with. so I think we're aligned there…
Manu_Sporny: unless missing some detail. any other and Dave Longley is giving any other questions on what Paul covered? Is the use case that GS1's attempting to achieve clear? no Paul, back over to you.
Paul_Dietrich: Okay. …
Paul_Dietrich: so I think this spot in the document is the right spot to share when I talk about how to enforce transitive behavior with this. It's not as direct an enforcement as calling out a transitive behavior, but let me just describe it. So in this field match output validation, there's a source field and an output field. And then in the source field, I didn't put any pattern matching because we didn't need it.
Paul_Dietrich: But it doesn't mean we wouldn't. In the output field, I have a path to the field and then a pattern which is a regular expression. And so the source field is a value in that regular expression. And so you'd basically take the source field, stick it in the regular expression in output pattern and that regular expression would have to evaluate to And so this is what we think the pattern matching that we need is. We went through can it be just like a exact match or a prefix match or it starts with.
<Todd_Snyder> Here if there are any question that Paul can't answer
Paul_Dietrich: We went through something simpler than that to start and where we came up with is because GS1 has a long history of numbers and the history is complicated by the size of G10 that starts with isn't sufficient because of zero padding in certain numbers and so the patterns that we're looking for look like a starts with except that there's some number of zeros at the front and so we couldn't just use a simpler matching. That's why we picked a regular expression. any questions there before I talk about the transitive stuff?
Manu_Sporny: Nope. No hands up.
Paul_Dietrich: Okay, so the transitive behavior was somewhat a little bit roundabout here, but again since this is the behavior we had in our actual library, it was easy to carry over.
Paul_Dietrich: But basically what we're saying is in the recognized action the schema part of that the schema part says any credential you create has to have this field match in a recognized action and it has to match this pattern. And so that transitive behavior basically it's a little bit roundabout because the field match itself just applies to any credential that's created from that recognized entity. But the schema now says and that credential also better have a field match that looks like this. And so that's how transitivity is enforced. And so necessarily in our model every output validation would have a schema. And in our is a fixed schema. It's not dynamic for each member. It's a fixed one. And then this field match pattern.
Paul_Dietrich: And so the schema has a requirement on that field match being present and the credential is generated by that entity and then the field match has to be a certain thing. And so that's how we enforce transitivity. It's a little roundabout and so I would be open to a proposal that had a more clearly transitive behavior. but also this is the one we came up with that we felt like was the simplest to support our model.
Manu_Sporny: Go ahead.
Dave Longley: I just want to get clarification.
Dave Longley: Are we saying that this validation from let's just say GS1 at the root is on I'm going to call some delegates recognized entity credential.
Dave Longley: So you've got you GS1 one issues its own recognized entity credential that lists some recognized issuers with recognized actions. And one of the actions is they are recognized to themselves issue a recognized entity credential,…
Paul_Dietrich: I feel like Yeah,…
Dave Longley: but it must have this output validation in its own list of actions for anyone it further recognizes. Did I say that right?
Paul_Dietrich: Dave, that was Dave?
Dave Longley: Yes, that's right.
Paul_Dietrich: Yeah, that's basically true. I mean, that's what we're saying in our new license chain. While we're calling this 2.0 because we're following the recognized entity spec, a license to issue numbers is going to be both a GS1 license credential of some kind and a recognized entity credential. So, this will have two types and that was another issue we filed.
Paul_Dietrich: it wasn't clear in the recognized buy whether that would have multiple types and we said since the credentials that should as well so a GS1 a licensed credential will be a recognized entity credential and so yes we're recognizing to recognize someone to recognize someone so there's four levels deep here in our model because there's the global office there's the country organization there's the member company and then the member Company is allowed to do this for certain data elements.
Dave Longley: Yeah, just to respond to that quickly, it sounds like every credential that you want this to apply to has to itself be a recognized entity credential for you to get its properties. That's okay.
Paul_Dietrich: Yeah, correct. And they are Yep.
Dave Longley: All right.
Paul_Dietrich: So now every one of our license and key credentials and data credentials will all be recognized entity credentials if they're going to be validated through this chain.
Paul_Dietrich: That hurts.
Manu_Sporny: got it. So, I think I'm clear on kind of how this is constructed, at least at a high level. I put in a response there Paul with some thinking kind of again over the weekend. what this is effectively doing is it is moving logic that you would ac expect the verifier to perform during validation. It's that library that you were talking about. it's taking that and it's kind of moving it into a declarative form in the recognized entity credentials right into that chain.
Manu_Sporny: And…
Paul_Dietrich: It's going to be Yeah,…
Manu_Sporny: it's doing it in a way that is somewhat generalized right you can do field matching using this mechanism and I guess that mean at that point do you need that library for anything else? is that kind of like the big upside that this gives you.
Paul_Dietrich: I mean I think that the big upside for us is that it removed the need for that library and so that's not only supporting and maintaining a library monu but like integrating a library into every system that needs to verify credentials on trade is almost prohibitive.
Manu_Sporny: Mhm. Yeah.
Paul_Dietrich: Meaning every pilot we've done people are okay so we need a custom library for this standard.
<Kayode_Ezike> Only thing I wonder is whether we are preventing any use cases by defining the outputValidation array as an AND of all elements and not an OR or them. None jumps to mind, but worth considering.
Paul_Dietrich: I think that's kind of what comes out and…
Paul_Dietrich: so I don't know how often others have that problem but for us that was a significant thing and I mean we could continue our old model and try to make that library open source and have ecosystems include that but this felt like it was so close that we felt like this one step could make it so we could remove that library completely
<Kayode_Ezike> Also, we should be clear about this definition in the spec text.
Manu_Sporny: Mhm. Yeah.
Manu_Sporny: Yeah. Yeah. I heard I mean the upside is very clear to me. at least one of my concerns in the response to you was this would work for GS1. I'm concerned that it wouldn't necessarily work for a variety of other use cases, That need to do something more complex than field matching. And maybe for those use cases, we're too bad, you need a library, you need to move that logic into your validation code on your verifier.
Paul_Dietrich: Purple.
Manu_Sporny: So a couple of highle thoughts. the first one is how much of the validation logic do we want to move out of the verifier into kind of declarative fields in these credentials right so for JSON schema we moved quite a bit of that logic so we've already done it with JSON schema right so we've moved a ton of logic a significant amount kind of logic out of the verifier validation logic into the recognized entity credential and we have done it in a generalized enough way where you can probably verify the shape of any given verifiable credential, right? but we stopped there, right?
Manu_Sporny: the step that we didn't take was and now you can do validation logic between a chain of credentials where you have one credential and another credential and you do some kind of relationship testing between those two. that is what this field match proposal adds. It's the first example of kind of the minimum viable way of doing that. I am personally concerned that if we don't make this more generalized u like this is field matching, and it uses reg x's fairly generalized, but what happens when you have multiple field matching or what happens if you need to do some unit conversion before you do the field matching and a variety of other things like that.
<Dave Longley> "FieldMatch" is "just one special schema" ... each of these that doesn't make the standard is "going to need a special library"... it's not very scalable in a different place: at the standard level.
Manu_Sporny: So, one of the things, I suggested was I don't know if I suggested this, but it was like, are we going to end up at a point…
Paul_Dietrich: Don't think
<Dave Longley> i also wonder if JSON schema can do what 'FieldMatch' is doing ... i can't tell if there are "more inputs" here (i.e., 'the whole chain') or not.
Manu_Sporny: where we ended up with the HTML render method where we were like, we think we can do declaratively in the beginning. This is for just rendering something. And we'll just use SVG. And then we were like, we can't just use SVG. We have to use a So we'll add that, template processing in there. And then once we added the template processing, we were like, this doesn't work for dynamic lists. And we basically kept expanding scope until we're just going to use HTML and JavaScript because it's the only thing that'll actually, so I'm wondering if that is the path that we're on with field match. meaning this will work for GS1.
<Paul_Dietrich> I’ve tried this and can respond to my attempts
Manu_Sporny: I'm almost convinced that we're going to end up hitting something where we need to do something more than just field match. And at that point, we'll expand scope. And it feels like at that point, we'll just keep expanding scope until we get to all right, let's GS1 just publishes effectively you publish that library, but you publish it as a JavaScript stub in the verifiable credential itself that has a cryptographic hash against it. and you run that thing in a sandbox and it will do effectively the field match but it can do a bunch of arbitrary other types of checks. It could do unit conversion and field matching and heruristics and all that kind of stuff as well.
<Todd_Snyder> Not out of the box. In the GS1 Use case we need cross VCs field comparisons.
Manu_Sporny: So, I know that is an extreme Paul, you're just talking about field match right now, but I can't help but think yeah, but what about all these other use cases that are inevit in inevitably going to hit our door? go ahead, Paul.
<Dave Longley> a pipeline that might work: jsonata(chain) => JSON schema
Paul_Dietrich: So, I guess to respond first to Dave, I think we did try it by using dynamic schemas in place of those field matches because they just seem like they're matching a pattern. But the thing is the combination of that and the schema which forces the downstream credential to also have that same field match. you can't do that through forcing another schema. We tried to do it and it just got very complicated. So I think that's to respond to Dave Manu for you. I completely sympathize. This is all standard stuff like how much do we pull in? how many use cases do we cover. So, I don't have a strong opinion how to make that decision. but
Paul_Dietrich: something where we embedded code into the credential that has to run that also feels like okay that brings a whole can of worms that's besides what we're doing here if I were to guess where this thing falls short was like there's no input pattern matching or conversion we left it out cuz we didn't need it and the second thing we really didn't consider very strongly is arrays inside these elements and so how those path names would deal with arrays and so we thought both of those things would get complicated. but I think what we could also do is think about the use case. I think Phil was thinking first how do you get transitive behavior? Can we make a schema be transitive somehow? and that might be another solution. So if we want to investigate something like that, dynamic schemas with a transitive property to force the downstream credentials to enforce those same schemas.
Paul_Dietrich: That might be interesting. The problem is I think Monu what we're concerned about with dynamically generated schemas so each license have a schema is we can't put these in URLs because now everyone's phoning home and so we need to embed those dynamic schemas into the credential themselves. And so this transitive thing, you can't just do a schema check to say it's the same URL of schema because we don't want to put them in as URLs unless they're these big URL data elements. because I think the phone home risk to putting a dynamically generated schema into every one of a credential in the GS1 chain is just too much. Okay, I'm finished.
Manu_Sporny: Yeah, completely agree.
Manu_Sporny: We've got a queue forming.
Todd_Snyder: Yeah. just a couple quick points.
Todd_Snyder: One is the basic way our current implementation of our library works is to extend JSON schemas to do all this stuff. which is problematic because at least in the JavaScript world all the JSON schema libraries don't they are very limited what they can do you have to extend them to do basically what this matching is the secondary thing is part of I don't know if Paul mentioned before I joined part of our challenge at least from the GS1 use case is we are not the only issuers we're going to have the Pepsis the ca-Cola all the brands of the world will also need to issue these things and keep these schemas and these things so the more we can bake into a specification like recognize entity, we solve the pain that everybody would have trying to issue these credentials.
Manu_Sporny: Yeah, plus one to that. Paul, you're up next and then Dave Lley. maybe Paul,…
Manu_Sporny: your hand didn't go down. Okay. No,…
<Dave Longley> JSONata
Paul_Dietrich: Yeah, I didn't put my hand down.
Paul_Dietrich: Sorry, I'm struggling on my phone. Please get me.
Manu_Sporny: no problem. Go ahead, Dave.
Dave Longley: Yeah, I think there's definitely more to explore here, especially if so I think it would not be a good thing to define one special type of use case put that in the standard and say now everybody can just do that one special use case so if we're going to I think we do need to figure out how we can generalize this more or sol we should try to solve this transitivity use case in some way or express that it's not solved by this spec and here's the pattern you should follow with this extra thing. and if we are going to explore generalizing this, one kind of pipeline that might also work is to put a JSON template into the validation.
Dave Longley: in I already said pipeline but create a pipeline that takes the chain of credentials you've resolved runs it through a JSON auto template which transforms in to some other kind of JSON or maybe that itself generates the JSON schema that you then run but validating all of that is correct transitively might be quite a challenge.
Manu_Sporny: All right. So just re reviewing is this a valid use case? Yes, absolutely. Does it seem like it's something that the group wants to try and solve? I believe the answer to that is field match that solution? I'm hearing kind of at a high level, yes, it works for the GS1 use case, but we're concerned it doesn't work for others. and then maybe there's a little more, exploration that needs to be done around the use of JSON and other things of that nature.
Manu_Sporny: Paul, Todd, maybe it would help to go through the options here, but I think the thing we're most concerned about is are we going to accidentally block you in any way? Do you have some kind of hard deadline you're trying to hit? how much time do we have to try and address this challenge? Go ahead, Paul.
Paul_Dietrich: I think we're moving along with the spec. So, the hard deadline is probably your deadline, Manu, not ours. Meaning, we haven't released a version of this 2.0 data model. We'd like to. we've got pilots upcoming, but they're on a longer timeline than your working group. And so I think it's really, trying to finalize candidate drafts of this spec that's probably going to drive the timeline. That said, we've got resources to commit right now to help move that along. it's hard for us to come in and make up other use cases to see does this work for other use cases. we could, but I think it'd be probably not the best use of time. So, I don't know if the best use of time is to try to find other folks with similar use cases that either want to test this proposal or propose something alternate.
Manu_Sporny: Yeah, so that's all very helpful, Paul. but I think we're going to want to solve this as quickly as possible, Because I think the rest of the spec is Locked down we feel pretty confident that it's going to work for all these different communities. and so maybe what we do is we try and focus on this specific use case for the next couple of weeks to see if we can find alternate ways of solving this that we feel might apply to other use cases. So I don't think the ask is for GS1 to come up with some use cases in different industries.
Manu_Sporny: It's for the rest of us to see if we can see this happening in vital records or DMV or vehicle credentials or what these other industries that are going to be using recognized entities. and see if there are any other use cases there that we can see. and so that's item one is for the group to think about it as a group. And then item two is to see if there is potentially a more generalized way to solve the field match use case that gives us some confidence that we could use this thing elsewhere.
Manu_Sporny: So again to provide an extreme JavaScript code that is sandboxed and run against the entire chain of credentials I believe would solve just about every use case you could throw at it. The downside is now all of a sudden you've got to run this sandboxed VM in order in order to fully implement the specification. that's the biggest downside the other option is, Dave Longley suggesting maybe there's a JSON that maybe you can throw JSON at the chain and that gets us, far enough along. so we'll have to see.
Manu_Sporny: Anything else that we should add to this conversation? Paul, Todd, that the group should keep in their minds as we think about this over the next couple of weeks. go ahead, Paul. Mhm.
Paul_Dietrich: I was going to say one thing…
Paul_Dietrich: which again is the standards tradeoff that we don't know how many use cases that this proposal would cover. but we do know it covers this one. And so as we do versions of the standard is if you think this is going to be something that's useful by no one then maybe it's not the right approach. But if it's useful by some and then you can postpone the complexity of a generic approach to future versions I think it's something to consider.
Manu_Sporny: Mhm. Yeah. Yeah. Yeah. Certainly. I mean another option is like you do this as an extension right meaning GS1 would have this extension it would be in your recognized entity list but then I think you're back in the same place where you have to provide custom software to people right a library that people can use to process the recognized credential chain go ahead Dave
Dave Longley: Yeah, I'd like us to also try to expressing transitive rules of some kind. so that you could just express I expect this to be done transitively. if I recognize this issuer to recognize these and they may also issue any one of these. and that same rule applies with attenuation where they can only reduce the list of credentials that they're able to issue. something along those lines if we could express that that might also solve the problem without having to do this complex verification of other using JSON schemas that may or may not be dynamically generated stuff.
Dave Longley: You're muted.
Manu_Sporny: Yep. Go ahead, Paul. You might be muted.
Paul_Dietrich: I'm open to exploring that. I think if the transitive behavior was clearly defined of what that looked like, I could definitely sit down and see between that and generated schemas, can we make something that supports the model? I don't know exactly what you were thinking from forcing transitive behavior. but if you want to put something in the ticket, I can definitely look at it from this perspective of GS1 and see, how would it work? Would it make things easier or harder?
Manu_Sporny: All yeah, a plus one to that. So, I think we've got, a bit of homework to think about between, this week and next week. I think what we can do is we'll go off and think about this and then, come back next week, check in on it, see if anybody had any Eureka moments over the next week, and then we'll do that for a couple of weeks …
Paul_Dietrich: Oops.
Manu_Sporny: until hopefully we hit on a solution that, we're fairly happy with. the other thing, Paul Todd, is that we can always put in it's called a feature at risk. So we can always just add this to the spec and mark it as a feature at risk and basically tell implementers like hey this might change wildly over the next 6 months but we plan to lock it down before we do a global standard publish as a global standard. So there's time to work on this as long as you all have a couple of months that y'all can be flexible on what the final solution would be.
Manu_Sporny: All right. I think that's it for this item. Anything else before we move on to pull request processing? All right. And thank you Todd for raising that issue and we'll keep taking a look at it…
Manu_Sporny: until we find something that we get consensus on. yeah,…
Paul_Dietrich: Yeah, thank you Mono for bringing it to the conversation today and…
Paul_Dietrich: thanks everybody for your feedback.
Draft vocabulary definition by iherman · Pull Request #122 · w3c/vc-recognized-entities · GitHub
Draft Vocabulary And JSON LD Context
Manu_Sporny: no problem. All right. let's see. I'm going to go to poll requests. the first PR up and we're going to try and get through these pretty quickly. the first PR up is just a heads up that Avon has raised a draft vocabulary. PR this is every spec that we have that's an extension spec needs a vocabulary and a JSON LD context and that sort of thing. Avon has done his cut at that. there's a vocab directory that will have the vcabularyaml file in it with all of the things defined. I've taken a look at it and provided some feedback.
Manu_Sporny: And I suggest other people take a look at it. it's fairly, mundane stuff that needs to be done. so please take a look. It basically just establishes the recognized action, classes and property names and provides some documentation for them as well as JSON LD context for them. that's that item. Any questions before we move on to the next one? All right, that's 122. 123 issue 12 or sorry, pull request 123 is about an internationalization request.
Internationalization Of Legal Name Field
Manu_Sporny: So horizontal review was basically like hey you do not allow languages in some of your text strings you need to do that legal name specifically. what I ended up doing is, there's a PR raised for, BC data model and that is PR 1646 which I'll put in here and what that does is it more clearly defines this thing called a language value object and a language value object can have its basically
Manu_Sporny: language and text direction defined in it. and so that is going into the VC data model. There's a term that's exported called language value object and the legal name PR in the recognized entity spec uses that. So it uses a external reference and tells people go here and read about it if you want to learn how to use it. So this just needs a review from folks.
Allow legalName to be a language value object. by msporny · Pull Request #123 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: I think one of the other things that has come up in discussion is that we are currently struggling to figure out how to tell people basically a name can be a single string where the language is undefined or it can be a language value object where you define language in text direction. both of those are kind of optional things. or it can be an array of mixed values strings and language value objects that clearly has a downside where some of the languages are undefined and you have to use heristics to try and figure out if it's French or u Italian or Czech or whatever. and we're still trying to sort through those details, but that's kind of beside the point for 123.
Manu_Sporny: So that's is what legal name we're allowing it to be a language value bject. and this one specifically says one or more strings or language value objects a should not be there. okay that's it for this one. Any questions concerns before we jump to the next issue or next poll request is 124 and this one Philip Kolaric said, "Hey, can you provide an example of multiple language value objects or languages being used in a single string?"
<Manu_Sporny> Export definition of language value object; revise prose. by msporny · Pull Request #1646 · w3c/vc-data-model · GitHub
Example Of Multiple Languages In Strings
Manu_Sporny: And so, this one shows you how you can have a recognized entity credential. where the name and the legal name and the description support five different languages English, French, Japanese, Mandarin, Arabic which does right to left and Hindi as so this just adds an example I don't think very controversial at all.
Removing Use Cases Document And Updating Authors
Manu_Sporny: Any questions on this one before I move to the next one? We're trying to process all the lang we're trying to process all the language the internationalization horizontal review comments. All right, there's no questions on that one. This one is a little more involved. This is removing the use cases document, crediting all of those authors in the acknowledgement section and revising the editors and authors list.
Manu_Sporny: The reason this is involved is one we is a co-editor of the specification unfortunately I don't think he's been able to find the time to really participate in this group. I will note that Steven Kern's interested in editing this specification. and I think he'd be great there, but that needs to go through the main group and the chair's call tomorrow. so for now, I just moved Isaac down to a secondary editor. I put myself up at the top just because I've been the one that's doing most of the editing.
Add example that includes different languages. by msporny · Pull Request #124 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: And then we moved some folks that have not been participating I mean for the last five plus years Oscar Constantine Reeks Lena and we've added some people who have been participating Steve David Chadwick Dave Longley to the authors list again This is just a proposal. If folks have different ideas on who should be listed as editors and who should be listed as authors, let us know.
Manu_Sporny: And then of course in the acknowledgement section we thank all of the people that worked on this five plus years ago at multiple rebooting web of trust meetings and noted that their work on the use cases and the general requirements led to kind of the document that exists today. And then we take that document and we delete it because we're in version
Remove Use Cases document, revise editors/authors by msporny · Pull Request #126 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: control and we've published many versions of this and so if people want to go see the history historical stuff they can go and see the documents that were published in the past the date stamped ones I think that's largely for any thoughts concerns suggestions and if not please take a look and review. I would tagged most of you and then all the people that contributed to the use cases document over the last five years.
Holder-Based Delivery Of Recognized Credentials
Manu_Sporny: All right. If there are no questions there, this pull request 127 is an attempt to add a holderbased delivery section. I think yes, Stephen requested this.
Manu_Sporny: Dave, you requested some other things here that I don't know if it made it into this SPR. wait a second. Is this create demonstration? Yeah. Yeah. so this one adds a holderbased delivery section in the appendix and it basically says, a verifier can get a recognized entity credential in a variety of different ways. it can see that the credential that it was given has a recognized entity kind of reference and it can kind of follow that all the way up the chain.
Manu_Sporny: It can get a credential and just based on the issuer and the issuer's controlled identifier document did document can go there discover a recognized entity chain crawl all the way up that or it can be given a recognized entity credential alongside the verifiable credential. So if the holder is just like here's a fresh recognized entity credential as of today. in fact here's the entire chain. Here you go. So the verifier doesn't need to go outside and you during the transaction anywhere other than what the holder gave them. and so It provides a sequence diagram of food safety authority and a food processing facility and a food safety inspector.
Add Holder-based Delivery section. by msporny · Pull Request #127 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: And the way that the information would be fetched to do that check offline. it says what typically happens in these scenarios. because it provides example credentials on what the holder would hand over for the food safety use case and then just steps through all of the things that would be checked and in what order. it also talks about the verifier can decide to reject things that the holder gave it and just hey I don't trust you sorry whatever even though these are cryptographically valid and whatever I want to go out and fetch a new version of it for example and then anyway it does a whole bunch of explanation that was requested in the issue.
Manu_Sporny: Let me stop there. if there are any questions on this for holderbased delivery. All right. If there are no concerns, it should be pretty straightforward. Again, it's just an informative appendix. this is a lot of cleanup work on the spec that it's been kind of floating out there. all right. This one's fairly significant as Refactoring the algorithms to extract the recognition. We're now calling the recognition validation algorithm.
Manu_Sporny: So in fact, it might be I don't know if I let me try and pull up the recognized entities spec. So in the specification today we have an algorithm section and we have credentialbased discovery like a section and an algorithm on how to go from a credential and see that there's a recognized entity chain and kind of flow up the chain.
Manu_Sporny: And then we have an identifierbased discovery thing which just you get a credential and you look at the issuers did and you kind of crawl that all the way to the top of the recognized entity chain. so we had those two things in there but we didn't have an algorithm related to how you actually determine if you recognized an entity. So this PR refactors into a separate algorithm called recognition validation. give me half a second.
Manu_Sporny: Let me see if I can maybe I've got this right and then let me see recognized entities. No, this isn't it. Hold on one second. What was this called?
Refactor Algorithms to extract Recognition Validation algorithm. by msporny · Pull Request #128 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: I've got too many whatchamacallits.
Manu_Sporny: Here we go.
Dave Longley: If you're looking for a branch name,…
Dave Longley: it's Refactor Algorithms.
Manu_Sporny: Yeah, thank you. That's exactly what I was looking for. Okay, there we go. so this refactors the algorithm. So we've got now credentialbased discovery and identifier based discovery, but we have a recognition validation algorithm. try and get this a little bigger so folks can hopefully see it. and it basically says it doesn't matter how you discover recognized the chain. It doesn't matter if you do it through credential based discovery or identifier based discovery. At the end of the day, you have a chain of credentials. You have the verifiable credential itself and then every single upstream recognized entity credential.
Manu_Sporny: So, as Paul and Todd were saying at the beginning of the call, it could be deep the chain. but the way you decide whether or not you recognize, the issuer is by crawling the chain and going up the chain. And this is an algorithm that basically does that here. It tells you what you're supposed to do and at point recognize the entity. And this also does at what point you recognize the entity. So will be set to true. And then whether or not you recognize the action as well whether or not the action is recognized as well. and there's output validation stuff that's done here as well as a proc part of the output validation is processed here as well.
Manu_Sporny: So, this is something that Steve Capel asked for. I believe it's now done. did have to refactor credential based discovery and identifier based discovery to get it to all fit together and work. and also did an LLM based implementation purely based off of the text in the algorithm section. and it seems to work. hopefully didn't hallucinate something in there, but please take a look at it if you can. I've gone over the algorithm multiple times and I can't see anything wrong with it. but that doesn't mean I didn't miss something.
Manu_Sporny: So, that's, PR 128. Any questions, concerns about this PR?
Manu_Sporny: Go ahead, Dave.
Dave Longley: This doesn't need to go into the PR.
Dave Longley: I mean, it could, but having two different variables, one that's recognized and the other one that is action recognized, I would recommend that they have similar names. unless recognized encompasses the action that's recognized, we should probably put an adjective on recognized as well.
Dave Longley: So it's like entity recognized and action recognized both of those together. just depending on how it's written.
Manu_Sporny: Yep. Yeah.
Manu_Sporny: Did you note that You can just put it as a general comment and…
Dave Longley: I was trying to find the best place to put that. I'll just put it somewhere.
Manu_Sporny: I can Yeah. Or just, do a change suggestion for one of the variables and I can make it throughout. Thank any other comments, concerns, questions? All right. And then the last PR, just to make sure we got through all of these, is PR 129.
Manu_Sporny: And what that PR does is there is most preserving to least privacy preserving ways of searching the recognized entity chain and It documents it in the threat model where we're like, hey, the way that you fetch a recognized entity credential matters and because we have identifier based discovery and holderbased like discovery or whatever delivery. each one of those has a different privacy danger.
Manu_Sporny: And so we kind of try to speak to those privacy dangers in about a paragraph here. So take a look at one thing that was surprising to me in going through this is that there's a different pcy outcome There's a different privacy there different entities affected for each mechanism that we have. and there's the most privacy invasive thing is to do the identifier based discovery, which was initially kind of surprising to me, but then I was kind of like, I guess that does make sense. it's a very specific, thing that the verifiers, fetching.
Manu_Sporny: And unless the entity exists on multiple different recognized entity lists like which verifiers are interested in you as an issuer basically unless you use OHTP or something like that. So I thought that was an interesting privacy outcome. So please take a look. again it's all non-normative stuff kind of warnings but thought that was interesting. I think that is it for all of our poll requests. I may end up merging these by the end of the weekend if I get enough reviews on them. And if not, we'll just, ask people next week for more reviews. all right. I think that's it for our call today.
Manu_Sporny: Everyone please try to think of the GS1 use case and that transitive issue. We'll try and talk a bit about that next week and then do some more PR processing. That's it for our call today. Thank you all very much. Have a wonderful rest of your week and…
Paul_Dietrich: Thank you. Bye-bye.
Manu_Sporny: we'll meet again next week. Take care. Bye. Meeting ended after 00:58:25 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.