Internet Engineering Task Force Interim Meetings, 13 Sep 2023

Previous Meeting

Next Meeting

⏯

youtube image

►

From YouTube: IETF-MIMI-20230913-1900

Description

MIMI interim meeting session
2023/09/13 1900

https://datatracker.ietf.org/group/mimi/meetings/

A

A

Everybody uh we're just at the start of the official time but uh I think we're gonna allow a few more minutes for more people to join and then we'll get started with the uh with today's interim foreign.

A

A

Can you hear me.

A

Okay, I think we've got enough of the presenters in the room now that we can probably get started since we want to dispense with the chair stuff and get to the the meet today. So welcome everybody to uh another me interim working group session.

A

um So, as usual, uh this meeting is subject to all the its policies on. You know: intellectual property and being nice to each other. So please note well the note well um and before we move on, we do need a note taker for today's session. So uh if anybody would somebody.

B

A

Volunteer to take notes.

A

So we can't proceed unless we have somebody taking notes on the session. So very we would very much appreciate a volunteer.

A

A

Thanks uh so for the record, Ecker has grudgingly agreed to take some notes. Thank you very much appreciate it um all right.

A

Let's talk now about today's agenda and Bash So today we're talking about um user Discovery, uh we're going to start by having a few different presentations on requirements uh so that because we need the working group to agree on like what are the requirements we're solving for before we get into specific solution proposals, so we'll be hearing an order from um Jonathan, then uh Ecker, who will somehow take notes on himself uh the Guile's and then Vittorio and then time allowing we'll look into some of the uh so some of the proposals for Solutions, though we do need to agree on uh what the requirements are before we do that.

A

um So are there any uh any objections or suggestions with respect to the agenda.

A

Okay, one last program note is that um the data tracker apparently is uh undergoing a large bot attack today, which means it might be unusually unreliable in terms of showing like the slides, that people have submitted, so we're going to do our best. But you know if you're presenting and you find that the wrong slides have appeared. uh Please just let me know and um I hopefully have like locally a copy of the correct, slides and then I'll just screen share to to present them.

A

Okay. um So with that, let's move on to I think Jonathan. Oh.

C

Can you hear me.

D

Yes and see me too,.

D

A

All right outstanding, sorry I'm, just going to find your slides, I.

C

You know I mailed them out like an hour ago.

A

Yep I put him in uh put them in the data tracker, but.

A

A

Okay, here we go okay, good all right. uh Just let me know what you want me to Advance the slides.

C

Next slide, yeah next slide. All right, so uh I wrote a draft on on requirements to try and uh get us a line on the problem. We're trying to solve um the most important thing is probably this picture, which I'm not sure we're. Actually uh this in the next slide, we're all even on the same page here. So let me uh she can't. You can't build a protocol if you don't even agree uh the the system architecture in which it lives. So in the framework here, the idea is that we have users.

C

These are users of messaging services. Those are the app providers, so app provider, one. Maybe it's WhatsApp app provider, two, maybe it's Facebook Messenger, at least according to the EU. It's not going to be iMessage unless something's changed, but uh but you know it's it's um it's some app here uh that that is a consumer or an Enterprise application. We'll talk more about those use cases in a moment and uh those providers connect to Discovery providers. uh It could be that an app provider is also a discovery provider, but we are building protocols here.

C

So we will support the case where it is not, um and so the app provider talks to the Discovery provider when they want to uh do a a mapping or a discovery request, and uh specifically that's like okay. One of my users wants to talk to someone who's or chat with someone. That's got this phone number or email address, so the app provider would ask the discovery provider.

C

Please map this email, our our phone number, which is a service independent identifier, to a service specific identifier, so the result will come back with a a user ID and a provider name or ID of some sort. That's the framework for what we're trying to talk about in this picture. Therefore, there are two protocols in question: there is a protocol between the app provider and the discovery provider and one between Discovery providers, so I'm going to pause there and see. Like do people agree. This is the problem we're solving.

C

I'm sorry say it again: I'm sorry say it again:.

E

Do you want Tim and I to run the queue or do you want to run the queue yourself? Oh.

C

No I I, oh uh oh I, wasn't going to run. The I didn't even know need to be run. Looks like Eric goes next, so, okay.

F

Honestly, I have no idea, um it might be depends on what that's right. There are other things we want to want to think about our, but I can imagine, I can imagine being new discoveries at all. I can imagine there being only one um so um yeah so I have no idea.

F

I agree the bottom half of their user cutting out providers.

C

All right, so is your: you think that what might the main thing you're not sure about is whether there's one or two Discovery providers, or that they are.

F

Separated, maybe they're not I,.

C

F

I mean so like I mean it's like so like I mean I have like sort of a not actually a straw, man more like an intuition pump on one of my slides, but it's like you know, imagine a world in which basically and which basically there's a global directory that everyone just downloads um and just keeps synchronized. It's not that big, like what's wrong with that, like I, mean I, don't think it's really a good solution, but I'm just saying, like you know, I.

C

Think in that model, in that model, we're saying that there is one Discovery provider and you're suggesting the protocol between the app provide and Discovery provider is not query but download. Well,.

F

No, maybe the user is done with it.

F

Like this is like an answer to a question, I don't know what the question is yet and so um so I think, like we gotta start with a question. Not that not not the answer.

C

Well, okay, but I thought the the the question I think we're starting for is how to solve the following user experience, problems which is I'm on WhatsApp and you're on Facebook, messenger and I want to type in and all I got. Is your mobile number and I want some and I want to be able to allow my meeting provider to connect to your meeting provider? That's.

F

That's something I think, but right, but I mean that what I described would do that right. There's like a global directory, everybody that was a culture every day and like it's a circle right I mean like you.

G

Know I mean I, don't know.

C

F

Not saying it's a resolution, I'm just saying we have to like have requirements area.

C

Okay, well we're not going to get very far like unless we that's why I'm glad I brought this picture up, because we don't think we should bother doing this like you have to at least assume this picture to do any protocol work so.

F

No, it's assuming some pictures. You have to do some pictures.

C

Yeah I'm proposing this one.

F

So I know but I'm saying that this one I'm saying that this one is a good one or not derives from other requirements that we have not established.

C

Okay, all right it'd be great. If you can elaborate on those, but I think we should give others a chance to.

H

D

B

B

um So whether or not this is the right problem, Discovery problem, the the right multi-provider Discovery problem to solve, like I'm, not particularly interested in this in this problem and I, would be perfectly happy if we defer working on this. For you know another say another year until we make more progress on other protocols, so.

D

B

That's why you know that's just one: one View and I will shoot up for the rest of this presentation, so so.

C

I uh and- and the good news is I- did know that Rowan I I do have some some of the other slides I'll go into give a little bit more use cases that motivate why?

C

What reasons why one might care more about this problem so we'll go through them, but but I understand uh that that's not high on your your priority list. Thank you.

D

I

Yeah I I broadly agree that those are the actors in this system. um They don't necessarily connect in the way that those lines suggest that they collect connect.

D

C

So, what's the diminance in your in your model in.

D

Your view, Can, you view well.

I

um Like the previous person said uh you, the user could correct connect directly to a discovery provider potentially I mean okay, I, don't think, that's how it should work, but uh yeah and I kind of agree with the the model, but in terms of requirements.

D

uh We should start with just the main.

I

Their user journey I think we should start with the the user Journey which is like, like you said, I have a phone number or it doesn't have to be a phone number. By the way it can be a it can be. Any kind of arbitrary identifier um and I want to discover the delivery point and the the delivery service and the.

D

Key distribution service for a a specific provider. Who has that who can deliver a message to that user?.

I

So I I guess I'm saying that let's not spend too long on this diagram I think the user journey is more important.

D

C

I think so the reason I keep coming back. The reason I put this picture first is first we're like.

D

C

I

C

Of maybe you can mute, maybe you can turn off your audience.

C

Thanks all right, the reason I put this picture first is like you can't build protocols without a reference architecture. We here at ITF build protocols. We need a reference architecture. The reference architecture changes dramatically the protocols. If you don't, if you think users talk directly to the Discovery services, this is a different system, um in my opinion, because it has dramatically different trust and authentication and other models and like down.

C

You know at least I would argue, download the entire Global user directory, probably not a good idea, uh Ecker honestly in the user case, not out of the question in the app provider case, um so it certainly changes the Privacy data location, other things so, like I I, think we have to agree on a picture or we're not going to make much progress on on debating protocols.

C

um Let me, let me address one of the things you suggested well, that you said: okay, there's a different formulation in which the users talk directly to the Discovery servicing Echo mentioned this. You mentioned this and I thought about it.

C

A bunch too I will say: I ruled it out in my brain, and let me explain why at least I came to that conclusion is I found it quite impractical and the reason I say that is um even ignoring the like I'm going to download the whole database, which again I think is not going to happen, but like hey. What about? Like a user? Just queries, this thing with a phone number or an email address, and it gets the result back like can't.

C

We do that um and at least I didn't think that was likely because it requires a um like I have to have a new entity like I'm gonna, that that my me, as a user and my application, software have a business relationship with. So, if I'm, a user WhatsApp now I somehow need to sign up for an account with or use some other third-party Discovery provider service. That helps me find other people and I. Just think that that's like not like that's not right, but it was a very impractical solution.

C

um So I was trying to focus on I was on a belief, the solution here and um yeah. Just let me finish before you I mean.

C

I'm, just about done so because I thought of the impracticality of introducing another actor that a consumer or Enterprise user have to build a relationship with is not only Troublesome. It also is a critical mass issue. Right I mean so like you need every user who has a messaging app to now sign up and have an account with this global Service. That seems unlikely to me now, I'll! Stop! You can respond to that. If you like chosen.

I

I think the whether the solution is Impractical or not, we should focus on the required. This session is about the requirements and I think you're kind of bleeding into the. How do we solve for the requirements that, like the requirements, don't tell you how how it should be architected? They just tell you what needs to be done and, and that can be done in a number of practical or impractical ways uh and so I think I think we shouldn't fall into the classic trap of mixing and requirements up with Solutions I'll.

D

C

Okay, all right, we'll I'll, give others a chance to comment then go ahead. Victoria.

G

