VCWG Recognized Entities

Benjamin_Young: Hey everyone, I'm caring today some more time.

Phil_Archer: Benjamin. Thank you.

Benjamin_Young: No walkies today. Sounds good.

Phil_Archer: I've done that. I thought I wanted to be here today with a reasonable direction. I have just all done.

Benjamin_Young: I always feel like you're walking the dog for all of us. Getting the exercise we all wish we were having. All right.

Recognized Entities Task Force Intro

Benjamin_Young: pretty good group So, why don't we go ahead and get started? Welcome to the BC working group recognized entities task force. This is under the usual code of conduct of the W3C and the IP policies that you signed when you joined. we are going to look at the issues list. there's a few more from Steve Capel and we will likely start with issue 139, but I did want to ask before we did that if we wanted to come back to the one from last week for a bit. Steve, I'm gonna kind of leave that up to you because there's been discussion all up until the last hour on I think both of these

Benjamin_Young: No, just 135. Does anybody have preferences? I can screen share so we know what I'm talking about.

Phil_Archer: I think they're all interconnected. A lot of them are interconnected.

Benjamin_Young: Why don't we go with the new one first and then we can circle back.

Benjamin_Young: to last week's as it makes sense. Is that a good size for everybody?

Benjamin_Young: I can zoom in another notch.

Steve Capell: Sorry, I was trying to find my unmute button.

Benjamin_Young: I kind of thought you were saying really good things and…

Steve Capell: Yeah.

Benjamin_Young: we couldn't hear Sometimes you just know. there is no IRC even current. this one's autorecorded and what you type in the sidebar chat here is minuteed with the transcript. So, you can slash me just like you can in IRC to keep it off the record.

Benjamin_Young: Steve, sorry. You were about to say something.

Quality Infrastructure & Recognized Entity Use Cases

Steve Capell: So, this ticket is I mean I pasted it but it's not actually mine. it's from Brett and from Australia and Switzerland and the so-called quality infrastructure. suppose people know what that is, it's the way the world has worked for I don't know 40 years around assuring the quality of products and processes where you have certifying bodies that test products or assess processes against separately documented standards or schemes or regulations.

Steve Capell: And then you have accreditation authorities that attest that the certifying body is accredited to test against this or that standard. How it works. so this is feedback from them. So they've been using UNP to try to digitize in a traceable way the world's quality infrastructure. including raceability traceability is the wrong a trust chain in the case of testing all the way up to the global standard units of metrology, the standard meter, etc.

Steve Capell: and the recognized entity credential is one of the things they see as the way to, assemble this ladder of trust. so I think they're all pretty excited, so the issue is I not convinced that we've thrown enough genuine registry use cases at our spec to go we got the key components of the data model that we need so promised I quickly pasted this one in for Brett. and haven't studied it enough to talk about it.

Steve Capell: But the core issue is how do you say this conformity assessment body is accredited or this scope which could be something like ISO 9000 or Australian standard something for structural steel. it's again a case of you wouldn't say they're accredited to issue

Recognized Scope Vs. Recognized To

Steve Capell: something they're accredited really with a scope which can only be understood by pointing at an external definition of that scope this standard that regulation that scheme because they will all issue some sort of certificate that's not the thing you test right and it's similar with a business registration is the business registar is never going say you're accredited, you're recognized to issue invoices or purchase orders. They're going to say you're recognized as an Australian business with legal form, not for profit, that sort of thing. so it's this recognized scope or recognition scope thing that seems to me to be completely ubiquitous everywhere that we don't support.

Steve Capell: or at least I can add it. And we've added it to the DIA. Last week I said we would update the digital identity anchor spec which I've done. I noticed there's a bug there of haven't used some of the right property terms that we'll fix up but I'll put a link to it for you. So yeah, I don't whether we want to prosecute all these details. I suppose the question for the group is should we be collecting a broader set of use cases and testing them against a data model and have we also maybe overstepped some boundaries? Are we using the thing outside of its original scope?

Steve Capell: Does that mean we say no it's not really for that or do we say we need to support that to my mind the purpose of this thing is always it's basically a glue right it's a way to connect some transaction that I care about or certificate or credential that I care about to some authority or some trust anchor that's his purpose and for that I've felt like it's missing a few things. One is the identifier that the authority issues to the party.

