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

Hello. >> Yo. >> Hey. S. >> Hey, Glenn. >> Hey, Jeff. How you doing? >> I'm on fire. >> Yeah, I know what you mean. >> Uh uh yeah, this is actually one of the problems with um agent names. There's >> agent names, while they're exclusive, that's actually a foot gun. Nothing stops you from realizing you can use the same agent name across multiple DIDs and it's whatever last DID got the agent name by the hosting service everything becomes that last DID. It's something I just I don't even know how you can check against it. >> So you have to it's a >> it's I I hadn't realized that that would actually be a side effect >> of it. We have to be careful of that. >> We we learn by doing. >> Yeah. >> I'm just making a copy of the log here. There's a few more entries in V Open VTC itself. So, I'm just pasting that to the chat right now. >> Yeah. >> Let it keep running and see what >> Drummond, you are back in the land of the real world, not down under. I I don't know why the land of down under feels like being, you know, in a different world altogether, but yeah. >> Yeah, >> we're a long way from everything. [laughter] >> I don't know. It it does feel like that. And no wonder New Zealanders and Aussies feel so special. Um they are special. It's it was it was really amazing. Uh that made a very deep impression. Yeah, it's a special part of the world. >> It is. It is. I loved it. Um and uh and the the call I got at the very end of that trip just like my last international trip I'm largely over. So, it's it was good. It was light. [snorts] [clears throat] Yes. And good to see all my good close friends on this project that feels like a runaway train. So, >> you started it. >> Yeah, I know. But now it's like, what do you do about the runaway train? [laughter] >> Don't you don't you pretend you got nothing to do with it. >> Yeah. [laughter] >> All right. So, anyway, first of all, I want to acknowledge uh Jeff's idea that Yeah, we needed to have a a call like this. Um these started to get very real very fast. >> Are we on the tracks, Brennan, or are you just laying the tracks just in front of the train? [laughter] Uh we're we're still on the tracks. Yeah. No, I think you know we are inventing something. But yeah, I think it's >> I think it's going well. But this is an important you know group to get together. Um yeah, because um we do need to pressure test a few things and so yeah, welcome back Drummond. >> Yeah, Drummond's like Aussie Osborne I think. >> What? [laughter] Now I got to understand this one. >> Crazy train, right? You you start a >> crazy train. Or is he paranoid? [laughter] >> Haven't I haven't been an Oussie Osborne fan, so I'm going to have to go learn about that analogy. >> Crazy train and then paranoid. >> So, uh, everybody's here and Sankan's here, too, it looks like. Or he's got something in. Not sure. >> Well, we can't conduct a meeting like this without Yoda. Yeah. So, um I I since this is the first meeting, what do we want to I mean, we have a bunch of questions we wanted to talk through. Are we going to be super formal, take notes? What are we going to which what do you guys suggest? >> Or do we just outlive it and just make decisions? >> I mean, I I think we need some kind of, you know, record of something. Doesn't need to be super. >> Yeah. Um >> there there's an AI thing running. Do we know if we can actually get access to those notes when it's done because they generally do pretty good summaries? >> Um, yeah. Do we do we know the AI thing is running? >> Uh, it said something when I logged in. >> Yeah, it says AI companion is on. Um, yeah, that means it is doing the automatic notes thing. Um, >> okay. >> Here, a simple suggestion is maybe two levels. Um, one thing we could do is because this is an editor's um call and we have a dedicated repo for the uh um you know for the spec we could just any any important I mean I'll just share the practice we had when we had these kind of calls uh working on the spec was um we were resolving issues that the main thing that editors calls were for were to discuss and resolve issues So if we basically say hey look any discussion we have we're going to we're going to note in you know in in the in the issues and and one thing we did is if we did arrive at a conclusion on a particular call relative to a certain issue in real time someone on the call went and and made a a comment and added that comment why did we decide X before we closed or or or you know resolved an issue. Um, so that's what I would suggest is that that's the main thing we're doing and then we can always have the uh uh notes of the call as a um as a backup. How's that sound? >> Okay, sounds good to me. Yeah, I I I don't know. I've never done this before, so that's what I'm asking. >> Yeah. Yeah. So, that's it. It it just it keeps everything structured and means if anyone's got something to put on an agenda to discuss, post an issue, right? Um, and I'm going to be the first one to say I have not been um, you know, I thought I'd have a lot more time uh to, you know, like be studying this back and and posting some issues the the the U credential spec. Um, one of the main topics I have is I already put in our our signal channel is now that we're saying, okay, we need that and the trust spec and these two need to be, you know, coordinated because there going to be a lot of questions between the two. Well, what are we doing to get to a formal working draft? Uh, or are we ready for a formal working draft? I say formal, just get into the working draft process with um a trust aspect. That's one of the questions I have for this call. Um, so and I don't even know, you know, we we haven't set up and gone through the setup of a repo uh for that yet. There's the draft that I think where does that exist? The the one um I think Glenn that you you started, right? or somebody started uh a trust task spec draft. >> Yeah, it's in the trust task um repo which is in where is it? It's in the DTG working group itself. >> Yeah, it's a trust over IP repo. It's trust task task force trust task TF repo. >> I'll link it. >> Oh, okay. So, >> so it's just it's a markdown file that's you know kind of spec looking. I don't know what the model was that you used, Glenn, but it looks specular. >> It follows the W3C format. >> Okay. >> Yeah, exactly. And which is which is fine as far as you know um I think Glenn you started down that before we had created the trust format and and set up the the uh the >> we can rewritten. >> Yeah, if it needs to be rewritten just let me know. Yeah, it so since Jeff did a great job of figuring how to set up a dedicated spec repo that's got Specup T um integrated, um it sounds to me like Jeff the the the task in front of us is to go from the the current markdown document into our uh Trust RP format with a new repo. Um is that >> I mean that's that's what you set up that worked. Yeah, it's it's that's yeah, we we just create another trust task spec repo like we have a cred credential specification uh specific or I forget what the names are but we created a second repo for the credec for the spec to go into uh um whatever that specup t so we can >> specup t it it >> and yeah and then just convert it we just have a convert glenn spec into the into the same format. That's easy to do. >> Yep. And do we need to uh when we need a new repo are can we generate or do we have to go to Rye for that? >> Uh we just create a PR on the TIP governance repo and it sort of gets created. I think Ry just rubber stamps it. So it's pretty quick. >> Perfect. >> It's automatic when you do it. >> Oh, fantastic. All right. Well, that that's a very fast resolution to the uh because I mean does everyone agree that we should be proceeding with these two, you know, um I'm I'm voting that we have the term core in both of them, you know, core credentials, core trust tasks because we're going to be clearly we're going to have other credentials and many more trust tasks. Um but that's that's a a and and then we have the question okay once we start that who wants to be on the editor team for that um you know each each spec should have an editor team that is is taking you know uh that has editor responsibility for it we went through that process uh formally for the um uh credential spec I think we need to do it for the trust test spec um I'm I'm putting it by hand to you know be a guardian of both um mostly to help you brilliant people you know stay on the train tracks [laughter] >> uh for trust house I'm happy to be an editor given >> that's that's fantastic we what we'll do is we'll um yeah we'll take >> Martina is shaking her head she's like what are you doing >> just really Glenn >> I mean I'm happy to hear [laughter] trust song. >> No, no, no, no, no, no, no. She's She's putting you on, Glenn. It's like >> you don't you don't have any choice. You don't have any choice in that one. [laughter] >> True, true. >> Yeah. Well, folks don't have to, you know, make a hard decision one way or the other today. What we what I suggest we do is surface tomorrow and say hey editor's team if formerly where the editor's team you know identified and and in the repo and everything for um credentials the report tomorrow on trust task uh um um well our report is going to be to say we we think we need to you know launch working draft one of trust task the following people volunteer to be editors who else wants to volunteer to be an editor if anyone else does And that becomes the uh editor team that we set up for that. Uh and welcome David. Um this Yeah, I just [clears throat] I I just saw that David joined. >> Thanks. Thanks. >> Super. Um so uh so that's that's cool. Now, in in terms of like notes, action items, um this is something I can we can make sure is is not essentially on the agenda for the call tomorrow that we're going to take that action um and get that started. Uh and that already answers my key question about now having um the two working drafts that we can work against and away we go on that one. Um >> I um if we're talking about actions, one thing I would like to raise here would be potential of a new DTG credential credential type that's surfaced uh from building open VTC. So there's a there's a gap that's arisen. >> Cool. I mean I'm going I hope this is good news. >> No, it's I think it is good news, but it's um it's just again it's the pressure testing of the the spec. >> Yes. >> And um you know, there's a few ways it could be solved, but I think a new type would be the best way to solve it. You happy to talk about it when the time's ready. >> Okay, that's I was going to say what because again I'm coming back in uh fresh. So let's just a suggestion in terms of um since we haven't preset up um you know an agenda page for this call. So, that's we've already hit my one agenda item. So, that's uh um uh one thing to talk about. Who else has an issue that they'd like to help resolve or something they want to make sure is on the agenda here today? >> Just briefly, can you hear me? >> Yes, we can hear you, Martina. >> Perfect. Thank you. >> I don't have anything to put on agenda today so far. >> Okay. >> Yeah. >> I wasn't sure about the voice. We uh just also a process thing which is we have been moving ahead with Glenn on some stuff that allows something like our witness exchange to work. You know, it's sort of the first multi-art trust task if you will. Um and so there was coordination there which I think this group should be better aware of and have a chance to weigh in on. Um and then also just kind of a process thing of how do we surface things to the larger groups? you know, do we need feedback? Um, you know, that's kind of a question from you for your drummond. What's expected um on that stuff? >> Uh, okay. So, process. Okay. So, I got three agenda items here. We got the the process question. We got the um um I I I want to say that it's a ceremony um you know, question. And then we got Glenn's new credential. Um, are there any other agenda items that folks want to surface today? >> Brendan, is there anything from the back and forth on trust tasks and DTG feedback? Things like the um, you know, hash type that's in the witness credential. Uh, the linkage of using the hash. I think we're all in agreement, but is it worth just going through with this group so everyone's, you know, just in sync and that people are aware of the decisions that we're making and locking in? >> Yes. >> Uh yeah. Okay. >> Yeah, I would say so. Also, um and this is something where uh I have some knowledge, but I think we would maybe even cross over with the ZKP group. Um, you know, there's some things that have come up about like if we're doing a digest, then you have less of an ability to do selective disclosure. Um, you know, like if a digest is required. Uh, so then we're sort of saying that we're moving we're relying more on ZKP for privacy, which of course I know we've been talking much about and is the plan, but um, you know, just wanted to flag some of these things that um, you know, may be worth again discussing together. So, you know, the point about the digest, of course, is just to make sure, you know, when when you're linking something, you're linking to the to the, you know, actual credential and it can't be spoofed in some way or another or the actual trust task and it can't be spoofed in some way. >> Yeah, I'm noting that. And uh I've got some some some good uh um there's another customer IP um effort that might tie into that. Um, I can barely see that your hand is up, Martina, because your hand in the sky is sort of, you know, looking like a flare out of the sunset. So, go ahead. >> Well, that's San Francisco, you know. [laughter] >> Um, no, I'm um there was some distraction here, so I'm not sure whether Brandon already mentioned it. I um put into the chat the question again whether we should start working with forks or whether we are still working with feature branches. Um yeah well yeah that would be maybe something to discuss as well here >> that's okay for feature branches okay >> why why does is there a background as to why that matters just out of curiosity or is it just a style thing >> did you hear that Martina >> yeah I heard it I'm not the super expert with GitHub to be honest But from what I heard um it matters uh for merging. >> Um it's easier for roll backs and all those things. But maybe I don't know Brandon you know or anyone else >> know any anything more about it. >> The general rule is if you are a >> you have access to the repo >> branch if you don't the then you fork and the two work side by side like it's the PR that you reviewing. Well, I heard it a little bit differently that if you're just starting and a small group of like I don't know two to five people then you work directly. you may not even work with feature branches. Um and the more complex and the bigger um the participation becomes um the more you divert towards uh forks >> and then from what I heard it it seems that with rollback and versioning it seems to be easier with forks but I can't tell you why that should be and whether this information is correct. >> It's it's just a permission issue. There's no difference in rolling back a PR or a commit. >> Yeah. The the one thing I would add is um it's something easy to forget is uh when you create a PR, there is a setting to allow maintainers to contribute to the PR, which we have not done when we've been working with Glenn once or twice. And then he can't, you know, he can't add a commit onto the PR to massage the details. So that creates a collaboration barrier. And if we're on the same repo, that's less likely to happen, you know, if it's all forks. But, uh, you can do it from your own fork or something, too. We just have to make sure to check that box. Um, does that make sense? >> Yeah. I didn't even know about that. You're already at GitHub ninja skills that are beyond my uh uh experience. So, >> yeah, Alberto surfaced that one. I I I didn't use it so much in the past. I'm like, "Oh, yeah, that solves our problem." >> Okay. >> Brendan puts a PR from a fork, the main branch moves. So, now he's out of date and on a fast moving repo. For [snorts] Brendan's PR to get merged, it has to be in sync. So, either he has to time it perfectly or normally the maintainer will just push a merge for a force merge back to main and then accept the PR. But if you don't have that feature turned on, you get stuck and you're always behind the latest branch is typically what happens. Okay. So, what I'm hearing is it won't really matter fork or um feature branch if you turn on that flag. Is that right? >> Again, I would say for for big projects, maintainers typically branch anyone else Fox. It's just a permission. It's a permission structure. >> Wow. >> I'm learning a lot. >> One other one that's a little related to that I I think Sankrashan and I also had a question about is this versioning question. Um so I knew I know we're working towards quote working draft you know or uh what's the word implementers draft or something number one. Uh, but along the way, for example, for Glenn and Alberto and I to coordinate and have code that actually runs together, we also need ver some kind of subversion of that. And so I just want to make sure that we're in agreement how that's going to work. So it's like, you know, are we going to match version numbers somehow or will we say credential version.4 works with trust task credential version.9. you know, we have to have a way to to kind of coordinate that. >> So, [clears throat] again, now I'm reflecting from W3C experience. Um, the although they handle it one way and and and we're we have more flexibility how we do it. Um, but the idea of the working graph stages is you you know you version whenever you need to. Um, and and and you're there are two drivers of that. One is you want to flag, okay, there's a new version to review, look at the new stuff, right? Um when when things are moving rapidly, you know, you can't just ask for people's continuous attention to review stuff. So, you call out a new version as soon as you say, "Okay, we've reached a state where we want people to to look at it." Um, and it doesn't matter. I mean, well, at Oasis, we went to one 59 working drafts, right? because we were working in Word and the only time you ever knew anything was new is when we publish a new something new. We don't have to do that. We're using GitHub. But there should be very little friction in saying okay this is not working draft 03 or 04 or whatever. This what you're bringing up Brendan is a more important thing which is okay code sync to that stuff. My answer there is okay if you have that need then whenever you reach a point where you go okay we need to lock on a version we're working on that call that a new working draft just say okay that's working draft05 right I don't think you have to keep the two in sync you could do that we could just say hey we want to do that in order to so that it just reduces mental load but that's I'm going to say that's up to you as implementers whether um This is I mean Glenn now we're living the reality of code first, right? >> Yeah. >> Um so the the best practice of code first. This is the literally the first working group in my um career where we've taken that approach. So you're plowing the path. You tell me what will work best. >> So typically brittle architecture is when you start tying disparate components tightly together. Um, it creates really bad brittleleness. I'm just thinking from a code level, you know, DTG 1.0 what the what it's pointing to for a trust task should not matter from version because you'll just know that it supports trust tasks. And when you follow that linkage and you find the trust task that you might be looking for, then the trust task version number comes in. And then it's just going to be are you you know do can you read that version if not you'll throw an error that you need to be updated to whatever the latest trust task is. Um so I don't think there needs to be a linkage apart from maybe a in the specification just saying trust tasks need a minimum of DTG 1.0 and DTG uh tend to link towards uh trust tasks 1.0. As long as those two 1.0's O's recognize each other. However, they diverge in the future should be okay. Um because at the end of the day, we're they they aren't tightly linked and that's a good thing. Does that make sense, Brendon? >> Yeah, maybe that minimum version. Um you know, hopefully we won't have things that are like truly breaking um you know, it's like additional uh compatibility or additional features. Um but yeah, if we could say minimum version like you know these this DTG spec works with minimum of trust task version blah you know and vice versa. >> Um what do you think about something like that Drummond? >> Yes. >> Yes. Again I'm I'm going to defer. I'm also realizing that uh um now I you know I just had a good catch up with uh Erica and Shannon yesterday. you you all saw I finally listened to the recording u of the meeting last week. Uh we need to bring them in sync with this as well because now their code base is as dependent on this as everyone else's. Um and uh and and so I want to make sure that they're they're you know comfortable with all that too. Um I yeah I'm I think that's great. I think as long as we have uh agreement on it among the folks that are uh coding um I'm going to repeat again this first time I've done code first and I love it. I'm going to advocate it the rest of my short career doing this because this is the last specs I plan to spend uh you know full time on. So >> yeah, >> let's go for it. >> Yeah. So I think Sankashan you're right and I think that's why we're saying the loosest coupling would be almost like an MS MSRV style thing which is the minimum spec that we expect this to work with is you know 1.0 to 0.9 or something like that. Um yeah I I don't think it's a red flag. I think we just go with something as a starting point and just see what breaks. And so so um on that uh I just wanted like there's different styles. There's the kind of code first style which is you just do like 0.4 0.5 you know and you increment like that but Drummond there's this working draft 01 working draft O2 which is more the spec style. We could put tags on the repo you know with those working draft versions. So, I'm just I want to make sure I know when we say a version, you know, what are we what are we referring to, you know, and I'm not sure I understand the spec notion of versioning um as well as I need to. Okay, so just just clarify the spec notion of versioning in the working draft stage is you know just two integers incremental as the editors say okay we're going to just um um cut a new working draft and and you can do any amount of work that the editors decide to do. That's what the editor team is about until you say all right we're going to move from working draft 04 to working draft05. So, it's just an editor team call and you just at that point, you know, you you you you just change the uh the version number. You're you're constantly working against the one thing, but you just that's when you increment the version number. That's just an pure editorial decision, right? The GitHub decision of how to tag it is also up to the editors and can follow whatever you guys recommend. Um, again, I'm not I'm not doing the coding. So how to tag that is up to you. Um what do you suggest? >> Um well just if I can jump in just for a second before Jeff I I do think you know the kind of typical code approach of major minor patch versions is helpful and then maybe we can link a working draft version to that like a major version is a is a increment of the working draft version. You see what I mean? So like we might we might be iterating on 1.1 1.2 1.3 but we don't go to working draft 2 until we go to you know kind of uh git um tag two. Uh that that way we can keep the working draft version uh aligned but allow for more rapid iteration and more specificity you know with major minor patch versions. Just a thought. >> Yeah, that's whatever you as implementers decide is going to work best. I think the one thing we want to do is just document how we're doing it so that anyone new coming in can go, "All right, I understand how the spec drafts and the code uh repositories are being aligned. Whatever you suggest." Uh Jeff, go ahead. Yeah. What I was just going to mention is because I know you mentioned in an issue a while ago uh Drummond where you said you had it said work uh working draft and 01 and then you would bump it to 02. It's not 0.1. It's literally the number 01. Right. So that is that correct? So it's it's it's as if the draft document has a just a sequential number 01 02 03 and the code which we're more used to with sever um you know it's it's a question how do we align those two things because let's say we take the trust test spec and put it into specupt and create a formal working draft for that too. So it's we bas it would probably be a coordination saying well uh credec is at 02 right now trustec is at 01 we're going to agree that we're going to increment both of them so 03 of credspec aligns to 02 of trust spec and then whatever we do in the git repos maybe we just create a tag for that 0203 or something like that so that it obviously cross references the the drafts um of the of the working docs better if that makes sense. Yeah, that's that is fine. By the way, I'm realizing, you know, again, this is first time I've done code first. The 01 02 03 just incrementing um um um um you know, uh two twodigit integers is just a a practice we've used elsewhere with uh um you know, with with trust specs and um is is what the W3C has done. if it would be easier because it's just text in the spec to adopt the the same you know sever uh versioning of the working drafts to align with the codes uh uh code bases being developed we can do that too it's it is just text >> I mean I I would if we can use sever I would suggest it because especially having that patch level just means if there's a spelling mistake or you want to change something that's not really breaking or just add clarity. It's not a change to the spec actually. It's just clarification and that's where that extra level of depth really helps and matches with how you what we do with the code bases as well. >> Okay. So, do we want I mean because again it is we could literally do a you know PR in one minute just say okay we're going to adopt Sever um for the versioning of the spec drafts and align it that way. So, everyone, should we do that? Looks like I see a bunch of nodding heads. Uh, all right then. Let's do that. And now that's going to simplify how we can stay synced. We're all going to learn from code first here. And and then I have a nice [clears throat] anytime we run into problems with that, we have one a two-word answer. Blame Glenn. [laughter] >> Oh. Uh but so um so then just as a starting point um are we just continuing with uh like I don't think we've been uh you know kind of managing our versionings on the DTG side um so do we do we want to have a match point now where we align with something that's on the trust task spec or we just um start where we start and we'll just we don't expect the numbers to be matching right it can the DTG spec 3 and touch task spec 2. So we I guess I'm just ask just confirming we don't need them to match. So we'll just start adding those to our DTG uh you know pull requests. >> Yeah, I would actually say it's a good good practice to start with them not matching. So actually people just understand they do not have to match at all. Whereas if we artificially match them, I think it'd be super confusing to everyone. >> Yep. and Sangshan concurs. I think we all concur on that. Um it's striking me that the uh >> um Martina I think one place we wanna in the general repo I think we want to start a discussion on spec versioning to capture the process we're we're going to be using for you know because this can apply to other specs too, right? We're going to have uh VDS and we want all of our specs to work the same way. So, um I'm not I'm I'm pointing Martina because she helped create that general repo where we can put this stuff that's not um um task force specific. Um >> I just wanted to to ask in this context because Sashan also pointed in this direction. I'm not sure whether consciously or whether he meant something different. Would we have something like a mapping whatever table information somewhere to you know link the code to the spec. I think that should be in some place, right? Because there is a connection even if the numbers don't >> Yeah. Yeah. >> add up. So where would >> how we do that? >> Link to the tag. >> Sorry. You link to the tag, Martina. We would tag the specs. >> There could be many many many many commits and PRs, but when we ratify a, you know, 0.1.4, 4, you would tag it as 0.1.4 so that people then know how to find it in the repo. >> And and of course it appears in the text of the spec too, right? It'll be that the DTG spec, you know, 1.4, you know, requires minimum of trust test spec, you know, 0.8 or whatever it is. Um, >> and and yeah, I mean you your your general repo has been super helpful as an entry point for people. Um, so whether we want to like sync that and keep that up to date too with like a reference um, we could, but you know that's extra work to keep keep uh in sync. >> I think the general repo the the assumption is we just that's a starting point and things like this that folks need to understand the specs and the codebase. That's why I'm suggesting we have something there that documents what we just discussed so anyone can understand the numbering system. >> Yeah, >> if it helps. This is what VTI looks like. These are the tags. So at any point in time, someone can easily just get a zip of what it was at that point in time independent of the number of commits that actually took to get to those tags. That's what I would suggest. So this is a re this is the easiest way to follow it verse, you know, if you're looking at it naturally, you're looking at something like this, 1477 commits and trying to figure out which one of these was the right version that got released. So >> So go back to the Cypress one. >> That's commits and then this is the tags. So you can see here Cypress is a that's the named release, but these are the versions of the software. >> Yeah, those are the vers all the versions go into that. Yeah. Okay. >> So, if that helps, just give you a reference. This is what you would be working off the tags, not the commits. >> Cool. >> And uh one one thing uh that Glenn flagged um just a housekeeping thing which is on my plate. I'm I'm sorry I haven't gotten to it yet, is when we when we make the spec repo, um it can be confusing to people. Like the the task force repo for the cred still has an old version of the the spec there. And I think we should probably remove it from the readme and point to the spec repo now. Um, you know, and so that's a that's a simple PR that I can make, you know, so that we're not otherwise people are going to get confused very quickly. >> Please, please do that. Okay. Will you take that action, Brendan? >> I will. Yes. >> Fantastic. Yeah. Um, perfect. And once we set up the um uh the repo for the trust aspect, then let's make sure that it's clear that's the current one there, too. All right. Um I don't know if we've covered Jeez, that's amazing. We we got 22 minutes left. Um, we still have new credential ceremony and the ZKP question. But since we're on process, were there any other process questions um that we want to cover quickly? Although someone asked, I forget who, how do we surface things with the rest of the working group? And I think the answer to that is we have these calls. We're advancing the spec. Everyone knows that any any major you know action there is going to be you know reference the repo look at the issues um you know raise PRs or raise issues um discussions if if necessary. But I think this um otherwise you just we report out um and um um who wants to and in fact I'll make it easy. Who wants to be point on reporting out tomorrow on progress on this one? Let's just pick somebody who wants to do that on on credentials. >> Uh I can I can do it, but I would like to, you know, talk through with the group a little bit more just to make sure that there's at least an understanding of what I would say. Um and you know that some clarity on where we where we think where I think we're at, you know. Um, so I think yeah, let's take some time to make sure that, you know, uh, things can always be changed, but that, you know, what we've been working on makes sense to the group. Got it. Yeah. And we can reserve a couple minutes at the end to make sure we're synced up on that. Um, okay. So, of the other three things are the the new credential ceremonies and ZKP, which is the most important to get to next? You want to you want to do this new credential um proposal? Uh you're on you're on mute clan. >> Let's do a ZKP first because I feel like that's maybe a quicker discussion than the new credential type. >> Okay. Uh Brendan, you you were raising um the ZKP coordination question. >> Yeah. So, so basically um the mechanism that we have now is there's more detail to it but when you want to link between a credential and a uh trust task ceremony you know or flow that um >> uh generated it you know so that you can you can verify that uh you need to have some way to link it you know cryptographically and so the hash of the trust task is how you would do that. Um, and so you know, we we've proposed a a standard hashing algorithm. So we can talk about that if you want, but it it should be pretty standardized. But the point is once you're doing a hash over the whole credential and you're requiring it, then selective disclosure is kind of blocked. you know, if you if you felt that selective disclosure was important, but I'm not sure that it is because our our um credentials are very kind of atomic and small. I don't know that there's, you know, will you really need to selectively disclose things and plus it's also like a commitment to the ZKP approach. You know, do we want to sort of say that that is how in this world that we're managing privacy is not really with selective disclosure, it's with ZKP. So, you know, there's also that kind of policy direction, if you will. Um, so do you think that describes it? Well, Glenn, >> anything to it? >> I would just say at the end of day from a DTG witness credential, it's just saying you have to provide some form of data that matches this hash. Whatever that is, whether it's a trust task or it's an intermediary ZKP that's been inserted as a proxy, actually doesn't matter. it's just up to the verifier to say, you know, are you providing something that's going to match that hash as you go through it. So, part of me is just kind of saying it shouldn't matter what the input was. Um, selective disclosure, you know, if people want to add that to trust tasks, but then date still going to be a hash of the selective disclosure in the trust task. It's still the task as a whole that gets um there. So I feel like that pushes the responsibility actually back down in the trust task layer than enforcing something more complicated into DTG where DTG now has to deal with every single possible use case of what it could be witnessing. At the end of day it should just be saying I don't know. I'm not telling you what I witnessed. All I'm saying is here's a hash of what I witnessed. It's up to somebody else to provide that if they're willing to be verified that it was witnessed. And I think that's the best logic that works. Does that did that make sense what I said? Just which then becomes its universal input. It's like garbage in garbage out. I can I could literally create fake witness credentials if I wanted to obiscate what's actually happening by just throwing some junk data in. And it's just going to be random hashes to anyone who's looking at it. Yeah. [clears throat] I I suspect though that um Brendan, what you're bringing up is that hash going into the Does it does the hash end up in the credential or is it just used in the trust task um um workflow? >> It's the hash of the trust task that is represented in the witness credential. >> The hash of the Okay. Okay. So we take the trust task and we just hash it and then that's the that's the u what was witnessed is that hash. >> Got it. >> So we we've seen two you know we we've already talked about the task context. Um >> yes yes >> you know so that that's an identifier which points to something that has an ID but you know you could just copy that and paste that anywhere right so that's why we need the hash to have something that can be cryptographically tracked >> tied to it. So it's kind of both points. You need the the ID and you need the hash. >> Got it. >> So that's what that's the new part, you know, but we're we're trying to follow that core model that we've already discussed of the task context of of a uh you know. >> Exactly. No, but correct me if I'm wrong. Both of them could be correlators, right? >> If that's what we're worried about is correlation of that. Um um I mean if if we're worried about having correlators that can be tracked if in the usage of that credential is that is that the privacy issue? >> Uh that that's worth considering. I think less so is my intuition. It's more like you know selective disclosure um of uh I guess in this case uh trust task uh data data from a trust task >> data from a trust task okay >> because then you you couldn't really um you couldn't really do that uh you know you would still have the hash of the whole credential um and it would be hard to to verify that selective disclosure I Does that >> I guess the the challenge would be let's say I do a trust task with Brendan to uh I don't know change my legal name for example and that gets witnessed as a hash and now Martina wants to verify that she can't verify it unless I give her the original trust task which is going to have what my old name was for example so that's a leakage now to the verifier. But at the point there it's like what's the verifier going to verify otherwise? Um >> yeah. Wouldn't the verifier just simply ver be verifying the um the resulting credential? Is it signed? you know. >> Yeah. I mean, it feels this feels like one of those edge cases that comes up where again you hear it a lot in the industry, but in practice it doesn't seem to I would rather just say let's go with a hash until we find a real world use case that requires a different approach and then let's solve it at that point. >> Yeah. Yeah, I agree. Um, by the way, Sakshant did his usual amazing I don't know how he finds these things. Um, as soon as we talk about crosscredential linkage, I just want to point out Trust OP has um coming out of the carry work standardized a uh the self-addressing identifier or said for how to do that. So, um I just want to make sure we're not reinventing a wheel that we've already now um uh you know, it's actually there's an IETF working draft that he um that Sashan found um for SDS. Um we've got that registered now with uh um uh Ayanna as a as a um >> Yeah. No, doesn't said is actually the it's doing the wrong thing here. >> Okay. >> Okay. So, it's not needed here. I just I just wanted to >> Good. Um, >> as long as anyone's aware that if we need to do cross credential linkage, let's not reinvent that wheel. >> Yeah. Um, again, I would just start with it simple until we find a reason why something more complicated needs to come in. >> Yes, please. >> I don't know, Brendan, if you >> No, no, I like it. I again, um, I just want to also flag for the group. Um, I don't know if we're going to take a position, you know, or need to on ZKP versus selective disclosure. We don't have to do that now, but um, you know, that might come up to say, you know, our p preferred privacy approach is ZKP for such and such reasons, you know. So, you can punt [clears throat] on that. The reason why I'm punting on this is a good word is the danger is we end up putting ZKP at every single level and then it becomes an implement's nightmare when someone new comes along and goes at what level should I be implementing ZKP at. Um if there's too much choice everyone will have a different interpretation. Whereas if you don't have it anywhere, it becomes a conscious decision and a discussion about what is it that we're trying to do and where is the right layer for ZKP to be inserted and try to keep it at one layer as much as you can. And you know this is the problem. There's just too much variability of what you could do for some to be blunt academic reason, but in practice it never actually happens and everyone wears the cost of over complicated specs as a result. Yes, it's we [snorts] have to make the hard choices as an editor team to not make those complications and it it's going to I guarantee it's going to cause us a lot of pain but we got to do that. >> Yeah. I would also just say when we did the demo for DT DTG at scale uh for something like Linux Foundation which we modeled about 18,000 nodes with interconnectivity that was already 600 to 800 megabytes of credential data. If we overload it with like ZKPS and selective disclosure you are starting to talk about tens of gigabytes of data um very quickly which just becomes unworkable in this model. So again, I think we should have a design ethos of keeping DTGs as light as possible because the graphs are go we want to have very very large graphs that are very very dynamic. We do not want to have extremely fat, heavy and slow graphs that become inefficient to actually work with. >> 100% agree with you. I I I I feel that's that's that's a kind of architectural u uh philosophy that I I almost feel we we should document in the general repo and just say hey this is this is because you know folks should understand that. >> Yeah. >> Um okay we only have uh 10 minutes left. Um if that satisfy that one then we have either the have new credential uh type or the ceremonies uh question. What's which one's more important to talk about? I would say the delegation one's probably more important because ceremonies is still under heavy dev work and I think part of the goal between now and GDC is getting the ceremonies properly set up so that we can look at it materially. I think it's hard to understand what the ceremonies look like end to end when we don't have one fully instrumented end to end. So then you can't really see it. >> Okay. So when you say delegation, is that the new credential type you're talking about? >> New credential type. So in what we're running into, and this is coming up, I don't think it's coming out of the ceremonies when you start having things such as parents who are acting on behalf of a child or an adult parent acting on behalf of um a elderly parent or actually a maintainer who may be acting on behalf of another maintainer. for example, you know, maybe someone is on leave and I've delegated my approvals while I'm away to someone else. Um, or in the case of AI, fiduciary AI, I am delegating authority to another entity to take action on my behalf. That does not exist in the DTG structure um today. So, I'll give you kind of an example. Um, you know, I thought that the endorsement credential potentially could look at it, but it's [snorts] VEC's are kind of an unverified opinion. You know, I think Glenn is good at Rust. Um, verse Glenn may spend my money. They are two very different statements and should not be in there. Uh, a delegation. So, a VDG would be a delegation credential. It would have scope. It would have what the parent delegation digest is. If it's redelegated, it would uh actually use ZKP for um what the credential status would be. So you could either have it in there as a raw format or this is actually where I think ZKP slots in really nicely as a easy first grant which is the DTG sorry the uh VDC would be saying that there's a delegation authority between these two but you can't see what the delegation authority is unless you've got access to the ZKP chain uh which will then tell you you what you may or may not be able to do with it. I'm happy to write it up and send it through, but uh right now there's no ability for me to track a delegated authority in the open source communities, which happens between the maintainers, contributors, and you know, I'm delegating authority for you to merge PRs, for example. Some of the very conversations we had here. >> Yeah. So what Glenn says makes sense to me. Um the the thing I just wanted to raise, you know, I think that's a decision point. You know, he kind of flagged like an endorsement credential could be another alternative path and he gave a reason why that's not a good choice. Um I just wanted to also raise this issue of like let's say roles within a VTC. um we're going to need some way to say okay uh you know Martina is co-chair of the DTG working group you know um so these kind of role assignments it's it's not the same as delegation but it's also some formal designation that maybe is different than an endorsement so I just wanted to throw that into the mix as we're deciding how to handle it so 100% backing what Glenn says but also flagging that role question that is going to come up pretty soon. >> And today in OpenVTC, we're using the VEC, the endorsement credential, as a proxy for the RO credential, Brendan, which it's working, but uh [laughter] may get confusing uh to others. >> So, I put in the comments, you had me at delegation, right? This is just Oh, I'm sorry. I did not see I sorry I just didn't see your first Martina. Go ahead. >> Okay. Um Glenn I just you tapped into both a little bit. So so I just would like to to dig a little bit deeper. Uh you mentioned delegation and authorization in the sense of the delegation of authorization. Yeah. >> So what's the difference from your point of view in this context between delegation, pure delegation and authorization? Why why isn't it called for example uh WAC like verifiable authorization credential? >> Uh because I'm Australian and we use lazy language. >> No, good. I'm just I'm curious about your your thinking. I'm I pick delegated because again probably more bias of as I work very heavily on the AI side as well that is the natural thing which is I'm delegating authority to somebody else um um it's just language if I'm not wedded to it if it was you an authorization um you know I'll give you I'll give you a sentence and just see they both work right um Glenn has delegated scope to Martina for payments until December. Um Glenn has authorized uh scope of payments to Martina until December. Both work. I think it's just a question of which one >> I think maybe there there is a I I just feel I >> there is a slight difference. I mean delegation is more like it's your authorization in the first place, right? or or your task or whatever and you give that for a certain amount of time, maybe also only partially or 100% >> to someone else, maybe because you're on vacation, whatever. >> Um, and then you take it back and it's yours again, right? So, so I think there is a slight difference, but maybe the native speakers. >> That's that's you just nailed why >> you just nailed Martina, why delegation, I think, is the right word. And you may have noticed if anyone ever needs to that the diagrams I've been using since March. >> Why? >> Uh I was just sorry I was just I looked up the definitions and the definitions help that's what we should have used. >> Can I just briefly say because time is running out this then leads to the question do we need authorization as well or would delegation be enough? No, I'm not. >> Well, I think what we're calling authorization was what Brendan's actually talking about as the role credential. Um, I just put it in the chat, by the way, if you want to know what the difference is between the two. But, um, delegation is where I'm giving decision- making power to some other entity. You can you have autonomy to make decisions on my behalf. Uh, whereas authorization is you're allowed to do an action on my behalf. Um, and so that's maybe the simplest way of doing it. Um, >> yes, >> perfect. >> I also also agree with that one. Anyway, I was just going to point out in my diagrams explained DTG that the big aha is when you actually show um what we call the authorization uh the authorized delegation between a person and an agent or between a community and an agent. Um it works every time. And so anyway, that also that is the discussion the whole rest of the industry. I mean, Glenn, that was your whole point of saying, you know, they got internet of people, internet of agents. >> So, um, >> I was wondering when we were going to get to this point. I literally took a snapshot and just put it in my um my personal, okay, we finally got to that point. So, I I'm fine. Are we posing who are we saying let's do a PR to add that credential type? >> Yeah, I'm happy to I'm happy to raise the PR with it. and what the structure of the credential could look like. >> I agree. I just think there may be more discussions needed for the authorization part because I don't think it's just limited or defined by roles because it could just simply be access to your mailbox whatever >> or two. >> I was going to say there's the upside that yes, we finally tackled this. The downside that now we have to now we have to deal with a Tina um my AI agent is authorized to access my email but it is not delegated to send emails on my behalf. >> Yeah. Yeah. Yeah. Exactly. That's the difference between the two of them. But your your your AI agent doesn't need a specific role. It's not the role of mailbox >> um >> maintainer >> reviewer. Yeah. Reviewer >> or whatever. Right. It's just >> again it's a bleed over >> some entity >> of how our back works which is >> the role is the proxy for the authorization policy is basically what it's doing. >> So I and I know we're going to run out of uh time here but um Glenn the one thing about a delegation credential is that does that then require us to specify the delegation semantics? Um, is is that >> yeah, there'll be it is a little >> it's a more complicated credential for sure, but let me let me write it up and then this one absolutely needs to be reviewed quite heavily. >> Yeah. Okay. >> Um, but this one should go to the ZKP group. it should go to the wider uh community for discussion and for exactly what Martina said, you know, asking these types of questions, having people just think about what do the words even mean. I think the words in DTG are very critical to get right. >> Yes, absolutely. It's a martine all the way back to our glossery. >> Yeah. >> All right. Um Brendan, we didn't we were going to save time for you to uh um you know, give a a summary. or do you think you can? Um, >> yeah, I'll just I'll do what I can and of course anybody else here can jump in, you know, if I think I if they feel I missed something or uh misstated something, so I won't be offended if that happens, but I'll try to just give a little summary of where we're at. >> Okay, fantastic. Um, just a heads up, I'm just poll next week, I think, let let's plan on the following week we're going to be at GDC, a bunch of us. So, um I mean those who are not there are welcome to have it, but I don't think we're going to be able to um uh uh hold the call that week. Um yeah. Okay, fantastic. Um this is, you know, I think it's obvious now why we need these calls. Thank you again, Jeff, for uh um for that heads up. And Jeff, you're you're gonna are you going to kick off the the u uh creation of that the new repo? >> Yep, we'll take care of it. >> That is fantastic. you're an amazing set of folks to work with and I tell you we uh yeah I I'll I'll tell you more about the Malry experience uh uh on the call tomorrow. I will make sure I I will take the action item to set up the uh uh template for the agenda and as always anyone can edit it and we'll see you well some of you on the next two that's three straight hours of uh task force calls now on Tuesday mornings Seattle time. Um, so see some of you on those calls. Otherwise, see everyone tomorrow. >> All right. Thanks everyone. Have a good day. >> Thanks all. >> Bye everyone. Take care. Bye.