Yes, yes, well. This also looks to be more like a solution. The architectural solution than a definition of the problem so I think we should start by defining the problem which, in my mind, is so to convert whatever identifier the user has and which is even a flange identifier into the information. This is like who establish the connection and gone, and so I mean the I I think that I mean, for example.

G

This already has the assumption that you have one or more Discovery providers, but maybe it's because I come from the email world and the email world does Discovery.

J

But does not Discovery.

G

Providers there's just one in this query, which is also what I try to I mean. Imagine in my draft so but before even getting to that I think we we should I mean start by defining the problem going through the use cases and see what are the requirements to solve them and then maybe we will naturally get into this kind of architecture. But maybe we also come up with something completely different.

K

D

F

I think I think I I, like largely agree with her I just said, I. Think like the like. There are a bunch of implicit requirements in um in in this architecture that you get you here and the biggest one is the um is the one embodied um on your slides, aren't numbered, but I believe it's slide.

F

um I believe um I believe a slight 15-year last slide, um which is that you seem to think that it is bad to have the mapping database and um and in General's presentation in San Francisco. He implicitly assumed the mapping, databases, public and I think enormous requirements here are derived from that basic disagreement about with me and so I think like. That is not a question, but like does that require knowing this architecture it requires, like a question of. Is it Matthew public?

F

So I would suggest that, like that, like we talk about like what are the things that drive, um you know the drive, the kind of architectural choices you think you think want to make I think that's really one of them um I think another one is um who should be allowed to assert identities, um yeah and I, think um and I. Think um and I.

G

Think, under what.

F

um If any administrative control of those assertions debate, which.

G

F

Is what you kind of get at with your with your Geographic restrictions? So I think probably those would be the things we ought to debate, um and um you know I exercise in this, but you see exercise in this too I think like I guess, I I would like to try to move there. I think I think discuss all those things without discussing any architectural questions. First, okay,.

C

I think uh got it I think that's a I think this is Fair coming it's clear. The read of the room is and I think this is an accurate assessment that there there are. If, uh if you look at my requirements, Doc and the slides, there are a subset of them that are fairly independent of the architecture picture um and there are those that are specific. So, let's, let's debate uh the ones that are independent of it and then see what we think it means for the picture. I think that's fair.

C

So after Rowan well, I suggest we close the mic and I'll I'll focus on those of the requirements. Ron.

B

Yeah I just want to point out. um You know, since we were talking about the public, the public option like keybase wasn't, you know particularly successful, but it was successful enough to get bought by zoom, and that was a less you know less stupid than just download a file uh public directory. Basically for for something like this, just as a example.

D

C

Got it all right? So why don't we stop the my okay? We got an oil left and I suggest we skip the next slide um because it's still in the architecture picture yeah go to the next one.

C

um So, let's, let's talk about the cardinality requirements, because I think that at least for the app providers I'm making a statement here and- and this is where I'll go through some slides and then I'll pause again for comments- that there could be a lot of them and I say thousands and we may not trust them. So, let's go through that. If those are requirements next slide.

C

So, let's talk about the cardinality of the the app providers and how many we're trying to solve for so I tried to sort of break these down into different types of use cases and, in particular, make sure we're thinking about ones that are maybe not the the top of Mind One. The top of Mind One is like the first category, uh which is consumer over the top applications. I think this was one we all pretty much understand. Well, it's like WhatsApp and wire and Facebook message. uh I also put iMessage in this category.

C

I'll come back to why it's why I said in just a second, so this is sort of the over-the-top not not affiliated with an operator uh of a telephone service or an email service, um and uh and- and so that's this first category- there's if you just cared about this category, there isn't a lot of these providers. Today we have The Gatekeepers, plus other vendors uh like wire, who are in the market.

C

I, don't know, maybe it's a dozens or so uh the next category is a really interesting one um which I was calling consumer operator aligned and what I mean by this is and, and the only one I think in this category is Google messages and I say that, because this is one where it's this, this app, this service is provided by your mobile operator. In this case, uh your identifier in the service is your mobile number.

C

um You up, you become a customer of this because it's on your phone in the mobile case when you get your phone from that provider or you sign up for them and it can't be decoupled.

C

um So uh so this is sort of Google messages. You might argue that hang on. Why are you even talking about this category because, like where you know this whole effort is focused on non-number aligned services, but but this is one where it's not it's not using the SMS Network, it's RCS in the case of um uh Google. Sometimes it's run by the operator. Sometimes it's run by Google um and we want to connect it. So that's why I listed to me.

C

One of the use cases like um I think is really interesting and I hope we can solve. Is the quote-unquote green bubble problem, which is Android 2, iMessage interoperability, and can we get to the point where you know I, don't have these big differences in the user experience and that requires us to solve the interconnection for those uh the reason I I think it ends up being a separate category. Is it introduces some additional interesting use cases uh around like transitions between numbers and porting and I'll talk more about that?

C

The third category is Enterprise Cloud. um So we mostly talk about consumer uh but um Enterprise again from a system. I think is in scope again, that's the debate. What we're going to have in a moment um that we're not ruling it out. We allow it to happen, and so here too you can say: there's Enterprise Cloud providers. These are people who provide messaging voice and video communication Services one to one and one to many focused on Enterprise users.

C

uh This Enterprise Cloud our Cloud providers, and so this is folks like RingCentral Zoom uh WebEx, my own company, five, nine, which does cloud connect Center. This is another variation on the Enterprise use case.

C

um We send and receive messages, uh and uh we would like to be able to do that by interconnecting with these other consumer providers or other Enterprises. uh The last two I include largely for completion. I, don't think these are significant use cases, but there's an on-prem Enterprise. Maybe you know Bank of America I, don't even know if this is still true, but back in the Heyday. You know people used to run their own call manager or jabber on-prem, uh and so they might actually request.

C

Federation like I can see a world in which a large Enterprise supports messaging voice, video one-to-one and group, and they go and request interoper the gatekeeper where they want to join the network to allow their employees to message to other businesses or consumers who are connected to This Global Network that effectively we're looking to build here with Mimi.

C

The last category is, you know the on-prem consumer case uh where again I I, you know I'm, like a I, got a Linux box at home and I'm running my own open source version of something that provides messaging services to my family looks a lot like the Enterprise on-prem, except the probability that I can request. You know like I'm, never going to be able to get on the attention of uh of someone to explicitly request enter.

C

But besides that, like that's the category, so that's a categorization I thought about, and and if you consider this list, you start to have a lot more vendors, especially if you think about the Enterprise on-prem case I, don't think there's going to be a ton of them, but there will be some, and you know it only takes uh you know 20 or 30 large Enterprises and you you've jumped the cardinality significantly so um I'll pause there. I think it's a good stopping point.

C

Do folks agree or disagree that this is a set of use cases uh that we are trying to support for the discovery problem.

D

Echo you're up.

F

Yeah me again, um I think it's a pretty good taxonomy I like most of my details, um but I, think it's a good pretty eyes on me. um I think, there's a really important point that you made that it actually got hidden between by me or probably by me, urging you to skip ahead, um which is um that you know you sort of say you think these are untrusted um and, um and so um I think that that is like that. That gets more becomes more requirement.

F

The deeper you get into the stack like it's not really pulls the Boston like there's any trust, relationship um and I.

F

Think that, like um that's, I, think that that's gonna become relevant like really soon in terms of like, um in terms of like again, this the public purpose of the database right or any essentially anything that requires correct behavior on the part of the um of of the of application providers, um uh you know, um is basically a non-starter as soon as you get like, like below enterprise, Enterprise, Cloud phase or even Enterprise Cloud, maybe right um and um and in particular like I, think just you know just to push on a tiny bit.

F

um You know, like um you know, if you imagine a system with some Oracle that contains the contains the database and you know, um and it tries to relive it, the rate at which you can and the way it tries to conceal the database about rate limiting how many queries you can make, which is basically what they can possibly do.

F

um You know if you allow anybody to join the system, then that is game over right, I'll, just spin up a thousand guys and all the whole query for a thousands of the databases, and this database is just closing this stuff right. So.

G

F

Is quite small, it's actually quite small, so I think um so I think like either uh like that actually tells us that we either have to give up. They already have to give up on something right if they give up on allowing random people on the system or if they go up on privacy database.

C

Yeah yeah so and and I think, even if you so thanks for that and I agree. Like part of the reason, I I I didn't again talk to the sort of trust ability, but I do think it's a fall. It's a it pops out of the categorization here, um but it even shows up in the in the top one like I I. Think about it like okay. So if I'm, you know, my job is in the business of spending.

C

Spam emails, um I'm, gonna, look at this thing and say: oh man, this thing is like winning the lottery like I'm gonna start a what looks like a consumer messaging app and it might even have real users like, but it's objective is to generate lots of spam traffic and sell it. I mean people. Do this, I mean.

F

C

I, you know I so.

F

Yeah so I certainly agree with a threat, but I guess I do want to resist a little bit. The Assumption you see implicitly making which that threat should be fixed by considering the mapping table as a personal example. Some other way, and we have a work example of like a system that has a factory a public bathroom table and um and and where Spanish person happens and like I know, people try to conceal like their email addresses. It doesn't really work and like. If you do, you should get plenty of spam.

F

Like you said enough email, you get plenty of spam right and so like I, just like I agree with you, it's all spam, but I just I think I want to resist a little bit. The notion that has to be has to be concealed has been fantasy, fixed by like by consume they're doing a fire space. That's not an obvious conclusion.

C

Okay, so just to make sure, let me repeat what I think you said: I'm not sure I got all that I! Think what you're saying is um you. You agree with the premise that they'll be untrustable providers, but that doesn't mean the database has to be private and and blocked from being accessible by those Bad actors.

F

And there's a practical matter like you know, but yeah there's a practical matter, an email right. You know everybody like not everybody's emails, probably people say military generally, pretty public and people try to consider email doesn't work very well, and you know, and and so Spanish suppression is based on content analysis. It's based on sender, reputation, all those things and so I'm. Just saying like it's not obvious to me that the place to fix spam is to make identifier a secret, it may be, but it's like it's an object.

C

Okay: okay, uh fair enough; uh okay, any other comments, at least on this.

E

