**Session Date/Time:** 16 Mar 2026 06:00

Here is the verbatim transcript of the IETF 125 DIEM working group session:

**Rohan Mahy:** Hello hello. We are at start time, but looks like there's still people trickling into the room. Do we have Felix in the room?

**Orie Steele:** Yep, Felix is here. Summit's here. A couple other folks are here.

**Rohan Mahy:** Great. Okay. I think we'll... do we have somebody who would be willing to be a note taker? It's a very important, very important job. Do we have anyone interested?

**Orie Steele:** Yes, we have one. What's your name for the...? Laura. If you could just in the chat just say you're willing to take the notes. It'll record you. Thanks.

**Rohan Mahy:** Wonderful. Thank you.

**Orie Steele:** Sure. So I'm Orie Steele. I'm the responsible Area Director for DIEM. Our chairs are remote. It's Rohan and Sarah. And Warren's up here to keep me company and help me in case I get scared if you know. Chairs, anytime you're ready. You are the chairs. I'm here for you.

**Rohan Mahy:** Good afternoon everyone.

**Sarah T. Wood:** Afternoon. Hello.

**Rohan Mahy:** Welcome to the session of DIEM. As Orie said, I'm Rohan.

**Sarah T. Wood:** And I'm Sarah. Lovely to meet you all.

**Rohan Mahy:** We're going to start with the usual Note Well. So by participating in IETF, you have already agreed to follow the IETF processes and policies. This Note Well is a reminder or a summary of the most important of those policies. The QR code below and the link in the second line of the slide will give you access to the full gory details. But briefly, IETF participants are expected to behave in a professional manner and be respectful and courteous. If you feel that someone is not doing that, please feel free to contact the ombuds team. They are really lovely people and they have extensive power to investigate, report, and try to make everyone feel comfortable participating at IETF. If you are aware of any contributions that might qualify as intellectual property that is covered under RFC 8179, you are required to disclose. Please see the appropriate documents if you have any questions or contact the Area Director or feel free to contact one of us by email. All right. Finally, you are being recorded. All right. So we're... this is the agenda we've prepared. If anyone has any proposals for additional items, we... if we have time remaining, we may discuss one of the architectural proposals. At least the... we may discuss some of the open issues, the main issues that have that have... that we feel would be subject to discussion. But for now, we are going to talk about a liaison statement that we've received from the ITU Study Group 17 or so.

**Sarah T. Wood:** 17.

**Rohan Mahy:** 17. And here it is.

**Sarah T. Wood:** All right. Shall I kick it off? So back in December, following the ITU-T Study Group 17 meeting, we received an incoming liaison statement about two new work items. So the first, have just pulled some text out, is X.str.dm, Digital International Humanitarian Law Emblems, talking about complementary standardization in ITU-T to ensure that the emblem is integrated into telecom standards in a way that's scalable, secure, and aligned with states' obligations. And then a second item, X.str.dm-assets, Digital Emblems as a key solution in resolving the issue of inappropriately exposed OT assets in the cyberspace. So detecting, identifying, and removing exposed assets from the internet and using digital emblems as a mechanism to achieve that. So, we talked a little bit about potential response. So, we are, as chairs, considering our kind of best mechanism of response to the liaison statement. The sort of first thing I think to flag is the IETF being responsible for developing the technical framework, and that is following the requirements for the various emblem types defined in the use cases and requirements draft. We'll also consider network security and privacy considerations. And it's worth kind of flagging and bearing in mind, DIEM is defining a framework for emblems for lots of use cases, including non-IHL use cases, and involves both digital and physical use cases, and it's not defining new emblems for which there's no physical analog.

**Rohan Mahy:** And so we wanted to open the mic to have some discussion if there were some additional items that people wanted, or thought would be important for us to have in a liaison statement. We have a couple of people in the mic. Why don't we go ahead... Jim.

**Jim Reid:** Yeah. Thanks, Rohan. I've got a couple of questions about this and some comments. I'm a little bit concerned about the developments in Study Group 17 for a variety of reasons. One of them is that Study Group 17 probably isn't the appropriate place inside the ITU-T to do this kind of activity, in my view. This probably relates to identifiers and working identifiers is done in Study Group 2, not Study Group 17. And I'm also concerned that some of the developments that have been put into Study Group 17 seem to be attempts to either preempt or duplicate the work we're trying to achieve in this particular working group. There were two documents at Study Group 17. One came from Sumit, which seems to do with contacting administrations to find out about the digital emblems they're using, with a view to trying to set up some kind of global registry for them. In my opinion, that's non-controversial, irrespective of where that lands inside Planet ITU. The second one is a report on use cases and requirements that's going to be a technical report. That seems to be completely at odds with what we're trying to achieve in this particular working group, and frankly, I don't understand why that document was adopted by Study Group 17. Well, I do know why it was adopted, but I don't want to discuss that. Frankly, I think the co-chairs of... the chairs and leadership of Study Group 17 made a huge mistake there. Since then, we've had a discussion about this with three of the sort of concerned parties who happened to be at the TSAG meeting of ITU back in January. So Sumit kindly came across the road from the Red Cross headquarters, Scott Mansfield was there, and the meeting we set up with Arnow Taddei, who is the chair of Study Group 17, but he couldn't really participate in that discussion because he was busy elsewhere. But we came up with a general idea that what we try to come up with is an idea is that... oh, I see he's just arrived. You should have told me he was behind you. But we try to keep... a general idea is that ITU would try to deal with issues to do with policy issues and government engagement type activities, but the technical work would take place here in the DIEM working group at the IETF. And somehow, I think we need to formalize that a little bit better. A heavyweight liaison statement mechanism, I think, is somewhat inappropriate because that's best dealt with documents on a case-by-case basis. And I don't think we want to overburden Scott Mansfield, who is the IETF/ITU-T liaison, because Scott is vastly, vastly overloaded with work, and we don't want to add to it. I'm not speaking for Scott, but Scott can speak for himself in due course. So, but I think there's probably a need to find somebody as a stuckie who could sit between both Study Group 17 or elsewhere in ITU-T and also with this working group to keep track of what's going on and try to make sure we don't have any other conflicts or overlaps or attempts at double dipping or forum shopping or anything else like that that might come along. I think we have to clearly delineate responsibilities between the two SDOs and make sure that those get kept with and are going to be adhered to in the future. I know that Arnow said that that's what he intended to do, but I think we need to properly capture that and get this properly nailed down. Thanks.

**Rohan Mahy:** Jim, before you go away... I think it would be very useful if you could post into the chat any specific things that you would like included in say an outline of the points that need to be discussed, whether you think that they should be in a liaison or not.

**Jim Reid:** Okay. This might take more than going in the chat, but I'll do my best.

**Rohan Mahy:** Thank you.

**Sarah T. Wood:** You have anything you want to add on this?

**Rohan Mahy:** Sounds good.