Steve Capell: That's something I've said before doesn't have a normative place in the data model because we say the subject is this did but we don't say the subject is this did known to this authority as that Australian business number or whatever the ID is right because that's the number everyone wants to know but there's no placeholder for it in the data model. there isn't a way to say scope as opposed to recognized to and…

Steve Capell: I still don't really know what recognized in I haven't found a use case for recognized I think I don't understand it. So that's it for me.

Benjamin_Young: Thank you,…

Benjamin_Young: We'll work through the queue. Go ahead, Phil.

Issuer Identifiers And Recognition Scope

Phil_Archer: So, I think…

Phil_Archer: what Steve's getting at is something that we've been dancing around for the last few weeks. and I think there are two aspects or two questions that we need to be clear on the answer to. I mean I fully support Steve's point about if you issue a credential to somebody, you issue it to their dead, that's what we expect. but this is what We call them this number that we issued to them. That's a common case.

Phil_Archer: for certifications, for business registries, for all sorts of things. Every organization that issues something to somebody else will have its own existing longestablished identification system that it uses. And so I do think we need that to be part of the vocabulary. And then there's the question of scope. what is the scope of our recognition?

Phil_Archer: There may be cases where there is no specific scope in which case okay but yes if you're accrediting a certification body to certify certain things then that's part of the scope so I think that is also an important element a separate layer on top of that sorry I should say I think that those two elements the identifier by which the issuer knows the older other than the dead I think is important and a way to say this is the scope this is the kind of thing that we recognize them to do. we then get into the discussion that Dave and I have been having over open world versus closed world.

Phil_Archer: If it's open world then the fact that we're saying we recognize you to do these things doesn't mean that it means that we're remaining silence on anything else other than those things. So I get that. But then the question is do we expect that scope and those identifiers and other elements to be machine processable and therefore machine verifiable? And that's where I think we're starting to come up with the answer. No, we don't. but I do think we need to be able to say over here is a document that describes why we gave them this thing. This is our governance model. This is our procedure. and that might also include, and here's a link to some software that you can use that would actually carry out what we would cons call a full verification where the boundaries are between best.

Phil_Archer: I think there's two elements that Steve highlighted and the ability to define the scope of the recognition and whether that scope can be machine verifiable and…

Benjamin_Young: Demetri, go ahead.

Phil_Archer: whether that's part of the spec or something else. I think those are open questions. That's it.

Steve Capell: Next.

Historical Motivation For "Recognized In"

Dmitri_Zagidulin: I just wanted to address recognized just as a historical note. I think one of the original inspirations or motivations for recognized in was as a bridge between other recognized entity specs. Right? So for example, there's an existing list or an existing issuure registry that doesn't conform to the recognized entity spec. And you can point to it. You can say, " yeah, this issuer is recognized in that list over there." So it's meant as a bridge thing. That's it.

Benjamin_Young: Sorry. Go ahead,…

Benjamin_Young: I was on mute.

Steve Capell: Yeah,…

Steve Capell: just quick couple of things. Bill said recognize to do. whilst there are some use cases like that in my experience most of the recognitions I would use a word more recognized as right because usually these things are the registar doesn't dictate what the subject can do but more what they are right so that we have to be careful with that word the other thing is I think we should when we think of these use cases put ourselves in the position of the registar who's usually very often a government agency with fairly well- definfined and strict policy positions and things they can and can't do. Right?

Steve Capell: So I'm imagining even for the famous education one we keep talking about a university coming back to the department of education and saying can you add these schema references into my identity anchor credential will that map to a existing business process and policy position that the department has likely not right so imagine yourself some bureaucrat that has a job all we're expecting the DIA or the recognized entity credential to do is exactly what the authority does today. No difference whatsoever except digitally. So if you're asking

Digitizing Existing Processes Vs. New Tech

Steve Capell: them to put something in a credential that doesn't align with the way they naturally work, it's going to stop dead in the water there. so I'm not sure we've thought that through So, I just wanted to make that point that it ought to be a principle. I would have thought that the purpose of this is largely to digitize ex existing processes. And don't ask somebody to do something that doesn't fit their existing process because especially if they're a government authority, might even need to change the law to do that.

Steve Capell: I think we assume that they will just do something because we think it's a technically good idea. And I don't think that's generally true. So that's all I wanted to add.

Benjamin_Young: Yeah, good talk to see you.

Benjamin_Young: Good day.