Yeah, um there's Q, so I have a question and it's it's actually kind of applies to all of Mimi, not just to Discovery um something you and I've talked about before, which is that, if we assume that you know some of what's driving, this are the dma requirements, um and also just that, like the those who have the obligation to interoperate are going to have some measures in place to mitigate uh interoperating with other providers that they that they themselves don't trust who they think are the spammy providers.

E

Yes, um like I, think that bears on these last two categories, like uh if the last two categories really like blow open the number of potential interoperating parties, then that makes it much more difficult to negotiate on a bilateral basis, exactly which other providers I'm willing to interrupt with, as as a as a standalone or a gatekeeper provider.

E

um So I think I just want to raise that because, like of course like conceptually like we want to support all of these like it would be great to have as much interrupt as possible, uh but I think like realistically. My expectation is that it's actually gonna it's more likely that this is driven and towards like a limited set of entities that are willing to Federate with each other, and um so that bears on this discovery question, but it Bears on other things as well, and if other people agree with that, then that's meaningful.

E

For uh you know whether we truly consider those bottom two categories as like. First order use cases or not.

C

Yeah so I think there's two things that I would separate here. One is like the cardinality question and then the second is the trustability question and whether or not um the trustability problem is just sort of implicitly solved by the fact that you know No One's, Gonna, Let, You, just join this thing. You're gonna have to request to Federate with these Gatekeepers, so so on the first one like I, think, even if you don't go to the bottom, two, the cardinality is still pretty big.

C

um The bottom one. We should just eliminate I mean it's. It's not like you know. Joe Tinker is not going to go to WhatsApp and request interop anyway, but but Enterprise on-prem I think is a good chance um that a large Enterprise made what say: hey I generate enough massive traffic I. Look at my bill, like the amount of money I'm spending on delivering SMS to users that actually have WhatsApp or iMessage.

C

That I could reduce my cost, and my business users have a a need for communicating with consumers and in b2c use cases, and they need the feature set. That comes from getting out of SMS like it's worth it for me, and so I can see a lot of that and I can promise you. It's definitely worth it from an Enterprise Cloud. That's why I'm in this meeting I mean for multiple reasons, but that's one of them, like I, am very interested like I would go and request interact.

C

I would go like this musical to us as a business, so I think it's going to happen, and that means the cardinality is higher, whether they're all trustable or not. My view on this is like I, like the idea of defense and depth, meaning like there's multiple we want to I, don't want to go with a model that says we assume they're trusted, because no one is going to Federate with them unless they were trust in the first place. You know I I, like that.

C

There's a check on the Federation that we're not going to get terrible people in here, but I would love it if our protocols also dealt with people whose behavior is not great and that that's why I continue to focus a lot on the untrusted case and I think it shows up at the consumer Ott case again.

C

I think you'll have cases where people there are a lot of businesses that sit on the fuzzy line of whether they're legit versus not um that you know um are hard to know and I think the more we can um protect uh against that I. Think the better thank.

E

You, okay, I, think that's fair, but just to come back, you Did you sort of drew a line on consumer on-prem and you're you're. Fine. If, if the requirements don't support uh those scenarios- and it would be good to hear from other people if they.

C

That's my view, yeah that we should support the top four of these yeah.

E

Yeah, okay, thank you.

C

You'll see you next.

I

um I, don't think bilateral agreements or Federated multi-party Agreements are the only way to ensure that you have trusted actors in in the Federation. You can also use you know, certification, programs, or something like that to set a minimum bar of trustworthiness.

I

um And then also you can have you could have if you wanted to include the last two, you could have sort of to disjoint federations, where the trust is established differently.

C

I

C

Don't quite follow that one? What do you mean some other federations where the trusted scholarships link? Can you elaborate.

I

For the for the consumer for the.

C

Well, let's, let's get Let's ignore the consumer on-prem! That's just not going to happen! So just let's focus.

I

No, no for the first two consumer ottm consumer operator line. You could have you know, 50 bilateral agreements or whatever as a way of establishing Trust, um and you could have them as an island playing together and then for Enterprise or consumer on-prem. You could have a certification requirement that requires an audit.

D

Or something and.

I

uh And have that as a completely separate Island of interoperability.

C

Okay, for what's worth I, do hope we can get away with like the goal. In my mind, of the Mimi effort is to not require bilateral, although if we only if the only thing that mattered was bilateral, you can you can argue, we don't even need to be here. As a working group right, um you know, um I think the idea I'm hoping is that it's more of a you know some kind of group Federation um um it.

C

You know whether there's multiple I guess, but um all right, fair enough I want to make sure he gets everyone in the queue tutorial.

G

Yes, well, um I, understand, I, think it makes sense to consider who would be the the early adopters so to make sure that it makes sense for them, but at the same time, I don't think we should preempt the business models and the types of deployment that we will be possible.

G

So we should design these in the most flexible way that we can imagine so that any even future I mean different way of putting me into something can be supported, and so this implies supporting any number of in any type of of services that want to interface and interpret and.

I

G

Actually, if you think of like metrics today, there are people that sell for the dramatic installation and we want to be part of this new Federation. So even the last part I mean the last item on the list. I, don't think I, don't think you can just roll it out.

G

Actually, I, don't think we should build this thing for like a centralized warning, which you only have a limited number of operators or so, and once you start to assume that you can have any number of of the services that want to interoperate, then I mean it's really any number so I mean you do like an email and, as I said in taking this by analogy for email and in email, you you deal with a stability problem with I mean at the higher level, with reputation with another number of things, but not by building a protocol that basically excludes some possible types of image service.

D

G

C

F

D

F

Got up to say what Victoria just said, which is like.

D

F

Designer system, which actually in principle, could work for like all these all these cases- and you know it's like not like you- know- I- think where the dma um you know proposal is not like the world's greatest in our ability proposal. It's just like it's a make work um and you know they'd be any better if we didn't rely on that, so I think you know, while I think you know I'm happy to have something if we don't really have their own problem.

F

I guess, like that's, that's like something we can do, but like I, prefer designs that didn't exclude solution for the general ball. If we could um I think one more thing, I I, um you know uh um I'd like to mention here. um This is going to become like really relevant. um We start talking about um about identity.

F

Is you know, we've been talking a lot about the price of the database right, but one question is what identities come from and impersonation is much worse than database Revolution, um and so um you know um you know, even if I was willing to like you know, trust uh you know, uh Joe Tinker, with copy the database. I, probably would not be willing to allow them to search any phone number that he wished to insert um so um so we're clearly design. It does not require uh I, don't think requires such thing.

F

Almost I mean someone doesn't require trusting anybody below like a consumer operator or line, and maybe not even me and and Ideal World. Not even people love it right. um So.

C

Yeah I agree: that's that's a good lead into the last slide, I'll probably get to um so if we could go to the advanced. The next slide, I think we'll end here.

C

um So this is to me the most important core requirements: they're not specific to the architecture. One is we have to support like functionally work, provide a mapping whether it's by a lookup or a download or whatever I, think this one's probably super non-contentious um the echo's sort of talking about the next one, which is the hard problem right, which is how do you make sure the mappings in question are valid and trustable, um and that's that's that isn't to me.

C

That is the bulk of the problem and it becomes super hard if you convince yourself that we don't necessarily trust, even if you think the provider is, you know respectable organization like do you trust their assertions on which phone numbers and email addresses correspond to the users in their system like just for me like? Maybe they messed it up or what, if they're wrong like I mean these all come up and the system has really bad properties if incorrect data gets into the system so valid and trustable is a key property to deliver and I.

C

Think it's really really hard. um The third one is sort of scars that I have and others who are in this in this session that have been doing this for a long time. um You know this is not the first time we've been in working group meetings that have tried to solve the oh. How do we have a way to look up things that aren't hierarchical and map them to some service right?

C

This has been tried multiple times, um you know, enum, being the the one of the ones I'll call out is as a particularly substantive ietf effort that that largely didn't work um it it got some deployment, um I, don't know if we have John Peterson on that I mean here, but but he reminded me that this got rolled out in private environments, but the but the public deployment of enum, where there's a public Global database never manifested itself, and one of the reasons this is super hard. Is this network effect problem?

C

So if you need to create a new database that has mappings in it, you have a networked effect problem, which is like well, the very first user that wants to consume. This database gets no value out of it. There's no entries in it. You can't do anything with it and so they're incentive to contribute mappings, for example, is also low because, like they're not going to get any value, other people aren't going to get any value. Until this thing has a lot of data in it, it actually isn't useful, and it's this.

C

You can't underestimate the challenges with this network effect. Cold start problem, and so um I don't want to do another repeat where, like oh I know, let's, like invent a new, you know Central database and everyone consumer apps directly write this data into you know. I I have an app on my phone that uploads my data and that great, like is not gonna. Work like it's. We've tried this kind of thing like many times, enum Viper.

C

um These are all attempts at this and they didn't work so I I think something that doesn't explicitly acknowledge this and try and solve it uh is pretty important and and the the last one is again uh related to this, which is like, what's the incentive to populate these mappings right, and you know, one answer: is it's obligated by regulatory agency?

C

um Maybe there's other rationales for it, but you know I think you have to you have to really understand that as part of the solution. So uh there's only two minutes left before the next agenda item. So I think I'll stop here and see. If there's any comments on this.

C

Wow, surely someone disagrees with something on the slide, so you can't go to an ITF meeting where everyone agrees with everything on the slot foreign.

C

E

um Well, I mean maybe just to reflect a little bit from the chat and get the people into the queue uh I mean I, yeah, I, think I. Think people assume number three and four are will be taken care of in this case, not in the like the naive way, but in the like, you have providers who are like the it's, not the tail wagon, the dog right. It's like none of this is going to work at all and like they have to make it work and therefore, like things, will be populated with mappings right.

E

So um so maybe that's part of why people are quiet and then and then the top two are like functionally. These are the only things that matter right like it has to work and um and and just be trusted. So.

G

I don't know I feel.

E

Like I feel like yes, I like agreed, but some of these are um are the basis for the very discussion that we're having so yeah.

C

But I do think that number three and four manifest I I agree in the end. It it's not. Basically it's going to come down to a gatekeeper is obligated to put their database in this thing. There's almost no other. Almost no other thing that works. um The, however I do think the way in which that manifests is relevant.