**Mallory Knodel:** Mallory Knodel. Thanks for leveling this up. Yeah, I'd agree with everything Jim said. And I was going to suggest there be at least one more bullet point to express some of that. And but the thing that I was concerned about is timing. So I think actually out of the two statements, the second one makes a lot of sense to me because you are going to have governments implementing these, you know, these specifications. And I think it's really, really important that they... like that member states who plan to do that be invited into this process so that whatever is getting specified here includes those concerns, which may be unique. And so the additional point on this reply, I think should extend that invitation and also say that any implementation needs to wait until this process is more mature. Because if they start doing it now in parallel, I think a lot of what Jim said would be concerning, duplicative, it's not the right mandate split, etc., etc. Thanks.

**Sumit Dookna:** Hey everyone. Sumit Dookna, ICRC, International Committee of the Red Cross. So, you know, I am one of the... one of the editors of the technical report that Jim mentioned, the DIEM one for digital IHL emblems. Just very quickly on sort of how we got to this point. For digital IHL emblems, of course, the journey was always going to be at least partly an intergovernmental process. States involved, we needed states to be involved, we needed states to be part of the conversation. And so in our discussions with them, we consistently invite states to attend the DIEM meetings, like the IETF meetings. But part of that discussion was also, you know, there is a body that is intergovernmental that has states, where they can discuss this issue. And so that's what led us to... also speaking with Arnow, of course, the chair of the... of SG17, that's what led us to drafting that initial new work item. For us, we were really clear in all of our discussions that of course the technical work takes place here. And so that's why what we're doing there is rather a report. It's to share information, it's not to adopt binding recommendations or standards. It's really just to shed light on the important work that's taking place here. But yeah, happy to take any questions on that, on the first one. On the on the second one, I'm not very familiar with it, but maybe Arnow has a few words or someone else in the... in the room.

**Sarah T. Wood:** Thanks Sumit. And I think it goes back to Mallory's point. It seems like one thing we'd want to make very clear is that if states or participants in Study Group 17 have use cases or requirements that they don't think are currently addressed by the drafts, then that needs to be brought into the IETF and and how we can best invite that and facilitate that... part need to set out.

**Rohan Mahy:** Arnow?

**Arnow Taddei:** Good afternoon everyone. So Arnow Taddei, here I speak as SG17 chair. So, so first of all, Sarah, congratulations for being there. That's really fantastic to see, with Rohan as chair. You guys are in Tokyo, right? You're in Japan. Okay, so it's not... it's not too bad from a jet lag perspective. So... so before anything, just so that people relax, this whole story of things starting at SG17 are not coming from out of the blue. This is something that Sumit and I discussed a long time ago, when Sumit was working on this idea. And very quickly I realized that because there is going to be an intergovernment... government part of that, the only place that can actually address some of it or help the situation is the ITU, and at that time I was not even chair, so in the meantime I became chair. That's the first thing. The second thing is that took me a long way to improve relationships between ITU and IETF, especially with SG17. I have really remarkable relationship with Roman. You can be sure that I want this collaboration with DIEM as exemplary. Right? I'm... I've not done all of this work with Roman to get it to screw up here. Third, at this stage, the only thing that we are doing is non-normative text. So the two liaison statements you received are for technical reports. One of them is aligned to Sumit and the Red Cross use case. And out of the blue, that was the news, there was another one that came from an operational technology issue where companies such as Schneider Electric realized, "Oh, that would be awesome if we could do something like this." So here, we would be happy to bring back the requirements to DIEM in IETF so that you can continue your work on... on that. So this is really for us to help you. The area where SG17 can be of help here is on terminology. That's one place. The reason is that because of member states, and that's the only SDO which has member states, we have two constraints. One is interpretation. Because we translate everything in six languages, if something doesn't fit a certain language, it's impossible then to have it in their regulatory and policy text. That's one. The second one is the fit to United Nations language. So that's where we can help. The other place where we can help is on United Nations resolutions. So the issue we faced was a race to get to Plenipotentiary outcome. Because there is going to be an ITU Plenipotentiary in November, it's supposed to be in Doha, so I don't know what will really happen. But because we did what we did in SG17, this suddenly opened the eyes of member states and some European member states are interested to support DIEM language at policy level in the resolution. I don't know if they will succeed, but we already reached one goal is that we could create the right awareness and they were happily surprised by the fact that there is a... a construction on IETF side to get the right technology there. Finally, as I... I had the good surprise to see Jim coming back to TSAG and to ITU. Yes, I tried to organize a meeting, but as Jim said, I was taken out and hostage in another battle in TSAG so I could not even attend my own meeting on DIEM with TSAG people. But anyway, the meeting happened. So anyway, point is that I think we are really in a good place. And if anything happens, let me know, but my objective is to get an exemplary collaboration as a first collaboration between SG17 and ITU. And sorry it was very long, but I hope this helps.

**Rohan Mahy:** Yeah. Thank you Arnow. I also want to mention that we... many of the participants at IETF are likely to be unfamiliar with some of the ITU specific language, even what the significance of a technical report, which to some people to some ears may sound very normative, and the Plenipotentiary. So I think that we all have a little bit of work to do to explain to the working group exactly what... what the significance is of the liaison statement that we've received. But yeah, it remains to... to us to as a working group to provide source content for any response, which I think would be an important step for us.

**Rohan Mahy:** Okay Felix, take it away.

**Felix:** Cool. Yeah. So the deadline to start a working group last call for the use cases and requirements document was in November. It's... it's March. And in this document... in this short presentation, I would like to discuss... I will first present an overview of the current discussions that happen primarily on GitHub and remaining issues. This is more an inventory keeping and to get everyone up to speed. I will open with a personal note and then I will close with a point to discuss about the use cases and requirements document. Let's go. Let's go. So, yeah, first my personal note. We have been working together on this use cases and requirement document for a while and collaboration started with a team of people including Jim. And Jim said that he doesn't do GitHub. And I must first point out that initially I was annoyed and I did do GitHub. But Jim's input was very valuable. But now I am a convert and I think Jim was right all along and we shouldn't do GitHub. My feel...

**Rohan Mahy:** Okay. Is this immediately relevant to the requirements?

