DTGWG Credentials Specification Task Force Meeting - 2026/08/25

Hey Jeff. Hi sanction. >> Hello. >> Hi guys. Hello. Morning dear Erica and Jeff and Sen and Glenn think we're expecting uh Bernie Alberto too. Uh I don't know about Martina. Give it a second. There's Martina. That's a slide or there's Brendan and Alberto. Fantastic. All right. Um, if you're hearing a little something in the background, I'm going to be monitoring the the call the uh for the um the same time slide as the call for the global digital collaboration organizers. So, I'm seeing if there's any last minute info for uh yeah, I'm just going to monitor sort of in the background. So, um, one thing I realized after last week's call, we should probably be setting up a compliments page and taking meeting notes like like, uh, we do for the the other meetings. Um, but I have not done that for this one. And there's a ton of stuff on, you know, to discuss. And plus, I think, am I correct, um, uh, Brendan, that the U, um, CKP folks were going to join us at the half hour mark. Is that right? Yes, I believe that's that's right. >> I've arrived. >> So So that's even less time to discuss. Um I think Glenn, you you ping me about uh the really key decisions that you want to move on as fast as possible. So should we just dive right into those? Do you want to share that uh uh that decision page or I don't know what to call it uh that summarized the issues? >> Yeah, I've put it in chat already. Uh I don't know. Brandon, can you see it because you joined? >> No. Would you mind resending it? >> There you go. So background to all of this has been uh DTG's as they've gone through different spec versions the code had drifted a little bit. Um and so as the code kind of caught back up to the spec, this had happened in the first uh the version 0.3 which was the old spec version that we used as a template. There's always been a lot of confusion around the use of the you know RDI, MDID, PDI, CDID. Um the purpose of them exists for a reason which was a a moniker to try to say you there are DIDs that have a different purpose um and help you think about when to use what type of DID uh as you go through it. But what we started to find as we implemented them was there's kind of two things being stacked on top of the one name that didn't always correlate. And we started to get caught in what was the right definition for the use case that was coming through this. And so that had existed from the very first version of open VTC, but we kind of just pushed through it and we used the PDI and RDID mainly um as kind of a placeholder for that. as we've been going through tightening up the code implementations and now that we have VTC in place so we can kind of test a full ceremony end to end of using DTG credentials in all their glory. the basically started to run into this logic problem of the logic of the DTG spec started to kind of conflict with itself either directly or indirectly. And so that created a flurry of issues that started to uh accumulate at the DTG working group. And then basically the next step then was hang on let's just take a step back and look at this with fresh eyes and just say hang on what is it that we're trying to do here. And so the document I've linked um is kind of like a just a fresh look now that we have a spec that's well written and um I think has been very good to get us to this point and we have a implementation and I would just take this with a grain of salt. It's one implementation. It's a highly opinionated implementation um and it's very much skewed towards the Linux kernel use case which is a one end of the spectrum which is it's a very public community right it's uh there is no design in that community for privacy you can be anonymous potentially but uh the identity would be known on all of your commits on all of your uh interactions, emails, news groups, everything kind of gets linked to a known identity within that community as we go through it. So, I would just call that out. So, you know, as we step back and look at this and kind of think, well, the purpose of the DTG ultimately is to represent graphs and those graphs primarily are representing the relationships within a VTC itself. um the relationship a VTC has with other VTC's and then the representation of one or more VTC's within a verifiable trust network. So there is a kind of a hierarchy. You can have overlapping I think of them as kind of vin diagrams as you go through this and it just started to feel like we were fighting against the spec then the spec helping drive clarity uh as we went through this. So I then and actually Sankashan a lot of this came from your risk and harm prevention report which actually started triggering some of this as we started to put into effect some of the findings from that. It had the side effect of basically increasing the complexity of some of the edge cases. Again it's not a bad thing. It's uh just kind of a step up in the maturity of the implementation. And so we ran an audit against how we were using all of the DTG credentials and realized that while we think often of DTG credentials as purely nodes and edges on the graph, they are actually a really critical point for the architecture and the design of trust tasks, the VTC and how it governs things. uh as well as some of the tracking or lack of tracking that a VTC must have to be able to guarantee some of the things that are in the credential spec itself such as uniqueness for example. And so where you see the conformance defects or the audits kind of labeled F1 to F10 um at the start of this they were basically all failing as we went through this. We uh have had not had the need for a verifiable witness credential for example. So that was pushed to the side. We have not implemented a personhood credential because it's not needed at this point of the development. So I'm not going to go through all 10 of them. But you could kind of see what the state was. This state is of maybe 24 hours, 48 hours ago. Uh a lot of them have been fixed, which is good. It's just us pressure testing the DTG spec as we go through it. But effectively there's a number of open questions and each of these open questions exists as a issue against the DTG credential spec. Um I would like to try to do one of two things. either get a decision on the specification itself or a kind of acknowledgment that we are deviating from the spec on the build and just make very clear note of that as others build. Just knowing that we may need to come back and do a realignment at some point. And uh we can still do realignments, but really we probably want to get an agreement on this by the latest, you know, kind of two weeks before plumbers conference. So kind of midepptember as we think through this. So hopefully it just gives a bit of a overview of kind of what caused this to happen. These are kind of real world problems. Um I wouldn't say I'm stuck. I I am deliberately just making decisions and just pushing through and just kind of keeping track of it. Uh I found what was very useful was in the uh infographic you'll see I've basically modeled out three communities and the idea is those three communities are basically the extremes of a continuum. There is a completely public community aka the Linux kernel or an open-source development group. There is a community that is extremely privacy um concerned and they do not want any correlation or any leakage whatsoever. Uh and then there's a third community which is a hybrid of the two. some parts of the community may want to be well known and some relationships within that community uh want to be private even within the community itself. And so to help with that kind of just came up with three example communities and kind of like a bit of a parable about that. And then if you kind of keep scrolling down um trying to represent what this would actually look like from a graph perspective. So what would the shape of the graph look like? Um what would be um attributable to uh the the constituents of that graph kind of how it looks. So, you know, just trying to think ahead. Um, definitely would love to have Brendan and Alberto, you know, when I think of some of the other um clarifications we've done to DTGS where you've modeled it in code yourself and just had an independent look at it. Uh, I think we definitely need to do that. But there's effectively one, two, three, four. there's kind of want there there's a number of decisions that would help just unblock this uh if we can move on them. So, I'll stop there. Happy to clarify or uh Drummond, Brendan, Jeff, you know, if there's something I've missed there. Uh because there's quite a lot has happened over the last week >> and there's a there's a lot on that page. I'm I'm back studying it again. I I only had a quick read through the first time and said, "Oh my god, we're gonna have to tackle this on Tuesday's call." Um, and now I'm diving down into it. >> Um, and then >> I say this is a very complex topic, by the way. Um, when you start implementing it, >> yeah, >> there's pretty serious consequences of some of this spec design. Um, which is good because I think we now have evidence of some of those consequences. >> Absolutely. That's that's it's why we're here. It's uh I'm ruining the fact that we um you know gave half the call time to uh uh to the uh ZKP folks because they've got we've got something to put in front of them too. And then Brendan, you've got uh you and Alberto have the uh um uh the the PR that you submitted that I you know gave you feedback on and said, "Oh, this feels like more than belongs in the uh in the credential spec." So that and that's something you're waiting on feedback on from the group as well. So we got we've got both of these to deal with. Um, and 15 minutes before the ZK folks join us. Um, so let's triage here. What Brendon Alberto, what um what's your sense right now of what you want to do about your PR and the feedback I gave you? >> Yeah. M maybe we can um deal with that real quick and then come back to Glenn's. Um, so, uh, the feedback we got from Drummond was that we were proposing to put a lot of stuff about how to interoperate with trust tasks into the credential spec. And Drummond was like, well, this seems like, you know, a lot of stuff that's not just about credentials, which is a very fair point. And so, you know, there's different patterns that exist for how to do something that's at the intersection of two specs. And so, I'm I think we're very open to that. It's like we could put a minimal amount into the credec you know rework it and then put other things about interoperating with trust tasks somewhere else. Uh but the question is where would that be? Um do you know if folks have clear guidance on that? Um then we can just rework the PR. Um uh if not then maybe we need to loop back to it next week and discuss cuz yeah we're there's going to be a number of these interop things that come up you know cuz like some credentials are just not going to be properly interpretable um without referencing the trust tasks from which they came. So um any any thoughts on that real quick? My primary thought is that um if it involves processing the credentials with trust tasks that belongs in the trust task spec. Um so if if we put on that lens and just say oh is that if that's guidance about you know trust task and how they interact with credentials. The idea was define the credentials and then and then define the trust tasks. Um when you and I discussed it Brendan we also said hey if there's a credential that is really specific to a set of trust tasks the other way to tackle that is put that in a in a spec and you know in that's dedicated to that credential and that set of trust task that deals with it. That's why um my feedback was we call it core credentials the core credential spec we call it core trust tasks that are very universal in that spec but then we say if you need to do a spec that's more specific to a particular kind of credential let's call it a staking credential and staking trust task right that those then could belong in in separate specs um that are you know beyond core that is a thesis not necessarily I you know I'm I'm I'm not close enough to say oh that should really work that way now that we're doing it and we're looking at okay these the postcore credential we got delegation for instance now proposed which I agree is a super important credential um but the processing of a delegation credential um there may be a ton of of of uh uh trust specific um work around that so I'm putting it out there what do folks think about yeah >> the guidelines on these specs So I would agree with you Drummond in that don't leak one spec into another spec because they just become extremely complicated and you don't know which spec to read depending on the direction you're coming from. I suspect what is happening uh which is fairly common in architecture is that there's a DTG spec there's a trust task spec there is a ZKP stack uh spec and I will say in the issues of how to solve some of the DTG issues ZKP has an important role to play I think what's missing Drummond is basically it's the in between the specs which is actually where the complexity is how do I apply DTG GS um how do I apply trust tasks? How do I apply trust tasks when using DTGS? And trying to capture that in the spec is why it fails. I suspect the solution is that we're missing a specification grouping somewhere that there is either a you know something like a trust over IP spec or a VTI spec or something that its job is to talk about how the sum of the parts come together. So to work within VTI, you must use DTGS with ZKP with trust tasks. And this is that's basically filling in the gaps in between. I suspect that's where we'll be heading. I I don't think overloading any one of the specs will solve this problem. Um it'll just end up being way too complicated and uh become kind of everything in the kitchen sink in what can be a very clean spec of just DTGS. um how people want to use DTGS for other use cases shouldn't matter. >> And when you say DTGS, uh Glenn, that's short for DTG credentials. Yeah. >> D credentials. Yes. >> Yeah. It's funny because I came into all this work a long long time ago in the SAML days and that's what SAML ended up doing. You know, it's a family of I don't know eight 10 specs when it finally got together. But they had to do that same thing of have the one the the the spec that basically referenced all the others and and and the suite. Um I I have no you know other than SAML being looked at as as you know uh a very heavyweight infrastructure that you know it's still out there still used in some places. Um I I found out from the internet too people there's still you know their stuff stuff's still based on SAML but it's still out there. Um, I just, you know, I don't think any of us want to make it too too heavy, but if that's the answer, I'm I'm open to it. Um, any other reactions uh to that to taking that approach? And then if we're going to do that, we need to start figuring out what needs to go in that spec versus um any of those other three. Um, and by the way, that that we've also had a question, where's the agent name spec? um how soon are we going to do that? Um because you know some folks are already implementing that and asking questions about that. Um I do have an action item's law. Yes, I'm a big believer in Gaul's law. Um so how do we keep this as simple as possible? That's that's my goal. That's my goal. Thoughts? Thoughts on this on Glenn's suggestion? What if at a minimum we started with uh you know like an implementation guide which could graduate to a spec um possibly you know it's like where do we put the crosscutting issues we just sort of need a place where those are recorded and agreed at least in a working form and you Drummond and other folks can percolate on whether that needs to be a spec or something else. Uh what do you think about something like that? >> Yeah, I think that's good. I mean other projects sometimes they use terms like a blueprint for example or a you know design guide which is here's how to construct it and the ingredients for the construction are here are all the specs that you would have here's the DTG credentials CKP methods that would be supported trust task trust ceremonies uh you know protocols tsp did methods all of those would just be ingredients into that blueprint to create verifiable trust infrastructure for example One other problem that would solve I've been trying to figure out where we actually um put a description of the core elements of the trust graph. Uh the kinds of stuff that I you know end out describing whenever one says hey I want to understand this what you know how does this thing work? Um Martina covered a number of them in her you know uh overview that's on the uh um you know on the in in the general repository. So that would make a lot of uh sense to have in a in a in a VTI spec that um and and also putting on my W3C history. Um that's also where conformance you have a real problem if if any spec if you got conformance that involves other specs, right? Um, so we can in conformance that involves the use of multiple specs can go in I'm just going to start calling the VTI spec. Um, that does make a lot of sense and we can we can start. Now I actually want to point out Brendan implementation guide is in my experience a good thing regardless. Um, what you don't want to do is cross the line between stuff going in an implementation guide that really should be in a spec. Um, right. Uh, you want to make sure the specs just have the normative stuff and only enough to explain and and make it clear how to, you know, make normative decisions. So, I'm in favor of this. Uh, if if that's the way to to handle it, then I think we just we need to figure out, okay, where does that spec go? Do we, you know, are we going to set up another spec rep? Well, if it's a separate spec, we should set up a repo for it that we've got that um figured out. Um, and then I guess we just decide on on how we how we manage that. Um, so if we if we're going to go in that direction, uh, Brendan Alberta, would are you comfortable then saying, "Okay, we're going to figure out how to refactor um that that PR." Yes. Yes. I would love to have a PR that's reviewable, you know, that can be uh approved and and incorporated. So, yes, if if there's going to be a VTI spec, then we can I think pretty clearly pull the cross cutting stuff out, leave the key things in. Um, so is is that what you're you're going to set that up, Drummond? >> Uh, yeah. Yeah, I will I will get that going. So, now I'm going to actually request two repos. One for that and one for the uh um agent names. Uh, >> okay. Any final objections before we go with that direction? Uh, I that seems like a clean solution. Okay. All right. Appreciate it. Yeah. Thanks for taking a couple minutes there and sorry to uh we can come back to your priority stuff, Glenn, and um hopefully get you um squared away at least with some key next steps. >> Yeah. Um >> Glenn, how h how does it um there's there's enough related issues. Um how do we break down what you are asking about and and start making decisions about um what we want to go ahead and and you know incorporate and and and you know sort of a triage plan for that. >> Yeah. So just conscious of time. We have three minutes. I don't think we're going to get through any of them right here and now. Uh they are opened as issues on the uh DTGWG uh cred specs. Um, I guess I haven't had a chance to read all the the feedbacks for it, but um, you know, basically just need to get there and probably just I would suggest what we do and also I'm just conscious we have GDC demo on Monday. Uh we'll just put some warning labels that these are to draft spec. So you know any credentials you create and take away are subject to change. Uh but what I would propose then is uh Brendan if you're okay with it just kind of I'll keep building but just document any deviations and then you know as you get answers or we get answers on those together we just ratify them and then you know clean up anything that's differed over that time period uh until we get alignment on some of these. >> Okay. Okay. And so just to be clear, yeah, I'm looking at your um HTML document and it says layer 1 spec semantics. So there's a bunch of issues there. And so you're saying review those, put any comments on those. Um and we'll we'll work async at least until next Tuesday. Is that the idea? >> Yeah. Yeah. >> Yeah. >> Okay. Um Yeah. and of course everybody else. Yeah. >> Uh take a look at those two and we'll uh we'll see if we can come to some some decisions uh next week. >> The uh one one thing I'm going to point out is the problem is um at least a couple of us going to be tied up next week in GDC. So um uh you know for for those of us not tied up there, I I absolutely think go ahead go ahead with a call. But um it uh I don't know what time is it going to fall there and and actually it's going to fall during the uh the dinner on the first night which is going to be super super busy. So um >> yeah maybe we should we just work then asynchronously for the next two weeks or what do you think's best? >> I think we're going to have to do that. Um I do want to share one thing quickly before our other guests join us. Um, I'm sharing my screen just on as I reviewed Glenn's um, you know, this this HTML page. Um, this right here, as soon as I read it, um, I said, "Yes, that's like much better much better than the the, you know, those acronyms, you know, Miaopa." I it was just as we were trying to describe what we needed in terms of uh you know different uh dids from a correlation standpoint um you know I was just so much in did land I was just you know coming up with acronyms. These are in my opinion much better in a clearer terms. Now Glenn let me ask one second again as we wait for the uh um um CKP stuff. Is the proposal to um use these as terms or architecturally they change some things about how how the um um core credentials are actually used? >> Both both they change both. So >> okay >> um again some of this it's a it's confusing and uh it may what I again may say here may not be 100% but there's statements in the spec itself that conflict within the spec and one of the ones that keeps coming up is there's a concept of uniqueness but how do you guarantee uniqueness without tracking everything as you come through it and so that's one of the things that's coming up again and again. And so I would I guess the one decision if we can say can we move ahead and again I think this is a two-way door for now try using these four uh definitions both in the UX as well as in the architecture. just see whether that helps simplify things and then either they're going to help and be just very clearly a better solution or it will kind of f help identify where the next layer of issues are. I I suspect we just have to implement a lot of this and it's just flushing out where there are kind of design consequences that we haven't seen yet. >> Okay. Um I'm personally good with that. What I do want to dive down in and understand you know that you know it it might be a slightly naive view but the the whole idea that core credentials is this is everything builds on top of the core things that define the trust graph. So we want to get the DNA right. If we get the DNA wrong we're going to you know produce animals that don't reproduce properly or whatever. You got the analogy. So >> um >> just one um Let's just call out >> one from the the uh the chat. Martino was asking and I think it's just if we just address it we it'll help us just clarify things a little bit. Is VTN's um are those where do they fit in this missed access or is it a different dimension? Um just I'm curious because of course this this onion diagram that you've talked about Drummond is also in people's mind. Um >> yeah and that that actually does raise um the sort of growing importance of ETN's um uh Martina has several times brought up and said we don't distinguish those right now um you know from we just said even in the glossery just says VTN's are VTC's that agree to share some governance but we don't we don't call them out as a different node type and I've been sort of like yeah That's we need to talk about that. Um so yeah that is >> if it helps uh the way so from an access perspective three of those access the definitions would could apply to a VTN. Um pair-wise it doesn't make much sense but I guess you could have a VTN of just two. Um but the way I've been thinking about it is for the network nerds uh in the internet backbone um different networks can be tied together into AS's autonomous system identifiers and so just like the internet has a concept of autonomous systems uh I think of VTN's as the same logical grouping of uh what that is and so in that model I think it's very clear for myself um and it helps with the implementations of this. That being said, I will just say there is zero lines of code about a VTN at this point. We're we're nowhere close to implementing what a VTN would look like on this. The furthest we've got so far is VTC's uh recognizing another VTC. That's as far as we've gone into the depth of this. A VTN we're still some way away from. And that's, you know, it came up in conversation I was having with uh Erica and and Shannon yesterday that as we look at, okay, how is this stuff going to, you know, ultimately scale, we got the exact same thing um Glenn about about as and you know, looking at the internet architecture um and how we would you know route across you know across VTCs and VTN's and and yeah, same thing. So, all right. I guess we can uh park that one. Um uh um Scott and um um Mitchell, welcome. Um and you know, we offered up to uh start talking, >> you know, with the two of you. Um and and so um um who who wants to take point on on the ZKP questions related questions that were coming up uh to uh uh with with our uh uh coachure friends here. >> Um Scott, you're welcome to take point. Um over the last I think I think 3 hours ago or so I've been making um replies to some of Glenn's requests in the um discussion topics answering some of these questions from the CKP task force perspective so I can kind of follow up and illuminate those. >> Is that a good place to start? What what's the most urgent thing for us to discuss together? I have I have talking points that I think set the stage of our point of view that you all can react to. Does that sound good? >> Sure. Let's start there. >> Cool. So, first off, thanks for having us. Uh, it was exciting. These threads are some of the sharpest framing of the privacy theme that we've discussed so far, and it clearly lands on the ZKP team. Um so have a uh point of view on um what we were what we would be taking where the honest boundary is and how we think these three groups can divide it. Uh so we would be taking these as ZKP task force work items. Uh a binded non-correlating form of the binder task context salted commitments available now PRFder derived per context pseudonyms as the fuller construction. That was question two. uh issuer as predicate a witness in registry R rather than a named DID as a set membership proof that was Q6 uh delegation chain validity as nested set range predicates plus non-membership revocation and the root is in registry R uh as Q6 applied recursively which was in Glenn's number 40 discussion um and then the one that's very exciting uh the unified primitive is the prize. So Glenn's point in number 40 uh anchoring revocation status and registry membership are this are the same primitive and assigned publish set route plus a membership or non-membership proof carried in the presentation and if that holds it collapses several open questions that we're wrestling with into one construction and it would seem to be the natural home for the no live lookup skull. So we'd want to pressure test that and then framing of the honest boundary that we see um the durable correlators ID thread ID issuer recipient recipient uh the task context pairing the delegation invocation record uh those would live in the task trust documents trust task documents and the paper we build on proves over credentials uh not over exchange artifacts. So a ZK construction can only bind blind what the framework gives gives it a committed form of. So the hardest questions proving a task completed or what a delegate actually did are three-way decisions not solvable inside any one spec. Uh and the most useful thing we could do would be to decide where each correlator lives and where it can be blinded. Um, >> do you have a a link to >> uh this text or are these the sort of talking points? >> Yeah, this is talk talking points I prepared but I can share them. >> Is it possible to share them? >> Yeah. >> How would you share them? Oh, like like a shared screen. Um, yeah. Uh just a moment. Uh just one thing that I think I can frame as well is a response to the invited. Um there was another invited like the cybos ckping uh which I'll find well oh go ahead um Scott but there was a proposal with another zk um implementation that is mostly around the proof of the artifact of the signature um and I think that is one side and then the other side is uh allowing people to come up with their own con constructions based on the type of the trust graph and I think that's like a really important distinction that might actually solve some of the Yeah. Yeah. Thank you. sanction might solve some of these problems that I was observing earlier in the conversation is that like we we need to to me that is the divergence is like are we going to adopt ZKPs for just like the presentations and the artifacts of the signatures which I think is relevant to the kernel and the public access or are we going to allow people to like come up with their trust graph constructions based on all of the like corpus of credentials that they decide to adopt within um their particular expression of the graph. And that's when we have to start like coming up with our own um trust task equal math equal circuit pathway and then like have our own setups as well. But yeah, >> I I suspect you're facing the challenge that everyone is so excited by ZKPS, they're applying ZKPS to everything without actually thinking about the ZKPs do have a, you know, purpose and not a one-sizefits-all solution. So I would encourage you to be really strict on what the starting point for the first CKP implementation is and just put boundaries on it and say it's only to do this and go with the most simplest one first and then see how that goes and then also just see okay what emerges then is where else the use cases would come from because I guess my question to the ZKP team would be are you at the point where we you've picked an implementation that we could start to integrate with so we can start testing it within VTI and start issuing ZKPs for some of these credential issues between open VTC VTC VTA because I think that's there's an assumption that ZKP will somehow magically fix some of this. I think it will for some of it, but best way to do it would be just test it and see what we can do and not do with it. >> Yeah, that may that makes sense to me. Uh, Brendon. >> Yeah, that I just want to support um what's been said so far. Uh just another u kind of dimension that I'm thinking about. Yes, let's have something that we can start to integrate and try out. Um, and the other piece is as we're thinking about the specs, uh, it seems like the same principle, uh, that we just talked about in the first half of this call. Scott, you missed that. But basically, we're going to put a minimal amount um in like the credential spec, the minimal amount in the trust task spec, and then Drummond is making something maybe called the VTI spec, which is integrating spanning uh between specs and and also ZKP uh issues and and it's sort of like how to actually make this stuff work in practice together. And maybe um you know, there'll be a bunch of uh stuff that needs to go in that one. So um and and I guess the ZK ZKP will have a spec of its own uh maybe uh so I don't know but the point is you know just want to see if this principle sounds right. We'll try to keep the specs as simple and clean as possible and then we'll have something which is overwriting uh like a VTI spec where it's like okay this is how you put this together in a privacy preserving way maybe. >> Yeah. No, that's I I put in my plan to say that's that's uh Mitch and Scott where we're coming out in terms of things that cross uh you know issues or questions across the specs we've um identified. Um I've been assuming by the way um that there's going to be ZKP spec uh but I haven't even you never even got to okay what exactly is the structure of that um is whenever you guys want to start on that we will set up a repo for it we've got a standard procedure we have a dedicated repo for a spec so it can do all the uh specupt stuff and and all that so um I have to request a couple others if you want me to request one So, you've got a repo to start um uh you know, at any stage of outlining a spec uh just let me know and we can get that set up. Um but the um one of the thoughts I've been having to sort of reflect uh uh Glenn's comment is um that zero site that I referenced and I just saw there's been good discussion about that. I just wanted to point out that uh Leaf and and and Peter Altman and his team who will be at GDC by the way are you know have been working the problem that that they're after now. They they don't have the same remitt we do to say we need a set of proofs against um uh decentralized trust graph and the and the things uh involved in there. but they they're sort of experimenting with the kind of ZKP that they believe they're going to need in the seros wallet and and uh that the EUDI uh needs. Um that's why they're looking at the Longfellow stuff quite a bit. I've been thinking that it might be very helpful for us to start just maintaining uh um uh a list like in a in in a markdown document uh in the ZKP repo. What are the proofs that we need in priority order, right? What what are the most important um uh proofs that from a from a um utility standpoint with with implementations that are already going on out there? What what what's the you know the the the highest value proofs that we need where you know we're we need the privacy protection, we need the the the you know data blinding um of ZKP. Would it be helpful uh Scott and Mitch for us to start to have such a a place where we can keep track of that and questions around those proofs so we can be really pointed hey this this is something where we're assuming we can use a zero knowledge proof or we really want to be able to use one and then you would have you know more concrete uh all right how how do how do we attack that what are the what are the uh challenges around that I mean I know Scott in your case you've that uh we we want to have um you know privacy protected proofs of of of livveness, right? um that actually you know that should be on the list but we should also have okay what are the other things that we're basically assuming or knowing that we need uh uh privacy protection for but we don't it's I I don't just want to go oh yeah ZKP ZKP well you know we know no those could be very different kinds of problems requiring different kinds of circuits different kind of performance and it feels like that's a uh you a dialogue that we should have and a place where we can go all right are we working on this one or this one what's the priority it's just a thought to put out there >> now that makes complete sense and I think it is also kind of like attacking the thought or the problem from I don't know the intuition approach that I went with with building this evaluation build the own the circuit on your own machine and then plug your own um context and repo into that and see if it makes sense Um, so I think I can actually extend that where when we have this list of all of the ZKPs for different credential use cases, if you have like a I don't know a recipe planned, um, you can then go to that evaluation and see if you can reconstruct the circuit that has those pieces of that recipe and then if there was a way for the different repos to then be like, oh yeah, we were able to um perform this recipe in a trust task way using these EKPS and us to uh almost like build critical mass um of acceptance and like kind of like practice the governance in of itself. I think that that would be my expansion plus including this like starting point that we had of um educating our computers on the reproducing the circuits um that could be relevant. Hopefully that thought lands and the yeah the the work on the point for liveless spec is I also have that suspicion that yeah the proof of life li liveless is like a big um proof and there are some that will be predicate smaller for the more like public um data that we could have as small wins initially for these like trust tasks as well. >> Yeah, >> that's again that's what I was thinking about if if we have a way to um talk about the prioritization we need of the proofs we need. Um I I know Glenn for instance you you've you know you've said that uh um you know what OpenVTC is concentrating on for the kernel right now it's not uh you know that the privacy protection is not a major um issue although it's interesting that Hart named the uh the talk we're giving um uh at the plumber summit actually talks about privacy preserving um you know uh identity for for uh you know maintainers. >> The the example we use is you can be you can name yourself Mickey Mouse someone knows that you are Drummond Reed and you are a human and a US citizen but in that community you can be known as Mickey Mouse to everyone else but it's just you're going to be consistently known as Mickey Mouse within that community. Um there's and you Mickey Mouse has one did that you'll be known by within that community. It's a public did within a public community but there's nothing linking Drummond to Mickey Mouse. >> Right. Right. Right. So that that is something we can stand behind on that. >> Yeah. Uh but as we uh as we start you know moving out into you know other communities that uh I mean to to give a very um tangible example when I was in New Zealand uh uh in the uh in the conference that I keynoted um afterwards at the drinks afterwards a woman came up to me and said so what you described um would it provide a solution for a woman's shelter where um you know basically 100% of the occupants are in a position where they need to prove certain things like for instance the government to get assistance but they absolutely cannot be tracked um and and you know it's just it it it's literally a matter of life and death um that they be able to protect uh you know provide these proofs but not have to share any um actual identifying information. >> That's literally the definition of community archetype 2. a house where nobody uses names, which is there's proof. And as you go from room to room, we know that you're allowed to be in the house. We have no idea who you are. >> Maintains their privacy and safety. It's literally >> perfect example that. So, so again, what I what I'm suspecting is uh based on my limited knowledge of the EKP, it's always so dangerous to to know, okay, there's black magic over here and I just need to know how to cast certain spells. um that being able to start to um list the specific proofs that we know we need just some place where we can keep track of those and then have discussions around priorities so that um Scott Mitch the ZKP task force has a sense of all right the these are the most urgent things uh we need and of course you know you guys and and what you're bringing to the table you're part of it and we all provide input to what are the the the the most urgent things and Then then we can also as the solutions are there we can look at okay what are the trade-offs in terms of performance uh because that's my understanding is it's always coming down to that. >> So if if that would be helpful then I think it's just a matter of figuring out what how do we want to um start maintaining that um uh that list uh and and enabling people to contribute to it. Go ahead Glenn. Would it help Mitchell and Scott if I give you what I think is the first real ZKP that I can define with very tight constraints that would be used by open VTC in a VTC and we just get one working. It feels like that might be the f because it gives us something. >> It's concrete. It's easy to explain and then we're going to have to integrate it because we're kind of stuck on some of that. >> I think if we think it's a presentation as well. Yeah, it is. It is a presentation. It is absolutely Well, it's going to be a creation then a presentation. It's both sides of it. Um probably from the VTC back to the >> back to the individual or I don't know. It doesn't matter actually. It's one there's probably two ways. So if you're okay with that, I can write that up and just see what the first one that would unblock some of the uses in VTC and then I think that will just force all of the you know what needs to be done and integrations across the working groups. That sounds most pragmatic. >> Sounds good. Brendan, go ahead. >> Yeah, this is great. Um I definitely support that. Uh, one quick question um, I had just because um, I had some contact with them long time ago is you know like Hart and uh, Professor Gar and and you know the the folks who are doing that work um, just a very simple question. So what um, Scott and Mitchell you you guys are working on is alignable or consistent with you know cuz again I'm not a ZKP expert. I know there's different you know proof systems, there's different kind of signatures, you know, etc. So, are we are we moving in a direction where things will be alignable with with that work as well? >> Yeah, that that works the part of the source documentation and we have an overlap with them planned for September to make that alignment like a reoccurring um moment of confluence. So, >> amazing. >> Yeah, absolutely. Yeah, sorry. Just uh again just you know sharing information across groups. I just hadn't tracked that enough but really glad to hear that. Thank you. >> That's that's been it's been working. Um I had a another comment replying. Never mind. This escape me >> as we >> Oh, actually sorry. Sorry. uh we will make an item in the ZKP task force meeting to like review this uh like request for ZKP list and that I think will be an easy way for us to like sync it all together. >> That that'd be great. And uh we'll stick it in the agenda for the meeting tomorrow just so folks are aware we're moving in that you know that'll be something that they can point to. Uh you gonna say something Brendan? >> Oh >> no it's me. Uh so just >> try and get you a definition of what we need by tomorrow. So actually for the next work for the working group tomorrow Drum in which you say here's what it is. Um Mitchell Scott just because I've got the sign. Is it okay if I just ping you on that signal group just to bounce at a kind of async and you let me know if that's what you're thinking as well or whether you want to pick another one? >> Yeah. Thanks Alex. Perfect. Thank you. >> Um all right, we just we have three minutes left um in in the Craig call. I know the ZKP call is next, right? >> Um just quickly asking for um agenda items for tomorrow. I think we we do want to talk about fact that we've well let me ask this Glenn. What do you want to bring up or productively use time for tomorrow relative to the set of issues in your um or know exactly what to call it? The >> I think I think for the wider group there's not I don't think there's anything that's really useless. Probably just confusing everyone. I'll be honest. Um if they're not really deep in it. I think the update to the wider group tomorrow could just be here's some decisions we've made. um which is we're going to drop the use of the PM RC DIDs and use you know the four u kind of clearer intent. Second is we've identified a single use case of where ZKP can be applied for this purpose and that's going to be our first reference implementation within the VTI stack and open VTC and I think that and I think say there's still a number of open issues but doing those two will actually just help bring a little bit more clarity to what we're doing and you Is ZKP going to actually help with some of the design decisions on DTG? Or if it doesn't, then we know we got to go back to DTG credentials and just think about uh what changes need to be made there. >> Okay. The dialogue between the two. Um okay, that write up you're going to have do you is that something you would want to then be able to speak to? Uh >> yes, I can speak to that tomorrow. >> Perfect. Okay, we'll count on that. Um, >> yeah, and we can we can share that, Brendan. I think that's good. >> The axis diagram, which um what does that refer to, Brendan? >> That's in the HTML. The uh >> the one that you referenced in in Glenn's document, the one thing about public uh links. >> Yeah. Yeah. Yeah. Yeah. Yeah. Okay. That's a access. Okay. Got it. Um, >> yeah. And then, and then also the this idea of creating the new VTI spec for a cross cutting issue. >> Yep. Yep. Yep. I've got I've got that down. Um, excellent. Okay. All right. Uh, fantastic. Thank you, uh, Scott and Mitch. Um, uh, I just want to reassure everyone this is this is exactly where we need to be. Uh, because it's not until you dive into, you know, everything looks simple. Um it's like, oh yeah, we just put these pieces together, we write them down, and we build it all, and away we go. You don't hit these the hard problems until you get down into it. And then and then all of a sudden it looks like, oh my god, it's a morass and everything's just, you know, how are we ever going to work? And you know, when I looked at Glenn's uh which is very helpful, I was like, "Oh my god, there's a bunch of issues here. How are we going to work our way through this?" Well, we'll do it. Um, so you know, prioritize, knock them off. Um, anything else anyone wants to cover before we cut over to the next call, the ZKP call. >> Hey, only thing Drummond is on just going to be a little unapologetic. We are five weeks from plumbers conference. So >> yes, >> um, we just have to the more of this we can ratify the better. Um it's not a complete failure if we don't. It just means we're going in with a little bit more uncertainty if we don't answer some of these before then. >> Then and that's my feedback on that is prioritize what is it that we can make a decision about and update and and therefore implement as as quickly as possible. if if if whatever those priorities are Glenn just feed and of course we need to work as a asynchronously especially because with GDC we're going to you know we're going to get sometime some of us together next week but it's also going to be a uh you know we're not going to have the regular meeting cycle so um >> and then the second thing would just be related to that we I know we're sprinting ahead on the implementation side just as always just because we imple implement something one way doesn't mean that is the way it has to be done. If you think it's a red flag or we've misinterpreted one of the specs, please please let us know ASAP. Um it's quite easy to change it at this point, but the longer it stays in there, the deeper it gets buried by other things and kind of becomes a little bit like open heart surgery to rip it out again. So, you know, again, why I'm pushing for some forms of integration across this that keeps us all honest as we go through it. But, you know, there's kind of a bit of tension on both sides as that occurs sometimes. Uh, so from myself, please always feel free call out, reach out on signal if you're seeing something or you don't understand something or why we made a decision. I'm always happy to clarify. >> Super. Thanks, Glenn. >> All right. >> All right. We'll close this and jump over to the >> GKP call for those of us are going to be on that. Thanks everyone. >> Thanks. Bye. >> Bye.