Meeting minutes
Benjamin_Young: There we go. Hangouts wasn't happy.
Manu_Sporny: All right, it is four past the hour. Let's go ahead and get started. I'm sure a couple more will trickle welcome everyone. This is the recognized entities call. it is July 28th, 2026. we do have an agenda today. on the agenda largely is going to cover how the horizontal review request went.
Manu_Sporny: that's out. we are going to spend a significant amount of time on the UN grid example. Steve, just to make sure that the updates, I was able to make a full pass on it. I have some learnings from the weekend to share. and I think there have been some new comments that I haven't read on since we also have another PR from valid until on recognized actions. that I know Dave Longley had comments So, we'll need to see if we can discuss that a bit. and then we will do issue processing if we have any time left. that is the proposed agenda. Are there any updates, additions or changes to that agenda?
Horizontal Reviews Initiated
Manu_Sporny: All right, with that then we can kind of jump into it. let me get my screen shared. Make it a little more readable. all right. first up is I had an action to kick off the horizontal review process. I have done that. there is issue 95 here which I will some topic. so we talked about horizontal review last week.
Manu_Sporny: We have requested horizontal review from the W3C technical architecture group, the accessibility group, the internationalization group, the security group, and the privacy group. some of these required us to do a self-re which we have done. and then they each have their own form that we're supposed to fill out. So for example, this is the tags form that we filled out. They have you, say what you're doing, An explainer is basically like what is the spec needs to explain what it does. and then they request a whole bunch of links to information so that they can do the review. They make you agree to a couple of things like we follow the web platform design principles. They ask for primary contacts.
Horizontal Reviews for VC Recognized Entities v1.0 · Issue #95 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: They ask for who's funding the work. so, I did list some of us, that have been making comments on the specification. someone's paying your salary, And so, TAG wants to understand what that is based on public comments that people have been making. So, Steve specifically, if I mention the wrong organization here, please correct me. I'm happy to change it to whatever. I think everybody else is associated with the appropriate organizations and then who are the organizations driving this GS1 I don't know if it's UNTP Steve I can change that to something else VCWG and then horizontal review feedback and unresolved anyway and then what they should know we want to go into candidate wreck at TAC please finish the review before then so each one of the groups has you fill out this long laundry list of
Manu_Sporny: information each linking to other things that might Took about 3 hours to submit all the appropriate paperwork. which is just, painful. I wish they would make it easier, but that's the way But it's in and now we wait. So, that's done. any questions, concerns about it? let me change that right now while we're at it.
Manu_Sporny: At TP UNC thanks United Nations Economic Commission for Europe. Let me see. Excellent. Thank you. That is updated. So, that's in there. And now basically we just continue doing our work and eventually they'll come back to us and they will raise issues in our issue tracker and we will discuss them and that's how you typically process some of the requests we get in might say we really want you to fix this before you go to candidate recommendation.
Manu_Sporny: and so on and so forth. Okay, that's that item. Todd Snider, we merged the GS1 use cases in last week and so now they show up in the table of contents and…
<Steve Capell> it's UNECE, that's the organisation. UNTP is a specification
<Steve Capell> United Nations Economic Commission for Europe..
Todd_Snyder: Cool. Yep.
Manu_Sporny: the ecosystems examples section at the GS1 federated identifier that's in there. we can change as we see All right, that's the GS1 thing. next up are pull requests. let's start with the UN grid example. topic All right. And then maybe I should bring up let me see recognized. Let's do this one. And let me one second.
UN Grid Example Review
Manu_Sporny: Let me pull up and sorry I'm having to find the right branch. grid.
Add complete UN GRID example to appendix by msporny · Pull Request #104 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: Add examin grid example. All right, let's see if this is it. All right. Steve, this is the UN grid crossber trade example. I did make some updates since the last time. both you and John had some feedback on text changes I believe I made all of them and align the rest of the text with those changes. The other things that I took a look at, we had a different kind of diagram here, right? and I went through four iterations of that diagram trying to make it smaller and easier to understand and not repetitive and that sort of thing.
Manu_Sporny: And this is where I ended up which looks almost exactly like the GS1 use case. the thing that was complicating the diagram was this identifierbased discovery process. If you look at it with that stuff kind of shoved into a little box here, the shape of the problem, the shape of the credentials is almost exactly the same as the GS1 use case.
Manu_Sporny: I view that as a really positive thing because it means that we may have found a generalized architecture here that works for the UN grid more decentralized case versus the GS1 more federated case and…
Steve Capell: I think that's fine. That's
Manu_Sporny: the general way that you reason about these things is the exact same and the only thing that really differs is how you do the discovery process. So that is at least a working theory that I have. Good. I did though I was sad that you lost the detail in here and so I pulled that thing and generalized it out into this diagram here which I think highlights how you go from any arbitrary credential with an issuer on it.
Manu_Sporny: You do identifier discovery to find out if that entity is recognized and you loop as you go up the chain. I think this is effectively the identifierbased discovery algorithm. So you start at any verifiable credential. You see if you recognize the issuer of the DID. If you don't, you look up DID document or really it's their controlled identifier document. Still need to fix this a bit. If you find a document,…
Steve Capell: Yeah. Thanks.
Manu_Sporny: do they have a who is endpoint? If they don't, you fail because you don't know who they are and you have no way of discovering. But if you find who is endpoint, you go and fetch the content
Manu_Sporny: there you see if they have a recognized entity credential. Do you recognize the issuer of that credential? If so, you've succeeded. Now you've been able to anchor, the original issuer through a recognized entity credential back to someone you recognize. But if you don't, you go back and you loop, right? So you go to that recognized entity credential. You don' understand. You don't recognize the issuer of that credential. You go to their issuer document. You see if who is endpoint. You go and get the presentation. You get their recognized entity credential. Do you recognize them?
Steve Capell: Yeah.
Manu_Sporny: No. and you just keep looping until you hit someone and discovery succeed Or you fail because you get to a leaf where you can't go any further. okay.
Manu_Sporny: So that's the other modification that was made for the UN grid one. I added that and then linked and this link here identifier based discovery will take you to that diagram. I tried so hard to make this a hyperlink but mermaid was fighting me. So I'll try and fight that battle another time. so that's the new figure. upgraded this. Let me pause there. if there are any comments on any of that. go ahead Demetri. Yes.
Dmitri_Zagidulin: So no comments who is diagram makes sense but I'm wondering or rather what about discovery through a list credential are we covering that in the first iteration?
Manu_Sporny: Yeah, because this one the GS1 example I think hold on let me clarify your question. So this one is purely like it goes from the credential and looks at issuer.recognized in and goes directly to the list, I don't know if you mean that or if you're the person starts at the list and…
Manu_Sporny: then goes who is endpoint and then finds VPs and does like that.
Dmitri_Zagidulin: No, no.
Dmitri_Zagidulin: The GS1 the recognized in and the recognized in do we have a data model for the thing on the other end of the recognized in is a list.
Manu_Sporny: Yes, It's a recognized entity credential which is the list of all the entities that are recognized.
Dmitri_Zagidulin: Got it. Okay, brilliant. Amp.
Manu_Sporny: So I think we're covering that in this version. and I think the answer to the other possible question that you had is I think we're also doing that. because of identifier based discovery you can go directly to a recognized entity credential published by a known authority and you can jump to their did which who is service that then explains in much greater detail that organization is right so I think we covered that use case as well and…
Dmitri_Zagidulin: Got it. Okay. Yep.
Manu_Sporny: I think we also cover the use case where you mix and match credential based discovery and identifier based discovery and you've got two paths to get to the issue if you need to without adding tremendous complexity to the spec I don't think anyway, the pattern seems to be working out really much better than I thought it was going to. which usually signals that we've got a pretty good set of primitives jumping back to the UN rid question. Any questions on just the diagrams themselves? Got other things to also cover.
Steve Capell: Isn't that good?
Manu_Sporny: right.
Example Context Highlights
Manu_Sporny: If Good. thanks jumping down into the examples themselves. Avon was like, "Hey, it's really hard to tell what to pay attention to in the examples. Can we highlight some things?" and he said, " you've got this examples context in there. that's catching everything. I don't know where some of these terms are coming from, so for the UN grid example, I took out the examples context, I made up a context, Steve, for UNTP, and I don't know if this is the right URL.
Manu_Sporny: So I need your and John's guidance on that. But whatever this is, we're highlighting it saying look, this is where UNP or UNCCE again I need help on the acronyms, but this is where they did their extension, And for this one, I don't think we use anything. This is the UN grid recognizing the Utopian National Business Register. I don't think we use any properties from this vocabulary. it's all recognized entity stuff. However, when you get down to the next, example, we're showing how you go from this thing, you their did document and they've got the service endpoint. So, we highlight that in green to just say this is the part you should be paying attention That takes you to the register.
Manu_Sporny: And then we've got again the UNP thing in green and then now we're pulling in things from that vocabulary specifically registered ID and registration country. And this is the thing that Steve in Todd I think this is probably what we want to do. I think what ends up happening here is you kind of use the recognized entity thing kind of like just the base legal name, URL description, whatever. those are some basic things that you should be able to kind of talk about with respect to any recognized entity.
Manu_Sporny: But there are things that really matter to UNCCE UN UNTP and grid and they need to be able to layer those things in a easy nice way. And so I extended this object. This is a recognized entity but it's also a party per your vocabulary. U Steve this should be highlighted in green as well. I need to go back and do that but these are highlighted in green as well.
Manu_Sporny: And this is the thing what is it the Utopia business register whatever we're talking about the terminology there but that's a thing that they kind of mix into their data and so Todd this is where for the GS1 use case you do like the prefix right the license prefix so I think I need feedback from
Todd_Snyder: Yeah, the …
Manu_Sporny: both of you both for the GS1 use case and the UN grid UNCCE use cases if this pattern is acceptable to you if you're like we can work with that or if there's some reason where you're like yeah no that's not going to fly in our ecosystem I can't think of a reason why it wouldn't but just have a think on it please and let me know It's a type of entity.
Todd_Snyder: I mean initial thought, yeah, it makes sense. I like the idea of the green. That helps distinguish what's changed. and you're saying here party is actually a type of credential and
Manu_Sporny: And so for UN Grid, they define what party is,…
Manu_Sporny: for you, GS1, you would have a type it's a member organization. So yours would be like member organization and this would be like license prefix.
Todd_Snyder: Yes. Or yeah,…
Todd_Snyder: we're licensed or something. Okay,…
Manu_Sporny: Yeah. I Yeah,…
Todd_Snyder: that makes sense.
Manu_Sporny: I can't remember the exact term of correct.
Dave Longley: It seems Yeah,…
Todd_Snyder: No, that's fine.
Dave Longley: it seems to me that party should be highlighted in green as well.
Manu_Sporny: Yeah, my Yep. Yep. Agreed.
Todd_Snyder: Yeah, if I'm understanding correctly,…
Todd_Snyder: basically what they're looking for in green here is these are the things that are unique in that example compared to what's the normal schema for a recognized entity. Right? That's… Manu Sporny:
Manu_Sporny: Yeah, exactly right.
Todd_Snyder: what we're saying.
Manu_Sporny: And it's specifically how GS1 or UN grid has decided to extend recognized entity to directly match their use cases. because the JSON schema is going to do something with these highlighted green values. Right. So this is the utopian business register publishing this information. They're issuing this credential. But who gave them the authority to do that? the UN grid did. And when the UN grid did that they published a recognized entity for the Utopian business register.
Manu_Sporny: And in their JSON schema, they say anything that the Utopian business register issues any credential recognized entity credential that they issue better have the registration country as UTO because they're not allowed to recognized entity credentials for anything other than the utopia. so we needed something for the JSON schema to run to just do a very high level sanity check on is this even within the realm of acceptable acceptability.
Manu_Sporny: modulo everything that Steve said last week around there may be much more complicated rules that go into whether or not they should have been able to issue this credential. hopefully that I don't know if I'm making sense here we need something for the JSON schema to run against and these are the fields that it could run against. It could say any registered ID property in the credential they issue has to start with capital UT and the registration country has to be UTO just bare minimum for them for us to that's…
Steve Capell: Yeah.
Manu_Sporny: what we recognize them to issue. Does that make sense? Okay. So yeah.
Manu_Sporny: So I'm basically saying I think we need something that you need some extension property to make sure that the JSON schema applies against and there may be more things from a business standpoint you run but there's just needs to be like a base level sanity check that then these are universally that test can be run by any implementer of the recognized entity spec without them having to know the special business rules in an ecosystem. Hopefully I'm making sense. hard to tell. gotcha. I'll take a look at that. good to know. Are this was another question I had.
Manu_Sporny: Steve, are you guys publishing using URLs like this where you've got versioned JSON LD context. It looks like you are youper. That's okay right now.
Steve Capell: Yes. Yeah.
Steve Capell: But it's like I said, we've kept it below 1.0 because it's not approved yet. But within a month, it's going to go to one point. I mean, you could put an imaginary 1. I mean, does it have to resolve in an example?
Manu_Sporny: No. I think ideally when we get to recommendation Yes.
Steve Capell: So, you could put the 7 and it res would resolve now and then change it in a month or so. Or you could put one and…
<Steve Capell> https://
Manu_Sporny: Yep. Let me know what y'all want to do in the PR.
<Steve Capell> note that they are both about to move to v1
Steve Capell: Okay.
Manu_Sporny: I'm happy to go either way.
Steve Capell: right. Thank you.
Manu_Sporny: Go ahead, Benchman.
Benjamin_Young: Yeah,…
Benjamin_Young: I can also Steve offer some sort of polish suggestions on the context to make it sort of more stable as you go to publication. additionally, it looks like you avoided the thing that SPDX and some others have done where they've not only versioned their context, they've versioned every single one of their terms. Even if the terms don't change, they rev the numbers and…
Steve Capell: All No, we don't do that.
Benjamin_Young: the Thank you for not doing that. It's like getting a new graph every time you spin fix one bug.
Steve Capell: Yes. Yes.
Benjamin_Young: Yeah.
Benjamin_Young: So, no, it looks good. But, we're trying to encourage people to not use curries like your prefixes at the top and some other stuff we don't need to take up call time for. I'll reach out over,…
Steve Capell: Happy to risking some advice.
Benjamin_Young: .
Steve Capell: It's good time timing…
Benjamin_Young: Yeah, sounds great.
Steve Capell: because we're about to fix
Manu_Sporny: All right. that was the major change and then everything else is just highlighted in green. Who is service? I did talk with Stephen Kern today who is service and getting it more formally defined in the did resolution and did working group. he is motivated to do that and has taken an action to do that. So we should get a lot more clarity around this functionality in the next couple of months. and then this is the commercial invoice credential.
Steve Capell: Give you an example.
Manu_Sporny: Steve also looking for feedback here.
Manu_Sporny: I have no idea what I'm doing here. So any help that you could provide I will gladly update and here again it's just highlight in green the things that are specific to the use case. and this is where you would expect it to get very specific to the use case because it's kind of the leaf credential. I think that is it.
Manu_Sporny: There's a little thing saying that hey registered ID and registration country comes from the P vocabulary. the other question I had Steve is what happens to digital identity anchor? Do we mix it in with this object? Do you replace digital identity anchor with recognized entity? I don't know. I think those are decisions you guys are going to have to make and…
Manu_Sporny: we're happy to provide any input on that. I have no idea what the right thing to do is, It's largely.
Steve Capell: The intent is as we suggested to replace the IIA with recognized entity and…
Steve Capell: if anything define a profile not a different schema.
Manu_Sporny: Okay, And so the question is timing, right?
Manu_Sporny: cuz we are on a different timeline to publish recommendation than you are and…
Steve Capell: Yeah. Yeah. Okay.
Manu_Sporny: we just want to make sure that we're as tightly aligned with you and don't do anything to mess you up in that process. So just let us know if we're going ary or you need any updates and we're happy to make changes to stay aligned with your timeline. I think that's largely it for the UN grid thing. I know John provided some commentary. I haven't had a chance to take a look at it, but my suggestion is if there's nothing majorly wrong with this, Steve, and if John agrees, then let's merge this by this weekend and then we can refine as things go along.
Manu_Sporny: The reason being, I've kicked off horizontal review.
Manu_Sporny: If they look at it in the next two weeks, I want them to see the UN grid use case as well as the GS1 one. okay.
Steve Capell: Yeah, look,…
Steve Capell: I think it's good to merge. Like I said, we can fix some context references and things like that post merge if you like and the invoice schema and…
Manu_Sporny: Okay.
Steve Capell: things like that.
Manu_Sporny: if you are able to give me a concrete set of things to change before this weekend,…
Manu_Sporny: I'll make the modifications this weekend and then merge it in. But if it takes longer than that, I will merge anyway and we can deal with it in a different PR. Does that work for All right. That is that item. That's UN grid. All right.
Steve Capell: Thank you. Yeah.
Recognized Actions Valid From/Until
Manu_Sporny: Next up is the valid from invalid until stuff and recognized actions. basically the question was what happens when some kind of recognized authority recognizes an entity to issue a credential in a very constrained time period.
Manu_Sporny: For example there was a university and the university was just doing fine for 20 years and then in year 21 they lost their accreditation for some reason and in year 22 through 40 they have their accreditation back right but that means in the year 21 they're not supposed to be issuing any degree credentials because they're not accredited to do so
Add validFrom/validUntil to recognized actions. by msporny · Pull Request #106 · w3c/vc-recognized-entities · GitHub
Manu_Sporny: Please correct me. I have no idea if that's actually how it works. But as a general thing, that's the use case we're trying to address is what happens when somebody is not accredited and they're not supposed to be issuing credentials, but they do it anyway, and the accreditation authorities has to be able to communicate that in some way through the recognized entities list. the suggestion is that they would do that as something attached to the action. So the action would say they are recognized to issue from this time period to this other time period and if you have multiple kind of broken time periods there would be multiple actions one for each time period. so that's kind of what this is attempting to accomplish. I know Dave you had a number of questions. I tried to respond to you.
Manu_Sporny: I don't know if my responses resonated. So, how about over to you, Dave? I don't know if this actually addresses the problem or not.
Dave Longley: Yeah, I read those responses. my main concern with this is that whoever's creating a recognized entity credential might be thinking that they're constraining the behavior of an issuer that they're recognizing in certain chunks of time, but they're certainly not doing that. But what they're doing is saying when that issuer issues a VC with some validity period on it which that issuer can say whatever validity period they want it has no bearing whatsoever with the current time there's no reason they couldn't for this university that was not allowed to issue in 2021 not recogni that they issued with a validity period of 2021 were not recognized there's nothing that would stop
Dave Longley: that issuer through these rules from issuing VCs during that say 2020 for example or whatever would match a rule. So it's important that people understand that that is not what This assumes that if you're going to trust the validity period of the issuer, that it's constraining trusted validity periods, not open validity periods, just something along those lines.
Manu_Sporny: Plus one to all that. so I think you're saying we should really mention that in the spec so that people don't think that they have any control over what an issuer can say. they don't. It's a decentralized system. and in order to properly process the recognized entity,…
Manu_Sporny: you've got to apply this as a business rule on top of the business rule of whatever the issuer is saying. go ahead,
Phillip Long: Yeah, I'm not sure.
Phillip Long: I think you're saying that if the 2021 is a year that is not valid anymore. they can still issue whatever credentials they want and choose a year that is valid and it will then pass verification. But that's not necessarily kosher if in fact the credential was issued in the year 2021. and so what I'm trying to figure out is are we just basically saying, you can game the system here if you like. We can't stop you or what? because I think we should be saying that this thing with if it's expired, it should not verify and the institution should honor the fact that this is the case. I mean otherwise it feels like we're saying here's how you get around it.
Phillip Long: Yeah. Yeah.
Manu_Sporny: Yeah, it's a good point. I mean, this is effectively like what happens if the institution starts lying? That's what they're doing. If they issue something and at that point, it's like hopefully the accreditation body has some capacity to basically just take them off the list. " You're totally lying about when you issued these credentials. you're off the list. Everything that you issued, we can't trust anymore because, you fudged it for that year. We have no idea if you're going to fudge it for all 40 years," so that's the other approach is, this is getting into wouldn't it be amazing territory, but I don't think it people are going to do this.
Manu_Sporny: If we use the forgery defense stuff on this or if a university published hashes of all of the credentials that they issued at a particular point in time and they convey it to some other entity then they wouldn't be able to lie about when they issued the credential right they couldn't shift a 2020 whatever actually could Okay.
Dave Longley: I think you're just talking about a different use case where someone else publishes for jury defense or takes over effectively issuing if this does not cover the threat that this institution is to lie. It covers the threat that this institution is willing to be compliant and they might issue things in 2021 but they will not be recognized.
Phillip Long: Right.
Dave Longley: But what they won't do is issue things in the year 2021 that say a different year. and if they're willing to do that, then they can no longer be recognized at all as that issuer. And you have to come up with some other solution if you want to accept credentials that were previously And that starts involving bringing in some other third party or some combination of features with forgery defense or whatever it
Manu_Sporny: That's So, basically we have to write about this in the threat model…
Manu_Sporny: because we don't want people thinking that this thing can do something that it cannot do. it can't stop people from lying.
Phillip Long: Right. Right.
Phillip Long: Right. I mean to be honest the context within which I suspect in the higher education case and possibly in training issu credential issuers are programs which come and go and there are issu and circumstances arrive where a program has come and gone and they didn't get the credentials out before the end of the program and the year passes and so they get around to it the following year and you have all these permutations like that which is basically due to the internal inefficiencies of the institutions.
Phillip Long: But I could potentially write something that just raises this in a short sentence or short paragraph and say, things happen. These things are being done throughout institutions and by various entities within them, still using the institution signature and such, but you should be attentive internally to your quality assurance processes to make sure that alignments are not lost. Okay.
Manu_Sporny: Yeah, plus one to that. certainly. go ahead, Mitri.
Negative Registry / Bad Actors
Dmitri_Zagidulin: One thing that I would related to validity periods sort of one thing that I'd be really interested in is this notion of a negative registry or a negative list. for a prime example of this would be list of sandbox did values that are from test suites or from library readmes all that stuff. So known secret keys and resulting bids that are no definitely flag this as invalid or sandbox specifically. So it would be really helpful I understand if we did might not have time for it for the first iteration.
Dmitri_Zagidulin: But to have the opposite of this issuer is authorized to issue this kind of X specifically this issuer is recognized sandbox or this issue is recognized
Manu_Sporny: got it. yeah, that's a good point. Dave Longley's unrecognized entity credential. …
Phillip Long: Did you? What?
Dmitri_Zagidulin: No, no.
Manu_Sporny: maybe recognized bad entity.
Todd_Snyder: Are we quick question?
Dmitri_Zagidulin: It's recognized but
Manu_Sporny: Recognized bad actor.
Todd_Snyder: Are we talking about the issuer being bad the recognized entity credential?
<Dave Longley> UnrecognizedEntityCredential
Dmitri_Zagidulin: The issuer.
Todd_Snyder: Okay. Yeah.
Manu_Sporny: Yeah. The issue think it's worth capturing in an issue.
Dmitri_Zagidulin: The issuer.
Todd_Snyder: I mean that leads to a whole other can of worms of problems, right? Because what if …
Dmitri_Zagidulin: I mean, not really.
Todd_Snyder: I mean it really depends. I'm thinking the GS1 use case that it would be interesting that…
Todd_Snyder: if entity X was no longer a valid issuer or something. I just wanted to clarify that because it wasn't clear. Thank you.
<Dave Longley> maybe it is as simple as: don't put a sandbox issuer in a production list
Dmitri_Zagidulin: Yeah. Or Yep. Yeah.
<Dave Longley> and clearly separate your sandbox vs. production lists
Manu_Sporny: Dimmitri, I don't think we're tracking that. Would you mind raising an issue?
Phillip Long: Demetri, can I ask I thought you were saying actually something different,…
Phillip Long: which was you've got to test better things and somehow or other inadvert certainly or otherwise credentials in that test space are out in the wild and…
Phillip Long: it's not because you had did that intentionally. It's not because anything of that sort. it's just that there was a leakage or something happened that resulted in that. and…
Dmitri_Zagidulin: That's also a valid case.
Dmitri_Zagidulin: Yes. …
Phillip Long: but what I'm wondering then if that's the case is that it's still a valid credential. I think what you're trying to suggest is that this credential is just used for internal testing. If you see it in the wild, it's not relevant or…
Dmitri_Zagidulin: and here we get into fine grains of what's a valid credential. that no,…
Phillip Long: a type, right? So…
Dmitri_Zagidulin: it's not a valid credential because this is a known invalid issuer. whether it's known invalid because it leaked or because it's in a readme tutorial somewhere. that part doesn't matter as long
Dmitri_Zagidulin: As long as we have the vocabulary to flag this.
Phillip Long: if you're at an institution which has a test bed that's doing this and another part of the inst in institution that's issuing valid credentials their normal way, they're not going to be confusing the two.
Dmitri_Zagidulin: Correct. Yeah.
Manu_Sporny: this university has been overtaken by AIS and now they're issuing credentials left and right and we cannot yeah anyway I like the dystopian outcomes.
Phillip Long: That's what I was thinking. Yeah.
Manu_Sporny: Okay. is this thing okay so with that caveat we need to talk about this in the threat model and that sort of thing. is this the right direction? I guess Dave Longley is this because we could put valid from valid in other places.
Manu_Sporny: I didn't really look into it too much. Action felt like the right place to put it. thoughts is there a better place to put this information? for example,…
Manu_Sporny: we could put it recognize any what could we do? We could put it on I don't know what else we could put it on.
Dave Longley: We're kind of talking about different use cases potentially. So if we think about the directory use case, you might want to say if there's a did for example that maybe changed hands because for whatever reason you might want to say this entity was valid for this period with this did you know all these properties about the recognized entity should only be considered valid during this period.
Manu_Sporny: Hold on that I think that use case is just putting it on the credential itself…
Dave Longley: So that would be a reason to do that. maybe you would well when you're putting it on the credential itself,…
Manu_Sporny: which we already have from valid until right and you could list multiple of the same entity with different validity periods in the list if you wanted cover that use case.
Dave Longley: if you have a list of 100 of these and you want to h…
Manu_Sporny: Yeah, I take your point.
Dave Longley: how does that work? that doesn't sound like it works very well.
Manu_Sporny: And then I guess the question is how should I be reworking this PR or not?
Dave Longley: I think if we go so if we were to rework this so that and valid until could appear in multiple places, I think we'd rework the PR, but we would also need to think through. what we just thought through for actions for recognized entities as well. And I think for recognized entities, I don't know that it necessarily matters as much. I mean, you're just making a statement about this entity identified by this identifier are this for this period of time. there's no linkage to the issuance action. So, it's probably I don't think we have the same concerns that we just discussed
Manu_Sporny: I guess do we have anyone with that use case where they're like, " my ecosystem doesn't work unless I can do that." So, we can always add it later, I guess, is my point. we can start off with it, we start off with it fairly strict scope around it's just around actions. We've thought through that and the ramifications and security considerations and then if someone else comes along and they're like, "No, I want to be able to do this at the entity layer." At that point, we consider it.
Dave Longley: Yeah. The other thing to think about is you're always going to be anchoring it to some point in time. So really if you're going to put valid from and until on a recognized entity I think the only use case is for auditing. You're not going to look at it at the current time and then the way the infrastructure would have to work I don't think could possibly support that use case. So it would be like you're looking at some other artifact either a VC or something else that has a time on it and then saying who was this entity at that time. That's what you would end up using the fields for if they appeared on a recognized entity.
Manu_Sporny: Yep.
Entity Transfer Use Cases
Todd_Snyder: That actually raises an interesting question.
Todd_Snyder: So at least for GS1, I'm sure others have this too. We have the capability or the idea that something could be transferred. So today XYZ company could own a product which is tied to a prefix and then that can be transferred to a new company. So that sounds like what you're describing. So at a point in time, yes, company A owned this, but now it's been moved.
Dave Longley: However, that sounds like that would not go in a recognize entity some other credential about that artifact. for example the did associated with…
Todd_Snyder: But we would end up with two different issues basically and the date would drive it. So up to this point, it's owned by this entity and now beyond that date, it will be owned by a different entity.
Dave Longley: how would you differentiate the two identities? Would it be through a different did or identifier for the actual controller owner of that and if so well I'll let you answer that.
Todd_Snyder: So this Yeah.
Todd_Snyder: So in this example, both are memorizations. We'll just use cola a and cola b for this example. They'd have their own DID and we would issue our credentials to their DID. And what would happen is at some point COA would transfer ownership of some of the license, not all the license, but we'll just say it's some of the license to B and we would internally process them and now B would own them. and so we would issue new credentials to B for those same.
Todd_Snyder: No, they'd have the same DID.
Dave Longley: But B would have a new did.
Dave Longley: The same did.
Todd_Snyder: Yeah, we treat DIDs as the entity we're issuing to and obviously the issuer too. the underlying data itself does not use DIS like we don't have a DID for every gon for example because that would be lots of DS used. that's sort of…
Todd_Snyder: why we went down our path with our extended credential approach,…
Dave Longley: So there might right no I'm the same.
Todd_Snyder: which is why we're here to relook at how we can avoid rolling our own for everything. So, yeah. Sorry you
Dave Longley: So there might be a use case then at least a directory that would have two entries that's complicated for the same identifier with two different validity periods.
Dave Longley: I don't even know that seems like the information would be merged in ways that would not be easy to reason about. Those seem like they're Yeah.
Todd_Snyder: Yeah. Yeah.
Dave Longley: two, you're making entirely different claims, but together in the same graph of information. That seems problematic.
Todd_Snyder: And there is a use case around crossber trade where on this date yes that product was owned by that entity and then 3 months from now it's owned by a different entity.
Todd_Snyder: So there are use cases we've encountered where I said for now we were looking at date as a way to drive it we're going to revoke the credential.
Dave Longley: Yeah, I think Right.
Todd_Snyder: So I think there is probably something we should dive in digger bigger when Phil's here one week we can kind of explain it out a little more but I said at least in the GS1 world there are cases where ownership changes yeah that's a Good feedback.
Dave Longley: I think those might be better implemented as issuing a entirely new recognized entity credential with the new ownership information, not trying to mix it all together in the same one.
Todd_Snyder: Any can we capture that somewhere to explore as an issue or something?
Manu_Sporny: Yeah, I mean let's our issue tracker is the place to do it.
Manu_Sporny: Todd, I don't think I would capture it. here's the link in chat. If you could raise a new issue talking about that use case, just doesn't have to be A couple of sentences, then we'll come back to it.
Todd_Snyder: Yes. Yep.
Todd_Snyder: Okay, that makes sense. Thank you,…
Manu_Sporny: Excellent.
Todd_Snyder: That was good feedback.
Manu_Sporny: So, I'm hearing that we should proceed with at least this one. Merge it We captured Todd's concern. and we'll come back to that one to see how we might address it, at least figure out what the guidance is and for that use case. we've got six minutes left. there are effectively nine issues we need to discuss. and once we have clarity on that, we will be down to basically having clarity on everything we should finish up in the spec doing CR. we're not going to do any of these today.
Manu_Sporny: A number of these I think we have fairly clear guidance or we've made good progress on what we just need to clear them and see if we can convert them into pull requests or we just need to close them or if they've been addressed already. So that's a good place for this group to be at this time. we do need to start talking about test suites and creating those what testing the spec is going to look like and what we expect how many implementations what does interoperability look like how are we going to test it
Manu_Sporny: those discussions are coming up in the next month or so. but yeah, we're actually in a pretty good spot with this spec. I think that is it for this week. Is there anything else folks want to queue up for next week? Any other items we should be paying attention to in All right. If not, have a wonderful rest of the week and we will meet again next week to finish off some of these discussion items. All right. Thanks all. Have a good one. Ciao. Meeting ended after 00:53:48 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.
<Manu_Sporny> Issues · w3c/vc-recognized-entities · GitHub