**Felix:** Is it relevant to the requirements? Sorry, what was your question? I don't know, but I'll quickly make the point anyway. My impression is that discussions on GitHub disincentivize working group input, so from the people that are here in the room. And especially our working group includes many non-technical participants, for example lawyers such as Sumit, and GitHub scares them. And I think that's sad. We don't get their input, people miss discussions because they don't check GitHub daily. So I would like to encourage everyone to move discussions to the list and make suggestions there so that we have an inclusive way to discuss the document. Okay. Now to the bookkeeping. There are two open things that I personally consider easy. We have a pull request that adds people to be acknowledged. I reached out to a number of people to ask for their consent. Some have provided it. I did not reach out to I think four people. I noted that in the pull request because I couldn't immediately find their email address or verify that the email address I find for a person with the same name is the correct one. So I would encourage those who added them to the acknowledgments to reach out to them to ask for their consent. And then we have issue number two on the security considerations. I remember that Allison mentioned and I think also Rahel mentioned it privately in the last 24 hours, like on an off-list discussion, that they don't think we are good, but I think we are good. We have security requirements and in the security considerations, we note that there are security requirements and that we must take them into consideration as such. But I don't think it makes sense to discuss all of them in depth while we don't have technical documents. But that's my personal opinion, happy to discuss that. I think this is still not really a controversial thing. I'm very open to integrating new text into the security considerations. So now to the hard things. We have... yesterday there were two points, or yeah, yesterday there were two points, I woke up to two new pull requests, so that list got longer overnight. Let's go through these issues to be discussed one by one. Rahel would like an expansion of the requirement of proof of presence. We will have a dedicated discussion on that. I'm just mentioning it here for completeness. Rohan opened a pull request on discussing the physical-digital asset split, pull request number 28. Yeah, I think this is also be discussed in isolation. Then we have a couple of issues that would like to see new use cases being added, and there is one pull request that tries to address that in some sense, and it doesn't directly address a use case. And there are two issues that ask for more details on use cases. And I would like to discuss these two points together. So focus on this now in the discussion that I'd like to open. In general, I think it's easy to add more use cases, right? We have a number of them in the document and we can... we have some of them are described in a single sentence and it's definitely possible to add another sentence that describes a new use case. No problem. For me, the question is who provides the text, because I personally don't feel qualified to just write a sentence on a use case that I see described in very small... in very few words, and to what level of detail do we introduce these use cases? Which brings us, I think, to the elephant in the room, which is the following decision diagram that I think we should discuss here. In the document there are many use cases and a list of requirements that seem to be converging... the latter seem to be converging. But many of them are underspecified and it's unclear how they relate to the requirements. And Michael, I hope I think his name is Michael Richardson, could that be? Yes, I see a nod. Thank you, Orie. Michael Richardson provided some feedback, he read the draft, provided some feedback saying some like... it's not clear to him what an asset is, it's not clear to him what this requirement means exactly, and I can relate to that. And I told him, well, for the use case that I work on, I detail it in my use case. So this seems like we first do the general framework, you know, these are assets in general, and this is the removable requirement in general, but I think all these terms and requirements can only really be understood if you consider them in context of a use case. For some use cases, this is impossible, I would argue. And I would like to ask the question to the working group: Is that a problem? This is... this is the first thing. So do we want to provide more details on some or all use cases? If the... if we say that underspecified use cases are okay and we can have them in the document, then we're good. We can do a working group last call provided the other items are addressed. If we think that is not okay, then I think we have two options. We could a) specify underspecified use cases, but this hasn't happened in a while. It has been suggested many times and people have said that it will happen, but it didn't happen. So I don't see a reason why it should happen now, unless someone says "I'll open a PR tomorrow", then it may happen. Or we distinguish them. We say, for example, just a suggestion, we say, "Here are some use cases that have been brought up. We want to consider them, we want to keep them in mind because we have this extensibility requirement, yeah, if if we see easy wins to help these use cases flourish in the future, that's good to be aware of, but yeah, they're they're just here for reference. They maybe they don't interact so clearly with the requirements." There are also other ways to note that down, yeah, but I think this must be discussed. This is the end of my small presentation and I invite everyone to share their opinion. Or maybe to ask questions first when something was unclear.

**Sarah T. Wood:** All right. Thanks Felix. We'll go to Rahel.

**Rahel:** Okay. Um. So... Um. I guess, I know that this was a bit of a discussion we had online, but I think that what it means for a document to be hitting working group last call is something that we clearly disagree on. Um. And I think that this might be a case of we need to make sure we do it right. Um. And I'm not saying that we have to fill out all of the use cases now, but what I do think is important is that we do put in genuine effort to have at least the ones that are that we've started working on to be more fleshed out. I think that um in many cases, I know that the kind of holding place is on getting stakeholder input, particularly as a lot of the stakeholders we've identified have been UN organizations that have been kind of chaotic to try and contact for members of the working group. And so I would say that there like just this might be a process we need to have more patience with.

**Felix:** So you said that we disagree what it requires to come to working group last call? Wait, let me make my point first. It could be, but I didn't... I do have an opinion, but I intentionally didn't express it yet, right? We have this decision diagram and I'm mostly curious to hear where you think you land on it. And I intentionally didn't say which branch I would go for because honestly I can see many of them working out. So maybe if you can also clarify which question you're asking me to answer?

**Rahel:** Yeah. What's your opinion on the working group last call then? on what it means to have working group last call? Yeah. Um. It means that we feel comfortable enough with the document in its completeness that um we can move on from it and any further additions that would happen that are not corrections from either the IESG or otherwise would be addressed in a separate document. So that that means that the document from the working group perspective is finalized. So in that sense, I do think that it's premature to specify to say that we're at working group last call or that we should be, when we haven't gotten stakeholder input for use cases where there seems to be a much clearer set of interest or we've gotten beginnings of input, but we haven't been able to fully flesh everything out yet.

**Felix:** Okay, and any idea when that will happen? Because it has been a while now that we've been working on this document, right?

**Rahel:** I understand. I think that it might be reasonable to set parameters for what we're willing to wait for, or if there is a period of time and what that looks like, but I can't say for sure what time frame it's going to be exactly. I think that's something we need to kind of sit down and discuss as well.

**Felix:** Okay. Chairs, please... I mean, I don't want to be this to be a back and forth, so feel free to interrupt me. I'd just make one final note and then maybe pass on. My interpretation is that the timeline was until end of last November, because that's what's written in the charter. Yeah. I mean, working groups can change course and and we can discuss this, but that's my interpretation.

**Rohan Mahy:** Felix, I think we did mention at some point that milestones on the IETF charter pages should be taken with several sacks of salt. So don't take that as, you know, we are we're going to finish when when we have consensus, when we have good quality. I don't think that changes the content of your question on this slide. And I think there are several other people who would be supportive of moving forward under one or more of these branches. But but please don't assign any particular must strength to to a date in one of the IETF milestones.

**Arnow Taddei:** Right. So on this one I must say I'm super super super late. Um, but and I really don't want to delay anything because I've not done my homework, so you keep doing. But just two points to note. If I read just the table of contents of these use cases, the second work item, the DIEM assets that we sent as liaison statement to you. Here, this is a use case I never thought about that. This is a use case by which a digital emblem could be used to protect operational technology assets that are stuck in the wild. So there is a problem on... that's a cybersecurity issue by which a number of constituencies realize that there are tons of operational assets that are lost. And they are used as cyberattacks. And they would like to use digital emblems to put a pose on these ones in terms of the attacker be aware what they are doing. And this is... can I ask quickly a question? You you referenced a section two. Which section two are you referring...? No, no, no, no, no. I'm not referencing in the beginning I said I see this second section or something like that... Ah, no no. I speak about one of the two work items we sent to you as per the liaison statement. One is the use case of the international humanitarian law, I suppose that's Sumit. But there is a second one. And that second one is a use case where some people would like to use digital emblems in in order to... it's not reduce, it's it's in order to protect an attack surface that extended too much due to operational technological assets that are lost in the wild. And the process for them to detect them, identify them, remediate them is such that digital emblems could help them. So that's one. The second one came completely by chance a month ago in a discussion with a government I cannot name, on a use case I cannot share, and I fall from my chair when they realized why they had the problem and that would help them a lot. So, I will need a little bit of time to qualify that, look at the document, check that check if we can use what is in there or if we need another way to to document that. But maybe we can do that in the working group last call. So I again, I don't want to delay anything. I'm just dropping here and but there are at least two things that I will need to check if they are already in or not. Can I try to rephrase to see whether I understood you? You're saying you would like to look at the document again because you have more use cases that you would like to add but you're not sure yet? Yes. Okay. When will you be sure? Do you have an idea about the time frame? Like just a ballpark estimate maybe? No, I guess yesterday is the right answer, correct? So look, let me try to do it by the end of this week. Okay. That sounds great. Thank you.