Dave Longley: Yeah. I think that's really important and I think we're aiming for that but we also want to give primitives and capabilities so that we can move beyond where we currently are. So I think it is a baseline that we need to be able to do exactly what Steve just said. If we hand them a spec that they can't do anything with their existing law, we've failed in some way. But that doesn't mean that they have to use every feature that we put into the spec where we're thinking we're giving people a few more tools to make things dynamic, more machine readable, more programmable moving forward without any expectation that a number of parties will be able to use that right out of the gate. we should not expect them to be able to do that. But we should also make sure that we have whatever primitives they need to model what they currently do now.

Dave Longley: And to whatever extent we're failing to do that, we need to remedy that. regarding what you use recognized in for, it's what Dimmitri said. It's very similar to this identifier feature that we were clearly did not specify well enough where you're linking to an existing system where you already have some kind of identifier scheme and you want to tag a recognized entity with that identifier. The same thing is true of existing lists of recognition. That's what recognized in is that's at least one of its uses being able to link to that and say here's this existing thing over there that already exists. It's important that we be able to add that to this new technology that we have so you can continue using your existing thing before you can transition into maybe using something better or more powerful.

Bridging Existing Systems With New Tech

Dave Longley: Similarly what we're doing with recognized action is I think that is a way in which we're trying to describe scope and we're trying to say what are you recognized to actually do? who you're recognized to issue or verify these things and the only thing we've specified thus far and maybe this is insufficient is the way that you specify the validation for this is through JSON schema or through JSON and it's dynamic and programmable and maybe that's too powerful a feature for some of the scopes that we want to cover and instead maybe we also need to give the option to just say here's a URI over here our validation rules are this URI you follow that You may or may not get machine readable data, but it will take you somewhere to do exactly what said. And maybe that's just another kind of validation for what you're allowed to issue if you show up on one of these lists.

Dave Longley: And maybe that's the way we ought to model it because it will cover existing use cases where we don't expect them to be able to upgrade all their systems to this fantastic new machine readable dynamically programmable mechanism that we're just starting to add primitives to allow people to explore that space.

Steve Capell: So, if I may quickly accepted about recognized in good to have a connection to an existing system. I'll think that sounds quite reasonable. Also, I think I just be careful about positioning the recognized two as some sort of advanced feature that people aspire to because the point I'm trying to make is even if they can specify a schema that recognizes what you're allowed to do. What the point I'm trying to make is that is not the recognition that most of these authorities will ever do.

Recognized As Vs. Recognized To Distinction

Steve Capell: They will say you are recognized as a business that is an Australian not for profofit. They will never say what you're recognized to do. Now I'm not saying that some won't. So I accept the point that open world have a capability that some may use and don't have to. So I think you're on the right track that we need to this is a business question not a technical maturity question to understand that sometimes you recognize a party as something you recognize a party to do something. and we just don't seem to have grasped that no matter how much I say it.

Steve Capell: This is a really important thing, so as for machine readable, I think we need to distinguish as well between machine readable and verifiable within the spec versus machine readable and verifiable across a graph informed by Multiple specs the wrong word sorry cials. so for example, if an accredititation authority says you are recognized Two. this list of URIs and those list of URIs are well-defined public standards and conformity schemes that doesn't mean it's not machine readable.

Steve Capell: What it means is I need to look at the credential that was issued by the conformity body that said in that digital conformity credential what scheme is this attestation issued against and compare that to the URI in the accredititation and go yes the certificate they've issued is for a scope that is listed in the digital identity anchor the recognized entity. So that is a machine readable and automated processible. It's just not something you write in the DIA spec about how you do it because it probably 90% of these kind of graph rules they sit above a particular credential and they sit at the graph level and there's nothing wrong with that. I think it's a reasonable separation of concerns, so I think we're emerging getting towards something here, right?

Steve Capell: which is have the ID that the party is recognized in their terms that needs to be a normative part of the data model and extend the recogniz I'd rather call it recognition scope than recognize too and understand that there are these two kinds of scopes you're recognized to do something and that could be defined by a schema and a JSON other as you discussed or be recognized as something. So is that two properties recognized as recognized two or is it one property called recognition scope that has a couple of options about how you define it? I'm not sure. But let's just broaden our mind about…

Steve Capell: what recognition scope means. It doesn't mean to do something. It might very often mean as something. Yeah.

Benjamin_Young: Yeah, that's really clarifying.

