DappCon 2023: Legible Authorization - Ryan Betts

Transcript

uh I'll turn this into an artifact a record for the viewers at home um and uh we'll we'll probably uh skip quickly through uh some of the exercises that I had planned in case a larger group attended and we can customize this to the uh the the folks that are here right now um but uh yeah we're going to talk today about legible authorization uh AKA uh nailing U Act without sacrificing security um if you feel like scanning this uh there is a copy of the slides and a fig Jem that we might hop into to assemble uh resources and I'll make sure that after this uh anything that comes up uh from y'all's questions uh I have a Litany of links to

relevant stuff so uh make sure that there's some kind of take-home reading here um the tldr is that uh for a long time it has been uh you know often said that usability and security Our intention with each other um but for just about as long actually there's been um a a good thread from the HCI community and onwards uh that in fact the opposite is true the more usable that you make your systems the more secure they can be uh so these things work uh in tandem with each other uh if you feel like it um you can just share a bit about yourself in the document there uh and that'll uh

possibly speed stuff up uh later but uh are either of you a designer or more on the engineering side developer yeah yeah yeah okay cool um so I myself am a designer and sort of to give you uh my bonafides I guess uh I first connected to the internet in 1988 uh through a 1200 B modem and over the course of the preceding 30 something years I've seen a lot of things um uh presently I lead design at a company called fision uh so we build local first uh identity data and compute infrastructure um I'll talk briefly a bit about uh like some of the work that

we're doing right now and why uh it has led me down this Rabbit Hole of uh making ledge authorization more legible um so we have a few uh things some of you you may have heard of uh we're the authors behind um a local first authorization protocol called Yukan we work pretty extensively in the ipfs ecosystem uh we brought encrypted uh data to ipfs through something called winfs we're now extending the capabilities of that to provide compute over data in something called the interplanetary virtual machine uh and so of course when you're passing uh payloads of data around you want to make sure uh that folks are authorized to do

only the right things uh with that data and uh this means that you know whether it's to um uh uh developers or the end users uh there's a lot of moments of of authorization that need to be made legible there um we're currently uh uh uh focused on trustless offchain uh distributed compute um and we also have uh for for client side devs um uh something called odd uh which is an SDK uh JavaScript uh based for the web right now but also coming to to um Native mobile uh that makes it easier to work with those Lo level uh protocols without needing to russle with the details

um I also am here as a representative of Caza uh the chain agnostic standards Alliance um so that's where the the working group that I uh facilitate right now the secure design working group uh houses our discussion you can find it under their GitHub repo um a lot of folks there from wallet clients uh the wallet connect team metamask Brave Etc uh working to uh attempt to align on standards um uh many of which have been implemented today so if you ever uh are dealing with uh uh chain IDs that came out of Casa as a thing called uh uh we call our Improvement proposals capes uh so that was Cape 2 um we'll touch on

maybe a couple of other interesting capes in a bit uh but uh the the the thing that initially bothered me uh about uh the the state of the industry uh right now which I'm sure is like a non-controversial um uh opinion is that uh wet clients adaps work the least for people who need them the most they still rely on a very deep technical understanding and while not precisely uh blind signing You're often uh completely unaware of uh what the contents of a a message are uh you're just trusting you're depositing trust in the person who uh initiated the the signature right we can do better than that um um but we often beat

ourselves up and we say that web 3 uh is not yet as good as web 2 like uh password managers are fairly broken as well um you know I've uh had to help a family member with dementia uh manage their uh accounts and like good luck uh uh getting somebody with that cognitive capacity to benefit from the security that a credential management uh tool is is is meant to provide right uh it's just not integrated enough right right so um uh another one of my favorite examples of this uh is uh one password if you have to go through the recovery flow uh they've obviously done a lot of ux research on uh where people are depositing these things in the first

place they ask you to look is in the downloads folder of the computer that you may have lost right um so the the failure case is happening really really like early on and it's it's you know whether you think we're in web one 1 2 3 or five um I don't think that we've got all of the uh you know component pieces in place um we're we're still uh not at the first uh major 1.0 milestone for what would be a complete and usable system um so you got to make people empowered with uh information I can do the right thing with their data uh and we're at the point where a lot of that is possible