**Sarah T. Wood:** Thanks Arnow. I think it's worth just clarifying the scope is very much on use cases governed by international law. So if you can bear that in mind when you're sort of considering the use cases that you're raising, that might help us to sort of narrow things down a little bit better. Tommy?

**Tommy Pauly:** Hello. Can everyone hear me? Brilliant. Okay. So here's what I'm looking at in terms of decision making on last call. Point one: The intent of this document is to ensure that the set of requirements the architecture is based on do not paint us into a corner such that we could recharter later. Point two: The world is a moving target, and no matter where we end this, the next day there will be new use cases for digital emblems or a stakeholder we have not heard of. So from that, I believe that there is an 80/20 tradeoff here. And I think the intent is not to have a comprehensive list of use cases, but rather a sufficiently broad and permissive set of requirements that allow strict definitions of emblems that conflict with one another to both exist by implementing different subsets of a generalized architecture. To that end, I've contributed or proposed some text that adds a few or extends a few requirements that makes things more permissive, i.e., when it comes to authentication, saying that indeed it is optional... or sorry, not authentication, a validation, indeed it is optional. The architecture should not make any assumptions about what portions of the internet are available. Not because I'm making a strong opinion on what should be in scope or not, just so that when the architecture says an implementation has to define where its sources of truth come from, it can be over and we can get this group on to actually working on those specific emblems that we can adopt by consensus based on who's interested in what. Which is a lot to say that I think we are ready for working group last call if we will just... I have text proposed because when I complain about things it's fair that I suggest things. But I believe with those included, the set of requirements that exist will not be significantly improved by reviewing even several more use cases. Because as far as I can see, including reviewing the slides from IETF 123 eight months ago, that the other use cases we've been discussing were coverable by those requirements. And so I guess what I'm saying is: For those who do want to explore further, what requirements do you think are missing that we don't have? Because those are really the only things that matter. The use cases matter because they justify them. If we have actionable requirements, let's go. Non-published documents like this one, that are not to be published as RFCs, don't have to be perfect. They have to be guiding. And in fact, someone posted in the chat a link to that guidance of: Don't overthink these documents. We need to get to documents that will be published.

**Natasha Chhabra:** Hi colleagues. My name is Natasha Chhabra. I'm joining you from the Australian Red Cross. Thank you so much for including us in this working group. I work closely with Sumit at ICRC and and Felix as well. And Australian Red Cross is one of 191 Red Cross National Societies around the world that could be a potential user of of the digital emblem, specifically the IHL one for the Red Cross. Look, I'm not so much familiar with the IETF working group processes and the other use cases, but I just wanted to make a contribution about kind of our journey with our use case and how we're going with that. So just for consideration by the group, we've made great progress with the testing of our digital emblem prototype within Australian Red Cross working with our head of information security. And out of those 190 plus national societies, we've had interest from British Red Cross, Nigerian Red Cross, and Polish Red Cross, Spanish Red Cross and Romanian Red Cross to also conduct prototype testing. So just wanted to share that there's a lot of excitement and enthusiasm to sort of progress the the conversation for the IHL digital emblems. And we're continuing conversations with states as well, particularly here in Australia. So just to say that that Australian Red Cross would be very supportive of a course of action that keeps this momentum going and can really support us to to sort of continue the conversation. But of course I leave the technical aspects of IETF processes to the to the technical experts in the room, but thought that may be helpful to share. Thank you.

**Sarah T. Wood:** Thank you. Welcome.

**Rohan Mahy:** I think especially given what... what Tommy said earlier about the the idea that the use cases help us give color to... to the requirements and justify the requirements, but what we care most is the requirements and their use in building a suitable architecture document. I guess the first question is do we want to... do are we willing to sort of discuss whether underspecified use cases are all right to have in this document? And if so, then then we we could proceed as long as there are no requirements that people think... we're not having any active discussion about adding new requirements. So we're going to put up a show of hands here shortly.

**Rohan Mahy:** If you're not familiar with the tool, you will see a little pop up and then you can click in the tool on the show of hands and it will open the poll and you can click yes, no, or no opinion.

**Sarah T. Wood:** Jim, do you want to come to the mic?

**Jim Reid:** Jim Reid. Thanks very much, Sarah. I think we have to be very, very careful here with trying to deal with the use cases and requirements. If we try to enumerate every possibility, we'll be here long after the heat death of the universe. So somehow I think we have to cut off... cut this off, and there may be a need to say, for example, in the document is that we recognize this chunk of use cases here is what that needs to be done, but for the sake of brevity and for the sake of trying to get something useful out the door, we're going to postpone that work until later. At least capture the fact this has to be done, but not necessarily do it immediately now. I'm thinking particularly say of the case here of aviation. There's clearly going to be a lot of stuff in the aviation sector that's going to revolve around digital emblems. But given how the aviation sector works, it will take them a long time to come up with decisions, and I think we have to be able to move forward without waiting for ICAO to come back with their ideas about what the digital emblems are going to be in that particular sector. So I think it's enough to say, for example, draw a line on the map saying "There be dragons here," and we just recognize the fact that these are things to be dealt with at a later stage, but try not to get that in the way of getting something useful and substantive out the door in a reasonable time frame. So I would say we can have underspecified use cases. Thanks.

**Sarah T. Wood:** Thanks Jim. Just to clarify, you mean use cases that aren't currently specified in the use cases and requirements as it stands, rather than aviation specifically? Mostly... yeah, yes, you're right Sarah, mostly that case. But I think we might need to do some triage on the stuff that's already in the document because these things could become... could become quite intractable. I'm thinking maybe the case around wetlands could be a particular case that might be difficult to to grapple with, but I can be persuaded otherwise.

**Rohan Mahy:** Okay. So Jim, I just wanted to say the use cases are, as Tommy said, the use cases are instructive. They explain why we have the requirements that we do. But if you agree that the requirements in the document, that those are good and that those are reasonable requirements for an architecture, then we should be all right.

**Jim Reid:** Yeah. Wholeheartedly, yeah. They're good enough for now.

**Sarah T. Wood:** All right. Just for the record, it's 21 yeses and 5 no opinions and no nos.

**Rohan Mahy:** Okay. So Rahel, I think you are up next.

**Rohan Mahy:** We're currently uploading slides.

