Meeting minutes
Benjamin_Young: Hey y'all. I'm filling in for XL.
Phillip Long: Hey Benjamin.
Benjamin_Young: Can y'all hear me?
Phillip Long: Yeah, I
Kevin_Dean: Yes, we can. Benjamin Young:
Benjamin_Young: Thank you. the new Chrome UI was making it look like I was muted or telling me Windows was muting me. I had my doubts. Thanks. I'm filling in for mono today, but we'll give it a couple more minutes while people show up.
Kevin_Dean: Perfect. I'm on top.
Benjamin_Young: Okay, I think the revolving door has calmed a bit and…
Recognized Entities Call Kickoff
Benjamin_Young: we'll get started. thanks everybody for coming. This is the VC recognized entities call. I'm filling in for Manu today. I think the main things we're going to look at are the threat model and then coming back to the GS1 UNC use case conversation. Kevin, I believe you're probably on tap for the threat model state.
Kevin_Dean: I'm on top for the GS1 compensation actually.
Benjamin_Young: That one too. who was leading threat model or…
Kevin_Dean: Okay.
Benjamin_Young: did we quite have that sorted out?
Phillip Long: If it's anyone,…
Phillip Long: it's probably Manu.
Benjamin_Young: Yeah, I see there's a pending PR and it's got a couple plus ones. so maybe let's just take a look at that to start things off and then we'll move to the other topic. Can everybody see that? And is the size of it tolerable? Okay. Holler if you need it zoomed in or anything.
Threat Model PR Review And Merge
Benjamin_Young: I don't know if everyone's had a chance to look over it. we have a lot of the same kind of work happening across many of the task forces. So hopefully it's fairly familiar. does anyone have any concerns about what's headed in here? or Phil Dave, you want to say any last words before I click merge on your support if I can? Yeah, something is blocking the build…
Phil_Archer: I think this is one of the things that get filed under. my god, I was meant to do that.
Benjamin_Young: which fixing the bug or
Phil_Archer: No. just I promised I'd review it and…
Phil_Archer: I just …
Benjamin_Young: You plus one it.
Benjamin_Young: Is that not a review?
Phil_Archer: I Okay. Must have done that then. All right. I even forgotten I'd done that.
Benjamin_Young: Earlier Phil has your back. Looks like you did that two weeks ago.
Benjamin_Young: So, it's ancient history. Exactly. Yeah. No, thank You did the hard part. so the CI is failing here for some reason. and I'm not sure we want to debug this on the call. I do not know if I'm going to go check. I don't want to debug this live.
Phil_Archer: That's why I forgotten it. Yeah.
Benjamin_Young: I'm going to go see if the main build is failing. it so consequently, and it looks like the same thing, probably in the same Okay. So, I'm going to recommend that since we have approvals on the pull request, we go ahead and merge this and, deal with the CI stuff later. are there any objections to doing that? Okay, seeing thumbs up from Dave. So, I'm going to go ahead and rebase and merge and somebody else can figure out the robots. already a very productive call. Thank you everyone.
Benjamin_Young: Believe we do have two more PRs. One more because that one's closed. No. What did we just merge? I'm guessing this one has been overtaken by events. Yes, that's what just happened. Sorry so this one will likely get closed as merged by the other one. there is some commentary on this other open PR. I think it also has approvals.
Shigeya_Suzuki: No, we have a discussion in the BC data model. I mean so should be aligned with the discussion I think.
Benjamin_Young: Okay.
Benjamin_Young: So, this still has pending work. Okay, then we'll leave that one alone. Thank you, okay then why don't I stop screen sharing and we move to the discussion that was I think started last week or two weeks ago about the UN
Benjamin_Young: park and…
Benjamin_Young: GS1 and Kevin that is the thing I think you are on tap for and Steve you're likely mixed into this I would expect
Kevin_Dean: Yep. Okay.
GS1 Use Case Overview
Kevin_Dean: Just a reminder, I used to work for GS1. I have not worked for them for about two and a half years now. And although I am still involved in standards development at S1, any authoritative statement from GS1 would come from Phil Archer when he wears his GS1 hat. However, the GS1 use case is really just The core of it is the mapping of a hierarchical identification system to a verifiable credentials. Sorry.
Kevin_Dean: And the root of identification is what's called GS1 global office. they're based in Brussels. They have with an office in the US in New Jersey. and they're the identification system that we know as the barcode in the grocery store and every other retailer nowadays is essentially managed but locally assigned.
Kevin_Dean: when you look at any barcode for any product and let me just turn on my camera here so I can show you simple sample here. Okay, the barcode that you see I'm not going to tilt this completely sideways because there's still liquid in it and I really don't feel like getting it all over my lap. But the barcode encodes that number along the bottom. The first few digits of that barcode, the first three digits you are what are called the GS1 prefix. This is assigned by global office to individual country member organizations.
Kevin_Dean: The country member organizations then take that those three digits add a few more digits to it and assign those to user companies. That is called a GS1 company prefix. And that GS1 company prefix forms the basis of not all but some of the identifiers that company issues. Because if you're dealing with a very large company with thousands of products, they may have multiple GS1 company prefixes. The important thing is that although the GS1 company prefix can tell you which company has the license for that range of identifiers and from there which GS1 member organization issued it to them or has the license for that range. it doesn't tell you much more than that.
Kevin_Dean: But this was a system that came about in the 1970s and it came about in a time where of course communication was expensive and in many cases non-existent at least real-time computer communication and the system was developed so that if GS1 global office gave GS1 Canada a range of identifiers to use and from that range GS1 Canada gave my company a range of identifiers to use. I could then assign one of those identifiers to my products and be guaranteed that it was globally unique. the way that let me just bring up I should have had this ready to go.
Kevin_Dean: I just need to bring up the document here. white paper. so what GS1 did and I was the lead on this data model. I'll drop a link into the chat here. Anybody would like to see it for themselves. But the idea behind it is that we want to know that you have the right to issue this identifier to this product. And for that we have this thing called a GS1 company prefix license credential.
<Kevin_Dean> https://
Kevin_Dean: So the member organization would issue that to your company to say this is the range of identification that you can use. But that in itself is not enough because you would have to know all of the member organizations around the world. You'd have to know the DIDs for all of them. and although it's a mostly static list we do new MOS come into being old MOS drop out because they long can't sustain the business but you'd have to maintain that list and you would have to know that they are doing it correctly that this GS1 company prefix license credential actually it is actually one that the GS1 member organization can assign.
<Phil_Archer> Minor updates to what Kevin is showing is formally published at GS1 Digital Licenses
GS1 Data Model Explanation
Kevin_Dean: So what we have in the data model is this thing here called extends credential. And for the GS1 data model, it's a standard attribute. It says this credential exists because of the authority granted by this other credential. And for a GS1 company prefix license credential, that extends credential would actually refer to a GS1 prefix license That GS1 prefix is issued by global office.
Kevin_Dean: So if you have the appropriate chain of credentials right down to the identifier that's assigned to the product, you can state that this global trade item number, which is the formal name of the number in the barcode is based on this GS1 company pre license credential issued to this company and that in turn is based on this 1 prefix license credential issued by GS1 Global Office. The only DID you need to know is that of GS1 Global Office.
Kevin_Dean: As long as you have did as a trusted route and you apply the appropriate business rules, you can validate the jet the identifier and the business rules are pretty straightfor Extends it not only means that this credential is based on this previous credential. It also means that the issuer of this credential must match the subject of the prior credential.
Kevin_Dean: And if the issuer and subject don't match in that way, then the credential chain isn't valid because it means that somebody somewhere has said, "Hey, I'm going to create for this product. Here's the credential for it. It's not based on my GS1 company prefix. I've just borrowed somebody's and since I don't have their key, I'm just going to use my own did as the issuer. it doesn't match the subject of the prior credential and so the business validation fails. And it's important to note that this is nothing to do with the verifiability of the credential itself or with the cryptography or the structure or anything like that. This is now that we are past the ver verification phase, what business rules do we need to apply to validate the credential?
Kevin_Dean: Once we get down to the identifier, there are other credentials in this document that talk about the data associated with the product because it's one thing to say, "Hey, I've issued this identifier. That's fantastic. That's wonderful. What does that identifier mean?" There are data credentials in the document that outline let's see if I can find them here. a data credential we've got where we can make now we can make declarations.
Kevin_Dean: Okay, so we have a GS1 key credential which says this GS1 key exists. it is based on a GS1 company prefix license. And then we get into the data and data gets interesting because when you're doing data there are different rules about who is allowed to make claims about the product. You generally trust that the brand owner will make complete and correct claims about their products, but that's not always true. It could be that this data credential is a certification. the brand owner can't self-certify.
Kevin_Dean: If you have an outside certification agency, that agency is the one that can issue a credential that says, "Hey, this product is kosher or halal or vegan friendly whatever." that certification agency is the one that can issue the data credential. So the extends may not be present. it may extend a totally different chain of credentials. so who can make the data credential claim depends upon what the data type is in order to authorize that there are things like authorization who or delegation so as a brand owner for example could say what you want planagram data for my product planagram data it needs to be accurate because if we get the planagram data wrong which is the dimen
Kevin_Dean: dimensions and the weights of the product. as the retailer when you go to put it on the shelf, if I've given you the wrong dimensions, your planagram suddenly doesn't work because I've undersized or given you the wrong sizes. My product is bigger than I said It doesn't fit on the shelf. I've just created more work for you because you can't put it out on the floor. so I've hired this external service that will give you the right data and I can delegate the planagram data credential to them to say I'm authorizing this company and if you link everything together correctly and it goes into detail in this document as to how exactly you would do so you can look at a planagram data credential see that it comes from somebody
Kevin_Dean: other than the brand owner, but also see that the brand owner authorized this company to provide planagram data and that the identifier that's being used is traceable to a GS1 company prefix in turn to a GS1 prefix and in turn to GS1 global office. So there's a great deal of linkages in here which vary by use case but are ways of linking the credentials together beyond just saying that here's an entity who can do X.
Kevin_Dean: Some of this is also in the U VC use cases a summary of it is in the VC use cases document let's see focal GS1 identification if you want it I'll post the link to the respect rendered version afterwards but it's summarized in a chain of GS1 credentials to identify a trade item which I submitted to this document when I was working at GS1 out
Kevin_Dean: That's better. okay so there's a walks through a scenario here where healthy tots wants to list its products on the sell anything and everything marketplace and in order to prevent conflicts with identification sane requires unique identification and requires proof that
Kevin_Dean: the G10 does belong to the product that they are listing and there are some example verifiable credentials in appendix B we outline all of the actors GS1 global office of course which is the trusted route of the GS1 identification system we then have GS1 Utopia which is a member organization healthy tots which is the GS1 company prefix licency and so We also included transfers because after growing to a certain size healthy tots gets acquired by benevolent conglomerate and as part of that process it can acquire its rights to the GS1 company prefix licenses. That's standard practice.
Kevin_Dean: You see it particularly in grocery all the time. My wife works for a consumer package goods manufacturer and they're doing acquisitions and divestments of brands and product lines all the time. And part of that is management of the GS1 company prefix licenses that apply to those products. Are there any questions about that before we jump into related discussion? Right. Hearing none.
Recognized Entities And Trust Roots
Kevin_Dean: I submitted an issue because of the work I had done on the GS1 use cases back in the day. I wanted to work I went through the recognize entities document and looked at it through the lens of the GS1 use case. and more generally how do you deal with chains of credentials because of credential A I could issue credential B which in turn allows you to issue credential C.
<Kevin_Dean> Verifiable Credentials Use Cases
Kevin_Dean: And I wrote this issue up a couple of weeks ago. it's pretty detailed. but it starts with, as it says, stuff everyone knows, but bears repeating saying that every recognition chain must have a root of trust. We all have to start somewhere. Now, if we're dealing with supply chain, the root of trust for the identification system is GS1 global office. we've neither known nor care about any other identification systems because this is what we're doing. that's the GS1 world. But in reality, the GS1 identification system is a subset of an identifi of a larger identification system managed by The ISO standard in particular is ISO 15459.
Kevin_Dean: that writes the rules for identification and GS1 is registered as the owner of the identification space starting with any digit 0 through 9ine. So if you every other ISO 15459 identifier that is outside of GS1 starts with an alphabetic character. GS1 owns the numeric space.
Kevin_Dean: So we have to start with the root of trust and the chain up to the root must be structurally verifiable from the claim up to the root and the chain must be validatable from the claim to the root. You have to be able to apply business rules all the way up to the root to say to know whether or not you can accept this credential even if it passes structural verification. when I got to gnizing provides an a path to an externally trusted route and in my opinion I think this definition is flawed in that it's an attribute of a credential subject I think it's in the wrong place we see this for example in the European Union's SC trust services list example you will see recognized in
Kevin_Dean: is a credential subject is part of the credential subject and it doesn't really tell me anything I don't already know because this entity is in this external list and the verify credential is just duplicating that information. There are some confusing parts. Yes, Dave.
Dave Longley: Sorry I didn't mean to interrupt your train of thought.
Kevin_Dean: No, no, please interrupt at any time. I don't want to get to the end of this and…
Dave Longley: Okay.
Kevin_Dean: then forget what I said. when you come back with your question.
Dave Longley: The way that this is modeled in the spec today, and this might not be clear enough, is that recognized in is part of a recognized entity.
Dave Longley: So, if your type is recognized entity, then you can recognized in. That does not mean that you can only put that type in a credential subject. For example, you could model your issuer and say the issuer is of type recognized entity and put recognized in there. Any place you want to talk about not just a credential subject in the VC, if you mark it with the type recognized entity, then you can use the property recognized in
Kevin_Dean: And…
Kevin_Dean: that certainly addresses one of my concerns because if I'm in this list already and this list is already trusted I should be able to make a statement hey I'm in this list and based on that I have the authority to do X because if we rely on the manager of that list then now that manager has to stand up a verify credential ecosystem which they may not be interested in doing.
Kevin_Dean: I want to use VCs based on my presence in this list. I can't force the owner of that list to issue me a VC as a starting point. So, having the recognized in be part of the issuer would certainly help. it would eliminate the need to get the issuer to get the manager of the list involved. I would still have to prove the correlation between my did and however I'm identified in that list. but that's probably a list specific process.
<Dave Longley> one non-DID way to link things in a VC directly: `{"issuer": {"id": "...", "type": "Gs1FooBarIssuer/RecognizedEntity", recognizedIn: "<insert URL for a recognized entities VC>"}, ...}` ... another way with a non-DID VC is to make the issuer ID dereferencable to an HTTP CID with service endpoints in it just like a DID
Kevin_Dean: I did have some confusion point that I pointed out here which I'll leave for the whomever is managing that part of the document to go over in more detail and what it got to me was the way I recognize it is structured there's nothing preventing me from issuing the same credential. This I think is a weakness in that I could issue a credential saying that you Dave are in this Etsy list and a verifier would look at that and say hey okay that's correct is not the right did to be doing this because I'm not the owner of the list but a naive verifier could maybe it doesn't check it properly and it suddenly did extra author
Kevin_Dean: authority that I shouldn't have within their system. and this is where I started. I went beyond just basic recognition and applied the GS1 lens because there are many roots of trust that exists outside of definfined protocols such as X509 and Etsy. and what we want out of VCs and DIDs, what we've always wanted, I think, is a true self assembling trust system, flexible enough to support any root of trust. It's not our job to dictate what a root of trust can or As long as some group somewhere says, "This is what I want to do. This is my root of trust." We don't That's fine.
Kevin_Dean: And there's nothing we can or should do that would say otherwise. but what that means is but if we take a university degree okay and let's talk specifically about a university engineering degree in Ontario Canada because that happens to be my degree. In order for an institution in Ontario at least to grant degrees it must be authorized to do so by the Ministry of Colleges. for it to grant engineering degrees, it must be authorized to do so by professional engineers Ontario. And so for an engineering degree to be valid, it must be traceable to both the ministry and PEO. So we've got a verifiable credential that says I have an engineering degree would have to reference the government ministry and the professional society.
Kevin_Dean: under the list model the university could use recognized in to self-declare that it's in the lists managed by the ministry and PEO but it would require recognized in to be one to many multip multiple entries instead of in granting the degrees it could add the ID properties of the verifiable credentials it received in a
Kevin_Dean: fields such as recognized and I differentiate between recognized in and recognized because recognized in points to an external list recognized because points to another VC and when you're doing recognized in and pointing to an external list there's privacy risk because somebody who goes to get that list you could log their IP address and hey there's a verifier out there that's getting this list we don't know why but it's happening somewhere new let's see what we can learn about it. Whereas if you're doing recognized and you've got these IDs, then you can create a system where the presenter is required to present the complete chain. or you can mix the two. it's the VCs that the Ontario Ministry issues to the universities could well be public.
Kevin_Dean: And anybody who is presented with my engineering degree could look at the recognize and says, "Yeah, I recognize Those IDs belong to these credentials. Let's go and check make sure they're still valid and they still follow all their structural and business rules and u and that's correct." Or it could be that this is a closed system, highly secretive, and yeah, you've given me this credential. has got a couple of some recognized but you haven't given me the credentials on which it's based and I don't have them so I can't validate this. Yes, Dave.
Dave Longley: So, a couple points. First, usually I think we need to be more clear with this, but usually when a property is offered and it's described as here's what the value can be. you can also use more of those types of values by simply converting it to a set. That's how the VC data model usually works. So, we should probably be more explicit and indicate that's a possibility.
Dave Longley: and then analyze if that creates any problems. The other thing that can sometimes be done is a URL can be a data URL.
Kevin_Dean: That's the right?
Dave Longley: So you can embed an entire credential or something else. We should explore whether or not that helps solve this case and if not maybe recognize Dan needs a type that could refer to these other external credentials. giving us the opportunity to do things like refer to them and put a message digest in there. pros and cons. some of those you're covering here, whether or not there's potential privacy leaks because you're going out to fetch this information. but we also want to avoid making lists that are so enormous, that they're unusable as well. so
Kevin_Dean: That's yeah, we don't want to have a list that it takes forever to download.
Kevin_Dean: And having recognized in or recognize because just point to the ID of other verifiable credentials not to did but to other VCs would go a long way to solving the privacy issues and the download size issue because if I'm referring to these two VCs as the rights that grant that as the source of the right for this VC the data download is really small. you don't need to bed within credentials. You just embed their IDs.
Dave Longley: And it gives the holder the opportunity to fetch that information however they would and then present it along with whatever they need to present.
Kevin_Dean: Yep. All right.
Kevin_Dean: That's it for me. nobody's added any comments to this yet. I'm sure there'll be some changes thanks to Dave's clarifications. there are no more questions.
Kevin_Dean: I will hand it over to the next subject if we have one.
<Phil_Archer> Thank you Kevin
Benjamin_Young: I'm not sure we do.
Benjamin_Young: Let me check my notes. But I think that was a great overview. Thank you very much. lost my tab. does anyone else have anything pressing they'd like to discuss today?
Bottom Up Discovery Of Trust Anchors
Steve Capell: If I may, it's Steve here. I just like to say ditto to the GS1 use case. I've just posted a couple of issues which I promised I would do last time and I didn't get around to it. So, I sat and typed them while the previous speaker was talking. I think the spec is as it's written right now does not work for our use case or the GS1 use case right because it's a bit like Val it's just founded on the idea that there is a list somewhere that by some out-of-bound means I know where to find and it's a list of all recognized entities
Steve Capell: it's the kind of top down start with a list and check that the issuer of my credential is on it. Whereas our use cases are bottom up. Start with the credent you're given an invoice a product passport a conformity credential whatever it is and traverse a chain upwards until you hit a trust anchor. And the key difference is that It's an individual credential from a recognized entity saying this particular member on my list is in my register. and not only that, but it's not a single layer traversal.
Steve Capell: So I go from my invoice and I find a recognized entity credential from let's say Australian business register that says this party is a recognized Australian business. But it doesn't stop there. I still need to then go and say is the issuer of this recognized entity credential actually a genuine business register? For that I go to the next level up to the UN grid. This is the same pattern as the GS1 member office to head office, And so I don't think the spec currently it's just not written this way.
Steve Capell: I'm not saying it has to change completely but unless it can present a scalable mechanism to traverse through a bottomup discovery to a trust route. It doesn't meet their needs.
Dave Longley: Yeah, I think one of the things the spec is definitely missing is examples of doing just that and how it would be done.
Dave Longley: If you could put these back links into any credential under the issuer and…
Steve Capell: Come on.
Dave Longley: your issuer is a recognized entity and it has a backlink to this recognized in list so that you can follow up and you can then follow that all the way up whatever chain to wherever it goes. it's definitely a shortcoming of the spec to not say how that works right now and we should show it working and we should get verification that the people…
Dave Longley: who would like to have it meet these use cases would say it meets their use cases. yep.
Steve Capell: Yeah, I think by the way it works.
Steve Capell: There are two when people talk about trust lists they get used particularly in the ISOMDL context in two different ways. is the issuer of this thing authorized to issue it? is this California driver's license authority actually one of the world's driver's license authorities? and the other one is this verifier who they say they are and should I give them my credential? Right?
Steve Capell: And these two things seem to be treated quite differently but actually they seem to me to be the same pattern which is just give me a credential that proves who you are and if that credential alone isn't enough I'll follow a trust graph a traversal until I find a trust anchor just like a root certificate in a browser until I'm happy. It seems, that there's one simple pattern that solves all this, right? Because even in VCAL, who says that the issuer of the VCAL list is authorized to issue that list? Anybody could make a Val list, There's so many unanswered questions. It just doesn't seem to fit the real world pattern, And yeah, and also when it comes to discovery, we've just talked about a link in a credential, but I'm not even sure that's the most scalable. it's a possible pattern.
Steve Capell: But if I'm making an assertion about an entity who's recognized, shouldn't that assertion be discoverable DID document, not from the credential in which because I could have a DID document, which is my business did issue a million invoices. I only need to link my recognized entity credential to did document, not to every one of the million invoices.
Dave Longley: Yeah, I Yeah,…
Steve Capell: Really? Yes. Yeah.
Dave Longley: I think we ought to have both patterns. I think maybe the next bit of work on this spec is very clearly demonstrating how you can have both of these patterns and showing that you can work your way up and how it would work and then sign off that it seems like it works and covers the use cases.
Steve Capell: And then on top of that, once you've got the discovery sorted, as you say, whether it's through a VC link or through a did link, now you've got another problem, which is how do you consistently apply some validation rules not of the credential, but of the graph. For example, I could as a malicious business having discovered a recognized entity credential or another business, attach it to my did. of course that recognized entity credential would have a different subject did to my issuer did. But a verifier might go, yeah, valid invoice did who is endpoint. yes, valid recognized entity credential. tick,
Kevin_Dean: It's fine.
Steve Capell: " But if the issuer of the invoice is not the same as the subject as the recognized entity, then they're just two unrelated credentials, right? So you've got rules to test after you've traversed the chain and discovered your hierarchy up to the anchor. You then got to test some rules and should we be specifying at least a minimum set of rules. That's another question for this group. I've written a couple of tickets on this which I said I would do and I don't necessarily have the right answer to them. So, I'm starting with here's the problem. and maybe we can discuss on the tickets iterate towards what would that mean for an update to the spec.
Steve Capell: I'm done.
Dave Longley: That sounds good.
<Dave Longley> +1 to be clear with validation rules (as much as those are generic in this spec)
Dave Longley: We've got a couple people in the queue.
<Dave Longley> some of the JSON schema would cover this too.
Dmitri_Zagidulin: So, I agree with Dave that I think both patterns have their use cases.
Kevin_Dean: Okay.
Dmitri_Zagidulin: And I want to point out that the lines between bottom up and top down recognized entity approaches are very fuzzy because of what you said. until it recognizes a trust anchor or rather until it reaches a trust anchor it recognizes. And that bit right it's all top down because at the end of the day you do need to have a list the verifier needs to have a list of trust anchors they recognize whether it's a list credential or…
Kevin_Dean: Please conquer God.
Dmitri_Zagidulin: a chain doesn't really matter right the only way any of this works and not just in this spec but in pretty much any approach is if you have a list of issuer dids essentially you recognize now they could sign credentials they could run issuer registries whatever right but I'm just saying that architectural weightbearing piece blurs the line between top down and bottom up approaches
Steve Capell: Yes. Has anyone else got their hand up?
Phil_Archer: Yeah,…
Phil_Archer: wearing my GS1 hat. this is obviously very interesting to us because we really want this to work and we want to implement it. some people have said to me, " so you're going to publish a list of the s of all your 120 member organizations." which might be one way that we might do it. that's not the way We're currently thinking that we will issue credentials to our member organizations in the way that Kevin described. but at this stage, we're open to being flexible and we'll do whatever is easier. but it is important.
Phil_Archer: And also as far as possible I imagine absolutely everybody if our use case is taken care of within the spec overall that's fantastic because I mean we haven't got to have a special bit of code somewhere a special verifier that understands GS1 because they all do. I mean that's what I really would love to see. but that's something I guess everyone would like to see and I don't want to be selfish about it.
Phil_Archer: Switching to my coaching hand for a minute. as everybody on this call is very well aware, if you have two options or three options to get direct, you've got to have multiple implementations of each of those options. So there's a cost to supporting options in that you've got to prove that industry wants it and that may and tests. Yes, you're right, Of course. And so what you wish for. Be careful whether you say, "Yeah, we'll allow A, B, and C or whatever." It just creates more work.
Steve Capell: put my hand up button.
Benjamin_Young: You get Steve.
Steve Capell: Yeah.
<Benjamin_Young> ...and tests
Benjamin_Young: Go ahead.
Steve Capell: So acknowledge that atoms are blurry. In my mind, the distinction is in one case there's a list of if you like similar entities, all driver's license issuers or all businesses registered in Australia. and we're suggesting that you don't really need the big list. You just need each one of those to give a credential to their members just as Phil just said and make that credential discoverable. but at some point there is a kind of a list but at least in my mind I imagine it working much more like today's browser held root CAS right so there aren't necessarily very many of them
Steve Capell: that if it's an authoritative government run business register government run register of some kind somewhere in the world, maybe the UN did is all you need in your browser. If it's a commercial hierarchy like very globally significant one, then the GS1 head office route is all you need in your verifier, Maybe there'll be a lot more than that. so you're right that what's left unresolved is how do you get the short list of trust anchors routinely into every verifier's list of trust anchors. it's probably the same answer of how do you get the into every browser's root CA store today.
Steve Capell: It's going to be something like that, I'd imagine. No.
Dmitri_Zagidulin: Agreed. Yeah.
Benjamin_Young: Yeah, that feels undecentralized,…
Benjamin_Young: but I think I know what you're after there, we have about nine more minutes, and I think next time we can chip through Steve's issues. and if there are others here who want to create some related ones to these proposals or concerns, I think that'd be a great thing for us to tackle next week. Go ahead, Demetri.
Dmitri_Zagidulin: Yeah, I just wanted to comment on that. I agree that we need to be always vigilant about excessive centralization but even the list of CAS essentially is decentralized in that it's different per vertical right for each vertical there's going to be a different list right the medical industry is going to look to their roots of trust to the product industry to theirs etc right and also every single decentralized project has to deal with this bootstrap of what are the known directories, And I don't think we've come up with a better way than you ship with one or more places to look and then discover everything else from there. That's it.
<Benjamin_Young> hoping to avoid Public Suffix List
Benjamin_Young: Yeah, this new Google Hangouts is driving me nuts. It keeps muting heard Dimitri. I think there as modeled in real life among other ways it's almost always more federated than centralized or decentralized and I kind of feel like that's what you were suggesting. and I think it's going to come down to what the browser equivalents are. And I think there's probably than and more than one type of thing that's going to have these quote unquote root dids. this is a great problem and I feel like we've got a good group of people on all sides of this issue.
Benjamin_Young: Go ahead, Joel. …
Phil_Archer: Just very briefly, our target for that is isn't the browsers, it's the It's the scanners held by customs and border people. that kind of person. And that's where GS1's target is. Other people may have other targets, but in terms of the actual hardware manufacturers there are basically five or…
Benjamin_Young: Would there be any value in essentially sketching up some of the user agents, for lack of a better word, that would need to care about this? Like you just said, Phil, the scanner is your browser. I imagine Steve has one or more such things in his head as well.
Phil_Archer: six of them in the world. so there's Data Logic and Honeywell and Cognex and a few others, but then you get to the larger handheld scanners that basically have an Android phone strapped to their back or whatever, and then you're into basically apps and you're into software that anyone can create. So, I've started to talk to some of those scanner manufacturers about this and of course they're sort of saying what's in it for us and everything else. So there's sort of some interest there, but I haven't yet got the full picture and I certainly haven't got the full set of credentials that I can offer them and say look this is the way things are going.
Phil_Archer: But because once this works which I believe it will then I can see someone working in the world of Anil John or whoever and a container comes in and they scan a load of things and they find out that it's got all the trade documentation in which Steve is an expert and then the bills of blading and the country of origin and the proof of this that and the other and the identifier on it which is a
Phil_Archer: PS1 barcode also checks out which means that it can get on its way very quickly. that's kind of where I'm trying to get to. There are any number of people that we can reach in that way. the scanning manufacturers are one entry point. but then you've got to reach all the vendors and open source code. A lot of people on this call have been very good at creating and maintaining. It's essential. So It's a long road is what I'm trying to say. And I'm talking too much. Sorry, I'm just waffling. Sorry, Benjamin.
Benjamin_Young: Not a problem at all. that was great to paint more of the landscape. great. with four more minutes left, I don't know that we'll have any concrete actions out of this. is everyone okay with returning to this topic next week and presumably chipping through Steve's issues if not others that get filed? This seems to be top of mind for the group at the moment. awesome. we'll return to this in a week and in the meantime, enjoy life and…
Kevin_Dean: Hi everyone. Benjamin Young:
Benjamin_Young: work and everything else. Take care all.
Steve Capell: Thank you.
Phil_Archer: Thanks everyone.
Phil_Archer: Thank you. Bye. Meeting ended after 00:57:17 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.