C

Like I, like an answer that says I know we're gonna have WhatsApp like our solution is, is that WhatsApp and Facebook Messenger have to like take their their list of phone numbers and email addresses and like publish them on a public site like at least to me that everyone downloads onto their device I think the odds that someone like I, don't think they're gonna agree to subject I think they would make arguments that that's not a good thing, uh so so protecting data figure out a way that this minimizes the exposure of what would normally be considered business sensitive data to the people who own this data I think becomes a requirement because of this thing,.

D

F

Yeah, so you know um you're really shocked, to hear this, but it used to be the case that you could just buy like a book that had like everybody's phone number in it, and you could just like buy that, and it was like just page through it had a name. It's like an index right.

C

Drop it at your door, though, like did.

F

They they didn't like I mean um uh you know it was. It was like dead trees, but you know, but there was a book um so I guess I'm like less I'm, like less persuaded by the Privacy point, but um but but I think I. Think you're sitting back for for a second um I. Do think that, like you know, I I do think. Why do you think we could bungle design so badly like no one want to use it, but um but I I think basically like I'm less concerned about this question of.

F

Like will people be willing to um to populate the database um because, like everybody who, like everybody's a big player, is either gonna, do it or not, because they were forced to I think they would have done already if they wanted to? And then all you do it now because they're a force too, and so like I, think you know. Oh it just to be better. You see better than like alternative.

F

um You know um which, like.

G

F

Know and whether it's database centralized the mechanism whatever it is. People are in the publishing of this because they're being made YouTube right and so I think it has to not stink and I. Think it has to be the other requirements that, like that you've laid out here but I, think there's a requirements um like you know, I think people well again. Not do it because, like because, like it's like in the wrong there's a technologically a goofy yeah.

C

But I think, but this is what's interesting- is in my mind if you acknowledge that there are providers who have numbers that are not WhatsApp or Facebook Messenger, who are obligated to do this by the dma, but they have users and those that data has to be populated in some way. We like that's to me where the heart, some of the hard parts of the problem, is like how do we? How do we trust that?

C

Do we have to trust everybody equally in this system, so that, like if you join We Trust, whatever numbers you tell us, that's one.

F

More, no, no, no, no I, I, I I think that won't work right, um um uh I think you know, as Richard Burns who's got the queue would say um you know. Trust is a bad word, um uh so you know um I certainly think it is on. It does not require you to trust these, that any assertions provided by um providers like is like it's like imperative. Basically of these for smaller providers and probably for larger one.

D

F

Eventually, for eventually for a lot, I mean like just just talk about Philosophy for a second like we're trying to we're trying to like retrospectively design the system. That is a system we actually wanted on the backs of these systems that already exist and having to make a bunch of compromise, because the systems are already yes, which is the point you made a number of times right and so like I think, respectively.

F

If we have to like accept that, like WhatsApp doesn't lie, but the phone numbers for a while, like that's, probably like not the best situation but okay and that, but that, like five nines, has to prove they're, not lying I mean that would be like an okay solution, at least for me, and not for you. I.

C

Think that's what we need like that's what I mean my proposed solution. Basically had that bifurcation, it said we're gonna, we're gonna, we're gonna, minimize the trust and set to the fewest number of providers that we trust the most and everyone else has to be we're going to verify their numbers because we don't believe them like.

F

C

All right, I think we got time for one more before we switch uh to you and I'll take notes, while you're speaking accuracy, you don't have to what last comment.

D

Can you hear me.

C

Yeah now we hear it now.

I

We hear it- oh sorry, yeah uh as I said in chat and every major messaging provider today already makes their database public and the only protection on it is rate. Limiting, um so I can look up a key. You know. I can look up a key on WhatsApp or uh your identity, key on WhatsApp or or Google messages.

I

It's completely public and the only the only protection is is rate limiting. So we wouldn't be changing.

C

You can't enumerate it as a consumer, you cannot enumerate it.

D

I

uh I, don't understand the that point. Sorry I.

C

Signed up for WhatsApp, it's definitely true: I can put in a phone number and I can see whether it's another user on WhatsApp, like that's a required feature of the product. But what I can't do is download a database whatever 500 million users, 100 million users and get and find out.

I

Oh yeah, but that's not I, don't think that should be a requirement here. The requirement is I need to be able to look up. I need to be able to look up as a client. I need to be able to look up the keys for a for a given phone number and obviously I can I can Brute Force the database by doing that, but I I don't need to be able to like.

C

You can't you can if we have rate limiting that's, why we're getting into Solutions yeah. Exactly for me the but I guess for me. There's a requirement here and it's more security requirement and then echo's going to cover that so I'll go into it, but like I, am opposed to Solutions the solutions with enable and enumeration attack by an appliance in the enumeration attack. If there's a wave attack, it is database that gives me Business Services.

I

But they are public already today. That's that's my point.

C

Where do you go to download the list every day? You can't do that today.

I

um You just do a look up for the keys. I mean you, you would be throttled by rate limiting for.

C

C

We're agreeing on that. The only thing you should be able to do is you will look up at a pace, that's appropriate for your use case. There.

D

Is no way for you to get it up.

C

That's all I'm saying.

I

Yeah- and the other thing I wanted to add, is uh I I, agree on the Privacy requirements of the mapping database or not important, but as I said and I put that as a non-explicit non-requirement in my deck, but there's another privacy requirement, which is very important, which is the privacy of the lookup query itself, because that leaks. Your communication graph I.

C

I agree: I I, in fact largely based on your presentation, ITF and documents. I I thought that was a pretty good idea, so, at least in my requirements, document I enumerate this requirement. It's later in my slides, but Echo is going to cover this area. So that's a that's a good lead-in uh to Ecker next on the agenda. Thank you.

E

Thanks Jonathan.

F

Charles, can you make sure you mute just okay um if you haven't already just because otherwise we had a lot of echo. Thank you um uh next slide.

F

So, like I think this is obviously this. Is this slide just like Recaps Lane Johnson's already said, which is you know you have one or more I said eyes, um you know, um uh you know Alice in one of Versailles. You know he signs up for some applications, a right um and each application.

G

Is own SSI.

F

um And Bob has Alice says Ah and she wants to contact. I also got to Ellis, and now he needs some mechanism to look up. um You know, mapping the mapping table um and and maybe associate game material that happens and other other mechanism. Maybe like you find out, it's like it's. There are WhatsApp and you ask WhatsApp for the game. Material I mean so we need some kind of mechanism service whatever for that. So I think everyone sort of agrees on on that. However, it actually works out.

F

um uh One thing that's sort of like um uh that, like I, want to just uh lampshade and then not talk about is we haven't decided whether um Bob gets like the entire set of mappings there's one mapping um uh and- um or maybe it gets to say, like give me one that being the court that is out of my list or whatever um you know we can deal with it later, but I but I know I'm not on that, um and it might be a relevant question.

F

Okay next slide, so I added this, the very uh at the very last minute, but um this was chatting about earlier. um You know: here's like an intuition pump, which is not intended to be like a national system but like to be, on the contrary, like look at this and tell and look at this and keep it in mind as you as you decide. What you think is wrong with this, so you know what you should be trying to fix. So here let the motion to eat possible system.

F

You know um you have a certificate, Authority and some kind of called public directory. Actually you can even have the public directory generally, but I think we all agree, that's bad, um so out is- and this is like just the webpack right Alice get certificate um by proving that she can receive messages at this phone number this if it gets issued, I'll put the certificate of the public directory and then Bob when he wants to like talk to Alice Dallas entire database, or that was a segment by you know.

F

My phone number or area code or whatever, right um and so privacy is provide. Unusual can in many sense by like saying what bigger fragment the database does Bob download. Now, obviously, you could staple PIR on the on the Arrow five here. If you wanted um so again, I'm, not here pitching this proposal. What I'm saying is like bear this in mind.

F

A lot of things that we're talking about over the next eight slides are seven slash our deficiencies with this picture, and so and so so every when you look at this, like this sucks, try to think about.

G

F

This sucks and then we can talk about about what what am I trying to fix um next slide.

F

Okay, so um as I sort of opened with earlier um I think actually the most important problem is not in these privacy concerns you're talking about, but rather the security of this SI and SSI method, and that is, that is to say, um uh um by the way, I'm not watching the queue. So someone will shout at me when I should shut up. um I am now actually um so, uh um like you know, I have a phone number and is the case.

F

Any provider can really assert that I am using that provider with my phone number. That's clearly not okay, if there's a multiple City providers that have like more than a very small number, um uh so who's allowed to assert it, and so I can tell these three possibilities.

F

um You know one is um you know that if there's a discovery service, the kind Jonathan's been contemplating, that's the one person gets asserted, in which case they have to verify it in some way, um there's an apple or maybe the application whatever it is to assert it. In which case do they say what stops the application provided from asserting an SII that doesn't actually own or maybe only a user can assert it?

F

um You know hoist It Again by maybe some kind of like um you know when apparatus, as in the diagram a minute ago or by direct direct validation, as in spin, um so I think um you know. Obviously all these things um uh implicitly assumes the phone network. If it is phone numbers accurately wraps things, but that's just an assumption. I think we have to make because the only way that way from validating these as I is, is forward running um so uh I guess um so.

F

I think I I think we I'm going to stop at that. Each of these slides so I think like what is it? What are people's expectations about? Who gets to make these assertions and how.

F

uh Jonathan I'm pretty sure.

K

Yeah, this is just a minor terminology: knit uh they go along with trust. Another brand I hated security, um because you know it usually encompasses multiple different attributes of what you're trying to protect uh I. Think I just wanted to put the fine point here, like you're focused on Integrity here, yes, the mapping is you know the the SS SII is only Associated to an SSI. If, in fact, that mapping exists there there's a user who has both those identifiers.

K

Characterization property, okay,.

C

To join the queue- and it's not like giving me the option, uh you're.

E

C

All right uh so I, I I, think the answer is that we it's this split trust model. That's what I think we have where there is a small set of application providers that we do trust to provide the mapping only because we have no choice, because we have no choice because of the bootstrapping problem, and you pick one or two and I don't know who's gonna pick, but there's a small handful that are trusted to provide the mapping and for everyone else, a discovery.