right now uh but it is sure as hell not probable um we focus presently on removing a lot of bad friction uh but I think we also need to uh consider that there are elements of good friction that we should preserve or or maybe even uh expand upon So today we're maybe uh going to to dig in to a little bit more on what those points of good friction are uh so my first question to the crowd is uh and this is is probably easy one but the difference between authentication and authorization uh because this is sometimes not widely understood does anyone want to give a give an

answer yeah the first one is who you are and the second one is what you allow to do boom nailed it yeah yeah um so I need especially on the um uh for anyone who's coming into the space from a nontechnical background I I don't think that we sort of introduce this important distinction uh right off the bat right auen uh who you are aad what you can do um and often who you are uh you know like we talk a lot about identity uh I think it's very important for us to be precise and narrow about what we mean in that in in this space we're talking about functional identity uh we're not talking about like emergence uh emergent Rich identity like who you are as an

individual we're simply talking about like a provable identifier of of who you are right and that can have a lot of different flavors we can do Anonymous ones we can do synonymous ones which everyone is now saying pseudo Anonymous uh I think just to make that concept a bit more legible uh to folks there's identifiable um uh uh Records uh and then there's verified uh Records where I've actually uh provably attested to the fact that I am such a person uh but back to offz does anyone want to uh uh uh try to list the three categories of authorization uh that that typically are

used I'll give you a hint the first one is Access Control can anyone think of a second one that's a it's a good term um and maybe I'll just skip to the slide uh rules-based access control and object capabilities both of which could deal with uh some other terms um which uh you know often we refer to these things as permissions and that tends to be more often not the user facing term um we also talk about these things as

privileges uh and we talk about these things as object or as capabilities right um and so sort of the first uh authorization approach that happened in the history of computer science was Access Control this was to govern uh time share of the Mainframe at like you know academic institutions and you signed in with a uh password um and every individual person was uh identified and granted access that's obviously unsustainable when you hit large numbers of people so then you introduce this layer of abstraction called roles uh which is uh allows you to reduce the number of security policies in your software but um there's this other lesser explored approach

called object capabilities which uh attempts to uh encode the authorization into uh token itself uh that is sharable subd delegatable and works offline at the edge without needing to um uh connect with like a central uh Authority uh to determine who's allowed to do things and uh it's our opinion if Vision uh and and I know uh a lot of other people in the space share this that that capabilities are are a fantastic path forward um and you can emulate from a management uh uh uh point of view the same sort of screens and workflows uh that you would uh would be used to with

rules based uh Access Control um anyone want to guess what the first moment of dap authorization is in a typical flow today like what's the if you're going to go use a Dap what's the first moment where you're authorizing it some capability yeah um and what are you authorizing there address correct and then what do you do next correct by signing a message right and so presently that's a little bit of like a a a wonky flow um because especially

if you're doing it on mobile um and you're doing it through wallet connect um and this is surely no fault of wallet connect at the moment um you have to hop over once uh select your account hop back wait for that uh to be confirmed and for the uh RPC uh uh data to to to be fetched and then you hop back again and you get a sign in with ethereum prompt or an old school like you know uh bunch of hexadecimal stuff uh and you sign that and then you're back again so these are some of the capes that we're working on right now which I think are going to be really powerful if you're on the DAP side if you're on a wallet client side uh please take a look at uh

uh supporting these on your your end but uh Cape 25 and 27 which would allow for feature detection so if there are specific Networks you're going to need specific uh RPC methods that you're going to need to use that would otherwise break your app Cape 25 and Cape 27 let the DAP express that to the wallet client so that both the wallet client and the DAP can provide more useful next steps uh back to the end user to say oh you're going to need to use a different wallet or um perhaps you're on an outdated version uh that you need to make sure you've updated to the latest because this is making use of a specific new uh RPC and uh uh method uh that otherwise the the DAP can't uh

function without Cape 222 is really cool because if folks align around that it'll turn those two steps into one um and I'm just a designer so I won't explain how that works because I don't honestly know um but I urge you if if any of this sounds interesting to you to go check out the discussions on that um from the design point of view these are three of uh the uh sort of key Cornerstone papers that I for whatever reason made up the term pyramid of secure design um uh to to describe uh but they uh are where a lot of the

principles that guide us at secure Des design a working group uh emerge from um specifically like the user interaction design for secure systems is is a phenomenal uh uh read uh but all three of these if you haven't read them I encourage you to um within those three papers there are a a you know if you add up all the principles that are proposed you're at around 20 that's too many for someone like me who's simple-minded to remember um so I attempted uh uh with our group to uh distill this down to seven guiding principles um some of which are not just about legible authorization um but about