Benjamin_Young: Thank you, go ahead, Dave.

Dave Longley: Yeah. …

Dave Longley: first I want to acknowledge that it's been clear to me, Steve, that you are driving at that difference. that there is recognized as a business and then there is recognized to issue these specific credentials. What I've been driving at is something that is a little even broader than that, which is that I will recognize this party to issue as a business. I'm combining those things together as when you say that you have a recognized action to issue you then provide to issue how to issue as. Those are Only one of those validation rules is here's a JSON schema for a really specific credential.

Dave Longley: You could also say, I recognize this entity to issue as a university or I recognize them to issue as a business and I'm con considering that to fit into the existing modeling that we have. And maybe that's stretching it too much, but that I feel like my proposal or the way I've been thinking about it is actually a further broadening of what's been presented as two distinct classes. I think there's a way to view them as being in the same space. It's just different validation rules.

Steve Capell: Okay, that's reassuring the whole discussion and the words in the spec certainly give the reader the impression that it's about, a particular credential type. you're right. If you broaden the validation rule and say a schema validation against a credential is just one type of thing. There's another way to say validate that you're recognized as a not for profofit in Australian business or whatever. So I think we're really converging here right on a shared understanding and some of it is misreading of the spec. Some of it is perhaps the spec has an idea in mind that it focuses on that isn't the way a lot of the real world works.

Steve Capell: So, we're getting close, aren't we? we just need to find the right language and…

Steve Capell: the right validation rules and the right words in the spec, I think. But I still prefer recognition scope, honestly, than recognize two. But anyway,

Benjamin_Young: Yeah, we can come back to that name.

Benjamin_Young: Phil, go ahead.

Phil_Archer: Yes,…

Phil_Archer: I recognized that certainly works in the so GS1 US is recognized as a member organization of GS1 and that is actually a separate line to the thing about what number sequences they can issue. And I'm now accepting of the fact that this standard is not going to include the information necessary to make that kind of validation that we're looking for part of the spec and I'm happy with that now having argued this and listened to everybody and what people are saying.

Phil_Archer: So I'm perfectly happy that we are going to have to have some sort of validation rules potentially I certainly hope with executable software that you can do that but that is outside the spec. So yes, I do like recognized as I like scope. so I guess I am in the hands of Dave as one of the editors to take all this on board and see how that affects things. Just one more very minor thing. purely by chance, I was introduced by email to the person who actually is behind

Phil_Archer: this issue that is still on the screen at the moment. the Swiss Metrology body, I forget what the name of the organization is, but it's a Swiss it's a national body in Switzerland that if you want to know how long a piece of string is, you send it to them and they'll give you an answer to within a thousandth of a millimeter. and I'm speaking to him first thing Friday morning my time. looking forward to that. This is an area that we hadn't thought of. it hasn't come up anything as a use case but it does obviously fit in with the certification and accredititation world that we have been talking about. So thank you. That's it.

Benjamin_Young: Muted again, Steve. You're back.

Steve Capell: I think I just didn't put my hand down. Sorry.

Benjamin_Young: And okay. Yeah, sometimes Google does, sometimes it doesn't. Go ahead, Dave.

Dave Longley: Yeah, I wanted to say Phil,…

Machine Verifiable Vs. Legacy System Support

Dave Longley: I don't think even though we're looking to make sure that the spec is more clear that we can be more broad about validation rules that we're now eliminating the validation rules we were talking about in the other issues that worked for GS1. So I do think there is a path forward for at least that the prefix and dynamic JSON schema generation stuff that's being explored in one of these issues that still exists.

Dave Longley: It's still a feature that can be used and my understanding is that it did solve GS1's use case.

Phil_Archer: Paul's on the call.

Phil_Archer: He did that work. Yes, you're right. so I'll let Paul speak to it, but I just don't personally see that as part of the recommendation. But Paul, what do you think?

Paul_Dietrich: Yeah, thanks hil. I mean my thought that was really valuable to what GS1 US was doing in their model. Meaning we want to recognize someone to issue a very specific type of credential and then we wanted to do that with the JSON to replace this field match rule that the group wasn't happy with. I can still see what Steve saying that if you're tying to an infrastructure that is basically trying to tie these credentials back to some legacy system, this may not be that useful. meaning recognize too in a schema may not be that useful in a legacy system and that we need some way to point back to some legacy system you're recognized as someone who's compliant with something. but I can still see the value of both of these. And so I think it's a question of how do we use this for new machine verifiable formats and…