C

Service itself is responsible for generating the mapping because we put the discovery service in a in a sort of a more trusted Camp. um That's what I think the answer is.

F

C

You definitely don't trust the end user I. Just don't think I, don't see any useful way to do that and.

F

In this in this, in this version, The Discovery Source will independently verified that you you possess, that that that's how.

D

F

So like how I like first, we said to an SMS and require you to respond to it.

C

Yeah yeah, so so, for example- and this is what was in my proposed solution- was the discovery service basically runs the mobile number verification process that everyone is used to uh it's embedded within apps you use.

C

um So, for example, let's say I start a new messaging company, you know Jonathan's messaging or us uh I want to be part of the Federation I connect to it. um My UI still asks the user to enter their number. My you know my mobile provider sends it to the Discovery service Discovery service. Does a validation, creates the mapping. The consumer doesn't really know that it was done not by their mobile app provider but Outsource. In the same way, people use twilio for the most part to do it.

C

I'm suggesting a similar number, a model where announced up on the Discovery service.

F

Let me just push this a little bit like. Are you saying? Are you suggesting that the um the discovery service would persuade itself that a given user was associated with this with like who? Who would that authentication be owned by that? Is the user or the or of the AP, mainly because the AP simply claim.

D

um Because the APA.

F

The ape like do anything it wanted once um you know, like imagine, other Associated data associated with with the um with the mapping, not just not just the SSI right, a key, for instance, would the AP be able to escape all on its own key.

C

Yes, so it in the in my model, like there's a the the the there's, a core thing, which is the Discovery service, just Associates, the some identifier provided by the AP with that mobile phone number and agrees that that's true and that that that verified fact is passed back to the AP. And then the AP can, you know, store whatever additional data it wants associated with.

F

It okay! So that's different from from, like my my diagram above where it's like, there's a credentialism with the end user and then usually the only one who can start facts about themselves and they might assert that they make a research about the about the AP.

C

Say that one more time Echo sorry sorry.

F

That's different from the from the from the sort of straw man I showed at the beginning, where the user demonstrates ownership, perhaps with the ap's app um but they're. The only ones who can make assertions about themselves so like the AP would not be able to staple on a new key. In that case,.

C

Right, the AP is not able to make the assertion, except for I'm, saying I, believe they'll, we'll have to make exceptions for like a.

F

Small number one sorry, sir I think we're I, think I, guess I think we're still me talking about each other. I, don't want to take up too much time in this piece, but um like so. What I'm saying is that one of two things can happen. One is that um so the current in the current system.

F

We agree that, like the giant provider, a will be able to write anything any copyright that wants to write in the databases at once, right, um yeah and um and that when I want to associate my SII, which provide a smaller provider B, which is not permitted to do that, um then um then one or two things can happen, one of which is provider B persuades the discovery service that it controls that that this user controls the SI and then from then on provider, Beacon right any crop it wants for that phone number in um in the database.

F

Another possibility is that um provider B facilitates an authentication transaction between the user and Discovery service, and then the user gets to write stuff in the database provider. If you can't honest.

C

F

Guess I don't think.

C

It's quite either of those two things, but it's closest to the second one.

F

Okay, um okay, jobs.

I

I think it's unlikely that we'll have separate a separate, a discovery, uh Discovery service, that's separate from the messaging providers, and in that case, uh every messaging provider will be basically responsible for their own for phone number, verification or other other form of identity, density, verification, and there might be minimum standards of identity, verification that they decide to apply between. Among that Federation, um much like a certification Authority like they are basically certification authorities.

I

um So, even if you have a separate Discovery service.

I

uh That Discovery service would still have to kind of meet a set of requirements that you would apply to a certificate certification Authority um in order to to play in the system.

I

Does that make sense? Yeah.

F

I think yes, it's so you're saying basically like these are all self-asserted, and then we have standards for something from y.

D

J

Hello, um uh so uh I, don't know if you mean we need to solve this problem like I. Think it's a it's a very complicated problem um and you know, like users, came already today, potentially like access the app with them like.

J

If you know somebody on WhatsApp um like has the phone number, they can already kind of go to WhatsApp and be able to kind of look up that phone number and like there's nothing guaranteeing that we will have that, like you know, security of SSI SSI mapping um from the actual native app, so you know try them from like MiMi to kind of solve that problem. Where, like you know, people can kind of circumvent.

J

That is feels a little weird like you need to kind of have a like an almost higher level um like at an operating system or, like you know something in the um like that is controlled by the actual SSI provider that will solve that problem for everybody, but I, don't think we as Mimi need to solve this specific problem.

F

Okay, I'm sure.

K

Charles used the word certificate Authority, so I had to pop up like like Beetlejuice, um but I actually do think. That's the right um kind of metaphor here that we that pretty much regardless of the solution, you're gonna, have some trusted authorities. If you don't have some interestability, it's all peer-to-peer verifications that are in scale, um I. Think the question the interesting question here is: you know who those authorities are um I.

K

Think that's jazz is probably right that it's going to be challenging to have any third party Authority here, I wasn't like completely ruled out in principle having something like that's encrypt stand in where there's you know some Authority that you know Bridges us, maybe maybe you know that let's encrypt like they would stand in for a bunch of you know. Second tier providers who didn't have enough verifications or establish their trust learning. This is verification services, but at the same time, I think.

K

It's also plausible that you, you know, even in a regime where you had like you know, cab Forum, like standards for what you know. Validation should be done uh before asserting one of these mappings.

K

um Like you, you could apply those sort of Standards to the providers themselves, and so it may be that, like yes, you know, there's you know this, you you think of this thing as an authority of some sort, but um um you know Google's messages and Apple's, iMessage and WhatsApp. Are you know they? They are willing to prove to each other into the world that they're they're acting up to the standards that everyone's agreed on, and so they are trusted as authorities.

K

um You know in particular for for their users um and in fact you see this happening in the web. Pki where, like Google, Trust Services, is now a webpki Authority and they offer certificates for folks on gcp.

K

um So it's not like totally unprecedented to have that sort of model um I, just also just one of the responses to what Basel said about not solving this problem. um I think this is kind of the the problem that we have to solve for MiMi, because it is this Integrity problem is you know the impersonation and redirection problem?

K

So if you don't have some sort of solution here then, like you know, honest documents, House of messages is going to be able to pretend to be Ecker, and you know get people to spuriously connect to uh to on this document and when they think they're connecting to Ecker, which I think is not going to be an acceptable security outcome for the system.

C

I think we're making progress and that we're starting to get to sort of the root of some of the disagreements, right and and I. Think one of them is this, this one that Charles just said, which is that the app providers can be trusted and in which case you know, and we and we and we create that trust by audit or rules or whatever um and and I'm, not so sure, right um and, and my view is a little different which is well.

C

Maybe we could trust a few of them, but the cardinality is high enough and that's sort of why I went through this other use case is when you throw in Enterprises and B2B SAS, vendors and small consumer players. You know there's like an exponentially increasing risk that you know your audit aside. You know, one of these guys is going to either maliciously or accidentally created invalid mappings I.

C

Think that my view is that probability quickly, Rises to like 100 and therefore we need a solution where we we have a a different entity to which we can apply a much higher standard, because you could say the same thing like hey: what prevents the discovery Provider from being really bad and misbehaving and I would say: well, it's going to be like Audits and rules and governance and Jill said. Well, that's exactly what I'm saying, except do it on the app providers? I.

C

Just don't think you can do it on the app providers because they are Enterprises, they're, B2B, SAS vendors. There are small consumer at home shops that need to be allowed to be part of this Federation, but there's no way they can either execute the rules that would be required for them uh or, more importantly, we don't trust them too, and therefore we need a smaller set that we can impose really stringent requirements on, like you know, Hey where's, the guy with the uzi, you know protecting the computer with the mapping database. Like that's a requirement.

C

You know machine gun predicted vaults of this, so you know you can't do that for everyone who's in AP. So that's why I I feel there's a need for uh Discovery Service as a separate entity. Thank you.

J

I mean I'll jump in I think this is like. The problem would exist like completely outside, like the reason I don't think Mimi should solve is because the problem exists outside of Mimi right like if I go to Google messages and WhatsApp or whatever and I, look up an SSI SII, sorry like they are claiming to have that map Aid and so like whatever we do.

J

We're not going to be able to solve that specific problem like because it's not an interop like messaging happening is happening within the app, and so uh you know, I do think that's something that we need to potentially solve I. Just don't think that this like place is that this is the right place to solve that problem.

F

I I guess, like I, I, think that what makes our problem is that it became providers right like in in the current environment, like when I enzyme measures, I'm trusting that Apple has verified that that I binding, but but then when well, but if I allow Google, who I don't processarily to kind of to claim that they have that binding, then what happened was that is exactly the in our ability. Crease. Then you just solve this problem.

J

But you know that you know the problem can kind of exist like also like within people or, like you know, looking at with an apple like somebody, who's like look up some user with an apple like how do I trust that apple is actually doing the right thing there right like just because, like one person has potentially a trust in apple, doesn't necessarily mean that everybody can be able to trust an apple. No.

F

But I think the people who bought Apple vices crushed Apple.

J

Not necessarily.

F

Well, I understand that's inherent design as a.

J

F

Of a closed system like that right, is it like those are? All closures are designed to operate this way, but we're.

G

Talking about an.

F

Open system now do I wish Apple had like a public PPI I do um but like it up.

J

That's what I'm saying that's why I'm saying we need to solve that problem independently of Mimi right uh um and like looking at it kind of holistically across the industry, to kind of provide like a much better security guarantee for like stuff within the network and outside the network.

F

Sure, okay, well not sure what I progress at this point.

F

Do you reopen the cues I guess it's Roman.

E

I thought we could maybe close yeah.

B

So I just wanted to comment on what Richard said about this like we need this, we Mimi has to do this and it's a super high priority and when he said this um I think he was conflating two things. I think he was conflating that if I decide to go in peer with a hub provider and I set up, you know a set of rules about what policies our group chats can have that I need to have some agreement about how we do identity and I agree that we absolutely need to have that. I.

B

Don't agree that we need to have a way to discover that identity broadly on the public internet and that we need to be able to do that with an arbitrary provider and I think that's an important distinction.