um uh other aspects of it we'll we'll winnow that down to to uh four or five of these uh for the discussion today uh they are as follows I'll quickly uh go through them one super non-controversial things should be easy in obvious we know that human in the loop is like where things often fall down and if things are complicated then people are going to find a way to to make the the system easier for them right this is often what results in people writing passwords on sticky notes um so like uh the stricter you make things if you don't make them all easy uh to uh adhere to you're you're going to uh uh really weaken uh

your system right um sure if it 100% belongs in this category but I I see a lot of daps presently still don't uh uh honor uh 1271 and in our push uh to move to a Smart account-based world uh this is absolutely critical um session keys are a knife that cuts both ways uh but obviously there uh delegation of authority to the browser um to do things without needing to hop back and forth constantly is very um compelling we're going to have to be careful about uh you know to what degree and how we let people subd delegate um and then persistent State across uh devices and sessions is something we still don't

really handle very well um uh safe does uh some of this um uh I was really interested to learning the other day actually that there's a tab I didn't know about it that will persist the offchain messages that you have signed across all of your sessions um this still obviously needs to read through uh um uh sort of a centralized system uh but you know keeping access to that stuff is going to be really important uh for us moving forward um so that we can provide uh better uh risk management opportunities to the end users um number two stuff needs to be maximally drisk uh before it is launched right we also

non-controversial we do audits on stuff um but there's a lot more that we can be taken care of um before it ever gets to the uh the responsibility of the user themselves um here there's a lot of uh uh you know flagging of suspicious transactions through uh uh Registries or um uh evaluation of the payload itself or domain binding uh you also have transaction guards and spend limits that you can apply uh to to things like safe we do simulation um a whole bunch of things there uh but when it comes to the person themselves uh and this really ties back to the to the session key question we need to find

the right granularity of uh expressing the request for permissions right um this part is tough uh because you don't want to overwhelm people and neag them constantly and uh lead them to become habituated uh to just say okay okay okay uh but you don't also want to overwhelm them with so much detail UPF front uh that they either panic and back out or say yes to more things than they should have or needed to in that partic particular moment uh a bit later we'll we'll look at uh some precedence from uh the Android ecosystem uh early research there that that uh deals with that um

for this step uh interesting things for you to look at ukan uh caca's uh recap from Spruce ID which is is uh the authorization extension to their sign in with ethereum um uh uh project and then uh Dan Finley from metamask has uh put together an onchain set of uh solidity contracts to achieve sorry a set of solidity contracts to achieve onchain object capabilities uh that is called delegatable um and that's still a very early project but uh I know he's um uh putting a lot of effort into it and finding ways to fund a larger team um so definitely some interesting

stuff there things of course need to be sufficiently legible uh I should need to be tech technical uh here we got great progress with uh seway there's some groups looking at um human readable messages uh uh at the moment and there's bunch of different strategies there um things should be sufficiently auditable this is somewhat solved uh but not human friendly uh for anything that happens on chain of course I can go and I can look back uh I can go to um uh revoke docash uh as I was mentioning earlier safe messages tab is a is an interesting uh approach to knowing what

offchain messages I've uh signed and uh perhaps providing the clients or other services opportunities to uh flag things that I may want to uh reconsider or revoke or um overwrite and then we also need to be aware that things change right um this is the the common complaint about EAS obviously is that if you do something wrong in the beginning uh the only safe thing to do is abandon that account um and and at at Great cost and uh effort move things to a new one um so uh here obviously we're there's a lot of great work uh on the smart accounts front um there's some interesting proposals uh e 5003 and

7377 which uh each describe different hard Fork uh required approaches to um migrating control of an account to a contract uh while retaining your public uh Key address and last but not least uh if you've handled all that stuff you still actually need to let the person do what they want to do right like so um you need to thread the needle and ensure that like uh whatever they were intending to achieve is still possible um as as long as it's a a thing that they should uh seek to achieve not um uh sign a a fishing message or something

like that so the first uh exercise that I was going to do uh was for all y'all to uh just share something about the authorization problems that you have um did anyone come with a live problem maybe yeah what's what's the problem if you're willing to share we have a de and many of our users are not we right so all of this sign stuff insta metas that's just too much and I think if we want to address a