Paul_Dietrich: how do we recognized entities to legacy systems that won't be using those formats.

Benjamin_Young: Yeah, it feels like there is a bridge that we can build here between the now and…

Bridging Regulation To Digital Expression

Benjamin_Young: the next maybe. is collecting all of the recognized two stuff that maybe is imaginable in a bunch of Jason blobs or all the realities around us seems very far future looking and I think what Steve's been trying to keep our heads pointed at is the reality in front of us that there's not currently a clear bridge from regulation X Y or Z that says what kind of entity

Benjamin_Young: you are and the digital expression of that document in a bunch of plumbing and…

Benjamin_Young: knobs and dials for machines to limit your actions later. but how we go from A to B is maybe what Steve's going to tell us.

Steve Capell: No, no.

Steve Capell: I was just going to emphasize again because I just heard someone say, " legacy system not ready yet." It's the point I'm making. It's not a technology point. I'm trying to say that a lot of recognitions are nothing to do with what you can do, but what you are. It's not like that we're waiting for some maturity to happen. It's just that is not what they're recognizing and never will be. So, I don't know how many times I've said it, but people keep coming back and saying, " yes, it's a legacy thing we need to support." No, it's an existing business process that is unlikely to change. That is the real world.

Middleware And Ecosystem Solutions

Dave Longley: I'm definitely on that page with you, Steve. I also wanted to point out that with this technology since anyone can issue anything that they want to there might be a significant number of middleware parties that do some additional curation that produce things for different ecosystems and different verifiers that might augment things in certain areas where they add specific credentials that can be issued or not issued bas based on the fact that something is recognized on some authoritative register that says're just They're recognized as a business.

Dave Longley: There might be some middleware intermediary party between them and some other verifier somewhere that further sort of attenuates that for a specific area and there's someone who's responsible for curating such a list based on the higher level authoritative government list. we want to make sure that we don't close the door to these sorts of interesting solutions that help people be more efficient here or…

Benjamin_Young: Yeah, I'm going to skip me.

Dave Longley: there while we also accurately capture what different parties at different layers of this whole stack part. are willing to say that they recognize

Phil_Archer: Ju just for a brief to pick up on what Dave was just saying. yes, the middleware thing is something that I need to talk to Paul and Todd and others tomorrow, but that is very much something where we see a role for ourselves in our own validation. So yeah, we're going to be I hope producing some middleware software that can be incorporated. this is not directly relevant to the current conversation but as an example of what we've done in that space some of you will be aware that we're moving from the one-dimensional structure barcodes that most of you are too young to remember life before they existed to two dimensional codes and so on.

Phil_Archer: And we have a bit of software that is now embedded in a lot of scanners and a lot of printers around the world and that's sort of the model that we want to follow to get that middleware layer into other things. But as I say I hear what you say Dave those things that Paul has experimented with they're valuable and I want them to be possible. of course I'm just wearing my co-chair hat. I'm just aware that some of that stuff is not going to sit well in a W3C spec. It's got to be something that's sort of hinted at and pointed to as an informative you could do it this way. as distinct from this is…

Phil_Archer: how the spec requires you to behave. And I think that that's a difference that we're getting to.

Benjamin_Young: Yeah, I think that's a good summary.

Benjamin_Young: I think we should try to push this towards some practical proposals. we have the recognized two stuff already in the spec. Steve, you and Chad have proposed recognized scope and obviously recognized as has been floated.

Benjamin_Young: Is there a PR shaping up in anyone's mind that that could be written that would express this? Go ahead, Nick.

Recognizing Entities For Issuance Vs. Verification

Dave Longley: I'm not sure that we know whether or not there is ever a bifurcation between recognizing something as a business for the purpose of issuing whatever businesses issue versus recognizing something as a business to receive or ask for information. Then those things and maybe you end up not referring to one as a business. Maybe they get some other more specific name. But I'm a little bit concerned about

Dave Longley: creating a situation there are subtle attacks that come up with authorization systems between capability based systems and ACL's and I'm a little bit concerned that I don't want us to introduce something similar in this space. I know that by recognize to clearly distinguish between issuance and verification that's helpful in some sense. I don't know that we always need it but I also don't know if we will introduce some subtle problems if we don't always go through that pathway. I'm not sure that that was