**Rahel:** All right. Um. So I wanted to talk a little bit about, um, I guess some requirements that, um, had been discussed here, um, and I guess had been some of my motivation for saying we're not quite ready for working group last call. Um. And, uh, some of the the ones that I can talk to in more detail here are going to be on forensics tracing requirements of digital emblems, um, when they were present or otherwise. Um. So next slide. Okay, perfect. Um. So, uh, when it comes to, um, the security considerations, which was issue I believe number two, um, raised in the discussion, um, some of the things that had been brought up are, um, specifically about, um, digital emblems not actually having the power to prevent or stop any sort of attack, um, particularly when we're thinking about, um, a cyberattack. Um. And then, uh, there was also the issue of, um, an attacker or would-be attacker being able to, um, claim plausible deniability. Um. And so, uh, that was kind of the motivation for establishing a proof of presence. Um. Which is to say that, um, the sort of, um, forensic tracking, uh, kind of needs to be, um, both a mechanism through which any sort of related, um, laws or statutes can be enforced, um, and also as a deterrent, um, in a case where, um, for example, there is, um, an attack when there shouldn't have been or like when a record is or an asset is protected under, um, either international law or, um, an agreed upon standard or trade agreement, etc. Um. And so that kind of was the motivation there. Um. And then kind of thinking, uh, beyond that, um, there was also the idea that in some cases, um, the issue was brought up that, um, there could be potential replay attacks of old emblems, particularly in use cases where a digital emblem could be removed or put up more dynamically. And so having, um, a mechanism through which to verify whether a response received was in fact fresh, um, and reflected the actual state of whether or not there was an emblem associated with the asset, um, is definitely something that needs to be looked into. Um. I guess one of the caveats that I think that we probably need to consider is that, um, depending on how this gets implemented down the line, there still is a risk associated with, um, someone receiving a stale record indicating that there was a digital emblem and it was valid associated with a certain asset. Um. Particularly, um, thinking on concrete examples here, um, when we've discussed the press use case, um, how in some cases it might be rather dangerous, um, at certain times for either a member of the press or otherwise to publish a digital emblem associated with themselves or with their equipment or otherwise, um, and they take it down, that doesn't necessarily mean that a stale record of it will show up. So, um, I think that those things need to be kind of encompassed not only in potential requirements for specific use cases, but that we also need to think about those things when it comes to the security requirements.

**Rohan Mahy:** Rahel, going back about four sentences, you made a statement with a pretty complicated phrase structure and I was confused. I looked around the room, I saw several puzzled looks. So if you maybe you could rewind and and just rephrase what you said so that we understand what you what you were trying to convey.

**Rahel:** Okay, so in the context of proof of absence? Okay, so... I believe you were talking about the press use case. Before you... before you mentioned the word press. The risk of leakage that... leakage of the information that there was a digital emblem on asset X in the past because it gets replayed somewhere. It was kind of what I was referring to. Um. So basically what I was saying was that this requirement doesn't necessarily mitigate a risk that comes from associated with that risk of leakage. It would just allow for checking to see if you received a leaked record. Um. Or if you received a record that a digital emblem check... checked out, did it reflect the current state?

**Rohan Mahy:** Okay, so the threat that you're concerned with is merely replay of a no longer present emblem.

**Rahel:** Correct. Got it. Okay. Yeah. Anyways, it sounds like you... and so there and so there are, yeah, and so there are two potential harms associated with that. One is showing of an emblem for an asset that doesn't have it. Um. And two, in a case where the removal was due to like the vulnerability of disclosing that something was there or is there, that that information through the replay could still be leaked. If that makes sense.

**Rohan Mahy:** So when you use the term leak, I think a lot of people will be thinking that there is a confidentiality issue.

**Rahel:** No. I'm saying that like that it still gets that the fact that there was an emblem in the past that was published and perhaps it was taken down because the publisher did not want that information to be public, that the replay of that information still could pose a threat, if that makes sense. I guess a concrete use case would be if there's a reporter in in location X and they had had a they'd published a digital emblem but then realized that there was a threat to their safety and took it down, but they hadn't necessarily left that location. If that record, the record of their previous digital emblem got replayed soon enough after they took it down, then it would still pose a threat to their safety. Does does that make sense?

**Rohan Mahy:** It so I would be speaking... you know I don't have any further comment as a chair. But I guess the...

**Rahel:** Yeah. My point in including that was that I was trying to think about like security considerations of these requirements. The kind of a lot of the motivation of listing these requirements were some of the limitations that we had mentioned on in some earlier conversations about potential like general security considerations. I can try and pull them up and read them if that would be helpful.

**Rohan Mahy:** So my only observation there is that if somebody found this emblem and then posted a screenshot of the of using the DNS tool dig and posted that to Twitter or something, that doesn't seem like what you're describing is any different from it being posted to, you know, posted on some online forum. The security is identical.

**Rahel:** That is a fair point. Um. I guess what I'm saying is what... my point was that I was trying to be thorough in listing it, um, in thinking about how would a security consideration or a set of security considerations, um, play out here. Um. We might be beating a dead horse and I'm okay with moving on. If if that...

**Sarah T. Wood:** I think Jim is this a comment in relation to that or question to Rahel?

**Jim Reid:** Jim Reid. Sarah, this is a comment. Um. I think a lot of this stuff that Rahel's just identified is pretty much going to be addressed by using secure DNS. Because if the lookups are signed, you can a) first of all verify that the person publishing the data had the right to publish it because there's a digital signature over it and there's a chain of trust that ultimately goes all the way up to the root of the DNS. So we've got a reasonable degree of security around that from that point of view of being able to establish the bona fides of a particular emblem. Now maybe there's some other things at the corner cases there that need a bit of further analysis, but I think DNSSEC probably is going to do a good enough job for that. Similarly the issues around replay attacks are kind of also sorted to some extent with secure DNS. So I think we'll be able to deal with some of these issues, maybe not all of them, but I think we'll get a long long way by using DNSSEC technology to solve these particular issues. Um, but I would need to have a further detailed conversation with Rahel and others just to get a full understanding of what the issues they see are. But I think DNSSEC's probably a good enough way to deal with most of it. Another potential thing to look at here is what we might put into the as yet undefined DIEM resource record type and maybe there could be something in there like say some kind of digital time stamp that might help with that, but I'm just doing hand waving at this stage so just ignore what I'm saying.

**Rahel:** Okay. Yeah. I guess Michael in um so I guess I should probably explicitly state um some of what was going on, um which was that, um, part of my motivation for talking towards security considerations was that I think that some of these needed while broad, some of these needed to be stated generally, um when it came to security considerations for requirements, um and what um and what kind of issues need to be thought about or what would be appropriate to say when it came to security considerations generally about digital emblems. Um. Because yes, there are multiple different use cases and different threat models that will address different cases, which has been discussed, but um at the same time I think that even setting a framework for what are threats that are prevalent across many or most of the use cases, um or sets of requirements is something that's worth doing in this document.

**Sarah T. Wood:** Thanks. We have a quick question from Stefan.

