Meeting minutes
Todd_Snyder: Good afternoon everyone.
Manu_Sporny: Good afternoon.
Todd_Snyder: We're getting started. Manuel, I have a question for you.
Manu_Sporny: Just remember calls recorded.
Embedding JSON Schema In Recognized Entities
Todd_Snyder: Yeah, that's right. is it possible to embed the JSON schema for recognized entity inline? We didn't see an example.
Manu_Sporny: Yeah.
Manu_Sporny: Yes, it is technically possible. it is. Okay. So you
Manu_Sporny: mean in the recognized entity credential for the field that talks about JSON schema is it possible to embed it directly the answer is yes you can always use a data URL for the ID or…
Todd_Snyder: Yes. Mhm.
Manu_Sporny: just use a data URL I don't think we have an example I started out with an example for that in the spec and…
Manu_Sporny: took it out because I think I took it out because it felt a little too complicated but yeah, I think the answer is We should probably get clear about that and have an example in the spec around that.
Todd_Snyder: Okay. Yeah,…
Todd_Snyder: it would be good to have an example. I know it's something we are considering because of the volume of company prefixes we have in the US.
Manu_Sporny: Yeah. Yep.
Todd_Snyder: So the idea of having millions and…
Manu_Sporny: Yep. Yeah.
Todd_Snyder: millions of JSON schema files sitting around. So we should be able to embed it. So yes at the top level that's well known.
Manu_Sporny: Yes. Exactly right.
Manu_Sporny: That was one of my questions when I was putting together some of the GS1 examples. I was like, " man, this could get pretty unwieldy pretty quickly." Right.
Todd_Snyder: Everybody knows that every country has a set of known entities from global. But once you get into the individual MOS like the US, we have millions and other places over the world,…
Manu_Sporny: Yeah. Yep.
Todd_Snyder: Germany and stuff, they're going to have billions too. So, okay,…
Manu_Sporny: Yep. Okay.
Todd_Snyder: that is one of the things we were considering. So, it's good to know. Okay.
Manu_Sporny: So, let's make sure that we've got an example there. Basically, what that means, and let me go ahead and share my screen. basically what that means is actually let's talk about what that would mean. output validation, you could definitely do type JSON schema and then the ID could be a data URL.
Manu_Sporny: I think that's one way that you could do it. The other one that I'm wondering about is if you could have output validation and…
Manu_Sporny: then just a string that's a data URL.
Todd_Snyder: Yeah, I was specifically looking for the Jason schema.
Todd_Snyder: Let me embed it in here.
Manu_Sporny: Yeah. Does anyone have a strong preference?
Manu_Sporny: Dave Longley Benjamin Go ahead, Benjamin.
Benjamin_Young: Yeah, the data URL is existing plumbing,…
Benjamin_Young: stick it in the ID, but it is then a pain to work with because you have to have something to process it in and out of that. So if you were to put in an entire JSON schema though it's as an object then that's going to affect context itself and we probably would need a separate term to hold it…
Benjamin_Young: which we could have a term and add JSON it into the graph.
Dave Longley: There's existing work.
Dave Longley: from the previous iteration of this working group on JSON schemas and there's already a term and it might already be in the VC2O context called JSON schema or something that is defined as at JSON type where you could embed a schema directly and using that mechanism Yeah,…
Manu_Sporny: Where is this? Would that be in V2?
Manu_Sporny: Right. …
Dave Longley: if you search for Jason Yeah,…
Manu_Sporny: yeah, it's here in the types JSON schema.
<Manu_Sporny> vc-data-model/contexts/credentials/v2 at main · w3c/vc-data-model · GitHub
Dave Longley: there it is. Yep.
Manu_Sporny: So we already have it.
Benjamin_Young: Yeah. And it's done just…
Benjamin_Young: what I described.
Manu_Sporny: Okay. yeah,…
Todd_Snyder: Yeah, send link there.
Todd_Snyder: Drop that in there. That would be good to look at.
<Benjamin_Young> JSON Schema media type, fwiw: application/schema+json
Manu_Sporny: let me but I was thinking I mean yes we can do this right.
Manu_Sporny: So 100% we can do this. I was wondering about output validation is a can be just a string that's a URL and we could do data colon application/json- schema and then a big B 64 URL included thing for output validation. Do we want to support something like that or…
Manu_Sporny: not? Yeah.
Dave Longley: I would think it's going to be automatically supported.
Dave Longley: If somebody puts it in there, someone's going to consume it. It's already baked in. That's a valid URL.
Manu_Sporny: I guess what I'm saying should we in the spec explicitly state that is one way you could do it. It's going to exist whether or not we allow it, right? Because it's just JSON LLDD and that it's legitimate and legal.
Manu_Sporny: Should we be telling people to do it that way? If you're going to embed it, just do it that way versus create an object,…
Manu_Sporny: type JSON schema, and then JSON schema lowercase and then the value as JSON. Go ahead, Benjamin.
Benjamin_Young: Yeah, it really depends on…
Benjamin_Young: how implementers expect to work with the thing. because there's, round tripping in and out of B 64 or whatever escaping you've got to do if you don't base 64 if it's in the ID value. So having them as non-native JSON certainly feels super awkward when we've done it in the implementation details in the test suites. We do that with Zcaps. They're just inlined as escaped JSON blobs which means you can't really use JSON path on them or JSON pointer find them any other way than text search. and you can't manipulate them that way either. So if you were to inject them here,
Benjamin_Young: You have to have some little bit of script somewhere that takes your JSON schema, stuffs it in the ID value with basically turns it into a data it's trivial code to write and run, but that becomes prerequisite for any time you touch the inverse is that now that actually becomes a graph identifier, which is kind of weird, but possibly fun and useful. so that you can then talk about that thing if you're plumbing the whole thing into a graph. whereas you don't get that with the JSON s at JSON value only side. you can't really talk about it because it's not a subject in triple terminology. It can only be the value.
Benjamin_Young: I don't know if that last bit made sense, but p p p p p p pragmatically if you do stuff it in an ID and certainly if you base 64 encode that data L, it's illegible. It's not, encrypted or anything. It's just illegible. so be you have to think through what you want to touch or we do as a group and what you have to do to unpack being able to do stuff with it, which can be seen as a pro or a con depending on what you're trying to accomplish. So maybe Todd for your schema question, it might be good to talk more about…
Benjamin_Young: how you expect to use it or who you expect to use it. Go ahead, man.
Manu_Sporny: Yeah, I guess…
Manu_Sporny: what I was trying to get to is I mean yes, all of that is true. We should probably provide some guidance in the spec, meaning the first thing is do we suggest you can do either or do we strongly suggest one way version over the other? and if we say either or we have to say the benefits and drawbacks of it and maybe we should raise this as an issue to provide guidance related to base no to data urls when used with output validation and
Manu_Sporny: other objects types. specification LD allows data urls to be used anywhere regular URL can be used. we should provide guidance. This is probably general guidance that should go in the VC. C data modeling not here but we can start it here. We should provide guidance on when and where to use data urls us JSON values versus base.
Manu_Sporny: I can just start there and…
Todd_Snyder: Yeah. So again,…
Todd_Snyder: I think for the GS1 use case, it's definitely something we want to explore instead of having the u a separate JSON schema file that basically also encodes the license value.
Manu_Sporny: Okay.
Todd_Snyder: So, yep.
Manu_Sporny: So, we're tracking it. we'll discuss it and come back to it and try to get a concrete answer back to GS1. all right. let's go ahead and kick off the call. welcome everyone to the recognized entities call. this is August 18th, 2026. this is a W3C verifiable credential workg groupoup task force call.
Manu_Sporny: all W3C policies apply to this Reminder that the call is being recorded. let us know if that is an issue for you. today on the agenda, we have a number of items to go through. It's largely going to be issue processing. We don't have any PRs. I know GS1 is working hard on this PR. Phil provided an update to note that they still need to do a couple of things to bring things in line with recognized entities. so that's totally fine and we'll do that before we go into CR. and the rest of today is largely going to be about issues. Does anybody have any updates or changes to the agenda? Any announcements? Anything else that we should cover today?
Phil_Archer: I will just note that an issue that was raised on this call recently I think last week possibly the week before about the multibase digest SRRI issue is on tomorrow's full working group meeting as an early agenda item in the hope that you can be there for that Yes.
Manu_Sporny: Go ahead,…
Manu_Sporny: I will be there. Sorry, I just killed a window instead of unmuting. And thank you for chasing that down, Phil. All right. we have a set of issues to go through. basically, let's see. I'm going to try and put these in here.
Internationalization: USA-Centric Examples
Manu_Sporny: list of issues try to cover today just in the chat channel. and so let's go ahead and start with issue 110. we have been getting horizontal review feedback which is great. Addison is on top of things as always. so we're gonna try to process internationalization looks at the specification with a particular mind around can people in other cultures in the world that speak other languages have other writing systems? can they use this specification? are there any potential issues with it?
Manu_Sporny: So the first one that Addison raised is that he thinks our examples are a little too USAacentric. and he said specifically we say such as a county, city or state agency when we talk about vital records agencies and he said why don't you instead say city, regional or provincial agency. So we can update that. That's an easy change to make. would anyone object to that change being made? Just making the change that Addison want us to make. And I said we should be able to easily make all that's 11 next topic up is 111.
<Manu_Sporny> List of issues we can try to cover today:
Examples are USA-centric? · Issue #110 · w3c/vc-recognized-entities · GitHub
Internationalization: Legal Name Language
Manu_Sporny: Whoops. Not that one. 111. And It's a good catch. This is exactly why we have horizontal review. he said the legal name does not permit a language value object. so basically we say a legal name can be a string but Addison is like yeah but you don't specify the language or the direction of the string and therefore it's not compliant from an internationalization standpoint.
Manu_Sporny: I basically said, "Yeah, you're right. we really should be saying something like internationalized string or something like that." And, Addison came back with a lot of good stuff. but he said, "Why don't you say localizable string?" and this is something that we may want to define in the VC data model as a exported definition because we say string in a lot of places where we don't actually mean localizable string because JSONLDLD allows strings to be localizable because we build on top of JSONLDLD we allow all of our strings to be localizable but we don't say it outright and Addison also pointed out something very good which he was like I was like localizable string for all the strings and he was like nope that's not actually right
Manu_Sporny: For example, types can be strings, except I think we say they're URLs. but we have enums and things like that that are not supposed to be localizable. So meaning like an enum string or something like that, we should use string. But if the thing is supposed to be localizable, we should use localizable string or language value object, which is a little more of a mouthful. so I'd suggest we create a definition in the verifiable credential data model, which is where we talk about localizable strings. and we then update the recognized entity spec to say that things like legal name are localizable strings.
`legalName` does not permit a "language value object" · Issue #111 · w3c/vc-recognized-entities · GitHub
<Phil_Archer> As a non-American, I often feel that our docs are very US-centric, so I agree with Addison.
Manu_Sporny: We have a number of other properties that localizable value as Dave Wley is saying in the chat channel. So that would be the proposal to address this issue. thoughts,…
Manu_Sporny: concerns, objections on taking that direction. Go ahead, Benjamin.
Benjamin_Young: Yeah, I think he's just calling out that…
Benjamin_Young: if it's a string, the localizable addition of that lets you know that it can be in the overall language of the document, which might not be English, I think the key thing I would add is I don't want to lose the use of the language value objects because that is what provides our language credential capabilities. so we need to make sure that that hangs around for these values and not paint ourselves in the corner by only ever allowing strings for these values. But otherwise it sounds right.
<Dave Longley> perhaps "localizable value" which is defined as a string or LVO
Manu_Sporny: I mean his issue was exactly what you said Benjamin and then he suggested we basically say it can be a local string or localizable value and then we define that in the VC data model as a string is a string as infred defines it and…
Manu_Sporny: a localizable string is a language value object as defined by JSONLD or whatever the term is in JSONLD.
Benjamin_Young: So he's using that is synonymous. I got you.
Manu_Sporny: He's saying So BCDM probably should have provided shorthand for string or localizable value object. And I'm saying yes, we agree with you.
Benjamin_Young: I stand now. Yep.
Manu_Sporny: We should do that in the BC data model. and then when we define whatever this term is we'll call this thing a localizable string is a string as defined by infra or a Localizable value object is effectively what JSONLDD's language thing provides.
Manu_Sporny: We'll define that in BCDM and then we'll call that thing a localizable string and then we'll update legal name to be a localizable string. It must be a localizable string. plus
Benjamin_Young: Yeah, I think my one concern…
Benjamin_Young: then is that saying localizable string does not let my brain go to JSON object. It wants there to be some magic string, which this is not. but I understand that second paragraph now. plus one having a shorter phrase for string or language value object. Go ahead, dude.
Dave Longley: Yeah, that's why I suggested localizable value and maybe it even needs to be language localizable value to be more specific. I don't know. But we can come up with some name for it and then use that in these
Manu_Sporny: And the other thing I'm a bit concerned about is why does the internationalization group not have a word for this thing? And maybe we could because they talk about Jason LD, maybe we can point to something that they have.
Manu_Sporny: But if they had something Addison go ahead, Benjamin.
Benjamin_Young: Yeah, Jason LD is…
Benjamin_Young: what they have. in point of fact, Addison wrote a whole thing called string meadow where he went over all the W3C ways of doing, actually internationalizable strings in JSON. And, Jason LD won the day. it's at the bottom there you go. And he points to you could come up with your own JSON format that does exactly what JSONLD does, but maybe don't. So, there you go. Contain localizable text. And anyway, yeah, it was a deep analysis he did five, six years ago, and the JLD working group was doing 1.1
Manu_Sporny: And does he define anything in here that we could reuse.
<Benjamin_Young> +1 to localizable value
<Phillip Long> Isn't LVO sufficient?
Benjamin_Young: Not sure.
<Dave Longley> LVO is insufficient because it doesn't cover "string"
Benjamin_Young: He mostly points to stuff done elsewhere. I don't know that he calls the JSONLD version anything else. If you search for at DI or something, there might be a better example.
Manu_Sporny: Use the language and direction fields to supply the document level defaults. That's document level. That's actually useful for a render method discussion.
Manu_Sporny: But language maps yeah. Okay.
Benjamin_Young: Yeah, which is another JSON know the option obviously and…
<Phillip Long> That sounded like the brain problem (LOL) Benjamin was describing he was having.
Benjamin_Young: then this is the defaults.
Manu_Sporny: I will raise the PR and we can fine-tune it in VC data model. so the group 68 LON and decided to take to attempt a PR that does the following. define an exported term.
Manu_Sporny: That is along the lines of localizable. What word did you use? Dave localizable value local language localizable height.
Dave Longley: Yeah, I said localizable value or language localizable value.
<Phil_Archer> LVO most commonly stands for Lieutenant of the Royal Victorian Order
Manu_Sporny: Let's try localizable value first. That the second one's a bit of a mouthful. as long legalizable value that states that is either a string or an object that follows the JSON LD lang.
<Dave Longley> it's important to remember that someone reading the requirements will frequently do so in a vacuum ... so it's got to be sufficiently rigorous to cover things just in terms of basic types
Manu_Sporny: language value language r pattern. How we refer to that exported term from any VC G specification that needs
<Dave Longley> infra types, etc.
Manu_Sporny: that supports lies of value. How does that sound to folks as Any objections to that as a path forward?
Manu_Sporny: Go ahead, Phil. It does.
Phil_Archer: No objection man of course…
<Phillip Long> @Phil A - LOL, I'm sure we'll see these local confusions with some frequency.
Phil_Archer: but I wonder whether that's something that needs to be ported across to other task forces in the group in general.
Manu_Sporny: How would you like to handle that, I'd suggest let's raise it as an issue on the BCDM. have a discussion in the BCWG,…
Manu_Sporny: and if the group is okay with it, then we tell the task forces to go forth and use the new exported term.
Phil_Archer: Exactly. …
Phil_Archer: so when we get to the task force updates tomorrow, I hope you'll raise that.
Manu_Sporny: I will try to yes I will raise it as an issue.
Phil_Archer: Mean,…
Manu_Sporny: I will don't know
Phil_Archer: I mean, having all that I mean,…
Manu_Sporny: if I'll have the PR ready by then.
<Phillip Long> thanks for the clarification @Dave L
Phil_Archer: no, I mean, just mention it. hey,…
Manu_Sporny: Sure thing. Phil Archer:
Phil_Archer: there's something coming down the pipe. I don't mean have the issue raised and the PR written and all the cookies spokes and everything else. No, I just mean, hey, this is happening people. That's it.
Manu_Sporny: That is a reasonable request. go ahead Benjamin.
Benjamin_Young: Yeah, for…
Benjamin_Young: what it's worth, some term already exported is value object. which is, what Addison's pointing at so value object is already a defined phrase to mean what this thing can be with value language and direction because it's a JSL document. It has those as well as others available. There's a link in the chat for that full definition.
Benjamin_Young: So what we're I think aiming at defining here is the additional bit that says string or a JSON LD value object…
Manu_Sporny: Yes, exactly right. Yep.
Benjamin_Young: which just for those who don't know JSON LD is table stakes for using JSON LD pretty much everything can be a string or a value of
Manu_Sporny: Let's see. All So we'll get that PR raised and discussed on the call tomorrow. That is Anything else on this item before we move Issue 112 is next.
Manu_Sporny: And this is the last internationalization thing that was so show some nonasky non-English examples and label the English. so basically put together an example that includes some multilingual examples. typically we mix in English, French and Arabic. as the end of the example because that has text that's right to left text that is English and maybe we want to show English versus other Englishes around the world. and then I think it's just great an example. so maybe
Manu_Sporny: Tiny Tots has a no that's not we'll use a different example because that's got a region that's tightly tied there. we'll figure out something. but basically raise an example so I can raise an example and then people can take a look at and see if they agree or disagree with it. and we usually raise the examples early in the spec as one of the more complex examples. so we do the simple examples first and then we're like and if you need to support multiple languages here's an example of a credential that you might use in Morocco for example. okay that is that item. any objections to just creating an example here?
Manu_Sporny: So, that'll be recorded there. Let me make sure that these are basically and discuss and they're ready for PR. This is 111. We discussed it and we're ready for And then 12. We discussed this and we're ready for PR there as well. All right.
Show some non-ASCII/non-English examples and label the English · Issue #112 · w3c/vc-recognized-entities · GitHub
Normative References For DID Services
Manu_Sporny: Next topic is 117. So this one normative references to who is service and path service. So avon pointed out that we talk about this discovery mechanism in the specification and we even have algorithms on how to do the discovery. we don't have any normative references to who is service or the path service. the reason is because those things don't exist yet because the did working group is still working on them.
Manu_Sporny: I am a little concerned we do describe it in detail here to the point that we don't need to refer to it normatively outside and that was done on purpose because we have no idea when the did resolution spec is going to go to wreck and that is if we make a normative reference to that specification it is going to hold up our specification until did resolution is at wreck and the timeline for that is unk and personally I would rather not put that spec in the path of this spec getting to wreck.
Manu_Sporny: So what we may do here is did working group if they can give us a timeline on when who is service and path service is going to be finalized and if they can't give us a date then we're going to define it as we do in the spec and we would love to hear their input on anything else that we should change to define it in this way and let them know that we're doing it because the spec's not there and complete and once they complete it then we can update the references but until that happens we don't really want to tie our spec to their spec it's on a different timeline. let me stop there.
Normative references to WhoisService and PathService · Issue #117 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: thoughts on that as an approach to address Avon's concern here?
Manu_Sporny: Go ahead, I think the hope is they will be done in a matter of months,…
Phil_Archer: I don't disagree that being dependent on someone else's wreck is something you only do…
Phil_Archer: if you absolutely have to. But they are in So presumably they're already got a good idea of implementations and I don't know. I'm not active in that group. so I can't say but it sounds as if they may be done in a matter of months but I could be wrong. Yes. Okay,…
Manu_Sporny: Phil. and we have been hoping that for all more than a year.
Manu_Sporny: So being a regular participant in that group I am not as sure of that timeline as you might be.
Phil_Archer: fair enough.
Manu_Sporny: You are right.
Manu_Sporny: they are in CR. they have not yet u defined how pad service works specifically and who is service is still up in the air and it's noted as things that are at risk and are going to change during CR but it's mush right now and…
Phil_Archer: Yeah. Yeah. Yep. Right up.
Manu_Sporny: people are arguing specifically over those things and anyway that's kind of the current state if you
Manu_Sporny: If I were very sure about where we were on implementations with those features, I would definitely say yes, absolutely there in CR. We've got two implementations, no problem. I don't think we're there. what want do? do we want to just say, "Hey, we'd love to refer to something. Can we do that? And if so, what's the timeline to get direct so that we can get direct? And if they can't give us timeline, then we keep it is. And we say, "Hey, please." And if you can't give us timeline, please look at the algorithm we have and point out anything that we should update so that it will be compatible with whatever you, do when you get to Wreck.
<Phillip Long> I agree with Manu - but there remain some ... challenges that aren't clear will be resolved soon
Manu_Sporny: …
Manu_Sporny: notify the Go ahead, Phil. Yeah,…
Phillip Long: Yeah, I would actually turn it around and…
Phillip Long: present them with what you've got written there because that might speed up the process and at the end of that you could say if you can tell us when you're going to get to wreck then fine but would this suffice for now and does this align with what you're thinking of anyway?
Manu_Sporny: that's a good idea.
Manu_Sporny: Who is service? let's see.
Phillip Long: It's too fractious a group that I think that…
Phillip Long: if you give them something simple like that, it might
Manu_Sporny: Yep. Agreed.
Manu_Sporny: like Mor and see if able to get adopted div reference and provide a timeline to the CG on The timeline is not then ask them to provide input on what we have. that will align with there.
Manu_Sporny: normative reference time and at point future. Okay, how does that sound to folks? Any objections on us taking that approach? All right, then. That is discussion. Where are we? We're not quite ready for PR there.
Manu_Sporny: I guess it's ready for PR in that they can raise a PR using our text or we have effectively something there. I just don't want to come back and have to redisuss this. I don't know. What do we do here? This is in a weird state. I'll just mark it as ready for PR and then an editor will see it and go to write a PR for it and then see that now they actually need to move it forward.
Manu_Sporny: Here maybe we can ping the chairs of that group and yep that's them. Okay. So that's that item. Let's see. Next issue 117. Is Kevin on the call today? Kevin not. So we can't process his issue 85. Next one up would be issue 107 then.
Manu_Sporny: and All fine the UNVTD examples. we did get feedback from John which I have not had a chance to read in depth. So I'm just going to put this on the screen so everyone can read There we go. It's on the screen so folks can read it. I'm reading through it as
Todd_Snyder: I assume that the grid project or somewhere you can get more details about it. I know he talked a little bit about it when he presented this last week,…
Manu_Sporny: Yeah. Yeah.
Todd_Snyder: I think it was, but I'm not familiar with what that is other than he was it was in the context of the UNP.
Manu_Sporny: We do have this thing where I think they link to grid catch gtr.
Manu_Sporny: Where's the somewhere in here? Go ahead, Phil.
Refining UNGRID / UNTP / UNVTD Examples
Refine UNGRID / UNTP / UNVTD Example · Issue #107 · w3c/vc-recognized-entities · GitHub
Phil_Archer: I'm not involved in grid,…
Phil_Archer: but I know what it is. and it's an offshoot of the UN Transparency Protocol that Steve Cabal has been running or working on for years. so Tom, this is a way to publish a list of recognized organizations that do things like accredit certification bodies and company registers and basically government registers of stuff. so it's kind of if you think of it as a list of people…
Todd_Snyder: Gotcha.
Phil_Archer: who can recognize entities because the law says they can.
Manu_Sporny: And so there are two things he's saying we can do. The first one I understand which is John had suggested we put some dashed lines about around things to kind of establish the domains of control that each organization has and where their influence stops. that's fairly straightforward. I know how to run some, graphics experiments to see if we can get useful diagrams out of that. And if we're able to get it out of that for grid, we could probably apply the exact same thing to the GS1 case up to Phil, you and Todd to let us know if you find it valuable for your diagrams. So, this one's fairly straightforward. Know what to do there. I don't know what to do with number two. Does anybody else have any idea?
Phil_Archer: I'm just reading it out for the first time. Sorry.
Dave Longley: I'm going to assume that responsibility for the data refers to who has made the claims not how you're managing or storing the information and other kinds of responsibilities and I can see how having some visual representation that someone could follow in these diagrams to see who has made the claims and who's verify ing what could be helpful. I'm not sure how easily it's accomplished. That doesn't mean it can't be done, but that I'm reading number two is very similar to number one.
Dave Longley: I don't know what the necessary difference is other than there's verified seems to be different since you're just checking you you've determined who has made the claims and what claims they have made and that's just an assertion or…
Dave Longley: a check that what happened in number one matches I don't know…
Manu_Sporny: Yeah, maybe.
Dave Longley: if any of that's helpful.
Manu_Sporny: I was thinking that he just wanted these to be listed on the credentials somehow as text,…
Manu_Sporny: but maybe not.
Dave Longley: One concern I have there,…
Dave Longley: I mean that might be fine for the grid project, but I think authoritative, we've gone through great lengths in this spec to not refer to things as authoritative. but have a wide drawing a wider circle there where authoritative can be a reason that you accept things but anyone can accept anything and you don't have to accept some random person's list of things they accept on the internet. You don't have to use that. so I don't think we should introduce language like that. unless it's highly use case specific and then I think we're going to lose some value in the example.
Manu_Sporny: Yeah, Bill, go ahead.
Phil_Archer: I don't disagree with…
Phil_Archer: what Dave just said. I mean I kind of get where John Phillips is coming from. So That's John Phillips who not to be confused with John Phillips that works at PepsiCo. that's kind of grid specific. That sounds like an application and I'm very happy for our standards to remain a bit more abstract than that. So I agree with Dave and so I think we could say to John, that the difference between authoritative and verified. I mean I understand that authoritative as I say it's because the law says this is the authority. That's what he's getting at. This is the company registered because the law in this country says And in that sense it is authoritative. But I think that's a layer on top of what we're defining here.
Manu_Sporny: Yeah, definitely agree with both of you. okay, and it could be that we're misinterpreting what he's saying and so maybe we should ask him exactly what concrete changes would be made to the spec based on what you're saying. and then the rest of the conversation's going to be injected into the issue tracker for him to take a look at. So the group discussed this on the 268 call Pelon and came back with the following. we can do the first item mermaid diagram.
Manu_Sporny: and see how people react to the update. We will do that. for the second item, some of us are concerned that we might be misinterpreting what you are suggesting. And we'd love to hear about what concrete changes you think would be made specification as a result of applying your suggestions. the group was concerned about adding language such as
Manu_Sporny: native to the specification. You've gone to great lens. Try and keep the more generic allowing for use cases and would be concerned that people would take the message away from reading the updates.
Manu_Sporny: You are suggesting as specification is meant for institution. This significant.
Dave Longley: You could say legal backing. Yeah.
Manu_Sporny: You please
Manu_Sporny: Okay, that's that item. all right. So, it just needs more discussion. and it's somewhat ready for Half of it's ready for PR. The other bit we don't know. So, we can just mark it as ready for PR. It does need a little more discussion. final one here. I think this one we can just make the update.
Explaining CRQC In Specification
Manu_Sporny: Let me this as a next topic. Ted, you suggested that people don't know what a CRQC is. a cryptographically relevant quantum computer which most people don't. and so we should talk about it and spell it out in the specification. plus one to so we should do it. That is the suggestion. any objections? All right.
Manu_Sporny: Thumbs up.
Dave Longley: And just a yeah,…
Dave Longley: quick note that the quote there says breaks cryptography. That should say breaks the anchor link that's in the quote on line 1626. That should say breaks traditional cryptography. So that we can correct that at the same
CRQC is not in general nor wide use (yet) and should be included in each document · Issue #115 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: Yeah, that's in the threat model, too. It needs to be updated there as well. All right, that's ready for I think that's it for our issues. There are some issues that are floating out there, but we are largely running out of issues to discuss, which is great. That's exactly where you want to get to as a working group. and once we run out of issues, we are effectively, unless somebody else can find another problem with the spec, which you can always find if you try really hard, we would be ready for, the candidate wreck phase, which means that we are then kind of stuck
<Dave Longley> should say "breaks *traditional* cryptography" (not all cryptography)
Manu_Sporny: waiting for our horizontal reviews. one thing that we could do is we could shift to talking about what a test suite looks like for this work and what you need to support and that sort of thing. So that might be where we have, discussions over the next, one or two calls, but frankly, we can maybe fill two to three calls with that and then we're out of content for that as so that's good. this is a lovely group. we love meeting with each other and talking about these things, but we might just have to end the group because we're more or less done.
Manu_Sporny: We'll back way off, maybe meet once a month, but there wouldn't be a reason to meet because we've pretty much done what we set out to accomplish. okay, I think that's it for today. Anything else that we should keep in mind before the call next week? All right. with that, have a wonderful rest of your week and…
Manu_Sporny: we will see everyone here next week. Take care. Bye.
Phil_Archer: Thanks, man.
Phil_Archer: Thanks, everyone. Bye-bye. Meeting ended after 01:07:28 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.