Meeting minutes
GitHub Repo For Note
Carolynn_Bernier: Okay.
Carolynn_Bernier: Okay, I suppose I propose that we start. Is that okay, Ivan? If I start now,…
Ivan_Herman: I am not the one to decide you.
Carolynn_Bernier: I decide. So, let's start. last week I told you that I would put together a GitHub repo where we will start to work on our note.
Carolynn_Bernier: And I even had the time to do it. Let me just share my screen.
Carolynn_Bernier: And so if you go to the GitHub repo of the workg group, let me share this screen here. You should be able to see this.
Ivan_Herman: We don't see it.
Ivan_Herman: Now we do.
Carolynn_Bernier: I assume you all know where our GitHub is for the task force. So, the vocabulary task for GitHub, I just pasted it in the chat. so in this repo, you will see a DPP document.
Ivan_Herman: No. sorry. Yes.
Carolynn_Bernier: It's in a UCR or DP. No, it's a DPP UCR.
Carolynn_Bernier: one hour ago. Yes, this is it.
Ivan_Herman: Yes. There.
Carolynn_Bernier: It's in DPP UCR means use case something R. I don't know what the R stands for. and here we see wait no there's nothing here. The slides from our previous meetings are here under slides. So if you are curious about that. but in DPP UCR you will find index.mmarkdown and here you will find the draft of the document our note that we are starting to work on. And this document when it's transformed by respect looks like this.
Carolynn_Bernier: much nicer. But we have to decide on a title for this document. But basically there's an introduction. then this first section is why are verified credentials useful for DPSPs. The second chapter is why is there an international DPP task force in W3C working group? And third part is DPP standard X compatible with this V VCDM.
Ronald_Koenig: Yes.
Carolynn_Bernier: And my proposal to you is that we start with working on this part here. Why are useful for DPSPs? So that we can collectively build intelligence on why we're actually trying to do this.
Carolynn_Bernier: So you can so this is the markdown here and this is the nicer view of the markdown which gets automatically transformed into respect. And so what I wanted to invite everybody to do today is to read the draft that I propose and if you have any kind of comment or any kind of modification you would like to do then I suggest you make a pull request so that I see the edits that you propose and these pull
Carolynn_Bernier: Quest can be anything like grammatical errors or corrections or anything. So maybe I can give you all 10 minutes of silence so you can read the draft and then we can discuss a few things.
Ingo_Wolf: Just a short addition from my side.
Ingo_Wolf: I believe the R in UCR stands for requirements if I'm not mistaken.
Carolynn_Bernier: Yes,…
Carolynn_Bernier: you're right. that's right. But I think now it's less than a use case requirements document. It's more like a note.
Ivan_Herman: Yes, that's correct.
Ivan_Herman: We can change all that at any time. those are minor.
Legal Evidence In Data Authenticity
Rigo_Wenning: Mrs. Bingo, we don't have, legal evidence in there yet. I will provide a pull request for that one in the why I v this is useful for DPSPs,…
Carolynn_Bernier: pretty cool.
Carolynn_Bernier: But there is something about some legal here limiting liability.
Rigo_Wenning: it's not only limiting liability but it's yet you have many of those providing data authenticity because of the fake products and so on. This has all legal connotations but to be absolutely clear that in supply chains we need temper proof data for accounting for ESG for many things.
Carolynn_Bernier: And you would formulated differently than proving data authenticity.
Rigo_Wenning: Maybe I data authenticity is generic is too generic.
Rigo_Wenning: Creating legal evidence is part of data authenticity.
Carolynn_Bernier: Mhm. Okay.
Carolynn_Bernier: So, can you add that make a pull request for that? That's good.
Dr._Susanne_Guth-Orlowski: Don't we maybe have two topics here? The one is data authenticity. So we at all times know which key signed the document. But then legal binding to an identity just comes with things like eidas one or…
Carolynn_Bernier: with the quality of the signature.
Dr._Susanne_Guth-Orlowski: eidas too. So maybe we can differentiate that way with the quality of the signature.
Rigo_Wenning: This is relative Susanna this is really relative because there are certain things and I agree some of the things for example you have in France a rule starting because there is a decree that says beyond €4,000. A contract needs to be written in written form and the written form is one article further says the written form can only be achieved with a qualified electronic signature. so this is when you want to create a legal evidence, you need a quality qualified electronic signature.
Rigo_Wenning: of course this is so heavy that it's ignored everywhere…
Rigo_Wenning: but I just give this as a typical example where legal evidence comes into play and where legal evidence has special requirements and also where certain semantics are perhaps even needed. so we should look at it closely.
Carolynn_Bernier: But on the legal evidence part and…
Carolynn_Bernier: and linking back to what Suzanne was saying our VC based approaches lighter weight than qualified signatures than those that based
Dr._Susanne_Guth-Orlowski: No, no, no, no,…
Carolynn_Bernier: Mhm.
Dr._Susanne_Guth-Orlowski: no. That just depends, who signed it and how you can verify the party who signed it.
Rigo_Wenning: the verifying credential framework is totally agnostic to the amount of insane security you put into it.
Dr._Susanne_Guth-Orlowski: Yeah. Yeah.
Rigo_Wenning: And the Europeans have tendency to just put security on an insane level which makes things totally unusable. so there's always this kind of finding some middle ground between what still counts as evidence and at what point in time we are losing people because it's not usable anymore.
Carolynn_Bernier: Mhm. That's
Dr._Susanne_Guth-Orlowski: But coming back to our original point authenticity by verifying the signature and then pointing to the person who signed it and then liability we can bring in at different levels according to the quality of the signature. Isn't that the difference and how we can describe it?
Rigo_Wenning: No, because liability is tied to faulty behavior and faulty behavior itself must be so the last logical step that you do is not a valid one for the rest I agree but it Viability is unrelated to the quality of signature.
Dr._Susanne_Guth-Orlowski: Yeah. I see what you mean. Then maybe we have to still we and…
Dr._Susanne_Guth-Orlowski: we can discuss if we want to bring in the qual the quality of the signature that you can use it the quality of the signature can differ and then no the ishua …
Carolynn_Bernier: Yes. But I think we need to be to…
Carolynn_Bernier: which signature here the holders or the issuers because here when you check the VC that you'll be checking is the VC held by the holder right because
Dr._Susanne_Guth-Orlowski: not necessarily.
Carolynn_Bernier: Okay.
Dr._Susanne_Guth-Orlowski: When you're checking authenticity, you always check the signature of the issuer. Is this data uthentic? from which source is it coming from? Who signed it?
Carolynn_Bernier: But wait Ian
Verifier Versus Issuer Checks
Ivan_Herman: I think we have to be careful not to mix up two different things.
Ivan_Herman: One is the verifiable credential itself that you get as a verifier and the other one is to check whether the issuer is a valid issuer. Now both of them are partly under work in the working group. There is a recognized entities which does the letter which provides you means to verify that the issuer is genuine and…
Ronald_Koenig: What are you going to do? But
Ivan_Herman: allowed to do that the issuing itself. But when you get a verify credential itself then what you see is the holder signature. These two should be separated.
Carolynn_Bernier: this is very important and this is so actually I tried to capture a little bit of this here in this paragraph Ian…
Ivan_Herman: Yeah. Yeah.
Dr._Susanne_Guth-Orlowski: Yeah. Yeah. Yeah.
Carolynn_Bernier: because I don't know because In the DPP context where in some cases the holder is the issuer not all the time. Who verifies what and knows what about whom and is very unclear to me. Yes.
Ronald_Koenig: Caroline just I think this is pretty easy because what you are describing the second chapter is what we are calling a selfisssued credential. So that means the issuer issues this credential to itself and you are pretty aware of it because in this case the holder and the issuer is the same entity and you can see it on the assertion proof and you can see it on the authentication proof. But I think what we should do here is we should really follow the VC data model because the VC data model defines credential and presentations and the presentation has two proofs.
Ronald_Koenig: One is the assertion proof which is applied by the issuer to make an assertion and make a statement about this claims which are in the credential that they are correct to the best knowledge of the issuer. And the second one is the authentication proof in the presentation.
Ronald_Koenig: And this is the signature of the holder. So that the bar can verify that this is the holder of the signature and that maybe the claims inside the credential are the claims related to this holder.
Dr._Susanne_Guth-Orlowski: But we don't have that use case in digital product passports,…
Dr._Susanne_Guth-Orlowski: we don't have to verify that someone holds a credential. That's not a DPP use case in my view or I'm missing something. Yeah.
Ronald_Koenig: I can give you use cases for this one. For example, if we have a use case with the Switzer railway where IP in this case is producing a rail and the production process for this rail is certified by institute…
Dr._Susanne_Guth-Orlowski: All right.
Ronald_Koenig: which is responsible for certifying the carbon footprint which is generated in the production. And what happens here is that this institute for Bomb is asserting IP there's a production process is generating this amount of carbon and this enables H IP to prove to a third party that this rail was produced with this carbon Yes,…
Dr._Susanne_Guth-Orlowski: Yeah, I understand. But that's then we already have two different credentials.
Ronald_Koenig: of course. But at the end, the whole digital product passport is not only the physical dimension of the product.
Ronald_Koenig: It also includes the carbon footprint during the whole life cycle of this product. So if you…
Dr._Susanne_Guth-Orlowski: Yeah. Yeah.
Ronald_Koenig: if you take a greater view of what a product passport is, not only the size and…
Dr._Susanne_Guth-Orlowski: Yeah. Yeah.
Ronald_Koenig: the length and whatever
Dr._Susanne_Guth-Orlowski: I understand. But we were coming from a different. So do we want to look at one credential and just the product passport that has been issued by the economic operator as a first thing to start with and then additionally look at credentials that maybe the economic operator has in its wallet and additionally the verifyable credentials that come down the line during life cycle with repair processes and
Dr._Susanne_Guth-Orlowski: Everything. Mhm.
Carolynn_Bernier: Yeah, I agree that these are two different things.
Carolynn_Bernier: The scope that I was setting here is issuing the DPP itself and the DPP as a VC. and of course the DBB can contain links to VCs with per claims and events and all sorts of things. so maybe that's not clear yet.
Ivan_Herman: And she's kicked out again.
Carolynn_Bernier: And I think that what I was kicked out of use case even just on I get it.
Dr._Susanne_Guth-Orlowski: You're back, Caroline. Carolynn Bernier:
Carolynn_Bernier: Okay. I'm at work. I don't know what's going on here. so, I think that what Ronald said at the beginning was that we should distinguished the self-issued VC case from a third party held DPPVC case. because I don't think why are Cs useful for DPSPs, I think we need to distinguish these two situations. The DPP itself is a DPP and it's a self-issued one. and then yeah,…
Dr._Susanne_Guth-Orlowski: Yeah. Yeah.
Carolynn_Bernier: I think we need to distinguish these two. Yeah.
Dr._Susanne_Guth-Orlowski: So, yeah. So, in the case of a digital product passport, the economic operator is the issuer of the VC. At the same time, he's also the holder because he issues the DPP to his own wallet so someone can find it there.
Ronald_Koenig: Is it
Dr._Susanne_Guth-Orlowski: That's fine. We can describe it. but we have to describe the boundaries here, which use cases we want to describe with issu and holder because they're mixed.
Dr._Susanne_Guth-Orlowski: Of course they're changing depending on who is issuing additional credential that are required for the DPP use case. Yeah. So we can maybe discuss do we want to include all those cases with all linked data cases which I think makes totally sense or do you just concentrate on the economic operator issuing the DPP and then from there yeah
Carolynn_Bernier: Both I think we do want to focus on issuing the DPP itself and…
Carolynn_Bernier: then using VCs as claims to encapsulate additional DPP related claims and events and things like that.
Dr._Susanne_Guth-Orlowski: Okay. Then…
Dr._Susanne_Guth-Orlowski: then we need a nice little diagram that shows the different parties and the different use cases where we verify the credentials for.
Carolynn_Bernier: Thank you for proposing to create such a diagram, Suzanne. Wonderful.
Dr._Susanne_Guth-Orlowski: I have it in numerous versions. So you just
Carolynn_Bernier: Wonderful. Rio
Rigo_Wenning: Yeah, two aspects. first we have an issuer because at least in Europe the DPP gets a number or it has to be registered ity with the European authority and I think the European authority can issue some cryptographic hash signed hash that this has been registered with them and…
Dr._Susanne_Guth-Orlowski: Is that what
Rigo_Wenning: is authenticated which yeah, maybe that's a yeah no no we are not we still need to convince set Holland to help help us…
Carolynn_Bernier: Yes, but it won't be in the format of a VC.
Carolynn_Bernier: It'll be a signed PDF.
Rigo_Wenning: so that's the first one and the second one is when we have a complex product like a car
Carolynn_Bernier: Yes. Mhm.
Rigo_Wenning: then there are
Rigo_Wenning: many DPPs or self-issued or with an issuer or what have you coming together and perhaps the selfissued from a lot of issuers but then the interesting part is can you man manipulate the components and do we need a proof that those 50 DPPS belong to the same product so that those 50 DPPS make a new DPP that is for this complex product.
Rigo_Wenning: So I think that's an interesting use case also.
Carolynn_Bernier: Okay.
Carolynn_Bernier: So, I think that the use case is chapter 2 which is if you go down. So, why is there an international DBP task force in W3C VCG VCGW and that for the moment I put all the use cases there. So the importance of DPP data fusion is what you're referring to Rio. and this is for me a distinct topic than…
Dr._Susanne_Guth-Orlowski: So we can use this maybe
Carolynn_Bernier: why you should issue the DBP as a VC or could issue as a VC No,…
Rigo_Wenning: It's not distinct at all because you can only have the fusion because the verif credentials data model is the only one that allows you to do the fusion unless you have unified everything. But I think van is signed link data.
Carolynn_Bernier: no, no, no, no, no. It's the link data that allows you to do diffusion. It's not the VC,…
Ivan_Herman: That is good.
Carolynn_Bernier: But we could use link data without the VC and you'd still have the fusion property. And he just let's separate the property of the thing.
Rigo_Wenning: Yeah, but no security property.
Dr._Susanne_Guth-Orlowski: I cannot share my screen. Maybe it's easier to talk about a diagram while I cannot share it.
Carolynn_Bernier: Okay. Yeah. Go ahead, Ivan. …
Dr._Susanne_Guth-Orlowski: Is that a restriction on my side or…
Carolynn_Bernier: you cannot. I don't know.
Dr._Susanne_Guth-Orlowski: do you have to give me the right to share?
Carolynn_Bernier: Sisan, I don't think so. I can't.
Ronald_Koenig: seems to be on your side…
Ronald_Koenig: because I can share.
Dr._Susanne_Guth-Orlowski: Uh-huh. Okay. Then I come back in.
Verifiable Presentation Issues
Ivan_Herman: Yeah. So there are two things.
Ivan_Herman: One is related directly to what you discussed and then I have another issue which is a bit different. the one you discussed the verifiable presentation is doing not necessarily what you call a fusion but the fact of combining several VCs into one box so to say this is exactly what the verified representation does it is unclear and currently I think it is not absolutely doable
Ivan_Herman: And this may be an issue to raise with the working group at some point that I think that the component of a verifiable presentation can only be verifiable credentials. You cannot do it hierarchically and in your case it might be better to do it hierarchically but that's a separate discussion maybe worse on the working group level. and by the way I made a mistake earlier because what happens in the verifiable presentation is that you sign the verifiable presentation at the holder but the presentation itself has the original or transformed verifiable credentials which have all their own signature.
Ivan_Herman: So the presentation signs over all the credentials including their signature So the signature is signed again. So the presentation in this respect is a very strong thing. The other thing which is maybe a different topic but I think we should get to different topics as well. one of your last item in that section Caroline is privacy and I think it is worth mentioning somehow that verify your credentials and presentations are able to do selective disclosure that's a very very important point of the whole environment and your example of the medication to disclose only what's disclosable is obviously something very important in the medical world to take this example.
Ivan_Herman: So selective disclosure is something that we should list as one of the strong points of verify credentials that I presume for DPSPs have a major importance and maybe the last one although that's on longer term but good to know about it just to make some publicity with some work that happening elsewhere in the working group is that verifyable credentials eventually and…
Carolynn_Bernier: H. I totally agree.
Ivan_Herman: soon will be resistant to quantum computing problems and with DPP we are looking at long-term and the fact that already today we are working on inclusing everything which is quantum resistance is an important use case or sorry an important fact which is important for DPPs
Dr._Susanne_Guth-Orlowski: is there something needed in the model to allow different key length because it actually depends on the signature right?
Ivan_Herman: It depends on the signature.
Dr._Susanne_Guth-Orlowski: Yeah
Ivan_Herman: There is nothing in the model which makes a restriction which is a problem for quantum computing…
Carolynn_Bernier: Phillip
Ivan_Herman: because sometime the signatures are enormous. but that's one of the topic that is actively discussed in the working group.
Phillip Long: I will plus one to what her Ivonne just said. it is in fact a distinction that the verifiable presentation is essentially a transport envelope that can contain multiple individual credentials from any signatory not just the original sender of that. But the benefit of that is it protects the credential in transit so that you can know who in fact assembled that package to validate that it came from them. I think the other question that's being discussed is the notion of a compound credential where you might want to have the overall package verifiable but not ephemeral.
Phillip Long: a verifiable pres presentation. The outer envelope is an ephemeral thing. It goes away as soon as the verification of it takes place and it leaves the individual credentials as a pile so to speak. if you want the individual credentials to be retained in a structure for some reason for example that there may be relationships among them that you want to describe u that you don't want to simply have them as individual autonomous pieces then you can build a compound credential and that's what institutions in higher education have been doing with credentials that are used for transcripts of an individual's program where individ
Phillip Long: idual courses are signed VCs and the outer envelope is a signed VC and you can then give the individual receiving it the option of taking out those individual credentials with their signature intact and using them or sharing them independently with still the ability to verify that they were in not tampered with at the same time as being retained retaining the overall package and there are those who also wish to retain the overall package and have the individual credentials unsigned so that only the thing that is verifiable is the package and not the individual components.
Phillip Long: So that gives great deal of flexibility for the use case intended in that context. And I just wanted to point out that is an option and…
Phillip Long: I think one of the benefits of the verifiable credential VC design because it gives you that degree of flexibility in applications. Thanks.
Carolynn_Bernier: that's really amazing Philit that's…
Carolynn_Bernier: why I wanted to join this working group because I need to know more about VCs and all these little options and variants and things you can do with that but I don't know if there's a queue no coming back to the topic of verify so we need to get it cleared up or…
Ronald_Koenig: Hello. Thank you.
Verifiable Presentations For DPPs
Carolynn_Bernier: already for the simple case self-issue DPPS or third party held DPSPs so because I didn't talk any at all about verifiable presentation ations in this document. And Steve Capel when he talks about UNP DPP, he never talks about verifiable presentations. This strikes me as odd. Why he never does this? and I think this is an important question. Should we talk about verifiable presentations or not? Right.
Carolynn_Bernier: And this for the moment is completely absent from this document. Suzanne
Dr._Susanne_Guth-Orlowski: Yeah, I believe that was my earlier point.
Dr._Susanne_Guth-Orlowski: Although then says we might need it. Usually you have these verifiable presentations or I know them mainly from the personal use cases. in the oil wallet environment where you want to prove that as a person actually have a credential that allows you to do something in your wallet, but you have certain privacy requirements and therefore you don't just use, open verifiable credentials. Everything can link to everything. but the verifiable presentations allow you to do that in a more private way and allow zero knowledge proof and all that thing. Yeah, you can answer questions. Are you over 18 and so forth? and this is why I'm happy to brainstorm with you all.
Dr._Susanne_Guth-Orlowski: Do we actually need that in a digital product passport use case where the whole point of providing that data is to making it available to other people all that data. and if you don't want to make it available we have to find ways to limit the access to it. But this is also why my gut feeling is we don't need verified presentations for DPP use cases because it's not a privacy related use case for people but it's digital product passports making information available to businessto business companies.
Dr._Susanne_Guth-Orlowski: Yeah, but happy to discuss and…
Carolynn_Bernier: There we go.
Dr._Susanne_Guth-Orlowski: we have some hands raised.
Rigo_Wenning: Yeah, just I'm the privacy guy and sorry but it has nothing to do with privacy. but the still Ivan's remark is essential because the selective disclosure is a very important aspect in commercial relations…
Rigo_Wenning: because you want to disclose to this category of that category of user. and you want to selectively disclose things in no…
Dr._Susanne_Guth-Orlowski: What do you mean it has nothing to do with privacy?
Dr._Susanne_Guth-Orlowski: That's the way it's been used, in context a lot.
Rigo_Wenning: but we are talking about commercial privacy is the American use of it.
Carolynn_Bernier: Okay.
Rigo_Wenning: while the European use of it is about natural persons and not about access control. And so here we are using this feature of selective disclosure less to protect natural persons because the DPP is some thing that we hold in hand and some company who has issued information but it's rather about commercial secrets and things like that. they follow the same kind of dynamics, rules, restrictions, policies and so on. But we should be aware that here we use selective disclosure much more in a context of commercial exchanges where they are still useful.
Rigo_Wenning: And more wait on top there is always this distinction very dear to Caroline and…
Dr._Susanne_Guth-Orlowski: and…
Dr._Susanne_Guth-Orlowski: I have to Heat.
Rigo_Wenning: me between the compulsory information the legal legally obligator the compulsory set of information forced by law and the information that is given in a commercial circular economy context. So the deliberate DPP and I think those should be linked together. So for me the DPP as a public only and compulsory information only thingy is just a bureaucratic exercise and…
Rigo_Wenning: I just don't want this to be just a bureaucratic exercise.
Dr._Susanne_Guth-Orlowski: Okay, I'm not sure…
Dr._Susanne_Guth-Orlowski: if I fully did get your point. I just wanted to state that of course we are also trying to implement the dish product passport as a verifiable credentials. and therefore there are now in the JTC 24 standards which list all the technologies that may be used to be compliant at least to the EU DPP and we're not using zero knowledge proofs at the moment and the reason why is no one understands that and therefore no one is trusting this technology at the moment so when I've been working with the GBA
Dr._Susanne_Guth-Orlowski: BA to provide data from the supply chain made available by verifiable credentials for example greenhouse gas emissions the way they're now installing anonymization or aggregation is by putting men in the middle people in the middle who aggregate the data and issue a new credential but not with zero proof. that the technology with zero knowledge is currently not used nor allowed or anywhere standardized. So the overall question is Do we want to consider everything that's possible or do we want to consider something that is currently accepted under the EU regulation?
Carolynn_Bernier: Were you replying to Rico there,…
Carolynn_Bernier: Suzanne? No. No.
Dr._Susanne_Guth-Orlowski: Yeah, replying to Rio on the zero knowledge proofs and…
Dr._Susanne_Guth-Orlowski: then asking the general question where do we put the boundaries of what we want to do because of course we can do a lot of use cases but are we limiting ourselves maybe in a first step to the EUDP which at least as a profile should be good because maybe otherwise we're confusing people with what they can do under the EU regulation and what they can't do with the verifiable credentials.
Carolynn_Bernier: So clearly I think the scope of our work here is not the EU DPP. So we're talking to people from all over the world who are wanting to issue DPPS. So the scope for me. UNP is also in the scope of this work. one thing I didn't know about the selective disclosure thing does it always work with verifiable presentations? Meaning, if I have selective disclosure,…
Carolynn_Bernier: do I necessarily need a verifiable presentation?
Ivan_Herman: No, it can work.
Carolynn_Bernier: No. So the question of do we need verifiable presentations for DBP is still unclear to me.
Ivan_Herman: It's to use the jargon in the business it has crypto suites which can be applied both to credentials and presentations and there are crypto suites which are selective disclosure ones. So it can be used either for presentation or for credentials. I understand and…
Carolynn_Bernier: I don't I selective disclosure.
Ivan_Herman: it's not dependent on selective disclosure.
Ivan_Herman: I think that was your question.
Carolynn_Bernier: Okay, it was my question.
Carolynn_Bernier: Carsten has his hand up.
Privacy Versus Business Confidentiality
Carsten_Stöcker: Yeah, I want to say I think regarding privacy,…
Carsten_Stöcker: it's all about So most taxonomy people use privacy for natural persons and then the term business confidentiality in a business context. Yeah. I think when we talk about the business context, I don't want to disclose my supply chain or whatever only parts of a credential. I think that then it's more business confidentiality. My personal view is that people are massively struggling with full disclosure at the moment. that the technology provides this. So we can do selective disclosure which is great.
Carsten_Stöcker: But my recommendation is to not over complicate it because when I have let's say data attribute whatever set of 100 data attributes about a battery and…
Carolynn_Bernier: Mhm.
Carsten_Stöcker: then I would like to disclose maybe two not but five my other partner needs five other and so on then there's a going big big back and forth and this is already very big problem by 10 data attributes on a personal ID card and the combinatorics of all options when I have larger data attribute sets in industrial settings. This really really makes it very complex to come to proper product grade solutions. Yeah.
Carsten_Stöcker: I also want to say Ronard started this looking into linked knowledge graphs and we did some research so we looked up some academic research and we found some matrix here that when you're in a supply chain and you have your link data and with open world semantics and then you run your AI on top of it the very interesting metrics you have less hallucination less contradictions up to 80% less token usage less cost less environmental harm.
Carsten_Stöcker: When we think further in future that AI runs on top of the data set there's a massive business case for using vocabularies and open world semantics linked data for using this in the AI and I think we should also mention this and then the last topic regarding presentations I think we are only talking right now about data provenence on the data plane but we will have a control plane as well with personal
Carsten_Stöcker: legitimate access getting access to what with a market credential for example and…
Carsten_Stöcker: then we definitely need presentations on the control plane maybe.
Carolynn_Bernier: Thanks a lot Karsten.
Carolynn_Bernier: I did on the topic of link data and AI and all that that would be more in chapter 2 where so do you have access to the document in the markdown?
Carsten_Stöcker: Yes. I haven't Yeah. Carolynn Bernier:
Carolynn_Bernier: You have not seen it. I'm just going to link it in the chat so that you can make a pull request and…
Carsten_Stöcker: Yeah. Yeah.
Carolynn_Bernier: directly so right here.
Carsten_Stöcker: We now see I will. So, we're right now doing some research.
Carolynn_Bernier: please and…
Carsten_Stöcker: I will summarize the research and then add something. Yeah.
Carolynn_Bernier: but I think the use of linked data for DPP is a different debate. This debate has been going on for the last three years.
Carsten_Stöcker: Mhm.
Carolynn_Bernier: It's a different debate than the use of VCs for DPP. But it's always nice to add additional reasons why we want link data for DPSPs that this is one among others. Okay, but it's secondary to the topic of why we want VCs for DPSP. So, Phillip, you have your hand up Yeah.
Phillip Long: Yes, I just wanted to respond briefly to the discussion about the complexity that might be in introduced with selective disclosure and the issue there I want I think it's important to distinguish the capabilities of selective disclosure from the governance on how you wish it applied. so I would be hesitant to say that we should minimize the use or prominence or discussion about selective disclosure because I think it is actually an underutilized tool at the moment and will become much more important later.
Phillip Long: whether in a particular use case and of an exchange of data between partners, the organizations involved want to set policy over how things should be revealed and in context let individuals sending these credentials make their own decisions and apply whatever selective disclosure rule they want for the particular credential they're creating. That's governance and policy or a set of dis discussions and we don't want to throw out selective disclosure because the different people have different perspectives on that. Let them fight about the policy and come to agreement there and then apply the dleive disclosure appropriately.
Carsten_Stöcker: Hey, Philip, I fully agree. I only want to say we have to set proper expectations and maybe a warning because naive people think it's easy and it's not easy because of this governance topic. Technology can do it, but governance is super tough.
Ivan_Herman: and technology is not easy either to be honest.
Carolynn_Bernier: Before I take Rigo's comment again,…
Carolynn_Bernier: I would like us to agree on the title of our documents.
Ivan_Herman: That's bike shedding.
Carolynn_Bernier: Is what?
Ivan_Herman: It's bike shedding.
Carolynn_Bernier: Bag shedding.
Ivan_Herman: You are not yet in the standardization world.
Carolynn_Bernier: What does that mean? bag shedding.
Phillip Long: No bike shedding.
Ivan_Herman: Bike Okay, let's not go there.
Phillip Long: I in a bicycles.
Carolynn_Bernier: What does this have to do with bicycles,…
Ivan_Herman: I will tell you later, Caroline. I will tell you later.
Rigo_Wenning: Sorry Ivan, I haven't explained that to her yet.
Carolynn_Bernier: bike shedding? All right. Ivonne made a number of proposals for the name of this document. I like the third one BPP secured by verifiable credentials.
Ronald_Koenig: We got
Dr._Susanne_Guth-Orlowski: Maybe we think of the title once we have agreed on…
Dr._Susanne_Guth-Orlowski: what should be in there because I'm not sure if we're there yet.
Carolynn_Bernier: So I think we're there but we just need to continue structuring the document according to the discussion that was held today. So for example verifiable presentations is missing. but fundamentally the first section is on why VCs could be useful in the DPP context. So we can extend it to cover all the topics that we discussed today.
Carolynn_Bernier: And the second part is on why is there a DPP dashboard inside W3C. Okay, because that's not an obvious thing at all. Right. And then the last part is what we're going to do later is studying the compatibility of the DPP protocol with the VCDM but let's talk about that later. So the focus at the moment is on the first part. Why are VCs useful for DPPS? that's what I suggest that we collectively focus in the short term.
Carolynn_Bernier: Ronald
Ronald_Koenig: I have a very very simple proposal for this one…
Ronald_Koenig: because we are dealing with digital product passports and most of our customers today are using digital product passports. They are not asking for verifiable digital product passports because the first thing what they are discussing is now what you say we should use JSON ID so that we get link data to express on a semantic layer digital product passport and this is what we are currently doing and our product vera is this doing this.
Ronald_Koenig: It is really interesting that most of our customers are not asking for verifiable digital product passport currently. They are only asking for digital product passport and they have already a lot of things to do to get the semantic right on all the different data which are describing the digital and therefore I would say why we are sitting in this group is not defining dual product passport on a semantic layer. This is something we have to do anyway. what the CIS scope is, how we make digital product passports which hopefully are JSON ID data verifiable. And we put the digital product passport into the credential subject of a verifiable credential and make them verifiable by signing them and providing all the cryptographic information so that we can bind it to the holder can sign this stuff can have validation.
Ronald_Koenig: So credential status validation and all the things and this is what we should clarify how we bring the things together and I think it's not so such a big and a heavy task because the good thing is at least what I learned is that if you are already describing your digital product passport with the help of link data and the ver and the verifiable credential data model is also based on linked data.
Ronald_Koenig: It makes it very simple to embed the digital product passport into the existing verifiable credentiing VCDM model.
Carolynn_Bernier: Yep.
Ronald_Koenig: This is I think what we have to do put the data in and then recognize what we have additional requirements to the VCDM model and currently I don't know really additional requirements because it is a very flexible and…
Ronald_Koenig: very enhanced model already. Yeah.
Carolynn_Bernier: So the use of link data for DPP is the second point in the second chapter.
Carolynn_Bernier: So yeah, Regal
Rigo_Wenning: Yeah, coming back to the policy channel, I just wanted to note that we are organizing the 20 and 21st of July meeting on ODRL and you can easily mix permissions, obligations and duties into a verifiable credential so that when you want to have certain non-disclosed access in the certain non-disclosed data. ODRL can tell you what you need to do. and this can be part of, VC presentation, where you have your policy, being signed and perhaps even as a duty.
Rigo_Wenning: you want to have this policy signed by not the issuer or the holder but the one who's taking the data and confirms that they obey the rules in there. so to say that we have in W3C the policy language and vocabularies that we need and it's the beauty of link data that you can just combine those things but perhaps at some point in time we need to talk about what that means to combine a policy things like with DPPs
Carolynn_Bernier: Yes, but again that's the link data argument, not so much the C argument. Ivan is agreeing with me. Carsten Stöcker:
Rigo_Wenning: I'm lost.
Rigo_Wenning: I'm No,…
Carolynn_Bernier: You're lost. No. …
Rigo_Wenning: I'm No,…
Carolynn_Bernier: yes. She's done.
Rigo_Wenning: I failed. if Ivan says agrees with you, I have no argument anymore.
Dr._Susanne_Guth-Orlowski: Yeah, I just wanted to mention that people are maybe not looking at the verifiable DPP yet. maybe because they haven't read the ESPR in detail. maybe they don't know obviously the documents that have not been published yet from the standards where the DPP requires a digital electronic signature as it stands in the documents but it will come so definitely we will be needing signed digital product passports but one other thing that actually is
Dr._Susanne_Guth-Orlowski: disturbing my sleep is a different one where for example we have this data model for example JTC 24 and then we have the credential data model and in JTC 24 we have an issuer and we have a product identifier u but that's not in the subject that's actually outside of the subject in a verifiable credential so the issuer is the economic operator the subject is the globally unique ID and then I'm starting with subject but how do we map the subject then to everything that is needed by the DPP data model for example in JTC 24. So this is stealing my sleep at the moment how we can put this together. It would be lovely if this working group had super smart ideas on what we can do about it.
Carolynn_Bernier: That's an excellent question, Susan.
Dr._Susanne_Guth-Orlowski: and maybe just a note on dia. I have a meeting this week with Yasier I think from Gaia X. He made the OL profile for access control using verify credentials. and I'm trying to work with him on a DPP profile. I don't know maybe that can be part of the ODL workshop. Dr. Susanne Guth-Orlowski:
Dr._Susanne_Guth-Orlowski: I don't know if you know…
Rigo_Wenning: He already registered for the workshop and…
Dr._Susanne_Guth-Orlowski: but.
Rigo_Wenning: has sent the position paper.
Dr._Susanne_Guth-Orlowski: Okay. Good. So, I'm trying to push this forward a little bit that we can use it for DPP as well and…
Dr._Susanne_Guth-Orlowski: that's properly defined.
Ronald_Koenig: By the way,…
Ronald_Koenig: I have GTC 24 gives me also headache but real one because my understanding is that GTC 24 is not in favor of JSON ID because they describing this data elements and…
Ronald_Koenig: this language where they define really the serialization format which is different to JSON ID. And I currently have no idea how we bring both worlds different.
Dr._Susanne_Guth-Orlowski: Yeah. Yes.
Dr._Susanne_Guth-Orlowski: I fully agree but this is something that I wrote Ricky on. So a couple of people inside of sperity there is a high level text where it seems that we can use other reference to semantic repository than using element ids. It's in the text on a high level at the moment and…
Ronald_Koenig: Okay, that's fine.
Dr._Susanne_Guth-Orlowski: I will be participating in the meetings during the next three weeks to make sure this is possible…
Dr._Susanne_Guth-Orlowski: because otherwise we have a problem and I wrote Carson about it and Ricky knows it and Ingo as well. Yeah. So I'm trying to get this straight
Carolynn_Bernier: On the topic of …
Carolynn_Bernier: what Suzanne is losing sleep over the credential subject
Carolynn_Bernier: effect. …
Dr._Susanne_Guth-Orlowski: Yeah.
Carolynn_Bernier: so one thing that is clear in module 5 of JDC24 is JSONLDD is an optional serialization for the European DPP. So that's already a good point. In module 4, there is an example for the compact serialization in JSON and the expanded format serialization for JSON, but there's no example of a serialization for JSONLD. And I think they have one also for XML. Okay. So there is a gap for the moment in the standard which tells you which says you there is no example of how you should serialize in when you serialize in JSONLDD even if module 5 says JSONLDD is an authorized serialization. Okay.
Carolynn_Bernier: So this means that we may have an opportunity to impose serialization standard for JSON LD with and without a VC format.
Dr._Susanne_Guth-Orlowski: Yes. without a VC.
Dr._Susanne_Guth-Orlowski: And without a VC. H. Okay,…
Carolynn_Bernier: Yeah, and…
Dr._Susanne_Guth-Orlowski: I see. Yeah. Yeah.
Carolynn_Bernier: without. Okay,…
Dr._Susanne_Guth-Orlowski: Okay, let's do that. that's the really pressing topic.
Carolynn_Bernier: I agree. And I think that we have Ivan to help us with the credential subject topic.
Dr._Susanne_Guth-Orlowski: Yeah. Yay!
Carolynn_Bernier: So I would like to invite everybody to post poll requests on the document. I will also make some modifications to add some new sections on verifiable presentations and things like that. don't hesitate to post your comments or create issues.
Carolynn_Bernier: Ivan, the issues go for the entire repository, not just our car.
Ivan_Herman: Yeah, we have decided early on,…
Ivan_Herman: I don't know exactly anymore that we would use one repository for everything that the task for. I am less sure today that this was a wise decision because if the work comes complicated…
Ivan_Herman: then exactly…
Carolynn_Bernier: Yeah.
Ivan_Herman: what you say becomes a bit of a hurdle. So I wonder whether we should not revisit that but let's discuss that next week. I mean it's not
Carolynn_Bernier: So just for Carsten for consideration that we split the repo on GitHub. Caren, do you hear me? Yeah. Okay. So between it's originally we're sharing the same repository.
Ronald_Koenig: You can take it.
Carolynn_Bernier: But if we post issues, we don't know to which conversation we're posting to.
Ivan_Herman: Yeah, we can use labeling and…
Ivan_Herman: all kinds of tricks…
Carolynn_Bernier: We can use labeling.
Ivan_Herman: but we can use that…
Carolynn_Bernier: We can use labeling.
Ivan_Herman: but the experience is that lots of small repositories are more efficient except when we have issues that are relevant for several documents…
Ivan_Herman: then of course we lose But yeah, let's think about it.
Carolynn_Bernier: Okay, thank you.
Dr._Susanne_Guth-Orlowski: So I just posted a diagram from the whole supply chain. Dr. Susanne Guth-Orlowski:
Dr._Susanne_Guth-Orlowski: We can edit it and change it. it's from UNP but it can drive our discussion on what is our main target to issue a passport or to have all the linked data or download date in the EPCR…
Carolynn_Bernier: Where did you post it? Is
Dr._Susanne_Guth-Orlowski: if you reload it maybe it's showing here.
Carolynn_Bernier: as an issue as a PR.
Dr._Susanne_Guth-Orlowski: I don't know. No, I just okay. I has first to commit the changes.
Carolynn_Bernier: Okay.
Ronald_Koenig: What's this?
Dr._Susanne_Guth-Orlowski: Okay. Yeah,…
Carolynn_Bernier: I don't see it. Dr. Susanne Guth-Orlowski:
Dr._Susanne_Guth-Orlowski: it's commit directly to the main branch or…
Carolynn_Bernier: But go ahead then.
Dr._Susanne_Guth-Orlowski: I haven't created a new branch. How do we do it?
Ivan_Herman: For the beginning right now we can be a bit chaotic…
Ivan_Herman: if we want. but when it becomes more serious then we have to set up some rules and…
Ivan_Herman: mostly usually what we do is that we very rarely commit directly to the main branch.
Dr._Susanne_Guth-Orlowski: Yeah. Yeah,…
Dr._Susanne_Guth-Orlowski: I did it now.
Ivan_Herman: You do it now. That's fine. But let's not Yeah.
Ivan_Herman: For later.
Carolynn_Bernier: So this means I see you took that figure.
Dr._Susanne_Guth-Orlowski: Yeah, I mean I have it here and we can change it. I have the original version of it. we can use this one or a different one. But it helps us drive the discussion around, what are we targeting with our work here.
Carolynn_Bernier: Yeah, I see.
Carolynn_Bernier: Okay, thank you. Yes, we're over the hour. Thanks a lot.
Dr._Susanne_Guth-Orlowski: Okay, we're over the hour and…
Dr._Susanne_Guth-Orlowski: and if you have separate discussions on the credential subject staff,…
Dr._Susanne_Guth-Orlowski: yeah, let me know. I'm happy to participate. so I can sleep better. the heat and the subject staff is stealing my sleep.
Carolynn_Bernier: you sleep.
Ivan_Herman: Yeah. Heat.
Carolynn_Bernier: Maybe Ian, you and me, we can have a chat. Thank you. Byebye.
Dr._Susanne_Guth-Orlowski: Yeah, I would love it.
Dr._Susanne_Guth-Orlowski: Okay, thank you everyone.
Ingo_Wolf: Thank you. Bye. Meeting ended after 01:25:29 👋 This editable transcript was computer generated and might contain errors. People can also change the text after it was created.