Benjamin_Young: Yeah, I didn't quite track it,…

Benjamin_Young: but maybe others did. Go ahead, Steve.

Trusted Verifiers Vs. Recognition Scope

Steve Capell: Just following up on that,…

Steve Capell: I remember some discussion in Europe about so-called trust lists, And you parties are supposedly trusted to issue things, but you're also trusted verifiers. I never quite understood how you could even control or mandate trusted verifiers. and if I understood right, the previous commenter was saying be careful not we trust you to test or verify something space. Is that right? Because I'd probably agree with that. The scope here is what I'm accrediting or authorizing recognizing

Steve Capell: a party that I interact with have registered for some purpose. That's the purpose of this, right? not to start saying you can't or can you are or are not a trusted verifier because these credentials are out in the wild. I don't know how you stop someone from verifying something. was that the point? and back to the PR, I could write a PR, but the question for the group is probably a simple one. Do we think we should separate recognized to and…

Steve Capell: recognized or do we think we should have whatever we call it,…

Steve Capell: recognition scope that accommodates both models and maybe more?

Benjamin_Young: Yeah, good question.

Benjamin_Young: Go ahead, Ted. I'll follow up.

Contextual Nature Of Recognition

Ted_Thibodeau_Jr: Yes, we should recognize all of those things.

Ted_Thibodeau_Jr: If you are recognized as a thing, then you're probably doing shortorthhand for the things Does that thing issue? Then it's recognized to issue by being recognized as an issuer. I don't think many of these properties are being written about as requirements. I don't think we're saying that anybody has

Ted_Thibodeau_Jr: recognize scope or recognize issuance or whatever they are permitted to use these things and if they use them they should follow the guidance that we give as our definition of it. If they use them with some other meaning then they will probably be misunderstood because that other meaning is not what's in this standard. as to organizations that have never and therefore will never drop that from your head, please, because there's no way to predict that, We're all carrying around in our pockets super supercomputers versus 20 25 years ago, they just didn't exist.

Ted_Thibodeau_Jr: So, of course, nobody would ever be carrying a million songs in their pocket or…

Ted_Thibodeau_Jr: access to something like the OED or access to something like Britannica in their pocket. But every one of us is it freedom.

Benjamin_Young: Yeah. Thank you,…

Benjamin_Young: Ted. Go ahead.

Ted_Thibodeau_Jr: Sorry, little bit.

Benjamin_Young: Sorry. You're done.

Ted_Thibodeau_Jr: What we're specifying is freedoms. And the things that we don't specify, they are still free to do. It's just that they won't necessarily be as understood as they are…

Ted_Thibodeau_Jr: if they follow the published specification and standard. I'll leave it there.

Benjamin_Young: Yeah, I think based on your description and…

Benjamin_Young: what you posted in chat, Ted, that the thing missing in your list is the recognized action stuff, which is extremely particular in its aim and defines very specific shapes for very specific credentials.

Benjamin_Young: And I think everything Steve's been highlighting is not that that should not be possible or is not some way to constrain issuers around the actions they are not recognized to take. but that there are plenty of use cases where whoever is doing that recognition is not going to care and is not even going to enforce that and is not certainly going to be able to constantly update that while the organization changes what it does and how it does it does it.

Benjamin_Young: So I don't know if this is an applicable analogy but in the US we have 501c7s which are membership organizations and those things cover social clubs of varying kinds private bars and golf clubs and all kinds of stuff. and those things re recognized has 501c7s and are permitted to take money from membership and not pay taxes on it in order to buy property and whatever it's going to do. The IRS doesn't care about what your membership card looks like or what data you collect from your membership. you just have to report when they pay you and…

Steve Capell: It's best.

Benjamin_Young: that you use the money certain ways.

Benjamin_Young: So that to me sounds like Steve's recognized as a thing that would not make sense to encumber with a recognized action assuming the IRS is the recognizing party. because if I try to force recognized action into that, it looks really dystopic and the IRS is slapping hands and all kinds of stuff at a level that it doesn't currently, which that would seem dystopic to give that group in particular more power. But maybe I've misunderstood something. Go ahead, Duke.

Need For Concrete Use Case Examples

