Meeting minutes
Manu_Sporny: Hey folks, looks like we've got a good group of folks to start. So, let's go ahead and get started. welcome everyone. This is the recognized entities task force call. this is August 11th, 2026. on the agenda today is basically taking a look at our poll requests. we have taking a look at our discuss issues and I think Todd we wanted to focus on the GS1 item this week and then any other discuss items we can look at with a focus on getting every issue to ready for PR or we took care of that we're done there. so that's kind of the agenda for today.
Manu_Sporny: Before we get started, a reminder that these calls are recorded. if you are not comfortable with that, please let us know. we also operate under the W3C code of conduct and IPR. our policies. I think everyone here is a member of the group, so I think we're fine there. any other updates or changes to the agenda? Anything else we want to cover today? All right, then with that, let's go ahead and jump in to our agenda. Starting off with poll requests.
Digest SRI vs Digest Multibbase
Manu_Sporny: We do need to process these. this one has been sitting out here for four months now. I think both, Shaga Sun and I, have said, GitHub's having a hard day today. I think we've said everything we're going to say on the topic. there. this is not going to work if GitHub's down. I'll see maybe if I try loading harder. There this is I think summarizing the positions. We had a discussion on whether or not we should support both Digest SRRI and Digest Multibbase.
Manu_Sporny: I made a case for let's just support one since it's just both of them are a hash of the remote resource made a case that digest multibase supports everything that digests SRRI does so we have the ability to reduce to one disagreed and said our projects use digest SRRI and here are the reasons to use them and we went back and forth and we just disagree I think we had broad consensus us to deprecate the feature in the core spec. Shea son disagrees with that and is objecting to that R going in. and so we're at a bit of a stalemate. I don't know what to do other than we just don't have consensus to deprecate and we don't have consensus to add digest SRI to this spec. And so I think that's where we are.
Manu_Sporny: If somebody has a suggestion on what we could do at this point, that would be good. I am because we're trying to clean up all the PRs and issues and get the spec done. I am suggesting that we close the issue because there's no consensus to merge this.
Manu_Sporny: Thoughts No, it wasn't. It was like, we have a digest multibase example in the spec. Let's also do a digest SRRI example in the spec. Correct.
Benjamin_Young: was Shagaya's request for more than examples of using digest SR,…
Benjamin_Young: That's what I just asked is if he just wanted another example. So would a bridge in between be near the multibase digest SRRI is in VCDM 2.x X and can also be used, if you know how to use it. it's not like Chagayasan needs help to use digest SRI. He knows how to use it. and it's not coming out of VCDM as far as I can tell. But we don't need to cover every other feature of VCDM thoroughly with examples. So maybe just say, there are other hashing algorithms. this is the other one currently defined in BCDM. And maybe that's an olive branch.
Manu_Sporny: Plus one to that. Any other comments on it?
Valid Until Property
Dave Longley: So, this says it adds it to the general properties table. I assume that's in this spec for the VC recognized entity spec. do we need to have either of these in the general properties table? one of the things I proposed in the last VCWG call was to keep digest SRRI in both in the spec and also in the context if we produce a 2.1 context. but note that the recommended one is digest multibase and say that extending specs will use digest multibase.
Dave Longley: that enables anyone to continue using digest SRRI if they want to. And if they're using VC recognized entities if they're using that context on top of the VC 2.0 or 2.1 context, they would continue to have access to that field without having to define it in their own context. it just wouldn't come with spec recommending using that particular one. And I think that was somewhat of a middle ground for what was proposed over on the VCDM issue. I don't know if what might help here is for general properties that are already defined, we might instead of calling them out once again here in the table, we might say all of the properties that are in the VCDM are also defined here.
Dave Longley: And that might help avoid further entrenching something that a significant number of us think we should deprecate because there's two different ways to do it and one of them has the problems mentioned on that issue.
Manu_Sporny: Go ahead, Phil. And you might be muted.
Phil_Archer: Sorry, I thought you were ahead of me in the queue, I do not have the technical knowledge to make any comment on the relative merits and demerits of the two methods under discussion. the proposal that Davis put forward to my point of view sounds fine but my view doesn't matter. What matters is that sheasan can live with the proposal whatever the proposal may be. So I really think whatever the future plan is, it must get the support of Shagayasan
Manu_Sporny: Is there anyone in this group that would like to chase that down? Because I've tried to do that and the only thing is leave everything exactly as So, I need somebody else to chase it down. To be clear, this is a hill I am willing to die on. I know it seems like a really dumb hill to die on, but there is no technical reason for us to keep it in the specification anymore other than someone is like,… Phil Archer:
Manu_Sporny: But I want to use it." it is the exact same technical feature. So, I'll just point this out removing stuff from here makes the spec less readable.
Manu_Sporny: We would delete all of this and people would not know that they can put these things on a recognized entity. we do say this is defined in VC data model and we point there for it. So we do that here. but I think digest SRRI is an anti-attern. We're not using it in the way it was intended to be used in browsers.
Manu_Sporny: it is being abused right so it is not digest SRRI what we've done in BC data model it breaks from the spec it's non-inoperable for all those reasons I don't know if people are aware but that's the reason I'm so opposed to it is that we have invented our own thing in VC data model it is not digest SRRI but we continue to call it that it's just bad it's bad spec bad implementation leads the non-interoperable implementations,…
Manu_Sporny: that sort of stuff. I'll be quiet.
Benjamin_Young: Yeah, I think…
Benjamin_Young: though where you started was that Shagay Assan has implemented it and is using it. So is like there are implementers on the ground that are using it. So unless there's some way to convince Chagayasan to change course either switching digest options or to more fully understand the interop problems. I don't expect him to not. So it's unfortunate he's not here and we're discussing it again without him but yeah it's usual pattern is if it has implementation we don't take it out.
Phil_Archer: I'm happy to take this on wearing my chairs hat. I'm happy to talk to Shagasan. so forgive as I often am at this time for me Tuesday evening walking the dog so I can't really see what's on the screen. but I think I understand that there is a PR ready to go and so I have the information I need to sort of a one-to-one call with Shagaya and Sandy.
Manu_Sporny: Thank you very much, Phil, for taking that on. So let's say that the next steps here are that the chairs of the BCWG will engage with Chaya to determine next steps here.
Dave Longley: And I just wanted to give voice to what I wrote in chat so Phil could also hear it. I think what I propose does not actually break their implementation in any way. It just would mean that we don't recommend that path as one for other people to copy.
<Dave Longley> it will not break their implementations to do what i suggested
Phil_Archer: Thank you, Dave.
<Dave Longley> it just won't be a recommended path for others to copy.
Todd_Snyder: Yeah, that sounds like something that makes sense. if something's not standard or following what we think in the main spec specification, we really shouldn't be offering it as a solution if it's not because then people are just going to copy it. So, yeah,…
Todd_Snyder: makes sense.
Manu_Sporny: Yeah. Sorry.
Manu_Sporny: Go ahead, Phil. Your hand's still up, maybe. Yeah.
Phil_Archer: Sorry, my mistake. Sorry. No. Thank
Manu_Sporny: And to be clear, that was The proposal was to deprecate it, not make it so that people couldn't use it. It was to suggest that people shouldn't be using it anymore. And that is what got objection. I'll also note that just because one imple out there and as far as we know, there's only one implement that's saying that they really don't want this thing deprecated, not taken out, just suggested that people shouldn't use it. it doesn't mean the working group has to support it. do people implement all kinds of stuff out there in the wild and that does not mean that the working group needs to implement it. suggested as the right path forward. Okay, we've got a next step there. go ahead. and I think Phil, you'll take that forward.
Manu_Sporny: Go ahead, Dave.
Dave Longley: Yeah, just really quick briefly,…
Dave Longley: my understanding, at least in some of the communications that I heard, was that the proposal was to leave it in the vocabulary, but you might have to make your own context to use it. And my suggestion was that you would not have to do that at all. and so it would just come baked in. It just wouldn't be recommended at spec
Manu_Sporny: Yeah, I don't think that was the proposal, Dave. It was to leave everything but put the text as this is deprecated. It may get removed in a future version.
Dave Longley: Okay.
Manu_Sporny: So there would be no change in 21. It's just we literally add the text like the working group doesn't recommend people use digest SRRA. it may be deprecated in future versions and there was an objection to even that language. So Phil, you've got an action. Thank you very much. we'll move on from here. all right.
Manu_Sporny: Let's see. Next from valid until. I think this one's ready to go. Unless Dave Longley, I know you had concerns about this. I think we discussed them. I don't think there was a change other than what's in there right now. and so I need to go and look at it and update it. But just to be clear, Dave Longley, you're not objecting to this being put in the spec.
Dave Longley: No, I think it needs to, have that other informative text that comes along with it. And we need to make sure that this only applies to the actions and so on. If we put these properties which is what if I read the diff correctly it's on recognized action right now it's not anywhere else because we put it somewhere else I think that would be objectionable and create issues and we talked either on the last meeting or the meeting before about how if there are changes to a did controller you would issue entirely different lists for points in time for who had control of those dids at those points in time. You would not try to issue valid until and valid from in the same list for a variety of different dits.
Dave Longley: I think that would just be way too much confusion.
Manu_Sporny: Okay. Okay.
Aligning GS1 Appendix
Manu_Sporny: So, I'll try to get this merged ensuring that that's the case a bit later. the next PR 108 and I should be subtopping these link address topic 108 is just Phil a line with the GS1 appendix. It's in draft. and Phil, you say ignore this for now. We'll let you know when it's done. So I'm doing…
Manu_Sporny: what you said. Okay, awesome.
Phil_Archer: Yes, correct.
Aligning the GS1 appendix by philarcher · Pull Request #108 · w3c/vc-recognized-entities · GitHub
Phil_Archer: Todd and I have a meeting tomorrow where we're going to be discussing this and we are working as fast as we can to get this result.
Manu_Sporny: Thank you very much, Phil. looking forward to that.
CRQC Threat Response
Add reference to VC Forgery Defense in CRQC threat response. by msporny · Pull Request #113 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: next item up was an issue that you raised. Phil topic. which basically said, "Hey, we should talk about the cryptographically relevant quantum computer threat and point to the forgery defense spec." that has been done. as Ted rightly pointed out, hardly anyone knows what a CRQC is. It's a cryptographically relevant quantum computer and we should spell that out in the spec. so we will do that.
Manu_Sporny: Thank you, for suggesting a change here. and we'll probably have to do that elsewhere. I also note that Ted, you raised an issue to do that in the spec. Yes, we should do that as well. So, try to modify this R to apply those changes. that's the forgery defense one. The other one is something that Avon Herman brought up which was that I think it was von. It might have been I think maybe Steve it was you said it and then Avon raised it as an issue or something like that but I'm going to go and look.
Manu_Sporny: So basically Avon wants us to point out that the recognized entity specification is a textbook example of why we built the VC data model in the way that we did right and so basically it wants us to state that hey this is just another verifiable credential there's nothing really special to it there's some
Note that the spec is an application of the VC data model. by msporny · Pull Request #114 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: algorithm that you can run to kind of crawl the credentials, but everything else about it is basically bog standard verifiable credential. and so there's a little paragraph added to that effect. here, the language, Phil refine Ted updated it again, and I will merge all of those together into hopefully something all of you agree on. So, it's editorial. We'll process that. this weekend. That is it for all of our PRs and the attempt is to basically keep doing these PRs for any ready for issue. the other issues that are left that we need to discuss are marked with discuss and some of these discuss issues might be ones that we can close.
UNTP Digital Identity Anchor Compatibility
Manu_Sporny: So ensure compatibility with UNP digital identity anchor work that was raised in February. I think the question to you, Steve, is have we done this enough? …
Manu_Sporny: to the point that you think I will note that we do have another issue that says refine the example. So I think so let me pause there. are we at the point where we can close this issue?
<Steve Capell> Wasn’t from me. But no objection
Steve Capell: Yeah, probably.
Steve Capell: I mean, what I haven't done yet is updated the DIA spec to be a profile of recognized entities. And in doing that,…
Steve Capell: when you think something's fine, then when you actually do it, you go, " I forgot about this." something might come up. I'm happy to raise another issue if it does. As far as I can see, it is closed.
Manu_Sporny: Yes, exactly.
Manu_Sporny: And that's what we would expect. So, we are done with it forever and you can't raise any more issues on it. we think we're done with the initial thing and…
Ensure compatibility with UNTP Digital Identity Anchor work · Issue #48 · w3c/vc-recognized-entities · GitHub
Steve Capell: Yeah. We got a credit.
Manu_Sporny: the next step is you've got to take a look at it, do some implementation work, see if it works out and then come back to the group so that we can update it if it doesn't. that you can do at any point before we go to a global standard. So you've got six monthsish probably at a minimum to do the work maybe up to nine months.
Manu_Sporny: All right. first stage of this work which was requested. future issue will be raised. Okay.
Manu_Sporny: So I'm going to say let's see discuss and then we did raise an issue for it and we can take the discuss label off. I did take that issue then that one's closed. Okay. Thank you Steve. let's see the VCI. Hold on one second. These are all pull requests. No, I got totally recognized the tease. All right, let's take a look at the other one.
Use Cases and Applications
Manu_Sporny: Are there any other ones that we could easily close? digest SRI is open, Phil, until you're able to chase that down with Chaya. use cases. and applications for this data model. Benjamin, you raised this I think based on a previous call in March. look for cross compatibility and means unify expressions. So we did the UNPDIA work.
Manu_Sporny: We haven't really done this stuff other than you can express X509 with it and in that way MDL's covered I guess the question is…
Manu_Sporny: what more should we do here and who is going to do that work? go ahead, Ben.
Benjamin_Young: Yeah, I should have put more provenence details in this post.
Benjamin_Young: It wasn't so much my idea. This was when I was cheering while you were away back in March. and these were things that the group had kind of listed off as things that existed in the space that would be good inputs and possibly be worth comparing and contrasting in the use cases. I don't know how many of them still make sense or like you just asked if anyone's motivated to actually write them up, but that is where this issue came from was collecting call time thoughts as I recall.
Manu_Sporny: Got it. So I guess the question is do folks feel that if we are there any volunteers to do any of this stuff I guess is the first question. I know we I'm fairly convinced that we've got that covered. Someone from checked would need to do this thing. I don't know how the EPC stuff works. We'd need someone with specialized knowledge there. Open ID Federation. Dimmitri mentioned he'd take a look at it. I don't think he's been to these calls in a while. So we could ask Dmitri about this. And the UD wallet trust list stuff is not necessarily complete.
Manu_Sporny: But we do have an example of other things that are close to the wallet trust list stuff that we know works and we know that we're fairly convinced that DIA stuff works and the GS1 stuff works. So do we want to continue to pursue this or do we want to say we're pretty sure this is done? and if so who's going to volunteer to move it forward?
Manu_Sporny: All right. So, not hearing any volunteers. let's say we've discussed this. I'm going to mark it pending close and then ask Dimmitri if he is going to do anything on Open ID Federation. we discussed this on the 2026 811 call.
Manu_Sporny: The group has looked at a out variety of systems that could use recogn and it works for those just one vital records MDL etc. there are no volunteers that want to you looking at the initial list.
Manu_Sporny: As of today, Dimmitri, are you going to look into Open ID Federation?
Manu_Sporny: If so, can you please raise an issue on that topic? if you to it, go ahead, Phil.
Use Cases and Applications for this data model · Issue #51 · w3c/vc-recognized-entities · GitHub
Phil_Archer: Just very quickly,…
Phil_Archer: you mentioned MDL. I just want to let you know that an application has come in for an invited expert status for somebody who is a member of the MDL working group. He's a newly retired keen chap called Jim Richards. and it's likely his application will be approved. He won't be on the call tomorrow, but it's quite likely he'll be joining the group fairly soon. So, he may well have and the reason why we've said yes is because it opens up the possibility and I hope the reality of a much better connection between us and the MDL group. So just to let you know that we may be getting that kind of cross fertilization. I hope it works out.
Manu_Sporny: Thank you very much, that would be And Dimmitri, good to see you on the call.
Dmitri_Zagidulin: Yeah, just joining late and wanted to ask this data model part is what the context for that comment.
Manu_Sporny: It's the recognized entities thing. I think we're basically saying open ID federation exists.
Dmitri_Zagidulin: Okay. Yes. Yes.
Manu_Sporny: If you wanted to do what's being done in Open ID Federation using the recognized entity specification, could
Dmitri_Zagidulin: Yes, I believe so. rather I can add input there since the GCC team did a comparison of the existing specs including the then version of recognized entities. selected open AD federation subset for a issuer registry case. did an implementation along with credential engine and credential engine is currently operating a issuer registry based on the subset of open ID federation spec.
Dmitri_Zagidulin: So yes, I do have some experience with it and I'm happy to what form would you like me to give input on?
Manu_Sporny: I mean it's basically…
<Dave Longley> or even just "how do you link to an OpenID Federation"
Dmitri_Zagidulin: Comments to the Uhhuh.
Manu_Sporny: what is your opinion that and Dave Longley added another thing you could do how would we link to an open ID federation declaration or can you just do open ID federation with the recognized entity?
Manu_Sporny: spec does a recognized entity spec have basically what you'd need to do a basic open ID federation. and…
Dmitri_Zagidulin: Got it.
Dmitri_Zagidulin: Got it. Okay. Yeah,…
Manu_Sporny: and it's optional, right? I mean it's kind of like I can take pend and close off until you do that work or we can just close this and then open one specific to open ID federation if you're still doing that.
Dmitri_Zagidulin: let's do that. Let's do that. Yeah. Sorry,…
Manu_Sporny: All So let's take pend and close off of here.
Manu_Sporny: Okay.
Dmitri_Zagidulin: let's close that one and open a federation one because that sounds
Manu_Sporny: All right. is going to look at how open ID federation could be used with the recognized entities specification. and then this one will be closed and then we will open a new one to refer to this one. determine alignment with open ID federation.
Manu_Sporny: And determine how someone using the recognized entities specification could either one perform the same basic functionality as open ID Federation or to link
Manu_Sporny: to an open ID federation a document to bootstrap into that ecosystem and then let's see I'll create this this is going to be assigned to Dimmitri and labels are right
Manu_Sporny: No, do we need to discuss it? I think it's just an item for you, Dimmitri, and you just let us know when you make progress on that.
Dmitri_Zagidulin: Okay, copy
Manu_Sporny: Okay, thank you very much, mitri. let's go back to the issues. all right. I just we dealing with our different types recognized in create vocabulary. We need to do that. thinking verifying recognition chains. I don't think we have Kevin on the call today. and then refine you and grid examples in process and let's deal let's process your one here. Todd, can you give us a brief introduction to this item so that we can discuss
Manu_Sporny: And you might be muted, Todd, can you hear us? Maybe he stepped away. I'll do my best to kind of go through this. I don't know Phil if you know anything about this transfer of ownership thing.
Phil_Archer: I'm just looking at it and I'm trying to get my head around it. Forgive me. It Todd has raised this and I'll ask him about it again tomorrow. But we have this weird pace that I mean if the tech can't support it then I think it's a weird one. So, being neutral, I think we just have to accept So, unconscious I'm walking and I think I was talking at exactly this point on my dog walk last week and it faded out. So, tell me if you're losing me. we have this weird thing where companies keep buying each other…
Todd_Snyder: I'm here by the way.
Recognized Entities And Transfer Of Ownership
Recognized Entities and Transfer of Ownership · Issue #109 · w3c/vc-recognized-entities · GitHub
Phil_Archer: selling bits of themselves to other people and that has an effect on. Charlie, you there? Okay. Todd, can you take over…
Todd_Snyder: Yeah, I'm back.
Phil_Archer: because this is your thing?
Todd_Snyder: Yeah, yeah, just we started to have a discussion and let me to remember that we do have as Phil said this not a unique thing but a common thing that happens. someone purchase a prefix or identifier from us and over the course of time they can discontinue the identifier or the product associated with it but they also can sell those products off to somebody else. So in our system internally we have the process of transfer of ownership.
Todd_Snyder: So today, Healthy Tots owns the D set of gitins and this prefix it rolls up to in the future it could be traded over I forget the company name I put in here but it was XYZ cookies or something or XYZ baby products or something. So the idea was just trying to make sure that we are covering this use case and that anything we would introduce example wouldn't necessarily break because behind the scenes there would be a different ownership. And the unique thing about this is it's a point in time. So if something happens today and Healthy Tots owns it and then three weeks from now it's owned by the other company, technically for anything prior processing this data, this was still owned by Healthy Tots. So that's sort of high level.
Todd_Snyder: having spent more time in the meetings and looking over the specification, I imagine we're just issuing different recognized entities to different credentials and that will cover it. I think I threw in here the idea that maybe we need to deal with the valid from and too for tracking purposes. that's sort of the high level. Any specific questions? Good.
Manu_Sporny: Yeah. No, the use case definitely makes sense, somebody effectively starts out with the identifier being owned by one organization and then they're subsumed into another organization. It's kind of transferred.
Todd_Snyder: Yeah.
Manu_Sporny: Two things come to mind. I mean this is talking about how driver's licenses which is in production your license number that's issued to you your literal driver's license number that's issued to you is not necessarily yours for your entire life. So if you move somewhere else that same license number can be put back into kind of a pool and then it can be reissued to someone else. And so the way we deal with this, use case in driver's licenses is we have revocation information on the license number. And so when that event happens, the credentials revoked and a new one is issued.
Manu_Sporny: I think the GS1 use case is different in that it is totally legitimate for you to issue multiple recognized entities that had the ability to issue under these G10 prefixes for a certain periods of time and having that as kind of like an audit record that goes back through time is a totally legitimate thing that you could do as well.
Manu_Sporny: So go ahead.
Todd_Snyder: Yeah, the license makes sense.
Todd_Snyder: It's a good example. The reality though is the license always has an expiration, Most states give you I think it's four years is pretty standard…
Manu_Sporny: Interesting.
Todd_Snyder: where in our case I mean there are G10s that were created 50 some years ago. They're still owned by the entity. So Yeah,…
Manu_Sporny: So, you probably wouldn't have a valid So, I guess that's the question. How are you dealing with saying that something's changed or updated on that thing?
Manu_Sporny: Do you revoke it and just say, "Sorry, this was valid at some point, but it's revoked now. You need to go back and get a new one from somewhere. We don't care where." Mhm.
Todd_Snyder: we haven't reached that production level. I know that at one point Kevin was working with the reaggation group to add a third type. I think it wasn't suspended. It was like a different type and…
Manu_Sporny: Mhm.
Todd_Snyder: that was one way we were going to try to handle it because technically it's not Revoked, we felt revoked kind of meant you can never use this again.
Todd_Snyder: It's basically valid to a point in time and then it is no longer valid after a date, right? Or some event. So Mhm.
Manu_Sporny: Yeah, another option is Yeah.
Manu_Sporny: So I remember that discussion I think it was an update exists for this thing like this is a valid credential.
Manu_Sporny: It was issued and we stand behind it still but hey some of the information has changed.
Todd_Snyder: Yeah. Mhm.
Manu_Sporny: you really should get the latest information if you're going to do anything with this. So there was a status that wasn't revoked but it was a status changed or the credential has been updated and then there is this back burner specification we have in the group called the refresh service the re ability to refresh a credential. So you would be able to check to see, hey, is there a newer version of this credential that exists? You would see the bit flip to one. a new version of the credential exists. Okay, I'm going to go down to the refresh service and make a request to get new version of the credential. And then you may or may not have the right to get a new version of that credential, right? but that's one way that we could do that.
Manu_Sporny: for GS1 the refres update exists thing can be done today but then we don't have refresh completed except that it is actually deployed in production at scale in the US at least for age verification I would love to hear from other folks…
Manu_Sporny: but I think that's the way that GS1 could address this use case. Is there any part of that that you think Todd wouldn't work?
Todd_Snyder: No, like I said,… we're still kind of working through our examples. So I think we just would issue another recognized entity pointing to the new company. and probably behind the scenes we would have to have something that the verifier could call to get the latest or the current state of things. So there are definitely some things we have to work out, but again it came up because we were having a conversation about switching things and I thought it made sense to at least go over it in the group as an example. Todd Snyder:
Manu_Sporny: Yeah, plus one to that. there is a part in the threat model that we should probably think about which is what does it mean to have a company prefix out there that doesn't have an update exists or…
Todd_Snyder: All right.
Manu_Sporny: revocation information. it would potentially allow an organization that has the private key, the old company to continue to issue things.
Manu_Sporny: So I do think it's probably critical to your threat model to ensure that you have something to signal that an update exists and…
Todd_Snyder: Yeah, makes sense.
Manu_Sporny: you really should update the credential because you're working with something that's out of date. Yeah, without that I think you've got an un unmanaged in your thread model. and then the JSON schema, I think, probably stays the same for the new credential because the prefix doesn't change, right? It's just owned by a different organization. So, the recognized entity would change. So, it's moving away from Healthy Tots to somewhere else.
Manu_Sporny: So you're basically looking at,…
Manu_Sporny: this stuff changing, but the license value in the JSON schema doesn't yep.
Todd_Snyder: And I think that the digest multibase would be different,…
Todd_Snyder: Because we'd issue a new JSON schema. But I guess the schema is the same, right? So we've talked a little bit about so today what we do is we have a lot of custom code. We actually verify the did. So we verify this healthy tot here. the subject is the issuer of other type of credentials. So that's something we've talked about briefly too.
Manu_Sporny: God. Mhm.
Todd_Snyder: Then maybe we also the did in there so we still have that validation which in that case it would be a different JSON schema.
Manu_Sporny: That's right. Yep. Yep.
Todd_Snyder: So I think we can close this issue.
Manu_Sporny: Totally tracking. Yep. That makes sense to me at least. let's see. Todd Snyder:
Todd_Snyder: It is more about was a discussion point …
Todd_Snyder: since we're at the time going over the GS1 stuff. So, I think it's fine to close this out now and once we come up with our version of these credentials, I'm sure we'll come back and review it with you what we came up with. So, Phil thinks it makes sense to keep it open.
Manu_Sporny: Okay.
Manu_Sporny: Yeah. okay.
Todd_Snyder: I don't think it makes sense.
Manu_Sporny: All right. That I think we can close it and everything that we just said will be injected into the issue when Avon runs his script. So I'm going to discuss this and explore several ways to ensure that this use case was covered by the technology and will do some further analysis and raise another issue if our initial analysis is problematic.
Manu_Sporny: At this point it seems like the group is working on technologies that would support a big caveat that we need to move on that refresh spec. okay that is closed. Thank you very much for the discussion. Great use case.
Manu_Sporny: Let us know if we need to do anything that we're not thinking of. okay. yes,…
Phil_Archer: Just very very quickly did have my hand up.
Phil_Archer: Just to I thought I had my hand up. I'm sorry. Obviously I didn't. I apologize.
Manu_Sporny: no problem.
Phil_Archer: Yes in this discussion internally I did say there's this draft spec called refresh. This is the use case for refresh. And I could hear your voice as I said it matters.
Phil_Archer: So yeah, I think it is indeed a use case for it one day.
Manu_Sporny: Yeah. Yeah.
Manu_Sporny: And refresh is not that hard to do. It's just we haven't had a very strong reason to prioritize it. But if this feels a pretty strong reason to prioritize it, the good news is that it's a fairly simple straightforward implementation. the spec is so I wouldn't expect a ton of work there,…
Phil_Archer: Johnson.
Manu_Sporny: but it's work. We should prioritize if GS1 needs it. All right. let's see. We've got about 10ish 8-ish minutes left. Let's take a look at this one. I feel like we've discussed it before, but let me topic this. All right.
Manu_Sporny: How are different types of external registries list supported with the current specification? For example, how are non Etsy nonx509 lists are referenced? and I guess we have utopian commission recognizing this let's see trust list service. So basically what happens if we don't have a type for this is the question I think.
Manu_Sporny: Dave Longley, I vaguely remember you being the one that said we need to think about this, but maybe I'm misremembering.
How are different `type`s supported for `recognizedIn`? · Issue #71 · w3c/vc-recognized-entities · GitHub
Recognized Entity Type Support
Manu_Sporny: Go ahead.
Dave Longley: I'm trying to also remember…
Dave Longley: what my previous self might have had to say about
Manu_Sporny: I think it's basically we are hard coding a set of external types, right? So we don't have open ID federation in here and let's say we just went ahead and for whatever reason didn't take that into account and now this thing's out there and somebody wants to point to their trust list mechanism. What's the type for that?
Manu_Sporny: So one pattern we could use here is the whole crypto render suite pattern where we're just like this is an external trust list and then the specific type is Etsy or open ID federation or something else. I think that's what this issue is trying to get go ahead, Dave.
Dave Longley: And I think that was the approach we wanted to take because we're going to fail to mention all these. So it was either some kind of suite or a media type sort of thing. So if you had a sub media type for that XML file, you could use that to distinguish it without having to reference dreference it First,
Manu_Sporny: And there are not separate media types for these things. So I don't think Etsy's lottle is just an XML file. It doesn't do anything beyond that. so if we tried to do media type, I don't think it'd work out well,…
Dave Longley: We can always invent new media types.
Manu_Sporny: which means that right register it on behalf of the European Union. as long as we have some Europeans here, maybe we can get away with that. I would,…
Phil_Archer: I used to
Manu_Sporny: yes.
Manu_Sporny: Just like the USA used to have a good standing in the world Phil. without getting into any of that stuff let's say media's probably the wrong way to do it. maybe we just say it's an external trust list and that's the type or external trust list for lack of a better word. And then we have a list type or something like that that says Etsy or Open ID Federation or something along those lines.
Dave Longley: And I mean at a minimum media type I think is available through VCDM. So it could be something that somebody would use to distinguish what they'd be retrieving. but we can also explore having some property that's more easily extensible and drop that in More easily extensible than I don't think we want to just make this based on type. I think that will lead to some trouble.
Manu_Sporny: Okay, we're agreeing I think.
Manu_Sporny: Is that Okay, so let's see. the group discussed this on May 681 and seemed to arrive at the census. use a generalized external trust list type or some variation of that concept type.
Dave Longley: Yeah, I think
Manu_Sporny: Yeah.
Dave Longley: Do we know if the web origin is a trust signal in that case? I mean maybe we just use an external trust list and we say if you don't have a media type you can rely on the web origin of the externalized list as your trust signal.
Manu_Sporny: It's a good point. I think probably in every case the origin matters, right? Yeah,…
Dave Longley: I mean, unless these lists are all being served with their own cryptography on them, they might be relying on TLS for delivery.
Manu_Sporny: I think they all rely on TLS as well.
Manu_Sporny: Yeah, that's a good idea. So, signal that state that the origin the domain in ID, is the root of trust or the list, which it is.
Manu_Sporny: I guess establishes the root of trust for the list. I mean, that any other concerns? Does anyone feel like there's a better solution for this? this feels good to me. raise the PR that go ahead Demetri.
Dmitri_Zagidulin: I'm reluctant to bike shed, but could we at least have external registry list as opposed to trust list or external entity list? Perfect. we want to avoid trust in general.
Manu_Sporny: I like entity more to bike shed it a bit more.
Dmitri_Zagidulin: Excellent.
Manu_Sporny: Anyone else feel strongly one way or the other? And then Coyote, I saw your hand go up. you Okay.
Kayode_Ezike: Yeah, I had the same question pretty much. Yeah, I don't lose trust.
Manu_Sporny: I think raise a PR that updates this. great. That one will be very easy to raise. I'm happy for somebody else Didn't mean to spoil anyone else's fun. any volunteers for this one? Should be a fairly easy one.
Dmitri_Zagidulin: And the list of actions is to add that to the context and…
Kayode_Ezike: Thank you.
Manu_Sporny: And update the spec.
Manu_Sporny: So it says we currently have the Etsy trust service list type I think.
Dmitri_Zagidulin: back. Okay.
Manu_Sporny: And what do we have? Don't we have an X509 thingy? you'd have to Yeah, we let's see.
Manu_Sporny: I don't know if there's much that needs to be done to the spec. Yeah, I think it's just a quick scan of the spec to see if we have Etsy trust list in there that needs to turn changed to external entity list. and then a context change. I think that's all there is there. any takers? Go ahead,…
Kayode_Ezike: Yeah, I can take a stab.
Manu_Sporny: Co Thank you very much, sir. all right that it's ready for PR. at time. thank you all very much for the very productive discussion today. we are running out of things to talk about which is good.
Manu_Sporny: I'll also mention that we have our first horizontal review in. Addison Phillips, that wonderful man who is always the first to do a horizontal review just about any spec, has done an internationalization review. So, we can take a look at these during the next call. all right, that's it for the call today. thank you everyone very much. have a wonderful rest of your week and we will meet again next week. Ciao. Meeting ended after 01:05:44 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.