K

Yeah Fair clarification, Ron um and I was focused to be clear. My intent was to focus more on the uh integrity and verification half of that, so that uh also, ultimately, at the end of the day, what I care about as someone who's sending a message is that I know who the counterpartiest that I'm sending to um I think that's the thing that that we really need to solve and have have some way of building entire video.

K

um The reason I encued was was um some stuff that Jonathan was saying. I just wanted to confirm that um it sounds like we were kind of uh converging on this idea of um you know some sort of authority.

K

um The thing that continues to bother me a little bit is Jonathan's use of the word Discovery provider. The other thing that conflates multiple roles in terms of being a an authority for certain things, as well as a source of information um and I. Think the you know going back to the ca analogy: CA you know doesn't publish director of certificates or who has you know who which websites uh CA is not the DNS. They just say that whoever holds this public.

K

He holds his name, um they don't publish that in you know, information CT aside, um CT also probably important for the system of the law in our KT or something like that. But um any case I think the the critical thing here is. You know that we have some sort of authorities, whether that's the providers themselves or there's some external Authority um as well. Make sure that we're clear that the certain aspect is the authority, not the distribution of the information centralized.

F

And this yeah this is.

K

Already things that will be inherently sort of centralized um because you have to do all the vetting and Trust establishment, um and so I just want to make sure that we're clear the the thing that needs to have that centralization aspect is the authority and not necessarily information distribution.

E

Okay, I think um we should probably not open up another topic here, um but thank you Ecker. We will have more time for you another time and we'll move on to Giles.

I

I

uh How's, the echo is, it got better, I think I fixed it.

E

Yeah, it sounds okay,.

I

All right, uh you want to go to the next slide.

I

um All right so I try to focus on. What's the user Journey we're trying to support here and fundamentally it's not uh to to respond a bit to what Rohan was saying. It's not that you want to be able to look up a contact in a directory. It's I want to send a message to somebody on another service in order to do that, I need their public key.

I

There's no way around that um and uh I I need their public key and I also need to know where the deliveries where to send the message. um So that's that's. Fundamentally the user Journey.

I

We want requirement that we want to support and that's the most important requirement here is I I have the phone number or the identity handle uh of another user and I want I want to send them a message and I can't do that unless I have their public key um so uh and then second requirement is uh if, if I'm receiving a message, uh I I might have the same, I might use the same phone number or the same identity handle in multiple different uh clients um or or from multiple different services um and I might have a one of those services that I use by default and most frequently and that's where I do my you know that's where I operate during the work day or uh that's where I want to get my personal messages, and so um in the case where I as a message, receiver I, have multiple possible clients.

I

I want to be able to specify which client I want to receive a message on. So that's uh that's another requirement. I've added, um uh obviously uh I I I I I. Wouldn't we need some requirements around the namespace of the identifiers that are used for this lockup lookup.

I

They need to be globally unique, um uh uh otherwise you know you're going to have uh collisions um and then I put as a uh a fourth requirement and that that sort of ties into some of the discussion we've just been having is uh there should be a way to verify the association between the public key and the user ID, and um actually what I was thinking in terms of implementation here, uh when I put that requirement in was some kind of stat I was thinking about some kind of standard utilization around out of band key verification, um so, like the kind of flow where you have a QR code in WhatsApp that, where you can verify somebody's identity out of band, um but uh you know certificate, TransPass CT, like architecture, is another possibility there, um but uh and I put that as a P1, because I'm not sure whether it should be included or not in in the scope of this, this working group um all right uh uh next slide on the Privacy requirements.

I

uh As I already mentioned, the privacy of the the social graph is super important.

I

um It's one of the most sensitive uh and persistent pieces of uh personal information that you can you can leak uh is who your your social graph, and so the queries to the Discovery service should be, should be private um and then uh so, that's like who, who are you whose public key are you looking for? uh Who are you looking to communicate with and then the second one is uh the the discovery service itself.

I

um That should should not learn the querying user identity if possible, because that's the other side of the social graph right. It's who are you looking for and who are you when you're looking for that person um and then the third one is just a as well as the social graph, or should also not learn the timing or the exact timing on which you're sending a message. So those are the Privacy requirements.

I

um If you go to the next slide, I also added some privacy non-requirements, which we've.

D

Been discussed.

E

D

I just wasn't sure if.

E

You you want to take any.

D

E

K

Just a quick clarifying question um on especially on this first point, um when I naively come to this and think revealing social graph. That says to me revealing kind of the both endpoints of an arc in the graph, so both the querying user ID and the receiving user ID and a lot of cases. People don't regard this independently as as sensitive. But are you trying to say that, like just revealing that somebody is querying for Giles is something we need to protect against.

I

um That's kind of number two uh I think well number one is strictly about the recipient. The message recipient.

K

So let me explain this a little bit differently, so, like imagine, Richard is on WhatsApp, which is creating iMessage in in General's online message, I'm trying to figure out if how to reach it like if or and querying for your number uh at Apple um are we, you know I, guess, there's a couple of things. We could uh worry about folks, learning and learning in that system and they could learn that Richard is asking for Giles, which is the most sensitive thing. Obviously they could learn that Richard is asking for someone.

D

K

And they could learn that someone is asking for Giles, or maybe someone at provider invested in someone cases.

I

K

Is which are we trying to cover here?.

I

um So number one is uh is somebody is asking for Giles number two is Richard is asking for somebody um and the reason I separated those out is because number one number one is is easier to protect as part of the protocol number two like it's basically IP privacy um and it's it's going to be more of a a standard, a um certifying the service provider than a protocol thing right.

I

Yeah you for number two you'd have to prove that the service, the the um Discovery service doesn't log your IP address. So.

K

I think I think it's useful to kind of be precise and stuff as we go. You know I'll shut up in a second here, but because I think the fact that we have this client to server to server or client to server to server model built in here like provides opportunities for an anonymity, at least an anonymizing syllables right.

I

Right and that's why I've said in the in the requirement: I I'm, assuming a client to serve as a server I'm saying the result, the resolver service, in other words the identity, the um Discovery service shouldn't so shouldn't share the client identity with with the next hop right, makes.

D

I

Yeah, thank you. Yeah.

I

F

Yeah I just want to make sure um uh to sharpen a point that I think you're making implicitly, which is. It is not a goal here to conceal from the application provider which um numbers I'm looking up. So if I'm on WhatsApp and I want to know the phone number of somebody and maybe they're on iMessage like WhatsApp and iMessage, both get along the information or these WhatsApp does yeah.

I

Absolutely yes and I, I I, agree, I've missed that out of the non-requirement good point sounds good yeah.

I

uh Jonathan yeah.

C

So if you could go back to the first slide,.

C

um One of the areas where I noted I think we were saying different things is this first bullet and whether or not the scope of this is also to re in fact retrieve the public keying material, um because I I did not think it was. um It's not no.

I

C

I

It doesn't say that it doesn't say that in number one, it says, discover the service IDs, where you can retrieve the public key material, I.

C

See so in your model, the discovery service is not like literally sending me this certificate. It's just it's it's sending me that the place I can go to get the certificate which is may or may not be the same place. Is that always the same place? I go to send messages or you're you're you're, not planning on that question.

I

uh Not opinion on that.

C

Yeah, okay, one other question for clarification: um you were going back and forth with Richard I, didn't think I heard the actual answer to ritzer's question, which is we have these two cases that we want to worry about. Are we worried that the information that someone is querying for for jills is revealed or that or worried about Richard is querying for someone is revealed or both I think you're saying both but I want you to see.

I

It worry about both, but the solution to those problems.

C

I

Different, they understand, but.

C

It's a requirements, question because I think that's important you're, especially trying to like. If again, if I want to message you, you want to make sure that the discovery provider can't figure out that I'm actually trying to find you, that's what you're trying to put you. You think we should protect it. Yes, yes,.

I

That's why I say I guess the top level is the protecting the social graph, and there are two components like Richard said right, but.

D

G

I, don't think.

I

The the protecting and the query is identity is not really a solvable problem, so I would focus more on the protecting the identity of the query e. If right.

C

D

C

Yeah, okay got it because I think it's interesting and I just poking that one last bit, we also just said an echo: ask this question that you're not worried about protecting that from the app providers, in other words, so if I'm on WhatsApp and you're on iMessage like well, obviously like iMessage and WhatsApp are going to know that we're communicating.

C

You also, however, said I thought in our previous discussion that you thought the app providers and the discovery providers were the same okay. So then, why do we have this requirement.

I

um Yeah, that's that's a good point um because.

I

um When I make a discovery, query um I'm gonna be looking up the the the recipient potential recipient on Services, where I don't have an account right: oh, where I don't have an identity, and so those would also learn my identity, even though I'm not even though I'm not I'm, never going to communicate with you on so I.

C

Think you're making it you're making an important assumption in design right you're, making an assumption that there's like a forking query, where every app provider has its directory and when I want to look someone up, I, basically, query: my provider queries all of those providers and I: don't want the ones who don't own the number yeah to know. That's I!

C

Think again, there's even if you agree with the requirement that there's multiple app providers I, don't think it implies that you Fork the queries but now I at least understand where you're coming from with this requirement.

I

I'm not sure how it how you.

C

Could uh so this is part of, what's in in my draft, that my draft has a bunch of different pieces which can be used independently of each other? One of them is this idea of using Bloom filters for routing protocols and because broom filters have really nice privacy protecting properties. So you can imagine, there's a model where I'm Distributing Bloom filters with enough size that I don't need to query. Everyone. I only need to go query.

C

The few that are still you know put together in the bloom filter um and that's a subset now, there's still a forking query and a malicious provider could ignore that. But there are solutions like that that don't uh that don't necessarily acquire uh where another solution is full. You don't want to fully distribute the database I guess because of well. You could, if you only cared about the social graph, and you thought the database was public. I could just distribute the whole database, then there's no queries ever.

I

um But still somebody learns the query and.

C

I

In the model where.

C

You distribute the database, there is no query Oh.

I

Oh you mean to the clients.

C

No, no to the app providers like let's say, basically, all the providers exchange all their databases nightly and making this up right so I every day. Basically, every app provider has this whole database of all the numbers, all the email addresses and what providers are in that case, there's no need for a query: we're building a replication protocol.