Dave Longley: Right so to quickly respond way back when around being recognized to verify in Europe they are interested in creating lists of parties that are recognized to request certain information and then having digital wallets look at such lists and if a request comes in from someone who's not on the list to reject that request or something along those lines. So I'm not commenting on whether or not that's a good idea. I'm just pointing out it's a thing that is being done. and so we should consider it here in just given the fact that someone's doing such a thing. I think maybe what we're missing here before we jump into defining these properties is some examples of if precisely what we think issuers would like to express they recognize so that we can try and find what is in common.

Dave Longley: And I would rather us not invent many different ways to say we recognize this two or scope or issuance or regulation. I would rather us offer the people reading our spec the minimum number of things that helps them do what they want to do. Otherwise, I think we'll have a lot of confusion. And so I think maybe what we're missing are let's write down examples of these things. you're recognized as a business. you recognize to issue this specific VC with this prefix that meets the schema. we already know we have at least those two things. Let's take a look at those and see what they mean. And if the semantics of this shakes out that it's all should go under some kind of scope and then we go from there, that's one way to do it. If it makes sense that it actually could all fit under you're recognized to issue as a business or to issue this credential, that's another way to do it.

Dave Longley: There's a variety of different ways to do it, but we want to make sure that we can allow issuers to say as much as they need to both for existing cases that yes, we don't expect to ever change because they're already doing, what they plan on doing, which is only ever saying that you issue as a business or whatever. and future-looking things where hey we could put some more machine readable stuff in here and enable some more interesting cases or because we have this feature some middle party could build a list that makes it easier to implement in this ecosystem things like f***.

Benjamin_Young: Thanks, Dave.

Benjamin_Young: Go ahead, You're on mute.

Kevin_Dean: Okay. …

Explicit Vs. Implicit Permissions In Recognition

Kevin_Dean: yeah, throughout all this, I think we have to be careful with recognize too because it can be inherently limiting. if I, recognize as comes with a bunch of implicit permissions depending on what I'm recognized So, if I'm recognized that this is recognized as a business registered in Ontario, Canada, then there's all sorts of things I can do. file taxes, government, interact with other businesses, in B2B. Those are all implicit to the fact that this VC identifies my business. whereas recognize to is much more explicit.

Kevin_Dean: is saying explicitly that this entity is recognized as having the authority to do something and that anything else that this entity may want to do is out of scope at least of this VC. They would have to have another VC that would provide either explicit permission with a recognized to.

Kevin_Dean: I think that distinction is important.

Benjamin_Young: Yeah, thank you,…

Benjamin_Young: Paul, go ahead.

Abstract's Focus On Specific Actions

Paul_Dietrich: Yeah, maybe I'm going to say something similar, Kevin, but I think the recognized and recognized to are two different things. when I read this document, I'm a newcomer here coming to try to use this for what we're doing at GS1. And literally the first section of the abstract talks about what can be known to perform specific actions. And so in my mind I think about this as a recognized too because the abstract saying to support specific actions and maybe we need to go back and revisit that if there's recognized as is that's just describing kind of the identity of an entity from a root of trust meaning how does it fit into a particular ecosystem and that recognized doesn't feel like it's well called out in the abstract unless it's recognized as someone who can perform an action. so we need to go back and revisit that abstract as well. Thanks.

Benjamin_Young: Yeah, agreed.

Benjamin_Young: Go ahead take

Ted_Thibodeau_Jr: I associated with that is…

Ted_Thibodeau_Jr: what I'm hearing is a lot of universally accepted and acted upon statements. Who makes the statement matters a lot. If the government recognizes me as a business entity, that carries a lot of weight in some spaces, but not at all in other spaces. This is all very contextual. And I'm not hearing the context as being part of the pictures that a lot of people are speaking. And I recognize you as a wombat. I'm pretty sure that you're not a wombat.

Ted_Thibodeau_Jr: And my putting that into my VC about you has no effect on how other people act about you because I have no standing to recognize you as a wombat or a human. This is key to what I'm hearing. That's it.

Overloading Recognized Entity Credential

Dave Longley: Yeah, the other thing that I mentioned in this data modeling issue was we should also be careful. I mean a number of these use cases might just be better solved and have been at least partly solved by issuing an appropriate VC. you'll get a business VC that says you are a Use that business VC when you're trying to do business things. and how that links up or back to a recognized entity list might be at a different level or layer in that space. So we should also be careful with that we're not trying to overload the recognize entity credential to say all of the possible things that VC types are created for.