**Stefan:** Stefan here. Small point about DNSSEC. DNSSEC is great when you want to be certain of something when you want to prove to yourself that there something exists or does not exist. It's less useful when you want to prove to a third party. When you want to convince someone that there's something was present or absent with DNSSEC. It's possible but it's not common. It's not really documented. It's not the typical use case of DNSSEC, so we may have some technical difficulties here.

**Rahel:** Okay. Yeah, of course. Yes. That is and. Um. So kind of thinking about other potential needs, um, some other things that have been brought up are tracking the creation and evolution of, um, assets and and or the emblems associated. Um. So, uh, some of the use cases that we've talked about have been, uh, have concerned transporting materials, um in some cases transporting hazardous materials. Um. And so in those kinds of use cases, um, having a record of how the, um, the changes took place, um, for example, in the physical location of the asset, um, how it was processed, um, either whether it went according to plan or whether there were anomalies, um, would be something that we would want to consider, uh, potentially supporting. And then finally, um, if there were any sort of requirement that, um, some entity be monitoring that transit as it was happening, um, being able to show a record that that monitoring did in fact happen. Um. And I realize that that, um, that is different and possibly conflicts with, um, the non-discoverability or the, um, forgive me if I'm getting the name wrong here, um, but I just kind of wanted to put a name to that because, uh, there had been some conversation about, um, kind of the, um, like when it need to when might it be necessary, um, to show that someone accessed a record, um, in, uh, so this was probably the best answer that I was able to give. Um, I'm happy to take any further questions or comments.

**Sarah T. Wood:** Thanks Rahel. Can I can I ask sort of do you have a preferred answer to these questions or a kind of a proposal or or perhaps a specific question to the working group that we can sort of use to help guide this discussion?

**Rahel:** Um, so I guess the the proposal that I have is that, um, the original text, um, as introduced in, um, some of the suggested changes specifically the pull request, was, um, to only expand the proof of presence. And I guess the broader suggestion that I have is that we kind of consider it it seems to me like there are multiple avenues through which there would be a need for forensic tracing. Um. And so I think that it might make sense to sort of change that section overall, uh, to talk more about forensic tracing. Um. We can talk about proof of presence as part of that. Um. But that it seems like there's a bit more to talk about.

**Mallory Knodel:** Hi, Mallory Knodel. Um, before we move off of this forensic tracing, um, I couldn't find, albeit though I didn't was not able to review all the discussion about this, but I couldn't find anything in the document on use cases about validation being a single source of truth no matter who's validating. I don't know if this is something this is useful, but like for example, if you're interested in detecting whether or not there's been, um, you know, a violation of the of the protection, um, but for different locations or different people trying to validate that you get different information, um, like for example in the DNS, right, but depending on who's asking for information you can give them different answers. Um. It seems worth deciding what we think should be the um requirement there and um I think it comes into the tracing issue most directly. Does it make sense what I'm saying?

**Rohan Mahy:** I I think that what you just said makes a lot of sense. I um I realized that I had in my mental model that a particular emblem type might decide that it needs to to give different answers selectively based on who's asking, but in the you know for example in the anything that requires protection that would not be the case, right? In the same way that in the in the um Red Cross, Red Crescent, Red Crystal emblem case that uh having undetectable validation is a requirement, but would not be a requirement for some other use cases, uh like for example the uh sites or diplomatic pouch.

**Mallory Knodel:** Yes. I think that it's clear we need to determine the right answer and then have some specification around that requirement. Because I can see I think it needs further discussion because I can see an issue actually with having different answers based on different validation.

**Rohan Mahy:** So um Mallory, I'm going to ask a a question and feel free to stay up at the mic and and answer for yourself, but uh if uh if we have a requirement that some use case needs to be able to get different answers uh based on who's asking, uh does that and adding that requirement as some use cases may need this, does that cause us any problem as long as uh as a use case doesn't have any contradictory requirements?

**Mallory Knodel:** I will try to answer, but I think this is a really rich area for further discussion by everybody. The issue I'm having with it though is it means like there's no analog to the real world and it means that some people can contravene this but other people can't. And I'm not sure that makes sense. What do you mean by contravene? I think you're assuming protection case. Well let's say it's a website so I could I it could be the website could be attacked based just on my origin IP? Yeah. So I think you have to assume not a protection use case. Not a protection use case. Okay. Well that's a useful starting point, right? is that for protection use cases there's a requirement that no matter where no matter the origin of validation or whatever that the answer always has to be the same. You can't split it by anyway. I think Felix probably. Thank you for teasing that out. Yeah thanks.

**Felix:** Yeah, hi. Thanks. Um, so one comment on this do people see different emblems somewhere. We have a bunch of positive requirements in the document and I think we are best advised to not discuss the negation of particular attacks as requirements, be it replay or be it um people see different things. If someone says, "Uh, we I think this positive security requirement is missing from the document for this use case," I think that's a great point to discuss. But I, for example, see the validation requirement already covering replay, because if you can replay an emblem in such a way that someone parses it as protecting something that is not protected, the requirement is not met. Similarly with this do different people see different emblems, maybe there exists a use case where we see where we say, we want to make sure that at all times people converge on the same statement in a transparency style approach, uh yeah we can discuss that but I would encourage people to focus on such discussions and also mention the use cases that have these requirements.

**Sarah T. Wood:** I think it seems uh an sort of reflection that tying this to a specific use case would help to sort of draw out how necessary or unnecessary the requirements are, uh sort of drawing on what we spoke about earlier. Perhaps Rahel if we can we can task you to to consider that, to go away and sort of within the use cases identified or or any other kind of use cases which of these requirements may need to be considered uh and and try and sort of put pen to paper on that. And that will hopefully help us to to kind of find a way forward.

**Rahel:** Okay.

**Alex Rosenberg:** Sorry, hi Alex Rosenberg. Um, I think just about every use case is going to want some kind of organizational tracking who created the record and potentially have that be signed in with the record, uh if if such cryptography usage is part of the the process. Um, and I think that includes IHL use cases, you know, as part of the the the need here for forensic tracing and I think it it's pretty clear. I think every use case is going to want this ultimately. I mean it's standard for every IT and legal department at every organization on the planet that they want this kind of information forever. So I think it it, you know, we have this requirement for everybody.

**Rohan Mahy:** Did you have any comment about selective disclosure needing having specific concrete use cases?

**Alex Rosenberg:** Right. But that that's it. I'm saying every use case has it, right? There will be um perhaps internal organizational identification for who created the record that it, you know, ties back to some internal system or an employee ID or perhaps an employee name, those kinds of things that they would not want to disclose externally. So it would be, you know, encrypted as part of the the record and signed as part of the record but not necessarily exposed to those who do not have those keys. Right.