C

The only thing that's ever seen is the message transmission, which we just acknowledged is not privacy, we're not worried about its privacy. That is a solution.

I

I'm not sure I follow that, but.

C

I

Probably take enough of them.

C

Anyway, thank you.

I

I think we might be straying from the requirements a little bit here to solution so I mean.

I

Maybe we can refine that requirement to provide nobody, but the uh sender and recipient service providers should learn the social graph right and I. Think that's the real requirement here.

I

E

Yeah uh well, this is roughly what I got in the queue to say: I feel like there's, um there's like a matrix of privacy requirements to be written down here, related to specifically which entities the requirements are being placed on like the piece.

E

That's missing in this whole conversation is like being disclosed to whom, right it's not just like disclosure, and so like you have the sender, you have the sender's provider, you have the receiver and the receivers provider and those are entities that we know of because they exist in Mimi and then there might be additional entities.

E

We need to talk about if we think there's going to be independent, Discovery services or whatever, um but at the at the very least like the sender's provider and the receivers provider, we need to establish what they should be allowed to know at query time and I think what you're saying is, or maybe a little bit of what got lost there is that, um by virtue of by the time, you send the message they both know who's sending and receiving, but by virtue of querying they should not necessarily learn that the complete graph um until it's established that the recipient actually wants to be reached on the recipient's service provider um and then Richard also put in the chat something I was going to echo, which is that I.

E

Don't think. We should necessarily assume that you can't hide the sender's uh all the centers identifiers, including the IP address, because, like we have technology that could do that. So as a provider that wants to or wants to, allow that to be hidden at query time could support that. So I think. If we're at requirement stage, we should leave that open as possibility.

I

Great yeah, you said it really well with the Matrix of requirements, yeah, that's exactly what I was trying to get to thanks Rohan.

B

Yeah um Jonathan asked a question about you know: do you assume for and I just wanted to again point out that users application could go and do this themselves right? The user could be like.

B

Oh, uh they want to reach this phone number I'm going to try I'm going to try and see if, if there is a user associated with this on these three services or they could even prompt the user and say, hey I found a phone, this phone number on the following two Services, you know: do you care which one you know which one I should try so I just want to keep that in mind that there's a lot of user.

B

You know we can push this problem to the user for quite a while and that it might actually be really useful at the beginning, and you can get better interoperability by doing that.

I

But sorry um the there's a lot of noise on some of these line, uh even if, in in that case, where you have the direct communication between like a fan art from you from client to services, a bunch of services that you're never going to send a message to would then learn who you're trying to communicate with in that in that design.

I

um Maybe I'll just finish off the the deck here. So can you go to the uh uh yeah the non-requirement side, so.

I

uh Yeah, so number one means is what I've been talked a lot about already. Is that we, it shouldn't, be a goal to like the directory is public already, um there is rate limiting, um but that can also be built into this any implementation of this design. um So that should be an explicit non-goal.

I

um uh Also hiding the existence of a particular phone number or a particular public key, even in independently of the mapping, is also not a goal, uh and as the association between the public key and a user ID is also public.

D

I

You know it's in the name and also we're not trying, as I mentioned, we're not trying to look up contacts by name um there's another slide which, with some more requirements that haven't been discussed yet so can we get unless there's uh oh Eric, Eric and Jonathan? Do you want to comment on that?

I

F

I'd like to push on this on this uh this this point one here, because I sort of thought you were starting a stronger version of this, which is this information, is not secret, um as these mirror two versions won't get a search.

F

One is this: information is not secret and we're not having any templates are offer to conceal it and it'll be just fine if we publish the internet and the other is this, information is not like super secret, but people are going to try to like rate limited or whatever, because, like it actually does, let me so I always say to them with this one, assuming that any assuming there is rate limiting. Actually assuming that, like there's, any attempt to conceal it and there'll be in the actions limit.

F

Design is quite a bit um for the reason. Jonathan were discussing the very beginning of this presentation, which is to say that if you have a system which is like functionally open and we and which allows new new participants to come online as APS and those APS were allowed to query for any substantial Subs of the database, even with rate limiting, then it is easy to spin up a large number of fake APS and simply because simply require the targets. And so like is like so I, think like either.

F

We have to decide that it is a requirement that is especially a requirement to to print scraping or it is not, and if it is required event scraping, then we need everyone to designs. It's not required I.

I

Would say the requirement to prevent scraping is outside the scope of this working group.

D

F

Okay, yeah I guess it's one thing to say this is people's problem. What I'm saying is that the architecture that an architecture in which there's an open query system, that's only rate limited by the attempting to throttle the aps is like it really does not like there's no way that it will possibly work and so like it's an incompatible because of the database and so.

I

But like I mean it'll work just as well as it works today with with the each individual provider's key distribution services like the only thing that protects them from being an open directory is sure, is worth anything so we're not changing.

F

Anything with that, but I guess I'm just saying I guess, but what I'm saying I guess the part I'm saying here is that, like there are designs which are not even with their designs, which don't even attempt to pry any concealment right, as I said, one in which you just flood, fill the entire database right and like they may not have merits but like. If we're not going to try to protect the system protect us, then those designs were in scope.

F

But if we are in the they're, not in scope, I should call that invest in the rest of the design.

D

I

I guess there's maybe feeds a little bit into the next slide is that we don't want to set up the economic incentives of the system in such a way that it would be hard for any individual player to do rate limiting so I I. Do think that we should consider that rate rate limitability.

I

I

I

um Yeah I, don't think I think we should only consider it from the kind of economic incentives point of view and not from the technical implementability point of view. If that makes sense,.

C

Yeah so yeah, but I I, want to come back. I was going to make a similar point. I I still think we're not quite there. Yet right, okay and and I'm gonna try and ask the same question. Echo is asking in a different way, there's two classes of solutions for this problem. One class: the solution is where there's a lookup operation, that's done on an entity that holds the database and there's another solution where we simply distribute the database everywhere.

C

They one of the big differences, is on whether or not you're trying to protect against enumerations am I. Am I even am I worried about that at all.

D

C

We we all agree rate limits, are a policy thing and what have you but they're, not even possible in a system where you're just right.

D

I

Where uh you don't have a central database and you don't you, don't Farm the database out to everybody, but each service provider is responsible for queries on their own Shard and that that's that's the solution that I'm thinking of.

C

I understand, but that mean that that's fine, but that still rules out it I'm, saying I, believe there is a requirement here and I'm still, not sure and and I am going to State. It again I believe that there is a requirement that it is not possible for a consumer or an app provider to trivially to to get a full copy of this database.

C

We are trying to protect that it may be hard. We have to do rate limits, blah blah but like that is a goal goal of the design is.

C

I

What's that I I'm fine with that I think, okay, I.

C

Don't think everyone else has been fun with that, like that's, why I want to state that is. We have had postulated proposals here in this meeting, which are of the Forum I'm just going to publish the database on the internet and, like anyone can download it like I'm gonna down, and that was in fact that was air that was Eric's starting proposal. I think right like like, let's poke holes in it- and this is one of the holes I- want to poke to see if we are aligned on this requirement.

C

So I think you are in agreement. If someone doesn't agree, it'd be great for them to join the queue.

K

C

K

I do agree, but I'm trying to try and situate this in the context of the disagreement um so I. What I think Ecker was trying to say was that it is is largely that if you have a you know, it's just an open system where anyone can be in an AP like then the open, query, interface and public database cases are the same case, because anyone can spin up a number of memory limited.

K

You know a number of rate, limited actors to make a bunch of queries and download the database, um whereas I think which I was saying is those are actually separate cases. um We live in the open query interface today and rate limits are enough of a protection to prevent that from degenerating the public database case. So I I think that that seems plausible to me just based on kind of the empirical evidence um and so yeah.

K

It seems plausible that we could go for a design here that presumed an open query interface without thinking that that is generated into a a public database situation.

I

But but I think it's important to that. The the owner of the database is in control of the rate limiting. Oh sorry, the the owner of the data is in control of the rate limiting.

I

So you don't want a situation where WhatsApp and Google give up their entire directory to a third party who then completely neglects to do rate limiting right and they're not able to to influence whether they do rate limiting or not.

E

So we have one more presenter and um not that much time so I think we should take this to the list to continue discussion. Thank you.

I

Finish this slide, because I I think these requirements are pretty important.

E

um I really think we should take it to the list just to be respectful of Victoria's time as well.

D

G

Okay, so this was my attempt at defining the problem and the requirements, which is the first half of my draft, so I will not get into the second half, which isn't a possible solution. So next slide, please. So, first of all, I am trying to describe the Discovery program at a much higher level of abstraction. That than what we've been doing here, mostly so I I will just Define.

G

It very I mean very abstractly in a as a the need to convert a user identifier which is service independent and is human friendly into a one or more account identifiers, which are something that includes all the information that you need to actually then establish the connection and and start up the rest of the process. So in a way, what you're trying to map here is a any number of one to many non-exclusive unidirectional relations, meaning that the same account identifier can appear or be associated with more than one user user identifier.

G

Actually, the same person can have more than one user identifier if they want and um and and so in. At the same time, the relationship is a unidirectional, meaning that does not map him in the other direction.

G

uh But what is also different in my way of thinking as a problem is that I'm, not assuming that we are just mapping telephone numbers or email addresses, I, really think we should start thinking at a new native meme identifier, because that would solve many of the issues that and it will provide an alternative, at least for people that don't want. So, let's get to the next Slide.

G

The next slide is about the the use cases so also I think we should be clear about the use cases that we want to support and I I inverted them not like user B wants to contact USA But username wants the user B to contact them because that's I think conceptually the way we want to describe this, and so the first two use cases are actually the same, except that it's a different identifier.

G

So the first is the native one in which they I mean the user user. Id wants to be contacted through a new native Mimi, specific idea, user identifier and the other one is when I mean they want to give them a lot of the email address and the telephone number and they in the end they are very similar, but they might be different in the resolution, so you might have actually different resolution systems for the two cases.

G

