Session Date/Time: 22 Jul 2026 14:00
[00:00:05] Hank: That was
[00:00:05] Brent Sundell: good. Better spicy than salty.
[00:00:08] Heather Flanagan: We'll we'll get to salty later.
[00:00:10] Hank: Yeah.
[00:00:11] Heather Flanagan: Alright. We are officially starting. If you're here for spice, that's good. If you are not here for spice, you're in the wrong room. But you're still welcome.
[00:00:21] Michael B. Jones: You're welcome.
[00:00:23] Heather Flanagan: I'm getting there. Stop taking my lines, people. As always, do mind the note well well. You at this point, you have probably seen it several times. If you have any questions about it or how it applies, please read the documents first and then come ask us questions. That's what we're here for among other things. If you are in the room, do make sure that you have signed into the session on the data tracker as I'm sure you have been informed that that tells the secretariat kinda how big a room that they need to give us. In the past, they put us in the largest auditorium in the entire venue, and that was crazy pants. Oh, so please do do sign in. Use Meet Echo Lite so that we don't get the weird echoes. See what I did there? And otherwise, keep your audio and video off. For remote participants, hi. We're glad you dialed in. Also, make sure your audio and video are off unless you are actually talking. If you're chairing, I'm very confused. Okay. Scribes. Do I have any scribes for today? Echibot. Are we using Echibot?
[00:01:43] Roman Danyliw: It's gotten better. We got PHP as well.
[00:01:45] Heather Flanagan: Oh, PHP.
[00:01:46] Martin Vigoureux: Thank you.
[00:01:47] Heather Flanagan: Thank you. Okay. Our agenda is we we shifted it around and I sent that to the list. It's all the same topics. They're just in different orders so that we could get the right people in the room at the right time. We are gonna start with glue. Then we're gonna talk about our charter, which has sort of been stuck in Never Never Land for a very long time, and we would like to fix that. Then we're going to get a quick status update on SD-CWT. This is missing the quick update on OpenID Connect, COT. That is on there. That comes right after, SD-CWT. And then we're gonna do a call for adoption discussion on the architecture draft, which is in our charter one way or the other, so we should talk about that.
[00:02:32] Roman Danyliw: I apologize. I have not yet logged in to put myself on the queue. If you would like me to participate in the charter status discussion, I can't do it an hour from now. I have, like, the first half hour. I apologize.
[00:02:43] Heather Flanagan: Okay. Switch order?
[00:02:49] Martin Vigoureux: Yeah. Let's get the charter app.
[00:02:50] Heather Flanagan: Okay. Let's start with the charter conversation. We can be flexible. Excellent. Let's see. Was there anything else here? Nope. At this point, is anyone completely new to the spice world? Cool. Then what we're working on is digital credentials and presentations.
[00:03:10] Ted Hardie: Sorry. They asked me to come and talk about the URI thing, which moved first for that. I'm gonna go to quick, but if somebody could just ping me when you're ready for the URI, I'll be
[00:03:19] Martin Vigoureux: Should be should be quick, Bob.
[00:03:21] Heather Flanagan: No. He'll be quick. I
[00:03:24] Martin Vigoureux: didn't even think about that.
[00:03:28] Heather Flanagan: So, yeah, we're basically talking about digital credentials here more than anything else. We coordinate with several other working groups. Many of which, if you're in the identity space, you've probably been going to these all week or will be very soon. Rats, OAuth, Jose, Cose, Skit, and Whimsy. There are some things that are out of scope at the moment, and that is general key discovery and, cryptographic primitives. We do not need to roll our own crypto. That is bad. Don't do it. We have various working group resources. Of course, we've got a mailing list. We also have a pretty active Slack environment, on the IETF, so do feel free to use that. We have a GitHub repo. We have a website in case you find the data tracker difficult to follow. With that, let me switch over to charter slides. Charter. Confirm. Check. Okay. So our charter has been blocked for a bit primarily because there's been some questions about the the scope. Where if we say, as the current PR says that we're looking at data structures useful for commerce and trade, That feels like it might be a little large and that might be a little concerning. Where does it stop? Where is the where is the what what actually gets excluded when you talk about that? So there's a couple of ideas of how we can handle this. There's been many hallway conversations this week about how can we actually tighten up the scope such that we can get done what we want to get done while still actually being a useful contributing member of society. With those hallway conversations have we actually have proposed text. I want to thank Frohan and Mike and several others for hashing that out. It was very helpful. And this is what the proposed text looks like. Most of you have not seen it so I shall pause to let you read. I love how we're all of a certain age such that I can tell when you're reading because you're all squinting. Alright. With that, let's open the queue and discuss. Justin.
[00:06:18] Justin Richer: Hi. Justin Richard. Just to clarify, this text is additive to the charter text and not replacing? Or is it replacing?
[00:06:27] Heather Flanagan: It is going to I
[00:06:30] Justin Richer: It's additive?
[00:06:31] Heather Flanagan: It's replacing a bullet.
[00:06:32] Justin Richer: It's replacing a bullet. Okay.
[00:06:34] Brent Sundell: Yes. Thank you.
[00:06:38] Heather Flanagan: Oops. Hang on. I'm trying to make this do the thing. Michael.
[00:06:43] Michael Richardson: The the last paragraph, Michael Richardson, Mike. So does that imply that it also could just go through a human who types stall in again in a new format? Like, it says adapt and it's like machine readable, like, you know, date formats you're talking about. But does that mean that's the the far end of adapt or the beginning of adapt?
[00:07:08] Heather Flanagan: And I'm going to look to Rohan. Could you?
[00:07:11] Rohan Mahy: Hi. I wrote that. I just wanted to make sure, for example, like, if we looked at some spec that said, here are a bunch of here are a bunch of semantics for how you do, you know, like, waybills or something. And there's a date field in there or a you know, there's some identifier
[00:07:29] Brent Sundell: Fair enough.
[00:07:30] Rohan Mahy: That that we can we can make it sort of consistent with the kinds of things that we do in CWTs. And we don't have to leave it exactly the same that, you know, like an ISO, you know, whatever text data stream.
[00:07:45] Michael Richardson: Move on from dates. What else? What else are you thinking about? That's all?
[00:07:49] Rohan Mahy: I'm just thinking of things where there's, like, a one to one, like, I can take this thing and I can convert it to this other format that's consistent with conventions that we use.
[00:07:58] Michael Richardson: I I have no problem with that. I'm just trying to understand. I was trying to understand if it was if it was inclusive or prescriptively, this is all we're doing.
[00:08:09] Rohan Mahy: I think the prescriptive part was automatic machine conversion capable.
[00:08:14] Brent Sundell: K.
[00:08:19] Heather Flanagan: Other questions, comments? Okay. I'm good. I'm Roman, do you wanna be in queue? Or okay. Brent? Okay.
[00:08:39] Brent Sundell: Brent Sundell. I just queued to say I'm supportive of this textual change.
[00:08:45] Heather Flanagan: Thank you. Roman?
[00:08:47] Roman Danyliw: I'm I'm just trying to understand the proposed workflow here. So the business of spices to go hunt of of other people other people's verticals, other people's kind of tokens, and then register them for those verticals for a registry that's already specification required. Okay. Then I'm misunderstanding. And then I in that misunderstanding, identifiers is different than claims, though. Right? So we're not just adding to the CWT and the JWT registries. It's now we're gonna do identifiers.
[00:09:29] Martin Vigoureux: And what are those? Good
[00:09:33] Heather Flanagan: question. Mike, you wanna get that one?
[00:09:44] Michael B. Jones: Hi, Roman. I'm the one who put the identifiers word in. The reason it's there, again, trying to preempt future charter problems. The glue specification, which we'll talk about shortly, creates a bunch of identifiers. It does not, which will probably be claim values. But it does not create specific claims in which those identifiers will live. And specs will do that, protocols will do that. But I didn't want it to be the case that because that spec was defining claim values without the associated claim that it could be somehow construed to be out of scope. Does that make sense?
[00:10:53] Heather Flanagan: Yeah. Ori, do you wanna add some clarifications here?
[00:11:01] Ori Steele: Ori Steele. So there are a couple claims we see in JWTs and CWTs claim names, like issuer and subject. In the RFCs that define these claim names, they're listed as string or URI. That's, like, the space. So, like, any string or any URI could fit into those particular locations. I think the intention behind the Glue document is to create an identifier that could fit into those locations to be useful. This other OpenID Connect document that the working group had looked at also looks at, you know, a claim names that could carry similar identifiers, you know, same kind of stuff. So the business of, you know, JWTs and CWTs is finding ways to define and specify attributes that can be bound into these kinds of identifiers so that you can have demonstrating proof of possession and these other kind of credential use cases around them. I think in the context of the text we see here, like, the the goal should be to enable useful attributes to be specified for credentials consistently for for JOSE and COSE. Like, the OpenID Connect document that we saw before is a good example of that, you know, alignment between claim values and claim names across both JOSE and COSE. So that's kind of like the in terms of the mission, like, you got you're getting at, like, know, what's our business at Spice? Our I think our mission is to do credentials well for JOSE and COSE and to enable consistent use of digital credentials for JOSE and COSE. That's I don't know if it helps, but that's that's my view. Roman?
[00:12:40] Rohan Mahy: There was a lot there. Sure can turn my
[00:12:42] Roman Danyliw: original question. We're all doing, like, real time adjudication of of a ballot here. Yeah. I I think part of what I'm coming to is I'm trying to get my head wrapped around. Have we rapidly expand the entire scope of the working group, or is this this narrow thing? So I guess maybe my I am I'm very appreciative of this text. It's an attempt to unpack trade and commerce. I guess maybe the I'll start with maybe a different question that will help me kinda internalize everything that's happening here. Do we really just have the Glue document and one more document and then we're one and done? Or are we unpacking the scope of the working group now to cover managing the claims of all of these other workflows, all of these other use cases, all these other documents for what is, again, what I have asserted specification required registry that anyone can come to without even having to come to the working group. But there's something novel about what we're doing here at the ITF that we gotta run everyone else's claims kind of through this process. And so maybe you can kind of help orient me the novelty of what we're doing and, again, and why it's not one and done.
[00:13:47] Heather Flanagan: Okay. Rohan, do you wanna step up?
[00:13:51] Rohan Mahy: Yeah. Sure. So this is this is related. It's not directly in response, but, like, I was gonna say that so, specifically, we've got we have claims that's like, are for human credentials. All of these already exist in the JWT. In the JWT registry, they were registered by OIDC. So the semantics come from there. But we're just registering them so that we can use them in CWTs, so that we can have useful human identifiers with some stuff. So if somebody comes and we're not trying to boil the ocean with human identifiers. We're like, hey, here's a set that already exists that's pretty reasonable. Now you can use human identifiers inside of SCCOTS or inside of CWTs. An example of the supply chain, transportation, whatever, those we've got a traceability Internet draft, which which uses the features of selective disclosure. But in order for us to be able to actually show anything useful, we need to be able to show how to build the kinds of documents that people would build, like shipping manifests or waybills or things like that. And we don't need to invent the semantics of those things. Those semantics already exist in their three organizations that have all the pieces that we would need in order to actually be able to represent those things. But the way we represent them is is significant because we would be doing it in a cot and not in their native format. So we need we need a way to represent those things inside of the, you know, inside of the web token interface web token ecosystem of the ITEF.
[00:15:41] Roman Danyliw: Right. I guess my internalization of that is, again, we're now in the business. And I'm just checking here. I'm not saying that that's not a reasonable scope. We're doing claims for everyone else's verticals here. So we made the container, and now you roll all all people's verticals roll through us to kinda get them documented to the degree that someone comes with it. And so what this scope would allow is we don't have to ask again if I'm trying to think of some, like, completely unimaginable. Yeah. Okay. So if the health care industry said, we're already clear because we will run all their claims through regardless of whether we have kind of the expertise because this is the working group that if you wanna encode in in in CWTs, like, you get your claims approved here at the ITF based on that scope. Yeah.
[00:16:24] Rohan Mahy: No. I think we need an existence proof for how people go and go about doing that kind of transformation. Okay. And if we don't do one, then nobody's gonna figure out how to do it without a a whole lot of help from us. We're hiring Mike. So I'm hearing
[00:16:38] Roman Danyliw: I'm hearing no, but from the can I get the chair's perspective? Because I feel like you're reacting somewhere kind of in the middle of here.
[00:16:43] Martin Vigoureux: I'm gonna hit my mic.
[00:16:45] Michael B. Jones: Speak and then let the the chair chair speak. Speak. So, it's not that we're going to mine the world for stuff that we might register. It's that working group members have use cases for registering specific things that they do have expertise for. And the good news is in the ITF, have call for adoption in the working group last call. And I sincerely hope that nothing gets adopted where we don't have the expertise to do it. I think that's a reasonable check and balance, right? This language is written though in such a way that we know of three cases where this working group has already decided to register stuff or to ask for registration of stuff that's useful that already exists. So, it's not just one document. The OpenID Connect claims document is one like ProRox traceability claims is another, for instance. I mean, Ori and Mike are experts in supply chain. So, Rohan is too. So, that's reasonable for us to decide to do if we get it adopted. So, this language is written in a general way. I think the check and balance is working group adoption of spec.
[00:18:22] Heather Flanagan: Ori?
[00:18:26] Ori Steele: So at the risk of making things worse by offering a narrower scope, I think traceability claims document that exists right now is the kind of document that even if the charter said you can do this this specific draft document, the working group could spend a lot of time on that individual document. Supply chain traceability just by itself can be a very deep well of very deep water. So I I think just to make the position clear, put it to the chat. You know? I'm totally comfortable with charter text that's like these specific drafts on these specific claim names. Like, I have no problem, like, ratcheting it all the way down to specifics and getting even more narrow than this, but this text is also fine with me. Thanks.
[00:19:17] Heather Flanagan: Okay. So from my perspective, and hopefully Martin will tell me if he disagrees, I think what we're doing here is we're we're we aren't going to boil the ocean. We are actually narrowing things down and to say this this is this is the space that we're going to play in. I don't see us. At this point, we have no other drafts expected. No one's even talked about other drafts than what we have in place. The the as I said, the traceability claims, the OpenID Connect CWTs, the SD CWTs. Last thing that was in our charter is the architecture document and GLUE. That's it. Once we get those done, I'm really looking forward to closing the group.
[00:20:03] Martin Vigoureux: Yes. Definitely. So
[00:20:07] Roman Danyliw: I'm sorry. I don't know how to internalize that because if the answer is this is I this is where I feel I got a got a confusing direction. If the answer is it's just those two documents, I had the proposal, like, let's write a charter that says these two documents are in scope, and I heard then we close. But then I heard from the floor that that is absolutely not the aspiration. And the reason maybe I'm pedantically pushing on it a little bit is because we got to we cleared last call. We got to the ISG Telechat, and we just noticed that this wasn't at at a scope, and I'd love to prevent that from happening. But I don't want the answer to be that we make something extremely kinda wide, which is why I'm kind of exploring what the expected bounds are here.
[00:20:44] Martin Vigoureux: Yeah. So I'd like to hear from people whether they they think that it's acceptable or not to to simply list the drafts that we have currently considered as, and use them to set the scope here. That may be, I think that may be simpler than all this as well.
[00:21:04] Heather Flanagan: Hank?
[00:21:04] Hank: Did I press the button? Am I in the queue?
[00:21:06] Heather Flanagan: You're in the queue.
[00:21:07] Hank: Excellent. Yes. I didn't forget. Sorry. Hi. This is Hank, not surprisingly now. And so I was planning adding more drafts to the working group, and I'm very surprised to hear that we're closing. Sorry. I'm sad now.
[00:21:22] Martin Vigoureux: You can always ask for a recharter.
[00:21:24] Hank: Oh, okay. Let's do that.
[00:21:27] Martin Vigoureux: Get get us the drafts first.
[00:21:29] Ori Steele: That's yeah. I'm hi. I'm Ori. That's what we're doing right now, Hank. I mean, if you have the drafts now, tell the chairs we'll we can propose them as charter text. If you don't have the drafts right now, let's put the ones that we have right now, and then when we finish them, we can bring more.
[00:21:45] Heather Flanagan: And return.
[00:21:46] Hank: Exactly. I think the second item that he brought up is the cool one. When we have them as zero zero, we will bring them forward. If we have to need to recharter, again, sure. If you have the time, or we make a charter that will accommodate a little bit more space, I think both is an option. Whatever you want.
[00:22:07] Heather Flanagan: That was kind of the question. Yes. Whether we want to actually specifically list them or be general and allow flexibility here.
[00:22:15] Roman Danyliw: To be clear, I should have said I actually have two discussed positions. The top bullet would address the first one, which was, you know, what do you mean by these other CWD claims?
[00:22:24] Rohan Mahy: Yep. That
[00:22:27] Heather Flanagan: was Hank. Brent.
[00:22:30] Brent Sundell: Brent Sundell. From my perspective, I would prefer if it ends up being acceptable, a more general charter that allows us to add things that fit. Because in spite of assurances that rechartering is painless, this hasn't been. So
[00:22:55] Heather Flanagan: Okay. Other thoughts, feedback? Fifty fifty.
[00:23:03] Martin Vigoureux: Yeah. I think that was that was that was too close. I think we might need to go to a show of hands here, whether you want the general of a of a specific one, understanding that the safeguards in place on a more general one would be in line with what Mike suggested, which is we're not going to take it if we don't think it's acceptable, and we'll get sick of taking things and we'll finally cut things off, I imagine. Or we we tighten things up and go to go to a recharter if we find that there aren't additional things like like what Hank is maybe suggesting he he does. I see some IES team members discussing heatedly on the floor, which suggests that maybe that's premature, but I'll put that in the show of hands while Brent and Ron give us their thoughts.
[00:23:58] Brent Sundell: I I I will answer whatever show of hands the chairs put forth, but would recommend just asking whether the proposed text is okay or not rather than making it a general versus specific. But however the chairs wanna go was fine as well. Just
[00:24:16] Rohan Mahy: I was gonna say, if we if we think that we that we're okay with just a list of drafts and we think that this is gonna cause increased friction, then I would rather go with a list of drafts. But if people are already okay with this, that's you know, I'm fine with that too. I wrote it after all.
[00:24:46] Heather Flanagan: Okay. So the question is, I guess.
[00:24:52] Martin Vigoureux: On the screen.
[00:24:53] Heather Flanagan: On the screen. You go. It's a poll. Well done.
[00:25:15] Martin Vigoureux: I wanna be able to write in the answers. What's it doing?
[00:25:21] Rohan Mahy: But there's no way to actually select any of the options.
[00:25:25] Ted Hardie: Go to text.
[00:25:25] Martin Vigoureux: Because it's too Did I make
[00:25:27] Rohan Mahy: Because there's too much text. Scroll. No. It it won't window is the It doesn't scroll. It's like it's like four pixels tall.
[00:25:37] Martin Vigoureux: Alright. What how would you like me to vote, Rowan? Come on. Poke poke
[00:25:39] Ori Steele: on the screen.
[00:25:41] Martin Vigoureux: You can you can use my vote. Okay. Yes. At the top there.
[00:25:49] Heather Flanagan: Alright. There I mean, there are 54 participants right now. I suspect we can get a few more votes to help make this clear.
[00:25:57] Martin Vigoureux: I think it's pretty clear right now. Just
[00:26:02] Heather Flanagan: making sure everybody feels heard. Are we good? Okay. Apparently, we want we want the general text.
[00:26:15] Martin Vigoureux: It's not the same as the IDs being happy with it. What what do we think from the floor? You you're comfortable with that?
[00:26:21] Roman Danyliw: I mean, it's helpful for the work. It is very helpful to see the working group signal that we, in fact, believe there is more work to do, which is why there's a generalization versus this answers this back and forth. Is there more work, not more work, which I think is very, very helpful. So I appreciate that from the working
[00:26:40] Heather Flanagan: group. Okay. Okay. I think at this point, we perhaps create the PR and see what happens. Yeah. Yeah. Rohan?
[00:26:54] Rohan Mahy: Okay. So we've we've gotten pretty clear, like, this is our first choice. Do we wanna can we do a, like, a quick poll? If this doesn't work, are you okay if we go with, here's a list of four drafts? Yes.
[00:27:08] Martin Vigoureux: No? Okay. Okay.
[00:27:17] Heather Flanagan: I don't think we have anything else for the charter right now.
[00:27:22] Martin Vigoureux: Okay. I'll invoke the
[00:27:24] Heather Flanagan: Yes. So we are going to we're going to invoke the TED. He'll be back from quick in just a second. Let me get the GLUE slides up. Confirm. Awesome. While we're waiting for him to come in, I'm not looking at you, Brent. I'm actually looking through you to Chris. Chris, do you do you own the the the p the basically, the CharterText and PR at this point?
[00:27:57] Rohan Mahy: Yes.
[00:27:57] Heather Flanagan: Okay.
[00:27:57] Rohan Mahy: I
[00:27:58] Heather Flanagan: do. I just wanted to verify.
[00:27:59] Rohan Mahy: There's you've had a lot of, direct communication with Roman often via Slack, so I haven't been doing updates. I've been waiting for some feedback collectively.
[00:28:13] Heather Flanagan: Okay. Thank you. Alright. Where is the where is the thing? What did I say? Forty minutes. Okay. Brent, I think you are presenting. Yes. He's right there. I'm gonna put twenty minutes for this, and then we'll have twenty minutes for discussion if you need that much time. Hey,
[00:28:42] Brent Sundell: everybody. If you remember Glue going to working group last call and moving on, your memory is not faulty. Just assuring everyone that your sanity is in place. And, yes, we are talking about it again. This is what we're gonna talk about today. And next slide, please. Why did we make GLUE? We we need to issue digital verifiable credentials about organizations. And while some of those organizations have identifiers, the overwhelming majority of those identifiers are not in any sort of globally recognized digital format. There are hundreds of millions of organizations in the world, most of which are identified by some local authority. And then businesses who receive these digital artifacts about those authorities have no way to determine what this identifier means. And so we are hoping with Glue very simply to add a prefix that enables a bit of additional metadata to be provided along with the the identifier. Most of the data models that are calling for organizational identifiers as values expect a string or URI with URI being preferred. And so that's the direction we headed with this draft. Next slide, please. So, for example, if there were an identifier that looked like this and it just showed up in a document, if you were to append the Glue namespace and, metadata for it, it would be clear that, oh, this is a Glue identifier, specifically, IRS EIN number, assuming that was registered in the Glue registry, and then the identifier itself. So it adds this explicit context to business identifiers so that as they are stored and as they shift over time, the identifier that was used can remain identifiable. And yeah. Next slide, please. During review of the registration, as we so if you remember, last time we went to submit this, it was we were going with we were all in on URNs. That was advice we had gotten, and that's how we formatted it. And, the question came up quite repeatedly, why GLUE at all? There's an LEI URL already. There's gonna be GS one URLs. Don't those cover this? And, the answer is no. They don't. If they did, we wouldn't be trying to do this. Like, I know what LEIs are, and I know what GS one identifiers are. And if they were sufficient, I wouldn't feel strongly that we need to do this other thing. So short answer, no. Longer answer is the expectation that authorities for identifiers be expected to I said expected too many times there. Apologies. The expectation that these authority that these identifier authorities would register their own URN schemes falls apart in a couple of different directions. First, there are hundreds and hundreds of them. And if we needed to wait for every single one of them to register themselves before we could make use of their identifiers in these patterns, it it would be a very long time before that was actually reasonable. And then the second place, it's literally impossible for some of them because they don't exist anymore. The organizational for example, the organizational authorities that registered organizations in The USSR and Yugoslavia, those those those guys aren't around. They're not gonna be stepping up to register their own URN schemes. Organizations and mandates come and go. And when they go, we want to still know what they were, and GLUE would help us to do that. And for those that have gone and yet someone knows what they were, GLUE would help us to be able to continue to identify those. And this would work across changes of business so that a business that is one day has one name and one identifier after it's merged with another, you still want to be able to trace the generation of the the evolution of that organization over time, and that requires pointing to different identifiers at different points of time. So yeah. Next slide, please. So since IETF one twenty four, we passed we finished working group last call. Thank you for those who reviewed the draft and gave your thumbs up. They went to the IESG, and I think the phrase past IESG review is accurate. They looked at it and said, yes. We should publish this. This looks good. And then, it got a little stuck on the URN registration. The designated experts for the URN registry said, this doesn't feel like a URN to us. There are certain qualities that a URN has that don't seem to apply here. And I'm not gonna try to recreate their arguments. I I honestly trust their expertise. They are the ones who are in charge of the URN registry. They know what makes a good URN. They said this doesn't quite fit. Perhaps it might be better to seek registration as a URI. And you may remember we came back briefly to this group and said, hey. If we went from URI into URI, would anybody be upset with that? And nobody said that they would. So we began that process. And then the URI folks said, are you sure this shouldn't be a URN? And we said, you know,
[00:35:41] Rohan Mahy: you tell us.
[00:35:42] Brent Sundell: We just need an identifier, and we would like it to be of the family of things. We think IANA is a really great registry system and that it's kind of globally available and noncommercial and has all of these benefits of that we think are kind of vital to Glue being a functional identifier. I think after thinking deeply about this with my coauthors, I think URI makes the most sense at this point, you know, noting that but but then again, I'm not an expert in either of those areas. I have a little bit of supply chain expertise. I've got some identifier expertise, but not URI or URN specific stuff. So I think the ask for folks is what makes sense to you if you happen to have URI or URI expertise? I would love to hear from you. I think we all would benefit from that. I think that's pretty much the conversation at this point, but let's wrap up the slides real quick because I think they'll wrap themselves rather quickly. So next steps, this is what are we gonna do next. Let's let's talk about that.
[00:37:08] Heather Flanagan: Okay. Great. Ted, you're first in queue.
[00:37:17] Ted Hardie: Ted Hardy. I happen to be involved in in both of those conversations, and I wear a nice bright shirt so you can throw things at me easily. I agreed with Peter Saint Andre, who is the UN lean reviewer, that this didn't qualify as a URN because some of the subnamespaces did not provide the guarantees of uniqueness which are required for URNs. And that's a consequence of how the URN definitions are made, that urine's have a very specific set of characteristics and uniqueness over time is one of them. So you can never reassign anything that's been a urine at any at any point. And so I I was actually the one who suggested that you seek a URI registration instead, because we have done this before. Roy Fielding and I disagree somewhat on how philosophically, on how URIs are constructed. And Roy's perspective is that you don't mint URI schemes when you can do something else. And his perspective is, if you could use something that's different within the existing URI scheme, that you should do that. An example here might be, you have a registry. It has a set of registered organizations in it. You have a URI, like an HTTPS URI, which points to the registry entry that registered that, and then have that and the identifier as a tuple. You put that in JSON, and you are done. So from his perspective, that is the right thing to do. It's a very principal perspective. He's held it for a very long time. The reality is people have minted URI schemes of this type in the past. I am pointing you in specifically today to RFC forty four fifty two, which is the registered URI scheme info. It was registered by the OCLC, which is the library organization on behalf of NISA. It does exactly what you're doing. It does exactly what you're doing in that it lists a set of external authorities, and provides, in this case, XML entries for each one of them to allow you to create identifiers for them. I will, however, warn you, and it's a pretty strong warning, that they failed utterly and very quickly. Despite having years of experience as librarians, this registry failed within four years. And the reason it failed is, one, it was disconnected from the actual resources, and that was a huge problem. Looking at what you're trying to do, I think you're gonna have the same problem. If you are not having the organizations do the registrations for themselves, you have the risk that it will get divorced from their actual practice in assigning the the identifiers, and worse, you will have collisions. I noticed you had IRS up there. IRS happens to be the tax authority of The United States. As a resident of Portugal and a tax dependent person of The United States, I have noticed that there is a collision, in that both countries use IRS for their tax authority, and that I have an IRS number from each one of them that's distinctly formatted. But if somebody had simply registered IRS as the tax form tax authority in some registry some somewhere for The US and didn't notice Portugal at the same time, you would have a problem. Given the in the modern world for acronyms and small letter numbers, the chances that you don't have collisions in the organizational representations is very, very, very, very small. So you want a registry that contains hundreds or thousands of organizations, some of which are only registered locally. You don't want to involve them in the registration, and you you want to construct tuples that, at the end of the day, derive a uniqueness. I I don't think the URI is your problem. You can do a URI. The info URI can do it. Heck, you could make a tuple and shove it in a data URI and be done. You'd have to do a little base 64 encoding, but what's that between friends? I think your actual problem is the registry, because the registration procedures that you're describing to me do not seem to result in the uniqueness of the identifiers that you tell me you require. Now I have never been in Bolden Spice. This is my first working group meeting of it, and I got called out of another room to come and talk to you. So the chances that I don't understand what's going on is very, very high. But just from what I've heard today, I think you actually have a different problem. And once you work through that problem, set up the registry with Diana. Work through the registry process. Figure out, get that right, and then talk to yourselves about what the serialization looks like. That might be a tuple. It might be a reference to the IANA registry. It might be something else. It might be a URI at the end of the day, and it may be that with IANA running it instead of NiceO, it will succeed. But there are a lot of problems in the range of things you're hoping to get done, given the number of organizations you hope to involve. And it's especially troubling in that, from what I understand, several of the ones that were early targets for this scheme, whether it was a URN or a URI, said, wait, no, don't. Take us out. And if you have a situation where you do these registrations and then people ask you to remove them, you will lose one of the critical properties you're you're looking for, which is the continuity. Because you want these identifiers to be a point of continuity in the supply chain over time. And if somebody says, take this out because I'm giving this other thing to you, you're gonna have some of them that are registered with the old deprecated thing, some of them which are registered with the new thing, and you're not going to
[00:43:19] Rohan Mahy: get
[00:43:19] Ted Hardie: the properties of the system that I believe you want. But again, I'm a total newbie. I'm I'm being totally wrong. So I'm gonna continue to stand here for you to throw things at me or ask questions or whatever you like. But when Heather and and Martin asked me to come, when I looked at this, that's that's my impression.
[00:43:43] Heather Flanagan: Okay. We've got three people in queue. Philip?
[00:43:53] Ted Hardie: Yeah. I was trying to summarize what Ted said. I'm just thinking
[00:43:58] Phillip Hallam-Baker: too hard about it, so it's not yeah. I I've been doing URNs a long time, and I think it's basically bullshit. The distance between you are you just got identifiers. The reason you're not gonna get those properties of uniqueness is it's impossible. Just don't worry. Things will break. Things won't work as well as you wanted to. But all that really matters is you slap a label on them. It doesn't need to be perfect. Having two identifiers is okay because what is really, really bad is no identifier at
[00:44:43] Rohan Mahy: all. Yep.
[00:44:45] Phillip Hallam-Baker: And just throwing a stick in the sand, that's fine. They don't need to be labeled with a URN at the front. They're all just you know, that was the worst idea that we that happened. I really, really dislike the fact that that.
[00:45:04] Rohan Mahy: Well, there's a a structural problem, which is that the syntax requires a URI. It's that's not because we wanted that. It's because the syntax that we're using requires it.
[00:45:16] Phillip Hallam-Baker: Yeah. I'm I'm okay with requiring URI, but I've never believed that, URLs are a special type of identifier. We use URLs as identifiers and did so from as URLs and did so from day one.
[00:45:33] Heather Flanagan: Okay. Thank you. Pam?
[00:45:39] Pamela Dingle: Hello, Pamela Dingle. Thank you for all of the opinions. I'm one of the co editors along with Mike and Brent. I I mean, I'm really glad that both of those comments were made. You know, with respect to continuity over time, we can't have continuity over time. It's literally impossible, and the obvious counterexample here is regardless of whether it's a scheme or a URN, if we assume that pets.com is embedded in a URN and a product was made before the .com boom, and then pets.com changed hands. That identifier has already been written into how many manifests historically it exists. Pets.com, as I understand it, is now a totally different business with totally different identifiers, and we have to have a way for the URI or URN that contains pets.com to be distinguishable from each other. They will never there is no continuity over time because businesses change over time. The identifiers have to exist. They have to be distinguishable from each other to enough of a degree that a forensic examination can happen, but they do not have to be perfectly, exactly distinct in a technical way to be successful. So hope hopefully, that helps. Right? I I I'm not saying that that's the reason to choose one of these things or another, but only that we're not working in a world that's sliced and diced over all of you know, we need the tuple of the time and the geographic location and and, you know, the fact that there's collisions is inevitable in about 10 different ways.
[00:47:37] Heather Flanagan: Mike?
[00:47:40] Michael B. Jones: Yeah. Quickly, I will observe that Roy Fielding also made the point that Philip made is the world's messy. We need identifiers. Sometimes things will break, but having identifiers is better than not. Now, Roy said some other things too and that's fine. As an author and as an observer of where we are in the IETF process, as Brent said, we finished working group last call. We went back to the working group and asked if it was okay to make a change. We made the change. We've completed IESG review. We've completed IETF last call before that. There's a draft which is currently in review by the URI scheme experts. And I think the right thing to do at this point as a working group is to ask the URI scheme experts to complete their review and hopefully do the registration and then we're done. Thank you.
[00:48:53] Heather Flanagan: K. Other thoughts, comments, feedback? Queue?
[00:48:59] Brent Sundell: I I do have a question for our AD. If, you know, looking at the document and the changes, like, do we need another working group last call? Do we like
[00:49:10] Heather Flanagan: We don't change it.
[00:49:12] Brent Sundell: I mean, I Mhmm. Mhmm.
[00:49:17] Rohan Mahy: Mhmm. Basically, you know, so listening to the conversation, I'm more concerned with two things. One, did you make kind of any meaningful normative, you know, kind of the must, should, whatever language change? And then have you broken what I consensus working group consensus? Right now, I would say that doesn't seem to be the case. I wouldn't pull it back to working group, but I reserve the ability to, like, really do the detailed review to be sure of that.
[00:49:52] Heather Flanagan: Ted?
[00:49:56] Ted Hardie: Ted Hardy. I will point out that you might find it advantageous to do to do so for one reason. The document as it is now uses a relatively limited syntax from the full URI syntax, because it started out as a URN, and URNs use a limited syntax. Especially if you're going to have organizations from around the world, the ability to use the percent encoding syntax will be quite valuable to you, and it is currently ruled out. So I would suggest you consider, if you're gonna go down the URI path, that you pull it back and redo the syntax to take advantage of the full URI syntax, rather than using the limited subset. Again, I you know, from my perspective as somebody who cares about URI registration, I want to avoid scheme level collision. Strings are cheap. Glue is not in use. You can have it if you want it, from my perspective. You could have gotten a provisional registration for it for really cheap six months ago by just sending something to Wianna, and it would be done. And the upgrade would be where you'd be having this conversation. I do caution you, though, that I think your actual issue isn't in the URI scheme. And I think one of the reasons you want to be able to use the full URI syntax is because it will help you match it to the registrations, which will have diacritical marks or non ASCII characters in them for anything that's even close to a worldwide system. So I I really encourage you to consider that as a change rather than simply progressing the document as it is now because the limitations are gonna bite you.
[00:51:37] Hank: Hi. This is Henk Tid. Don't walk too far away. I'm tired already. So I'm I'm so sorry for this question. Next to the URI scheme item, you highlighted that why they're flexible and then they're percent encoded, which is nice. You mentioned the an AYANA registry usage, and I didn't get that quite right.
[00:51:59] Ted Hardie: So my understanding is what you want to do is to have a registry maintained by AYANA, which will have the names of the organizations for which a representation will be made in the URI. So the name of the organization and then the identifier associated with it. Okay. If the name of the organization is and you can't have any diacritical marks from French in there, it's going to be problematic.
[00:52:24] Hank: So how does it correlate with the authority in the URI? Wouldn't that be a redundant item at the beginning and then later not? Authority could be that, right?
[00:52:39] Ted Hardie: So the URI form you have right now doesn't require an authority. You can have a URI form with an authority.
[00:52:47] Hank: I reject my question.
[00:52:48] Martin Vigoureux: It should have an authority. Which who's my Hi.
[00:52:51] Rohan Mahy: No one may. You may wanna stand stand here because so while I do agree with you that having the escape mechanism of well, having the escaping mechanism as an escape valve is useful and valuable. I actually did do a survey of business identifiers registered in some 105 countries, I think it was, off the top of my head. And there was nothing that wasn't There was no identifier that was not alphanumeric. For the name of the authority, there were certainly authorities that did not have That whose most recognizable identifier was in some other script system. So This
[00:53:36] Ted Hardie: is a tuple. Right? Yes. And and if you half of the
[00:53:40] Nicolas: tuple needs it, you need it.
[00:53:41] Rohan Mahy: Yes. So, I mean, there were arguments that you could come up with a with another string that was in ASCII to represent the authority if you and I don't mean a domain name authority. I mean, generically, an authority. But yeah, I would to be able to express those things. We decided because of the confusion problem that we didn't want to have. Cerulicaria a's being mistook for Latin as and vice versa and that coming up with a Latin name for any authority was preferable. Did I understand that right?
[00:54:28] Ted Hardie: So you can make whatever decisions you you want. I I will say that's not the the decision that the name domain naming system took in the adoption of ASIN coatings for domain names, and it's not the decision that unit URIs take generically. So it is somewhat surprising. I would suggest if you do that, when you register the organization, you have IANA assign a serial number, and then you make the actual URIs a tuple of the the reference to the IANA registry, the serial number reference, and then the identifier. That's not going to look anything like what would have been assigned by the organization itself. The only bit that will be the same will be the actual identifier at the end, but the representation of the the bits before that will not be common to what they would have done if they minted their own URL or URL scheme. It it would give you the property that he's looking for that you maintain ASCII throughout, because the serial numbers can be assigned solely out of numeric or alphanumeric carrier characters, which would fall naturally within the ASCII range. It does, to me, lose semantic content. But again, I'm I'm not building your system. You are. And if if that's a valuable thing to you, you you can do it.
[00:55:56] Martin Vigoureux: I'm not sure whether this is a chair comment or not, but Rowan made the claim that this needs to fit into a URI. I just I also heard from Brent, this needs to be a string or a URI. Having looked at the specifications involved, and maybe this is not true for CWTs, but at least for JWTs, the type is string or URI. And so, if we're having this discussion, I wonder whether tuple as string is also on the table.
[00:56:29] Ted Hardie: So if you can represent a tuple as a string trivially by mandating a specific Yep.
[00:56:36] Martin Vigoureux: Concatenation characters, yeah, If
[00:56:38] Ted Hardie: you can do it as a string, then the tuple you register and the tuple you'll see would be exactly the same.
[00:56:43] Martin Vigoureux: Exactly.
[00:56:44] Ted Hardie: You would avoid this secondary level of indirection. However, you you would not necessarily avoid the problem that part of the tuple would be in non ASCII characters, whether they be diacritical diacritical marks, Cyrillic, Hiragana, some Abjad. I don't know.
[00:57:03] Martin Vigoureux: That's right.
[00:57:04] Ted Hardie: And that's a that's a question you guys have to kinda struggle through. But I have to say I'm not your area director. I'm not anybody's area director. I don't have that data anymore. It sounds to me like bringing it back to the working group and having at least a little bit more conversation would not be a terrible idea.
[00:57:23] Heather Flanagan: Mike?
[00:57:26] Michael B. Jones: Yeah. As an author and having been kicked around between different outcomes several times already, I would request that we try to complete the registration with the draft we have before we do anything else.
[00:57:44] Brent Sundell: On that, I do want to note that the draft takes into consideration the need for the authority identifiers to be unique and to give guidance for designated experts for making sure that they're unique. You know, recommends a pending geographical notation in order to make sure that, for the example, the IRS in Portugal and the IRS in The US would be differentiated in the registry, we we do try to take that into consideration somewhat.
[00:58:17] Ted Hardie: Ted Hardy. Different hat. Look. Suddenly, the chair hat goes on. Is here. Amanda and her team are down at the tables. Kim Kim is here. Please, may I suggest you guys go and chat while you have face to face time with them? They're friendly people. Often they have chocolate. Definitely worth your time to go and to try and figure out how they would best be able to help you make this registry work. Thank you.
[00:58:50] Brent Sundell: Building on what Mike just said, would the working group be opposed to us moving forward with the draft as is? It's a URI scheme. We try to register it it as as a a URI. URI.
[00:59:05] Heather Flanagan: Do we need to pull?
[00:59:09] Martin Vigoureux: It's not about hands. It's about whether the objections have been addressed.
[00:59:16] Heather Flanagan: Are there any any objections? Any objections that haven't been addressed? Any concerns?
[00:59:22] Rohan Mahy: No. That
[00:59:25] Heather Flanagan: will prevent us from keeping this going forward? Alright. I'm not seeing anyone in queue, and I'm not hearing any objections. So keep moving. I do agree with Ted about talking to the Ayanna folks and that they are very nice.
[00:59:42] Brent Sundell: Yep. And they do have chocolate. Yes.
[00:59:45] Heather Flanagan: And they have chocolate. Goodness. Okay. Great. Let's keep Thank you. Moving. Charter. Rohan, you wanna do SD-CWT?
[01:00:02] Michael B. Jones: Sure. Confirm.
[01:00:04] Heather Flanagan: Let me get the timer out. Timer. Cancel.
[01:00:18] Rohan Mahy: Next slide, please. Oh, No.
[01:00:22] Heather Flanagan: I don't think it is. Okay.
[01:00:25] Rohan Mahy: Okay. So we've been working on SD-CWT for a while, and, we had a working class call. That working group last call has ended. We had no open issues at the at this point, in the GitHub. We worked we, worked on an interop test rig at the hackathon. We managed to to I mean, with one implementation, we managed to pass it some some stuff that it processed and passed back. There's still some work to do. But thank you, Beltrum, for for work with your implementation on with my test rig. Ori also promised to get to get something that uses the same interface so that we can have two different implementations, and then we can pass messages among those two and also the implementation that I used for generating the examples. Next steps. Yeah. We'd like to finish testing these three implementations. Next slide, please. Okay. So if you haven't read the draft since or haven't skimmed or looked at the diff or looked at the change log, this is basically the change log. So there were exactly four normative changes since the last ITF, since dash o seven. So we added a bit more text about how to do validation of nested claims. We added a, a key context in the a a e a d encrypted disclosures. We clarified the nonce length of the AAD, and that then the Sorry. That's supposed to say the AAD is empty. And we were also We clarified how CBOR tags are treated with respect to nesting. Then we had a lot of non normative changes. Thank you, Martin. If you really care, you can can go look at them. This is your sort of your opportunity to say, hey. Wait a minute. This is not what I thought we were we decided we were gonna do. But, you know, we've been through working group last call. We've addressed all open issues. We think it should be smooth sailing from here on out.
[01:03:11] Heather Flanagan: Okay.
[01:03:11] Rohan Mahy: That's what I got.
[01:03:13] Heather Flanagan: Questions? Comments? Alright. Thank you very much. Great. That was never fifteen minutes just then. Excellent. Mike, do you wanna do an update on OIDC?
[01:03:32] Martin Vigoureux: Hi.
[01:03:44] Michael B. Jones: I'm Mike Jones again and I'm here with Beltrum also in the room is the one that really did this work and I helped with syntax. Next slide. And I won't have to say that again because there's only two slides. So where are we with the draft that registers the OpenID Connect claims? Which I and John do know some things about as CWT claims for the reasons that we discussed amply in the charter discussion. There is a Shepard review. We addressed changes to it in March. We completed working group last call at the end of the last year. So I believe the next step to progress the draft is an AD write up and then IETF last call. Chris, do you concur? Previous slide please, chairs. The draft is on the middle of the slide.
[01:05:09] Martin Vigoureux: Yeah. So I have not
[01:05:13] Michael B. Jones: I know.
[01:05:14] Ori Steele: And you're asking Yeah.
[01:05:17] Martin Vigoureux: We need to we need to pass it to Chris formally. That's that's really all that needs to happen.
[01:05:32] Heather Flanagan: It was on. I got very tired of talking about URIs.
[01:05:38] Martin Vigoureux: You're only one. A urine is a URI.
[01:05:43] Heather Flanagan: Well, the good news is that what was said, because I could hear that, is that at this point, we need to click the button, and he will take it.
[01:05:53] Michael B. Jones: I'm not aware of such a button. What is the button?
[01:05:55] Martin Vigoureux: We we can see that button.
[01:05:57] Heather Flanagan: We can see the button.
[01:05:58] Brent Sundell: Okay. It's
[01:05:59] Rohan Mahy: okay. We'll look after it.
[01:06:00] Michael B. Jones: Alright. Well, then do that. I'm done. Okay.
[01:06:05] Heather Flanagan: Alright. Which takes us to architecture.
[01:06:15] Martin Vigoureux: Discussion, twenty minutes.
[01:06:24] Brent Sundell: Hey, everybody. Let's talk about architecture. Next slide, please. So pretty straightforward agenda. We need an architecture document. In all the charter conversation, nobody was like, hey. That architecture piece, let's not do that. So I'm assuming that we do wanna do that. So I'd love to have a conversation today about whether that assumption holds. And if yes, then what should an ideal what should an architecture document have in it? Let's talk about maybe some let's do some level setting and then maybe a brief glance at a proposed architecture document. So next slide, please. So do we need an architecture document? I think yes.
[01:07:17] Heather Flanagan: It's in our charter.
[01:07:19] Brent Sundell: In our charter that we're gonna do it. Nobody said, hey. That thing, I don't like it. While we're fixing the charter, let's fix it so we don't have
[01:07:26] Rohan Mahy: to do architecture. I'm just
[01:07:27] Brent Sundell: I don't wanna misunderstand. I wanna make sure that everybody's cool with the fact that we're supposed to do an architecture document. We're good? K. Next slide, please.
[01:07:37] Heather Flanagan: Hank, do you wanna respond to that one?
[01:07:39] Justin Richer: Hates architecture.
[01:07:46] Rohan Mahy: So
[01:07:55] Hank: if we're asking these types of questions, then we should be inclusive and take care of the remote attendees and the chat. And I think this is a question that can't be just said and then we move on. I think that's not okay. Sorry. No offence. But also, I think, yes, it's a charter high chance. Obviously, we haven't changed that. So think it's a safe answer because it's a rhetorical question that needs a show of hands that we don't need.
[01:08:19] Heather Flanagan: So yeah. Okay. Yes.
[01:08:24] Brent Sundell: K. Next slide, please. So let's talk about the architecture of the architecture. Next slide, please. In brief, I believe that a good architecture document will have some terminology. It will have some descriptions of the actors involved. It will have some flow diagrams for how this, you know, proposed architecture works altogether. I'm asserting that each of these things is necessary. I'm inviting folks to challenge that assertion. I'm asking, is this sufficient? If not, what else should go in an architecture document?
[01:09:17] Heather Flanagan: Can you repeat that?
[01:09:19] Martin Vigoureux: Can we use the microphone? What happened to that?
[01:09:21] Brent Sundell: Anybody who wants to use a mic, you're welcome to use mine.
[01:09:23] Heather Flanagan: I'll just died. That one died. Yeah. Brent, take the mic over, please.
[01:09:39] Nicolas: So I'm Nicola Twerit from university. I'm a total newbie in SPICE, so maybe my question is dumb. But I wonder if maybe you imply that these three things also include the expected properties of these actors and terms that you will define and the interactions in the general flows, or if it is just going to be like, this is what issuer, verifier, and holder are, but doesn't specify what is expected of those things.
[01:10:14] Brent Sundell: I believe that assumption is correct. Yes. When we say actor descriptions, we mean we're actually gonna, yeah, say how all these pieces work together.
[01:10:29] Heather Flanagan: Great. We're back, Martin.
[01:10:30] Martin Vigoureux: Yeah. And please join the queue. Oh, we have
[01:10:32] Rohan Mahy: a mic. He's come to the microphone now.
[01:10:34] Martin Vigoureux: To the microphone. And if you're not in the mid echo thing yeah. Oh, great. As a chair, one of the things that we're looking for is feedback from the working group. One of the things that has been somewhat lacking in this area, despite the efforts of the authors to produce the text, is feedback to the authors about said text. And, a chair, it's pretty hard to judge consensus when there has basically been silence on the other end of that conversation. I understand that, you know, there's a good number of people working on this document, but it would be very helpful if people would review said document and provide feedback on said document, because sharing in a vacuum is not fun.
[01:11:28] Nick Doty: So what I could imagine in there is well understood patterns, for example, for the wallet architecture where you see in OpenID for VCI basically two bigger patterns emerging where we have primarily wallets that are focused on native apps, and then we have web wallets. And if you have native apps, then also you have just the native app being the primary component and just having, like, a back end component supporting that behind each other. Or there's, like, the new server to server model where, basically, things are first routed through the world's back end server and then the user's native apps kind of behind that. I think these are kind of, like, the bigger patterns, and I think that would be something that I could see as valuable in such an architecture document so that there are well established terms and descriptions for these things so that could be reused in other groups.
[01:12:31] Brent Sundell: I totally agree. That was what I was thinking when I wrote flows. So yes.
[01:12:38] Hank: Okay. Then we invite a grim. Paul beat me to it. I was, like, going, there's a lot of wallet scenarios. Obviously, Christian and Paul know about that. And we should name them, like the passport model and the background check model that everybody knows now. So, yes, this is the one of the good things that would the architecture would would be a benefit one, and I'm I'm I'm willing to contribute.
[01:13:07] Brent Sundell: Thank you, Hank. Okay. That was very helpful. Thank you. We have a draft.
[01:13:17] Heather Flanagan: Ah, two people have jumped in queue.
[01:13:20] Martin Vigoureux: Nick.
[01:13:21] Heather Flanagan: Oh, actually. Nick Doty? Yeah.
[01:13:25] Nick Doty: Just in terms of necessary and sufficient, I think I think describing the privacy and security considerations and the different types of presentations is necessary for an architecture. And and I think the charter mentions them a lot and doesn't give a specific deliverable, but I I think it would need to be in the architecture document as well.
[01:13:47] Brent Sundell: Fully agree. Thank you.
[01:13:51] Heather Flanagan: Nicolas. So
[01:13:58] Nicolas: Nicolas again. So it's a follow-up to the previous question and a plus one to what Nick just said. So if I look right now at the draft that is there, there are some there are defined some expectations or roles for the actors in the interactions, but there are no explicit privacy and security considerations. So in the in that sense, I wanted to specify properties for these so that one can fully reason about the models and what are the assumptions and guarantees.
[01:14:33] Brent Sundell: Yes. Thank you.
[01:14:35] Heather Flanagan: Tim?
[01:14:36] Martin Vigoureux: Hey.
[01:14:41] Brent Sundell: We said the
[01:14:42] Hank: Just using the passport. What did you mean by that? Do you want us to cover, like, how you derive a passport into a credential? Okay.
[01:14:49] Brent Sundell: That's the rest. I was very oh, okay. Oh, that's the rest. Okay. Alright. Next slide, please. So we we do have an existing draft. We've presented it a few times. The draft is a bit lacking in privacy considerations. I will admit that. But it there are there is terminology. There are flows. There are actors and descriptions. There are it's not perfect. We're not saying let's go to last call. We're saying we believe that this is a sufficient starting point for us to focus the conversation around architecture in this group. We have not had a lot of people review, but we have had a few people very thoroughly review. And in the feeling of the editors, though those reviews did result in a large number of GitHub issues opened for us to, you know, do the work that's called for in those reviews, none of them called for any large structural changes to the architecture itself as presented in our in our view. So we feel that the document is ready for working group adoption. We expect the document to change and evolve as as we develop it and present the ideas here as we, you know, get rid of existing sections and modify terminology and fine tune things, we expect that to be a conversation with this group. We think it's ready to serve as that starting point, And so we're asking for the working group to adopt this draft.
[01:16:39] Heather Flanagan: Okay. So we'll, of course, take that question to the list as one does. While we have some high bandwidth time, does anyone have any concerns that they would like to discuss before we take it to the list? And everybody's gonna read it and respond. Right? Right? And
[01:17:01] Brent Sundell: as you read it, please remember, this is a starting point. This is not we're not saying this is the best architecture in the universe. It solves all of our problems. There you may completely disagree what the terminology should be. I think we have rough agreement that there are roles, and there's a user holder ish role, and there's a relying party verifier ish role, and there's an issuer identity it's like, we have these ideas. We've tried to capture those. I I have full confidence in this group's ability to come to agreement on a final form.
[01:17:38] Martin Vigoureux: I don't. Brent, when we last discussed this, the next step was for you to submit the draft under an individual name. It was mistakenly submitted under draft IETF something or other. The draft has long expired, and that didn't happen. Can I request that you take that step again and Yes? Produce a document that is, you know, draft- zundel or or what have you so that we can discuss adoption of something that doesn't have a very confusing name. Yes.
[01:18:12] Hank: Hank? Yeah. I was coming to that. I was we're talking sorry. I'm I'm making this blunt. We're talking about this draft life started. Right?
[01:18:21] Brent Sundell: Yes.
[01:18:22] Hank: Okay. And that has expired, and there's only zero zero of them. That's one version.
[01:18:26] Martin Vigoureux: Yes. You
[01:18:26] Hank: are asking for adoption. That's the one. Okay. Just summarizing the effects.
[01:18:32] Brent Sundell: Clean up things so that
[01:18:33] Hank: it's more clear. V d arc. Right? Yes. Okay. Well, now we are on the in the clear because I was, like, a little bit confused, and it took me Gemini to find it. And so yeah. Sorry. Okay. Thank you.
[01:18:49] Martin Vigoureux: I could not get it on the working group page.
[01:18:52] Heather Flanagan: Okay.
[01:18:54] Martin Vigoureux: Data tracker might let you put it on the page.
[01:18:57] Heather Flanagan: I'll have words with it. Cool. Then you have your homework. We have our homework. The room has their homework, which I know they cannot wait to do. I think that was the last thing on the agenda. Pretty sure. Yep. Alright. Martin, is there anything else you wanna cover?
[01:19:19] Martin Vigoureux: That was it.
[01:19:20] Heather Flanagan: Okay. Then with that, we'll let Philip, go ahead.
[01:19:33] Phillip Hallam-Baker: Okay. So this is probably a bad idea because I only thought of it during the meeting. So as you know, I'm very much interested in DNS handles. And I've been looking at Blue Sky using them as a syntactic sugar for OAuth, and that works really well. And so well, in fact, that I would like to make that the general pattern that we use for things like SAML and other types of authentication credential. And I'm wondering if this might be the venue where it would make sense to discuss that sort of thing. The general sales pitch is, you know, when the DNS was created, it was only for hosts. Pretty soon, it became mail service, but we haven't really put users into the DNS. And, you know, it's always been thought of, well, the users are something that's going to be managed by a service, and they're going to be employees or members of some academic institution. And so users won't go into DNS. But putting user records in DNS is really useful because it means that they have their own they can have an identifier that they own and that they control. Now, this isn't really something that is part of the DNS gestalt there because they're thinking about resource records and so on. And it's really a question of how do we label a SAML endpoint so that as far as the user's concerned, when they're asked to type something in, they know what they're being asked to type in without having to know that it's SAML on the back end. We can't do this all with OAuth because OAuth works fine, but it's designed to work around the limitations of HTTP, and HTTP is a real problem to work around. You have to if you if you've got an application that just wants to authenticate against a service and that application has a web key has a private key of its own, you don't want to go through o auth. We've got better protocols for doing that. So I'm wondering if this might be a venue where we could have that discussion of tagging and bagging because it does look like it is related. And I would have brought it up with the chairs beforehand, but it was only
[01:22:19] Heather Flanagan: Pop quiz. Could you help draw a line for me between the how that fits in the charter that we will have very soon?
[01:22:32] Phillip Hallam-Baker: I'm not sure.
[01:22:33] Heather Flanagan: Uh-huh. That makes it a little bit harder to answer the question as to whether this is a good place for it. Right now, I can't I can't quite see how it fits in our charter. I'm hoping someone can help help me get there.
[01:22:45] Phillip Hallam-Baker: Yeah. It it seems to be stuff that we it seems to be aligned with stuff that you're doing.
[01:22:50] Heather Flanagan: Okay. Ori?
[01:22:53] Ori Steele: Hi. Ori Steele. In our last chartering endeavors, we ended up with this line that says general purpose key discovery is out of scope for this group. So I think that that kinda answers this very clearly, and there was a lot of discussion in the initial chartering around how important it was for us to do that for various reasons. So I think it's probably not for this working group, but I would encourage you to look at a auth and talk to o auth folks and see how agents are changing authentication.
[01:23:25] Heather Flanagan: Cool. Can someone grab the door, please? Don't worry. Mike.
[01:23:32] Michael B. Jones: So Philip, Mike Jones. John Bradley and I and among others worked on a system most of twenty years ago called OpenID two o where we did have URLs as identifiers for humans. I still have a blog where that identifier works with the OpenID two protocol. It's self-issued.info. But as much as the OpenID Foundation tried to get people to create their own URLs, only geeks would. Most people didn't identify themselves as having a URL which was them. I don't know that that's changed, but this is a sociological point more than a technological point. And it's probably out of charter for the working group. But we have two minutes or something, so feel free to respond to me.
[01:24:37] Phillip Hallam-Baker: Yeah. I was never a fan of using URIs. What the u if it's gonna work for the user, if you ask the user to type in anything more than a domain name that they're familiar with, It's got to be a domain name or an account name or they're not going to be able to get it. I I I predicted the death of the URI version of the OpenID. Yeah. This is an area where any grit in the gears, the slightest grit kills it.
[01:25:09] Heather Flanagan: And
[01:25:10] Phillip Hallam-Baker: but the blue sky people have 50,000,000 people using domain names.
[01:25:17] Heather Flanagan: Justin?
[01:25:20] Justin Richer: Hi. Justin Richer. This is why the Blue Sky people do not have 50,000,000 people using domain names. Because for most people, it's bsky.app. That's and they've got a username there. And people aren't thinking about it in terms of I need to go get a domain name. They're like, oh, I have a username, and it's got dots in it. Whatever. And so unless a system is also committed to creating an ecosystem whereby people basically get host names for free, which I don't think we can do with the protocol level, then it's it's just going to burn up. And I strongly recommend reading the book, Why We Fail, which has chapters on OpenID two, which has some information about users thinking about themselves as domain names even like, I don't think of myself as a something.bluesky.app. I think of myself as the username portion of that. That's that's my username. Right? And it's you you cannot conflate the on wire functionality with the user piece and say that because they happen to line up, it's the same. Right?
[01:26:44] Heather Flanagan: Pam?
[01:26:47] Pamela Dingle: I don't know if it applies to this, but I do think we need to rethink what friction is in a world where people have agents to do things that remove grit from the gears. So stating that it's bad because there's friction, that that could be changing as we speak, or maybe it isn't.
[01:27:06] Heather Flanagan: Cool. It's an interesting conversation, certainly. I'm I'm not feeling like it's in scope here, but wouldn't this be a a fun thing to keep maybe have a side meeting on next time? Cool. Alright. Any any other business? Going once? Going twice? Sold American. Alright. Thank you all for your time. Have a great rest of your meeting.