larger audience it will always be too much so we just integrated web three off which creates an EA that lives somewhere and the private key is assembled in the in the browser but I wasn't very satisfied with the structure where we of use it by itself so we augmented it by creating a key share we as the user on their computer mhm and they improveed things a little but still I consider it less secure slightly less secure than a than

a hot wallet right and uh yeah okay so so just repeat the question uh uh or the the problem um got got like a a mass Market uh dap for whom uh asking to install a a a a a wallet client like metamask is perhaps a bridge too far just to get started and so provisioning uh non-exportable keys in the browser browser through uh web web off sorry web3 off um but uh extending that a bit further to get them to download and and and self custody a key share uh and I can't remember web 3 o is like BLS uh uh is that how it's

working under like it's a an NPC based apprach bed didn't version which is called T and was developed by taus and it uses Shia secret sh right yeah so and and this is where like it kind of gets back to that initial uh recovery can't recovery uh um uh issue that that one password kind of drops it like the it's probably wrong of me to accuse them of dropping the ball but there's like this like the moment that you have to ask somebody to take this data and do the right thing with it like you've already lost yes basically

um and there I think some of the most interesting uh possibility is uh the pass key standard um so for provisioning maybe like sponsored uh contract accounts smart accounts uh there are experiments at least they probably need to get some more eyeballs on them uh where you uh rout control of the uh contract account in a in a a a web uh web aen uh pH Alliance Pass Key are you familiar with the pass key standard no it's super interesting go to pass key. energy which is another like

sort of weird uh living documentation site that we have um um it works perfectly for your needs in Chrome on desktop and Androids as long as you go into the settings and turn on a feature flag it could work broadly across all browsers and it is on a a a a standard track it option uh at the moment but this would uh allow both signin key material um and derived encryption key materials to come from uh pas key uh what's cool about that is Pas key is already being

adopted uh as a password list credential uh for signing in to like huge uh uh you know recognizable household Brands like in the United States and Canada there's a big company called Best Buy uh they're integrating this stuff I think that you can um already uh use Pass Key to authenticate into um uh Google's Services uh iOS has first class support for it um I still don't get what it is it's just a passwordless um uh credential right so it's like a again just a designer so I'll lose the words but um it's it's it's a it's it's

uh public key infrastructure that is built into to these operating systems at a first class level that you could use to um provision on chain accounts and then if you did it that way and everything works and we all agree at secure uh theoretically that person just ends up like this will be the way that people authenticate into all services and websites within the next the coming couple of years I urge you to check out the demo um yeah go to I think we have links to

some of the um other demonstrations from Pas key. energy uh and there you'll be able to try uh creating your account through a pass key and then that will be synchronized across if you were like a like I myself I'm an a 100% Apple person because whatever I'm a designer and uh those pass keys will be synchronized across everywhere where I'm signed in Via iCloud right so it's not for a certain threat model what you want to be doing device it's it's non-exportable from your device to a certain degree that device May mean uh that it is syndicated across everywhere that you are connected

in your sort of personal cloud of devices if you're cross ecosystem you can do a device linking QR code base flow um so I could still have my keys uh uh domiciled on my phone and the authentication handshake can happen uh via a QR code so that I could sign in on a desktop or or anywhere else where the standard is supported and again it's like the latest version of major os's and browsers all now support Pass Key um we need a couple more things to happen so that we can use it as the uh root of uh uh entropy for encryption as well um but yeah for for like uh

signing uh it's good and there's some people exploring how this would work in in in this space right and then so then the only question is later on when I've got like more stuff and I should maybe be a bit more careful and you you know tell me maybe your threat model is uh sophisticated enough where you don't want to have that key material uh encrypted in your iCloud sure like now let's add a separate signing Factor like I'm aware enough I've been doing things for a while and you know as we progressively enhance people's security through TFA we do the same thing I think right does that make

sense I would suggest looking at it I don't know if I've solved your question um but another problem yeah yeah go for it yeah hey I'm Alan from redefine H we just integrated with the safe wallet and we provide them a pre-transaction analysis like every safe users before he signs a transaction you can see uh we simulate the transaction we run it through our policy engine and if there is a bad impact to the user we give an alert and with explanations uh why this