The third case is when I mean it could be important for them. Let's say the migration, so the user already knows actually they're identifying another service. They know the telephone number the same one. They want at least to try contacting them, and, of course this includes the problem of accepting the introduction, so I mean making sure that in this case, user I actually wants to be contacted. But I think this is out of scope for the discovery. So this is something that needs to happen in the clients when the connections actually happens so.

C

G

Slide so I try to Define what are the requirements on the identifier, so we didn't I mean I.

G

I saw some of the presentations having something that looked like kind of one of these identifiers, but we should really think that I mean what they need to be, and so the my first most important point is that I I don't want to be forced to be reachable by an email address or by my mobile phone number, because I don't want all the people that already have my email address or my telephone number, which has been the same for the last 15 years to be able suddenly to start flooding, my mimi, client and and trying to get a connection with me.

G

And yes, I know that on WhatsApp, if you want like everyone, you are on WhatsApp currently having the telephone number of someone is enough, but I mean the policy point of meme. Is that I can actually close? My WhatsApp account and tell them to forget my telephone number and from that point on, maybe I will not be reachable on me by telephone number. Maybe in the future, people will not even have telephone numbers anymore or email addresses, so we should make sure that the system is independent from the existence of these other previous communication systems.

G

So, of course, the the requirements are all the meme identifiers, because the other ones already exist and the meme identifiers should of course be simple, be human, friendly and but, more importantly, I think that they should not just be owned by their service or app provider. So users, the users that want I, mean like for email, which is my model.

G

They should be able to own their identifier, so so to make sure that, even if, in the future they want to change their mini provider, they don't have to change their identifier and I mean most people, possibly will be lazy or not. Technical. Nothing will just get whatever identifier, their major or main service provider gives them, but for people that care I think you should at least give them the flexibility of having something that they actually own.

G

As an identifier and- and so this also includes some kind of portability made through I- mean preserving the identifiers, while changing the accounts that it is associated to and of course, identifies should not be easily easily guessable unless the user wants to so I mean I. Our email addresses are generally very guessable, because their name family name or whatever, but if I want to have something that cannot be guessed, it should be possible for me to have something which looks entirely anonymous.

G

That's all next slide, please. So then there are some requirements on the solution and my requirements for the solution would be that well, first of all, it should be able to scale to any number of users and relationships, and it should be decentralized, so I would the problem I have with all these. Like one provider, a few provider solution is that I mean there are several problems, but one is that they could be easy points of surveillance to map the social life of people.

G

So if we can make this very centralized, then uh I think it's better for privacy. uh Maybe we take the questions now so Echo. If you want to, if you have a question.

F

Yeah, so I do think we want it to emphasize surveillance, but I think the answer is not to centralize. The answer is cryptography, um uh which is the point I'm.

E

F

um Like I mean like the centralized, doesn't remove it's just it just it just express your balls around. The answer is to have a technical solution. They surveillance Impossible by the intermediate notes.

G

By using cryptography, we make sure that it's, uh but I I think we should also try not to make this centralized because also cryptography. You know in the long term, maybe what's secure today might not be secure in future, and so I mean yeah whether we want to make these these a strict requirements, but I think we should aim to have the system as decentralized. If is possible, no.

F

I mean I actually do not agree with that. um I think that's actually I have a huge important downsides and um and uh um so no I don't I, don't know that's right and I. Don't think it's right right from uh from a privacy of security, yeah.

G

F

If we don't trust cartography, the game is over. So like it's not gonna matter. How many, how many different numbers there are? The character doesn't work, so um so no I, I, just I, think you know maybe they're. Maybe there. Maybe there are reasons to make it decentralized or not involve screening privacy but I. Don't think that Supreme privacy motivates as well. Okay,.

G

But anyway, okay, so.

F

Well, anyway, we.

G

Whatever solution we have should offers like European privacy, so high the social life and not allow third parties to intercept the communication and we think that's that's a sort of implicit, but it's better if we state it and uh also I, think we should really build the system for the self-hosting model so or anyway, for any number of providers discover the providers if we have Discovery providers in the end or if we only have service or our providers any number of service or our providers and um and of course you should use Open, Standards and I think we should consider making something which has low barriers.

G

So it is really possible for people to even for let's say, smaller operators or even individuals to deploy a full Mimi service, including the message path, but also the discovery plan for their own identifiers. So next slide and then so. Of course, there's some non-tech stuff, like you know not having internal property issues and especially the regulatory issues, I mean some of the initial proposals. I I thought they would. They could be a regulatory nightmare.

G

So again, maybe this is sort of out of scope, but we should look at what we're doing in your same distance in these terms and yeah. In the end, it must work also in colonic terms. So next I think it's it's equally done right, so I mean yeah. My mate to close this down I mean my main point is that I would really like to explore the possibility of having maybe specific identifiers designed from scratch, because then you can decide them for discoverability. So, uh as I said, I mean the solution.

G

That's in the draft I don't want to talk about it now, but it's basically based on DNS user identifier has some form of an Source name or or a UI with a domain name. And then you just do the query from that. The name name and you get all the information that you need. So then, maybe you can discuss whether all the information that you have to put is actually something you want to put into a DNS.

G

You can imagine like having an intervenious type, only putting some of it and then having an adult going to handle whatever, uh but but I I think we. We should explore at least the possibility of having something which doesn't actually require to have a discovery provider or just requires. Whoever is providing your service to also provide the discovery.

G

Part pretty easily is a compliment to their service that they have to provide anyway, on the other hand, for external identifiers as I call them external device, because from other services like email and telephone numbers, I do agree that it's hard to do without this kind of Oracle of database or whatever.

F

G

All the rest of the discussion, I think applies nicely to that part of the problem, which is fundamental, but I think we should open this up and also have a discussion on Native identifiers.

G

E

Yeah I think that's kind of the main point. I would love to get people's feedback on here? I think that's different from everything else. We've discussed thus far in Mimi, so we only have a few minutes, but if people could join the queue and um give your thoughts on the Mimi specific identifier, that would be great.

C

uh Yeah so I I'm, not in favor of this I, think it's nice from a technical perspective. I think it's it's not practical uh to introduce the world to another new identifier and hope that we can get people to know it. Use it distributed.

C

um I appreciate your main concern material on you know: hey I want a way to make sure that, even though you know my number you can or email address, you can't reach me. You can solve that without a new identifier um and if I need to communicate a new identifier, I'll just communicate my service specific one, I I, just I, just don't see the need or the realistic possibility of deploying another new Global, unique identifier to all of the internet community that is on messaging, which is billions of people I, just I, just don't think.

C

What's going to happen, so that's my opinion. Thank you.

G

Well, yeah, okay, my point would be that you don't have to I mean you just have to make this possible for people that want to use it, and maybe there will be some smaller new services that use that as their identifier I mean it doesn't promote it to users. The possibly the dominant ones will not want to do this, so they will just continue to ask for the telephone number and that's fine I'm, worried by the idea of not having an alternative.

G

So I mean deciding straight away that you are telephone numbers and into our email. Addresses will always exist, which is a big assumption to me and uh and second that people will have to use. One of them. I mean things that are designed for a completely different service than now. They will become the identifier for this and by the way, the service specific identifiers.

G

We have to discuss them, but I, don't think it will be so easy to have a simple thing that has all the information that you need like at the end point and the part maybe and the account number and maybe version of the protocol. So I see it's very hard to build service, specific identifiers that are also usable as something that you can give to someone else. I think you need to build a separate human friendly identifier.

F

I think I mean I largely agree with Jonathan. um You know we have like how many points of users are using even 64 numbers identifier like that's, not going to change so like whenever we have to work with m64 numbers. um As far as I can tell all the designs anybody's actually reversed. Just assume that the interfer is resolvable is is geographically unique. Sorry is global, unique and resolvable. So I, don't think it'd be a problem with someone wonder what's new identifier space that we didn't it didn't depend on other.

F

You know DNS or e164, but, like um so I, don't think we all this hasn't recruited that but I think that's it I think any system was on the support. E164 is getting the one for a second.

I

Doing it uh I think, having a service, a service identifier, Plus, a an arbitrary string could be a phone number, it could be any kind of identifier will give you a globally and unique namespace and and is compatible with everything we already have today. So I, don't think we need anything new.

E

Jonathan, did you have something more to add.

H

Oh yeah I was just saying I, you know the one thing I would, you know say would be hard. You know might be hard, so some of the architectures have assumed that you know these are not just globally unique identifiers, but also routable that you know there's some other means outside the meaning protocol such that you can confirm. This person is not lying about that they own this identifier and you've got a new identifier that property obviously doesn't hold, because it only exists for Mimi.

H

So that might uh you know I see the the benefit of I. Don't want to give out my cell phone number, but I still want you know whatever meme identifier give out to have. You know portability between providers um and I'm, not sure how easy that is to achieve. At least it breaks some assumptions of suddenly some of the proposals for the other models.

E

Okay, thank you. Victoria um I think we got good feedback on on that, um so it would be great if we had continuous discussion on the list instead of waiting until whenever we get together again, because the next interim is going to be back to the design team um and, like obviously, there's a lot to hash out here. This is like complicated design space, so um I think if people have like it would like I think we should start some individual threads on particular topics.

E

um You know one on the rate limiting um the scraping of the database. That's like a good one, the stuff that you didn't get to Giles um feel free to start individual threads on individual topics. If that does not happen, organically I think Tim and I might try to instigate that and get the discussion moving a little bit.

E

um I also think I, don't know if it's like a little too early for this, but it would be really nice to have a Consolidated uh list of these requirements like one list, even if we're, even if it's some of them still have like an option space of like maybe it's this or that, um but it would be nice to get down to a kind of a single view. So I think that it could be possible to start now or we could.

E

We could do some rounds of further list discussion on individual topics and then try to bang that out, but I do think. That's something that would help us soon.

E

So that's kind of my Takeaway on on the end of this meeting and then the only other thing I will say is I think we will be soon sending out yet another doodle Poll for um for interims in October, uh more friendly to Europe time for October. So please look out for that. I think we're gonna need a bunch more of these and um maybe try to get onto a just a regular Cadence. So we could stop doodling.

E

um So that's coming your way. Tim. Do you have anything else.

A

I, do not oh thanks. Everybody.

E

Yeah thanks a lot, see you next time. Thank you.