**Felix:** Yeah, one final comment on this traceability. So the discussion was much more high level than the text suggested in the pull request. Um. And to me it's not quite clear what forensic tracing means. Uh that would need to be specified. Um. We certainly have the the um requirement from militaries for example that interaction with the digital emblem must not be traceable because they don't want to signal that they're about to attack an asset. It needs to be decided with concrete designs what the exact threat model is, whether there are third parties that you may reveal this to given that plausible deniability is sufficiently high. There are some nuances, I don't want to get into them, just pointing them out. However it's a critical requirement and depending what tracing means that may directly conflict. I can see the value for example in independent monitors so you say, uh "Hey, I'm operating this hospital in place X," and then you tell the monitor, "Look I I put out my emblem, please every now and then look and write down that you saw it so that later in court you can say you saw it." I guess that's fine. Everything else I think would collide with the undetectability requirement, which is critical, and already the prototypes that we put out that use the DNS, that use CT logs to some extent have caused eyebrows to raise among militaries. So yeah, we need to be careful there.

**Sarah T. Wood:** Thanks Felix. And thanks Rahel.

**Rohan Mahy:** So we do have we have quite a bit of time left. Um, we have a we have one slide uh from Jim uh as one of the authors of a sort of individual take on an the architecture document that uh the that is our next milestone. And uh we specifically rather than discussing the draft, we specifically asked him to come up with a list of of sort of open issues related in general that would allow us to have an architecture document whichever one or ones that may be.

**Felix:** Yeah, um just sorry to derail the agenda. Um as an editor I'm I'm very confused about the outcomes of today's meeting. Uh I don't I like if we leave it here I would just go home and wait for people to do things to the document. I I don't know what to do to it. So I would appreciate some guidance as to how we want to proceed on the use cases and requirements document. Multiple thoughts have been brought up um but I don't know yeah like they're just they're just floating around and I don't know how to continue. And eventually it would be good to have at least for me the plan on what what we want to do when we want to do it to finish work on the document. Because I would love to discuss Jim's architecture document in with more time and as the as the how do you say as the star on the stage.

**Rohan Mahy:** So Felix, we have uh we did have one one poll where we had strong consensus to go forward with the uh allow use cases that are that are not fully fleshed out. Uh we also we also asked specifically for um any traceability requirements or additional requirements related to forensics uh to have motivations that are related to um, you know, specific concrete use cases. And Alex gave a specific example that assumes that there's encryption. Uh that sounds like that could be, you know, that's that's something that we allow as as optional but doesn't require the DNS resolver to give a different answer. It just means that some of the information is not readable by by some of the some of the the queryers. Does that uh does that help you?

**Sarah T. Wood:** I think that's a yes in the chat.

**Jim Reid:** Okay, happy with what Rohan's just said. He said yes.

**Sarah T. Wood:** Thanks Jim.

**Jim Reid:** Okay. This should be very short. So first of all my apologies. Um, the requirements draft that I wrote is pretty much a stream of consciousness and I think some of the stuff is needing a little bit more of a better structure to it than it's currently laid out. There's far too much stuff in what's listed as the security considerations and much of that I think needs to move elsewhere so to reflect some of the conversations from Rahel and Felix that we've had. So there are a whole bunch of issues I think from a DNS point of view that we still need to grapple with. I think one of the biggest problems we have to think about is discovery. How will entities know where to look up a domain name or which domain names to use to retrieve information about digital emblems? Um, one potential solution is we anchor the digital emblem resource records with specific domain names for a specific purpose, for example refugee-camp.org as a possibility. Another scenario might be is if we've got a hierarchical numbering scheme for these as a hierarchical global registry for these, we could bang all these domain names under something like dm.arpa, like we used to do with E.164 telephone numbers, and then have hierarchical lookups so they're based on their serial number. That might be another way to do it. I don't have any feelings about this either way, and I think this is something the working group will need to think about quite deeply. Another thing that needs to be thought about, and I think work in this probably needs to start very soon, is a DM resource record type because presumably we're going to have some kind of resource in the DNS that's going to identify a digital emblem, and this could include things like the issuer, how long it's valid for, what it's being used for and all the rest of it, and maybe there might be a certificate in there too. But we need to start thinking I think about what that resource record type is going to look like. Getting the resource record type allocated will be a no-brainer. There's a lightweight process, uh 868-95 I think it is, expert review to get a new type code issued from IANA so that's relatively simple and relatively straightforward, but we then first of all need to think about what that DNS record is going to look like. I imagine it's going to be some kind of structured text thing, maybe JSON or whatever, but I don't have any feelings about this but again that can be worked out later. Something that was also mentioned earlier, um from um Rahel, was to do with this issue for the roles. We need to think now about who is it that's going to be issuing the digital emblems and how can we be certain that whoever is issuing an emblem has the validity and the authority to do that and how can that be verified. Now we can kind of do that using secure DNS signatures, but we need to think about who's going to be responsible for what and how those roles and responsibilities fit withhowever the issuing of digital emblems is done by particular organizations and I think there's going to be some rather icky governance issues around that. 

So things to think about for the next iteration of this document is: Do we think that secure DNS, encrypted DNS transports like DoH and Oblivious DNS, will they be enough to solve the problems that we've been thinking about in terms of anonymity and verification and making sure the integrity of the data is satisfactory? If it's not... if these solutions are not appropriate, what are the alternatives? And they probably won't be in the DNS, so we need to think about that. 

We also have to think a little bit more about how the use cases apply to DNS, and I've had some interesting offline conversations about that, but I'm still not quite sure how best to proceed. 

Another question for the working group is when do we think we could have a 01 version that might be ready for working group adoption? The document as it stands currently definitely is not. Um, and also I would like to see some co-authors come forward because I don't think this can be a one-man job or a one-person job to produce this document, and I'd be glad to see other people volunteer to come forward and help write this document or at least provide more constructive input towards producing the next release. And with that, I'm done and happy to take questions, bribes, beer.

**Arnow Taddei:** Uh, thank you, Jim. So, so Jim, I have a completely different question, I think on section seven on discovery. Um, so in fact, the point... and this is coming from something we... that popped up in in SG17 and I I just would like to naively um get your opinion. So... so when how is it going to work in practice? Um, let's say um a government would have some kind of a database with their with the assets they need to protect and they would have um something to push it to the... how do you call it, the DM-enabled authoritative server, and then it would do all of this architecture. I have no problem on that, but I have a problem before. So is is this how it is supposed to work?

**Jim Reid:** Maybe. 

**Arnow Taddei:** What do you mean by maybe? 

**Jim Reid:** I don't know. Um, it depends on how these things are going to be used and how, for example, governments choose to decide to to play in this space. If they've got a whole bunch of these digital emblems for whatever purpose and they see a value for populating them in the DNS, then it'll be up to them to figure out the mechanism to do that and populate it in the DNS. I'm not sure we can do a lot of that work in this particular working group because it's rather a question of how do I feed data to a DNS server. And that's that's probably not something we can do in this working group. 

**Arnow Taddei:** Okay. No, in fact that that's... got it. So that was not my question. So here is the... here's the problem I bumped into in... or we bumped into in in SG17. So for the use case of humanitarian side, uh no specific issue per se except that two countries put a reserve: Russian Federation and US. It's just a reserve. Okay. For the other technical report, the the the use case brought by Schneider Electric on operational technology, we only have a reserve from Russian Federation. US has no problem. Now, one thing that came from UK here was how would um the second use case be populated? Because their concern, what they don't want to see is that suddenly for other use cases, uh a certain country or a certain place should would have to create a completely new mechanism, new branch. They would like that all of them follow the same process in terms of whatever they have, how they feed it doesn't matter, but that they all follow the same the same flow, if I can put it this way. So sorry, I'm super tired, that's 30 hours I'm working with 3 hours of sleep, so I'm probably very confusing. But do you get what I'm trying to say or not?