is a bad transaction to sign and the Dilemma is um how much data should we provide to the to the user right uh in order to give him explanations but not overwhel overwhelming with a lot of information yeah so so this is like actually so I don't know if folks have noticed but in um uh in in metamask for example uh recently they have started to add uh warnings uh that you should you know ensure that you are dealing with an entity you trust and uh all the rest um and they noticed a significant drop off

in uh transaction completion at those steps uh because I and this is like you know a tricky thing CU like that I'm assuming for a certain coher of people they never saw that message before and then now it's being put in there and so they think they might be something actually wrong uh with this uh so I think that yeah there's there's like an art in how to relay this to somebody because you're what you're attempting to do is outfit them with enough information to make that assessment on their own and you don't necessarily know right so I guess maybe my followup question is in that payload is there anything to what degree do you ever have certainty that it is for sure bad for them so what we do we have um variety of

severities like low severity medium high and critical yeah so for the critical and the high we are really sure and we can also like explain in English what's wrong and why you should care yeah but I have a feeling that as long as the message um some people are not like even understand like what's what's what does this message means like not everyone is like crypto experts and even if you're trying to explain to the user uh I'm not sure that um the users is getting the value that we're trying to provide this is where a lot of slow and tedious uh ux research and iteration

basically is like the only safe path and then like right now um where is that showing up for somebody right like uh it's a separate plugin it's a it's it's on the safe oh yeah sorry you said yeah yeah in in safe right so um yeah I think like we're in this super interesting moment where um because of for example the modularity of safe core uh you know there's an opportunity for greater experimentation there there um you know already is a a plug-in ecosystem uh in that we have metamask snaps uh Landing uh you know in production sometime uh soon and so there's opportunity to rather than right now where for example um uh I think rev. has

a browser plug-in that will run kind of uh in tandem with your wallet and uh attempt to inform you about things that are malicious or suspicious um that you haven't explicitly allowed listed uh from a a certain contract address and like parceling stuff into low medium and high severity is a great place to start then really just experimenting with the semiotics like burying the details but making them available um and uh the the the whole lot of us uh working together to try and assemble uh a standard set of terminology to use

industrywide internally a standard set of terminology to use industrywide user facing um IDE that uh survives translation to other languages uh with with with a reasonable um uh Integrity uh and then also like you know has uh like example code backed uh UI patterns um that we can all test and improve together I don't know if anybody was around designing in uh or or or implementing in the uh early mid 2000s but Yahoo UI Library back when Yahoo was

like a relevant company um was an amazing resource uh that uh became uh whatever a shelling point for for that early phase of the industry even pre Ajax um uh pre-web 2.0 and so yeah I think uh designing and researching at in the open as much as possible um I mean this is kind of my pitch for the secure design working group that hopefully more people ask those questions there and then I don't know 100% of the work that's being done presently but I know like 50% and if more people keep showing up and adding to the GitHub discussions hopefully uh this slowly accumulates a

corpus of knowledge that like gives you an answer or at least um tells you what not to bother trying because we already did it and it failed um okay thanks we're probably getting close to the end here um I think maybe I got 10 minutes left uh does anyone else have an authorization issue burning because if not we can um cycle back to these two issues and take a look at them through the lens of how to ask permission which is this um paper from

2013 I think or 2012 um done by some uh security researchers at Google uh who were working on the Android permission system back when it was very very new um and looking at uh ways to escalate and manage and make decisions about request for permission um so you know 10 years later this has uh been the Bedrock of a lot of really interesting developments in both the Android and iOS ecosystem and I think when we like compare ourselves to web 2 uh as a litmus test of whether we're hitting the Mark we should we should probably actually be comparing ourselves to mobile operating

systems um and and measuring by that standard because they are uh really really really uh far more sophisticated not yet perfect but like a a better uh model to follow I think um and here if we walk through from left to right like the original notion of uh how you could use a decision tree to decide which uh permission request approach to use um you would start with is the uh permission that is being or is the action that is going to be taken with this permission revertible uh or severe um if if it is both revertible and low severity just automatically

granted right uh side effects will be you know like controlled uh and recoverable so no big deal you don't need to ask the person for consent to use this data some implied consent happened from some earlier step in that case where they you know hopefully they know what they're doing putting the information on them on on the computer itself um uh past that uh did the user initi the request or is this request uh like rooted in some business logic right um if the user initiated the request and the action can be altered then we pop up what they call a trusted UI does anybody