Dave Longley: You could just imagine trying to put something into, I'm recognized as a business. you're just going to drop the string business in there. I doubt that's going to work very well, which is why I was thinking more along the lines of having specific URIs to point at specific validation rules that is a little more row. and maybe a significant portion of these use cases is that are better solved with here's your business VC, here's your university VC, and if you're going to chase the issuer of that down, maybe they have an accreditation VC, and then you chase that down, and maybe that ends up being on a list of governments that are able to make statements. and there it does have to go somewhere.

Dave Longley: There's a stopping point, but we should be careful that we're not trying to make the recognize entity credential do too much when we have other primitives that were already designed to do those jobs.

Benjamin_Young: s***. Yeah,…

Steve Capell: deserve.

Benjamin_Young: agreed. I do think our biggest takeaway here is some use cases because in none of what we've discussed, has anyone said, I need to recognize the actions of these things. I know that's what's in the spec and what we're kind of working up from now. but our stories don't include that.

Benjamin_Young: And I worry watching this happen that the recognized entity spec, which sounds way more like what you just described, Dave, in its intention of, here's a list of entities that can issue certain or have been trusted by these other parties, etc. and then what that VC chain looks like or if it only exists to shorten the cost of chasing issuer chains infinitely. yes, Ted.

Benjamin_Young: these terms that we're using to and…

Steve Capell: and clearly disappeared.

Benjamin_Young: and whatever need to all and action need to all be hung on actual use cases so that we can push back down into the technical layer because I feel like a very particular set of use cases got expressed into the spec and clearly displace Steve and the things he's been thinking and it sounds like confused

Benjamin_Young: a lot of people including GS1 folks on the call. So we need to and Steve's done a good job of surfacing the fact that it's not matching with the language currently.

Benjamin_Young: It's not matching with the intention of why he's here. And so how do we then express those use cases irrespective of what's in the spec and then push them back towards each other for the different use cases. And I think that needs to be next. I don't know what issues we file for that, but go ahead and take us home, Steve.

Steve Capell: Yeah, first of all,…

Steve Capell: I just wanted to say thank you for everyone for being open to this discussion because I know it's a bit frustrating as we get towards the end o of the specification writing. I also agree with I think it was Dave or Ben that said let's not overuse this thing. if you need a VC then use a VC. So that brings us to what do we think a recognized entity is When do you use recognized entity? and in my mind it's when Ted's issuer whoever that is the party that is making the assertion the recognition has some sort of membership. It could be a social club or it could be the Australian tax office or it could be anyone that says

Role Of Recognized Entity As A List Membership

Steve Capell: is I've got some sort of process by which I register members and they could be all kinds of different levels of assurance or formality, but that's what it's for, right? It's basically to say you're on my list. that's my simple expression. And if that's what you're trying to achieve, a recognized entity is a good tool to do it. If you're trying to do something much broader, then maybe you need something else as well But if that's what we think it is, then that works, right? And then we're just down to I think a minimally simple what are you on the list to do, to the scope of your role on my list. And we want to keep that simple.

Steve Capell: And I think complex validation rules can be at a different level outside of the credential. But yeah, I'm coming away from this quite content actually that we're converging on quite a good consensus.

Steve Capell: We're just now discussing language really all right about what's going to be the least confusing way to express what we want to achieve. So thank you all for that.

Benjamin_Young: It's nice we're down to the easy part,…

Benjamin_Young: naming. Go ahead, Phil.

Phil_Archer: Plus one to everything Steve just said.

Phil_Archer: Trying to think of positive actions as we run out of time on this call. what I'm going to do is I'm going to review the use cases. There are five use cases in the recognize entity document and I'm going to have a look at them and bear in mind this conversation and see if they need tweaking a bit to sort of so that I know you sort of the idea is you write the use cases first then you write the spec to meet the use cases but there's always a bit of circularity in that and so we end up being clear as Steve was just saying right so what is part of

Phil_Archer: the spec, what is enabled to be happened outside of the spec.

Phil_Archer: And as others are saying, I think I'm feeling content that we are heading towards consensus, which is good.

Benjamin_Young: All right.

Benjamin_Young: Thank you everybody. We will be doing this again in a week.

Paul_Dietrich: Thanks, man.

Benjamin_Young: So please come back and bring more thoughts.

Phil_Archer: Thank you.

Benjamin_Young: Thanks all. Bye.

Phil_Archer: You on the main call tomorrow. Meeting ended after 01:02:53 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.