**Jim Reid:** I think I do, but I don't think the problem you're trying to articulate is a real one. It might be more something of a one issue of perception. Um, I can think of one particular uh counter-example that off the top of my head. There was a technology called ENUM that used to map E.164 telephone numbers into domain names. Now that's essentially dead. It's not quite dead yet, but it's getting that way. But there was essentially... there was an opt-in process for member states. So a country's E.164 numbers would only get put in the DNS if that country consented to it. And if they didn't consent, nothing was populated there. And how they chose to populate stuff after that was down to each country. It was technically a national matter in ITU terminology. So if that's the concern, it can be addressed in that particular way without too much effort. But given what Felix was saying before about the humanitarian use case where the emblems would be tied to a specific domain name that's associated with a particular function, a refugee camp, a hospital or whatever, then the country concerns probably go away. But I don't know enough about the country problems you're trying to articulate to say one way or the other. 

**Arnow Taddei:** Okay, so then I have the same problem. Okay, let's discuss offline. Thank you. 

**Jim Reid:** Okay. Thank you.

**Tommy Pauly:** Had to switch to my phone, sorry for no camera. Um, to answer the questions on your slide, I would love to volunteer to be a co-author with you. 

**Jim Reid:** Who said that? 

**Tommy Pauly:** Uh, Tom... sorry, Tommy Pauly. 

**Jim Reid:** Excellent, Tommy. I didn't recognize your voice there. And I'm glad to have you on board. Thank you. 

**Tommy Pauly:** You're welcome. Um, the other thing is in regards to the technologies available to us for securing things, I actually want the architecture to simply elaborate on a few possibilities with an analysis of the threat model and not take any positions, simply specifying that the specific emblems must provide their own threat model and then their requirements. Like right now, I actually really like the way the use case and requirements document specifies this and says that both validation and authorization are optional, but once an emblem decides to use them, they must provide a threat model and specify the mechanisms. And I think the architecture should go as far as saying for things stored in the DNS, here are options and some of their known security properties, not by restating them but by referring to RFCs, and then saying that an emblem that needs to provide one of these properties must specify in this way and then end the section. Um, I would like to solve... I would like to answer that question as a working group within the context of each RFC for an emblem as part of the deliverable three, not in the architecture.

**Jim Reid:** Okay. I kind of agree with you, Tommy, so thanks for those comments. One thing I would say though is that I'm not sure it's a good idea to have a whole bunch of RFCs referenced in the architecture document because a lot of the people who are going to be reading that are going to be bamboozled if they have to read, for example, all the DNSSEC-related RFCs to understand how DNSSEC fits into whatever threat models they have. That's going to make people's heads explode because we're dealing with people that maybe don't understand a lot about technology in general and DNS in particular. So I think we may have to put some text in the document that outlines, at least in brief form, or outline what those threat models are and then refer people to the documents if they want to go dig into it in more detail. 

**Tommy Pauly:** That's a fair point. Uh I yeah, that's something we'll have to do specific text over because I all I want to do is not get into IESG review and have someone say like, "Why are you restating DNSSEC?" But there's definitely a middle ground somewhere. 

**Jim Reid:** Yeah. Got you. And I'd be lovely to just talk with you about that over a beer or two, Tommy. 

**Tommy Pauly:** That sounds amazing.

**Thomas McCarthy-Howe:** Hi, Thomas McCarthy-Howe. Um, I have a question. It seems to me like... and again, I'm coming in kind of late here and I apologize about that. But it feels like if the architectural questions are around provenance and knowing, you know, if it's real or not and... one of the things that we're not even talking about is lifecycle, let's say we've issued the emblem but we decided to retract it. Aren't these the essential things that SCITT is trying to help us fix across the network, and instead of using DNSSEC just as itself, using SCITT to be the transparency ledger that provides all those architectural functions? And by using SCITT, you wouldn't have to worry about, you know, the far end... but in my wrong about that? 

**Jim Reid:** Yeah. Good point. Something to think about. 

**Thomas McCarthy-Howe:** Okay. I'm... so I'm part of the VCON working group and we're using it pretty aggressively in understanding how we can manage personal data inside of a VCON, um and so, I'd be happy to share those notes with you as well. 

**Jim Reid:** Sure thing. Thanks for that. Um, having said that, I'll just say that when I was asked to produce this document, it was a DNS architecture document I was asked to work on. 

**Thomas McCarthy-Howe:** Gotcha. So so was that in the charter? Is that... would that be out of bounds for the group or...? 

**Jim Reid:** I I think we're pushing at the boundaries there, if I remember correctly, the working group's chartered to work on a DNS-based solution. But I'm sure our co-chairs and AD will correct me if I'm wrong. 

**Orie Steele:** Hi. I'm I'm your responsible AD. Yes. There's a... there's a DNS-specific focus for this working group, so and I've watched... been watching the chat. I mean, I know it keeps coming up but... um this is the IETF and and I think for us to be effective in producing emblems that are useful here, we have to be focused on technologies the IETF has skills and capabilities around. So just one more time as your responsible Area Director, yes, this is a DNS-focused initial use case for your current charter and please stay within your current charter. Thanks.

**Rohan Mahy:** Okay.

**Jim Reid:** Yeah. And just one last point, um we have to also remember that the DNS is a globally distributed scalable database. It's the only game in town for just about anything that might be the potential use for digital emblems in the general case. Um, so we have to bear that in mind too. I'm not saying that DNS has to be the be-all and end-all of solutions, but finding an alternative to it that could scale to that kind of level is going to be incredibly hard. Agreed.

**Sarah T. Wood:** Great discussion. Thanks all. Going to suggest people who've put comments in the chat, uh please consider taking them to the list so we can start fleshing out a conversation on the architecture document. I think Tommy volunteered himself to work on this along with Jim, and Alex also posted a a kind of an architectural draft as well. So suggest that the three of you in particular get together to start putting your heads together to to work on something.

**Rohan Mahy:** Okay. And particularly, uh if you have a question about how something works, um and you're bringing you're posting it to the list, please reflect on the requirements, and if there is a requirement which is vague or ambiguous or you think that there is a missing requirement, we especially want to hear those discussions on the list. And feel free to put "REQUIREMENT QUESTION" in all caps in the subject or something like that. Also, there was discussion about GitHub versus not GitHub. Um, feel free to continue to create issues on GitHub and continue to submit PRs. It's a great way to be very precise about what you want to say, what text you want, but that shouldn't prevent you from submitting that to the list, and we're we're going to see if we can find some people who can do a little bit of translation to periodically make sure that issues that are raised in GitHub, that they get raised in the mailing list and vice versa. 

**Sarah T. Wood:** All right. No, I think that's it. 

**Rohan Mahy:** Perfect. Thanks all, and we'll see you on the list.