know this term no uh it's also a very vague term I don't totally like it but I could get used to using it it basically means it's a UI that is unspoof um that is originated from A system that inherently that user already has a trusted relationship with right so this is the uh um uh photos picker on Android or iOS right where you know that this is like you as an app I can't make it look like this is the photos picker one because I don't yet have access to your photos two CU there's a lot of uh UI hints uh

Shadows overlapping things and stuff being rendered outside of the canvas that the um the application itself has access to that like subtly show to me that this is the real deal right and we don't have very many examples of trusted UI um in in in the same way in the web 3 space but for sure uh the wallet client that you're using would be trusted UI and daps that you regularly interact with uh probably fit into that category as well right um and then last but not least uh does it need to work without immediate user approval

um if the answer is yes there that's where you would have used an install time uh warning those manifests that you recall from the uh uh Android ecosystem where it it's like this long laundry list of stuff uh that I will be uh providing uh just by downloading and installing the app right and it used to be the case that as an app you could request pretty much everything that you would otherwise ask for um with popups right up front and it was sort of like the onus was on the user to like read through that and decide whether it was uh uh worth it so you had a lot of apps obviously like that just

asked for everything and the moment that downloaded them uh they had basically like roote authority over all your data and they would scrape it right they would upload all your contacts they would start trying to siphon your photos they would like just do all sorts of nasty things and sell that stuff um over the years of course this is being clawed back and now even you'll notice like in the Apple ecosystem on Mac desktop um you know uh apps will ask for uh access to like read and write to various directories on on your computer right um in general it's good to inform people about stuff uh that that the app might be using at install time but it's good to really restrict that list and this is

something that as we in as we uh go further down the path of plugins uh Allah uh what's happening in the safe ecosystem or uh metamask snaps like we'll really need to be uh cautious about what is available uh at that those moments otherwise um and this is going to be impossible to read and I won't spend time going through it bit by bit um but there is this task we've been working on at secure design working group of attempting to update that how to ask permission decision tree and make it relevant to the web3 ecosystem that we exist in today so where

does where does trust get rooted to to make something become a trusted UI uh what kind of questions can I ask to help me determine the degree of information that I should be disclosing to somebody up front versus uh hiding behind um and uh show me the extra information uh breaking permission requests down to isolatable things and uh asking for them at the most timely moment right um there's been a bit of discussion in the industry over the last little while about

how to like um pre-request details in the DAP before you go over uh to the app so that like the first expression of what is being requested doesn't just occur in the wallet client that the DAP itself is able to uh um Prime the person for what's going to be asked we do this all the time in uh mobile phone apps right like you get to a point onboarding into the app where suddenly the app is going to need your location and the best practice there is for the app to explain why uh I'll show a quick example from a

different slide um so this is the popup you would then see the equivalent being what shows up in the wallet Client app but before you would get to this step uh this little purpose string here would have had like a dedicated uh moment in the app that goes hey I'm about to ask you uh for access to your photo gallery we use this for X Y or Zed um when I get then pushed over to the this is an example of a trusted

UI um uh do I want to limit access to the photos uh do I want to allow full access in in the web 3 space there going to be different options for how you're uh how you as an individual are able to attenuate that permission without necessarily breaking the experience of the app but like this kind of moment I don't think is done uh often enough right now and that pre-quest message uh a lot of folks are trying to treat it up front as an attempt to emulate the uh the exact interface that will show up in the wallet client and that's probably not the right path the right path is to

explain a little bit more about why this permission is being requested if it's a spend allowance uh you know like especially when you come into uh you know web 3 Neo fites who like actually problematically may not know that this information is going to be default public on an immutable Ledger right that they they need to be informed about that um we don't actually do that anywhere in in any of these flows because we know it's like you know insiders uh spelunking and uh mucking around with things um so like well

you're here you downloaded metamask I think you're already aware of what a blockchain is as we move on to the next 10 million 100 million people they won't be aware of this there's a a narrative that has stuck in their heads about blockchains being anonymous and so they think everything is is private and untraceable they do not know that uh these things are are default public so I think to avoid blowback uh when people do realize that uh it's it's uh incumbent upon us to to inform these folks about that part of it to then inform them uh gradually as they on board uh and and need to take actions uh what those are going to be and then kind

of work towards standards that will show up in the wallet clients themselves to make that like receiving part of that action in The Trusted UI of the wallet client far more legible we're done we can we can we can take more questions or we can talk outside while drinking a delicious white wine or something like that