DTGWG Credentials Specification Task Force Meeting - 2026/09/15

Hello Jeff. Good morning. >> Hi Seran. We're always the early ones. Hello Jeff. Hello Sashan. >> Hello I'm wondering if anyone else is going to show up because Drummond's not coming. Martina just said she's not coming. Haven't heard anything Bren from Brendan or Alberto. though. >> Uh Brennan was >> Brennan was pinging on uh signal just before somewhere. >> Oh, he was okay. >> And hopefully he joins. >> Oh, yeah. That's true. Yeah. Yeah. Hour and a half ago. All right. >> How you doing, Sankan? Hanging out there? >> Yeah. How are you doing? Good enough, I guess. Been a busy day. That's good. Ping them. We're on the call if you're available. See if they show up. Ah, speak of the devil. There's Brendan. Hi everyone. >> Hey Brian. >> Okay, Alberta says he's joining too. Cool. So, should we have a merge party today, Brendan, and just merge all this stuff in? >> Do it. Do it. >> Sure. Yeah, I think there's a lot that's ready, right? So, >> yeah, it feels like it's it's there. There's a couple small things, but I mean I think I guess the question is is there anything we need to discuss or are we pretty much happy with all of our agents talking to each other and sorting things out at this point? [laughter and snorts] >> Yeah, I mean um I think it's worth just looking through them, you know, one more time, but uh I did, you know, use my own brain in addition to Claude. Yeah, that's a prerequisite for sure. Yeah. >> Alberto. >> Hey folks, >> I'm at least version six. >> [laughter] >> He's hallucinating again, everyone. [laughter] Okay. Uh, yeah. Sorry. So, do you guys want to talk through anything specific on the issues? I mean, Brendan, uh, I I think 47 is the biggie, getting the the statement credential done, and I I think there was like maybe one thing that was still I don't know, you had a couple questions in there. Do you feel like they were all answered or there was there any that you think is worth having a quick chat about before we dig before we say uh merge? >> Um, yeah, I think we had a couple back and forths. Um, it seemed like we were were aligned. Um, I'm just going to pull it up real quick to see if there's anything outstanding. I don't remember that there was. Um, >> okay. >> Take a peek. >> Just looking again real quick. Okay, there is yeah, there is one final comment um I didn't get to yet. Let me see. Um okay. Uh yeah, it was about this, you know, vocabulary that doesn't exist yet. Um, so I think your point sense there. Um, yeah. Yeah. I think it was a matter of, you know, uh, when to include something or not. And so, you know, we can always do another revision if we needed to. Uh, okay. >> I mean, are we happy with the concept of a separate registry for all these predicates and everything like that? I mean, I I assume we are, but I just wanted I think that's probably the the main thing to confirm because uh well, it's another repo that we have to create and then, you know, there's the whole where is this going to get hosted question and everything like that because we just have a placeholder URL at the moment. So, it's a fairly big decision, but I think I think it makes sense. But >> yeah, so is it >> Go ahead, Glenn. >> So just suggest anything that's going to be an open-ended registry follows something like what trust tasks did which um you kind of have codegen and a name space for it that's completely independent and then everything can go in there and then you have the cred separate to it which is what we did with trust task pulling the trust task spec out of its registry that's open-ended. >> Yeah. So, it just it adds uh the slight bit of complexity of another repo, but it it seems like yeah, it's needed for the reasons you're mentioning, Glenn. So, um I would support that. Uh the one thing I think I also saw from Drummond which came up with trust test also is um how do we support decentralization? Um, so is it that this repo is the only place that folks can um reference something, you know, reference a vocabulary or uh is it just, you know, the one that has community consensus? Uh, do you know what I mean? >> Yeah, it's the latter. It's the I would say it's the authority, but it doesn't have to be the only way that like you don't need to talk to it live. And I think that's the difference. So if you create codegen libraries, those libraries can be distributed and used and you don't need to be online to use it. Like you don't need to be online to look up the trust task specs for example. They're turned into code and works offline, online, peer-to-peer, it doesn't matter. And I think that should be a design goal. It's kind of one of the failings of JSON LD, right? was that some people tried to create it online and it just doesn't scale very well. >> Mhm. Yeah. I mean, that's a critical one, the online versus offline. Another one is just um uh do they all need to start, you know, with uh the URL of of you know, associated with that repo, right? Could somebody say, you know what, I'm just uh these these DTG working group folks, they're fascist and they're, you know, not supporting me. Um, so I need to just register this somewhere else. Um, do you know what I mean? So we're we're not blocking people from doing that either. >> The trust task becket calls that out saying you can it's actually recommended to do that for things that might be niche to a community. So you know keyring you want to have there are some key ring specific tasks that just don't make sense anywhere outside keyring then you should use a keyring URI for that. um you don't need to put that into trust. So again, you know, I just look at it as it's it's the authority of what is common, but it doesn't have to be 100% of what you base your own application and service on. >> Yeah. Yeah. I think that's the key part. So then yeah, I would I would support it then. So we're not blocking people from creating their niche or breakaway, you know, um vocabulary if needed. And we als but we do have a place where you know all the things that have community alignment um go. So um yeah I I think I feel good about this then. Anybody else have any hesitations or other thoughts on 47? >> Ju just just to follow through that point Brendan I'm presuming and Glenn uh I'm presuming these are composable so you could use the sort of wider community vocabulary and mix and match with other stuff. But it's you're you're not you're not just tying to one per se. >> Yeah, you can inject custom URIs at runtime or compile time into your code, >> but what's clear is that's your responsibility to do and you've got to manage >> of course >> your own [clears throat] name space. So best way think is just it's name space is actually what it is. And so trusts.org is the authorative namespace for anything that is a public trust task. But nothing stops Brendan creating, you know, brendan.org/ whatever tasks he may want to do. Uh, but it just means the trust task libraries won't recognize it. You're going to have to dual load Brendan's libraries and mix them together on your site. That's all. >> Okay, cool. All right, then. If we're happy with that, let me uh give it one more pass and make sure everything syncs together properly and then we'll aim to merge that. volume to merge that in today and get it get that one in. Um, >> and just for the record, I will, you know, just kind of say looks right to me since you kind of directed something at me on the the PR, but I won't be adding I won't be adding any content. Just sort of like a thumbs up basically. >> Okay. Yeah, we we do need one review uh in any or one like uh approval review in any case if you want to do that to Brandon. >> Okay. I hadn't done that yet. Okay. Yeah, sure. That makes sense. Okay. >> Purging is still blocked. It can be overridden, but it's better if we have a a thumbs up on it at least. >> Sure. Yeah, I'll do that. Mhm. >> Thanks. Um, I think number 50, the one that you put together, Glenn, should mostly fit on top of that, but I think there may be still a couple things outstanding. I don't know if you actually need to look at that one again and see if uh I had a comment on it about a couple things to fix. I'm happy to fix those if you agree. I can just update it directly uh and then stack it on top and then that thing about dropping V1. Drummond had a comment about having a V1 sort of as a not as as an absolute sort of path, but uh I'm trying to remember how he worded it. >> Yeah. >> Yeah. V1 normally it's locked in. So what I would suggest, Jeff, is let's keep 50 just in play until we get a working end to end flow and just see because I suspect >> Okay. >> There may be some things that change once we get it working. This is one that hasn't been used in the wild yet. >> Oh, no. It was It was you, Brendan. Wait. Oh, no. No, that's not it. Where was that? I just saw one from uh Drummond recently. >> I I agree on the V1, by the way. It should be a different number. >> Yeah, I have to find that comment because I think it was Drummond who was making the point that we should add it but not in it shouldn't be like part of the URL. It would just be uh tacked on with the hash at the end of it. You know the the pound sign, the tic tac for >> can't remember for that. >> It should be in the UR in the URI. I mean, that would be best practice for a lot of other things. There's big debates of where in the URI it should go, but uh it shouldn't shouldn't be a hash, especially because we have it starts to pollute what you may use the hash fragments for. >> Yeah, fragment. That was what I was that was the word I was trying to think of. Yeah. Okay. Because he had suggest I can't find it now. I know. I read it. It was tacked into an issue somewhere or one of the PRs. So, okay. All right. So, so leave at leave number 50 for now. Okay. >> Yeah. >> Um, just just cross referencing something. So, you know, we're uh I'm not sure if this relates to Drummond's uh comment, but you know, we're moving towards this semantic versioning. Um, uh, and I know that already shows up in your URLs, um, Glenn. >> Uh, would that kind of solve the problem? Uh, again, I'm not totally sure. I didn't see that comment from Drummond. uh you know putting that in the URL. >> Yeah, I just found it. I'll paste it in the chat. >> And normally for protocols there's a slight there's a slight difference with sever on protocols first doc. So docs you'll have major minor patch and patch could be things like a spelling mistake. But on a wire level you normally only have major minor. There's no there's no real sense in having a patch uh because a patch would be a minor change. Yes. Yeah, that that's makes sense. >> Yeah. So, I just recommend for wire protocols major.m minor for doc major minor patch. >> Mhm. Okay. Yeah, that that makes sense. >> But so that doesn't uh Okay. So, you put in his comment here. Let me just take a quick look at that. Um >> talking about using the fragment uh Drummond Mhm. Okay. So, it's like that it's too broad for the whole name space. Uh >> Okay. So, he's basically what he's proposing is that the version get linked to some particular vocabulary item rather than uh the >> Yeah. Okay. Um have you seen anything like that, Glenn? Did were you just saying that you you voted against that putting it as a fragment? >> Yeah, I would vote against I mean it's just it doesn't m I mean it's not a something I'd lose sleep over. It's more just a consistency thing. So most versioning in URIs either places it before the path. So it'll be something like namespace slashv1 slash and then the API path or it's namespace slashpath slash version right at the end and then you put whatever fragments you want um at the end because I would say a version is not a fragment. Um a version is a completely different URI in itself. Um, if over time you have a hundred versions, that's going to be a really messy fragmentation issue. >> So, yeah. >> So, what if what if we just flipped it um where it's not like DTG v1, but it's more like vocab1. >> Um, so we're not using a fragment, but we are moving the versioning, you know, down in the hierarchy. >> Yeah. Yeah. I you know trust tasks just use a slash and then it's the version number just major.m minor so you don't even need the v um >> yes >> very simple >> okay >> I can I can add a comment to that one um to that effect then um you know that we thinking it's not the fragment is the right place but yes we can move it further further in you know below the vocabulary item >> yeah I mean why not copy what trust test does already. So we have some consistency. >> Okay. So you're you are supporting that essentially that um a particular trust task has its own version Glenn. I haven't >> Yep. Now they have their own versions. >> Okay. So that that makes sense then. So should we just uh do it that way? any any reason not to. >> Okay. >> Um do you >> like that? Yeah. >> So this was uh this was is this a separate Oh, no. This is the the predicate um registry. Okay. >> Um I can put um I haven't uh reviewed this one yet. Um, but you know, after this conversation, I can put something simple on and just suggest that. Um, should I do that? >> Yeah, if you don't mind, that'd be great. >> Okay. Yep. I can take care of that. And then, um, >> I already I started the issue, Drummond commented, so it'd be good to get a third viewpoint in there with with the thought. So, >> okay, perfect. And so um and then just other folks have reviewed the the structure. I will too. Um but yeah, it just um we're moving this vocabulary to a new repo. So okay. Yeah, I think it's all seems pretty straightforward. >> Okay. Where that repo will live, we don't know yet, but Drummond has been in touch with some of the LFDT people already asking about this. So hopefully we'll get some an idea in the next few days. >> Great. >> Um, real quickly on the number 54 PR, uh, Brendan about semantic versioning for the document status. I I I approved it, but then I had an afterthought which I posted. Um, you know, are we really strictly following SEverse? So, we're going to be 0 whatever up until we actually say this is ready to be the official version one of the uh of the uh of the draft or how's that going to work? Because uh I'm I'm assuming that's that's the case, but we don't really say that in in the text. >> Yeah, I thought about that after the fact. um that could be a useful clarification for all of us is um yeah what what do we do when version one you know gets ratified by the by the the right group um then I didn't say it there and it probably deserves that clarification that the document status would then move to version one to match as well is that is that the idea >> I guess yeah it just it's I mean December generally breaking changes when you're version 0 whatever where you just bump the minor. The minor is actually a major break I guess or can be. So you can go 0.1.2 to 0.700 whatever until you finally think you have version 1.0 already. So I just was wondering I was assuming that was the case but it it didn't specifically say that but it does say server and that's how server works. So just wanted to double check. I think what's good is if you take SEV with uh like a status and again trust tasks has draft candidate standard retired. So it's always good to think if we get to a version one.0 and that is now the standard what happens when you start working on version two that would become a draft. So even though it's actually version 2.0.0 zero. Uh, you know, and you can in the patch you can do some clever things like use alpha numeric for release candidates, but effectively it would start as a draft and then candidate uh for as long as it needs to before it actually gets um promoted to a standard and then 1.0 actually goes into retired as a status. >> Okay. So when so it gets approved, it gets ratified let's say um we go to version 1.0 know and then we continue to work on it. Um we um you know because there might be for example a 1.1 eventually possibly um that gets ratified. So we would stay with one until we have something that's truly a breaking change or truly next generation. >> Okay. Um, so basically, yeah, it seems like it's it's just applying. We have these two things that need to stay linked, the version and the document status, and we're just saying um that they should stay in sync, which I agree, Jeff. I I need to say a little bit more about that. So, should I um should I do a revision to it um uh to to to address that uh for those three PRs? >> Um yeah, sure. or I can do it, but if probably makes sense if you did it since you started it already, but I'm happy to do it if you don't if you've got too many other things. >> Uh I can I can try to just take an hour and, you know, bang out these these uh few that need some comments and attention. So that's not bad. And then yeah, that leaves you to be clear to be an approver, you know. Um >> Okay, >> cool. >> Yeah, I just linked you on signal the versioning section of trust tasks that helps you Brendan just as a >> Okay. And if you if you have a better system, trust tasks can also change the other way. >> I'll try to Yeah, I think you're the furthest along and you've been implementing on top of it. So, I'll try to align with that. Um, unless there's, you know, a hard reason that comes up and then I'll let you know. But I I think that makes sense to use. >> Yeah. Yeah. I did do some research on what was the latest thinking of versioning numbers and there's no hard fast winner but version at the end was the preferred because you can do pattern matching a lot easier like you can just leave it off and say show me all versions for example whereas if you put versioning at the start it gets really hard to do the regex matching okay Yeah. Okay. All right. Well, that's good. I think that covers all the outstanding PR. Oh, yeah. I guess there's still the we've got that original number 18 for the trust task context binding and splitting that across with the VTI spec and everything. So, I guess um yeah, that one's still parked for the moment. >> Yeah, I can start splitting that one up and uh adding some PRs respectively. Bren and I have already talked about we're going to go through it. >> Okay. >> All right. >> Yeah, I think it should be now that we have the repos set up and thank you for creating the VTI scaffold, Glenn, then yeah, we can it should be relatively straightforward to split it out in a clean way. So, we'll we'll be retiring 18 soon and, you know, getting those replacements uh for the CRED and VTI uh out to you all. >> Okay. And don't be afraid if you need to make breaking changes to VTI spec, please do. It's like so early. you know if there's better structure sanction a lot of your guidance went into it but you know if you look at it as well and think there's better way to structure it you know I think it's useful to pull it apart put it back together a few times and see how it feels Alberto let's plan to do that both you know that uh we're going to do the PR18 split but let's take a look at the VTI spec back and just see if we have any thoughts on the structure since it's still early days and um yeah, it seemed like a good start, but we'll we'll give it some thoughts also. >> Yeah, sounds good. >> Okay, awesome. Um I guess the question next question is do we want to There's still quite that's all four PRs that have been hanging out. So, it sounds like we can wrap those up except for number 50 uh pretty pretty soon. But are there any of the issues or is there anything there that anybody wants to bring up or discuss or you know we can just chip away at them as and when it makes sense? I mean there's a couple things around the namespace and uh the repo which we're waiting on but uh anything else there that is uh beckoning a discussion or questions. I haven't had the the time to really review all the other open issues. Does someone feel like they they have a good handle on what's there and um you know want to suggest if there's priority um things surfacing there. The the only comment that I added was on 48 on the name space the one that you did Jeff about what context URL to use and whether or who would be you know basically controlling it or stewarding the the actual namespace URL from the context URL. I just added like perspective that we've been using just like a local context URL to resolve it. Uh, that's a cool one. Um, in terms of like which one to use, um, you know, we can go for either, but it seems like OpenBTC uses firstperson.net network as a namespace. So, um, I put there that, you know, uh, that's the one that makes sense. You know, who controls it and the stewardship of that, you know, I guess it's open for discussion, but uh, yeah, I just wanted to mention that one. Okay. Yeah. I mean, oh, go ahead, Glenn. >> In um first person network that's being retired, so it's I use that at the start because it's it's easy for me to search for and find, you know, the handwritten APIs before trust tasks came along. But that also frees it up if it wants to be reused for something else. So, the one we're supposed to be using is um >> I don't I think that's the problem is one hasn't been given yet. >> Yeah, I I I think Drummond was thinking that it should be something under the trust over IP name space somehow, but I mean that was basically parked under GitHub. So uh it's all hosted on Git I think I think they have a dedicated I yeah they have trustover.org or something like that and I think they have um the glossery for instance is hosted in GitHub but it trust uh glossery.trusttoverip.org resolves to the GitHub pages hosted version of the glossery. So I think he was thinking something similar like that, but uh that's why he reached out to the LFDT folks. >> Okay. So that's that's a part of what his uh followup with them was. Okay. Makes sense. And so on that >> Yes. Yes. I just you know [laughter] that's a little a little too much for me to uh track everything. Um uh but um so that's that sounds good. So then would we be doing again consistency wise would all of the um uh all of our specs be working the same way then? >> Yeah, I think so. >> Yeah. >> Okay. And so uh like right now there's trust.org. So you're saying that we'll be migrating to um something you know on the trust over IP uh domain for that. I I I would argue no. I think there's a case for what are protocols that we want to become kind of first class citizens like MCP and A2A are recognized in the industry as being there. And I think trust asks for a agnostic way of asking two parties to do something that can be traced and audited across any transport stands on its own two feet. But if there are kind of deeper protocols that are a little more niche, then potentially they can get parked under other name spaces. But I would always vote a domain name is cheap. Um they should stand on their own. Otherwise, you start it starts getting really confusing when you've got trust overip.org and then depending on what comes next can be wildly different protocols. Um as you go through this, it I just don't think it's that easy for people to remember. Whereas when we talk about trust tasks, you just remember it's trust.org. It's not trustover.orgask or you knowdtgrust taskvti something. >> Yeah. >> I'm I'm just seeing Sankers's comments in the chat. I'm just I'm am I reading that correctly? that he thinks that you think uh that's trust test is best left as is. Is that is that how I'm >> inter interpreting it? >> I think from a long-term implementation or adoption perspective, it makes sense to have trust tasks outside of trust over IP. >> Okay, great. >> Yeah, because I think it's also trust task is designed to be much bigger than trust over IP. Yeah, >> that's the other way I would look at it is if it's there to support trust over IP, then it can go in its name space. If it's something that is much bigger but includes trust over IP mechanism, it's okay to be in a namespace outside of it. >> Okay. >> What's the uh again just to ask questions that other people might ask, what's the governance of trustest.org? You know, if if it we don't have to change the domain name, but you know, how is that going to be uh managed? you know, in a way that feels open to people. >> Yeah. So, it sits under trust over IP. So, the governance of it is shifted under trust over IP, which is why we pulled the spec out. >> So, it's just it's it's Yeah, that's I think that's good to clarify. Keep the trustest.org for uh you know, clarity, simplicity, but the governance is trust over IP. Okay, perfect. Yeah, that that works for me. Okay, great. Well, is there anything else we should cover or do we want to call it early and get on with all the things we just said we were going to do? Uh, I'm happy to do either, but if there's any more questions, feel free. >> Uh, I added a review to 47 that unblocks it for you, Jeff, if you want to hit the magic green button. >> Okay, I will do soon. Yeah, I just want to look at it one more time. Make sure I didn't miss anything. Um, but >> I'll get my I I just because he addressed me, I'll get my comment and my review on there very soon also. So, uh, you should be good to go, Jeff. >> Great. Thank you, Brendan. >> When we hang up, I'll take a look at it one more time and just make sure I haven't missed anything. If I do, I'll put one more commit if with any small stuff that might need that might have been a an oversight, but I don't think it is at this point. The only thing I'd say, Jeff, is we should not be too worried while it's in draft state of >> Yeah. >> trying to keep the issues and PRs to a minimum as in as in actually close them out and get it so that you're looking at one dock and the AI is looking at one dock. Trying to keep context across four or five open PRs is really hard. >> I know. At this point, we can we can always go back and change the docs and draft spec. So, you know, I would >> I would encourage you be immersive merciless in killing off PRs. Um, >> yeah, >> we selforrect once we see them. >> I'm trying to I'm trying to do that, but I don't want to just be pressing the green button all the time. Uh, you know, without getting a bit of input from everyone else, but I I realize that Yeah. Okay. >> Yeah. Yeah. I wonder issue myself. Yeah, >> I agree that's a problem. Um I I don't know if there's a place where we can talk about our process, you know, so it's kind of clear to folks, but I agree it's good to just get things merged in. Um so we we already have one reviewer required, so um uh maybe when we just get that review, we just merge it in, you know. Um and I guess we also just maybe allow a couple days for folks to see it. Uh but yeah, we don't have to wait a long time. So I agree. It's good to get these things closed out quickly. >> Okay. So one reviewer and let it sit for maybe two days max before we just push it in. Merge it in and >> have people use their judgment. If it looks like it's active, keep it open. But if everyone's kind of like, yeah, >> sure. >> Yeah. >> Just merge it. When the cricket starts moving, we merge. >> If someone cares enough to hate what's there, then guess what? They can open a PR and correct it. It puts >> puts the ball in their court a little bit verse too many observers on the bus who want to poke holes but not take accountability to actually move it forward. >> Yeah. Yeah. And if it's great, Jeeoff, I just want to affirm, you know, if you're keeping an eye on that and and merging stuff in, I'm happy for you to, you know, uh for you to do that. Um >> Okay. >> And uh yeah, and so we can yeah, self-correct as we go, you know. >> Got it. Okay. Thanks for confirming that. That's good. I I'll feel less apprehensive about it now going forward. No, >> we it might be worth um a note in our our um signal chat with Drummond just to let him know cuz you know he might be nervous if he sees uh the pace of things. um uh you know as the steward. Uh but we we can I think yeah he'll he'll get it uh if we just explain the process we're going for and why >> the the AI noteaker that's recording this should hopefully have that captured in the minutes but if it doesn't I'll make sure it gets flagged up so that Drummond sees it. >> Awesome. Thank you. >> Hear that AI noteaker? Don't forget that. [laughter] >> Let's see if it works. >> You'd be creeped out if voice just said I got it. [laughter] >> Okay. Anything else? >> No. >> I think that's good. Thanks everybody. >> Awesome. Thank you everybody. >> Thanks everyone. >> Byebye.