RAW FILE

ITU
DECEMBER 4, 2019
13:15 P.M.
FIGI SECURITY CLINIC

Services provided by:
      Caption First, Inc.	
      P.O. Box 3066        
      Monument, CO  80132
      800‑825‑5234
      www.captionfirst.com

***

This text, document, or file is based on live transcription.  Communication Access Realtime Translation (CART), captioning, and/or live transcription are provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.  This text, document, or file is not to be distributed or used in any way that may violate copyright law.

***
(captioner standing by).
>> Test, test, 1, 2, 3.
>> Test, 1, 2, 3.
>> Test, 1, 2, 3.
(audio is broken up).
Hi, Sarah, this is test for captioning, 1, 2, 3.
>> Hello, captioning test.  Hi, Sarah.
>> Hi, Sarah, is there a echo now?
(it kind of breaks up with a little echo).
(that is a big echo).
>> Perfect. I can hear you.  The meeting will start in a few minutes.
>> You can just mute your microphone ‑‑
   >> MODERATOR:  Okay.  Welcome back, ladies and gentlemen so, we are ready to start the next session actually on authentication which is a good follow on from the session that we had just before lunch, so we have a good panel, a good number of panelists today to talk a bit about strong authentication technologies for a seamless user experience in DFS, so the panelist, I'll introduce them first.
So Mr. Abbie Barbir from CVS Health and actually one of the co‑authors on the Report on Strong Authentication Technologies in DFS, the Report of the Working Group that he will present in a few minutes.
And then Sharmista Appaya from World Bank.  Kim Hamilton from MIT and also a remote speaker, Mr. Matthew Davie who is interest KIVA, and I understand that he's on the line.  Yeah.  Okay.
So without any further ado, I'm going to give the floor to Abbie for his presentation on the Report on Strong Authentication Technologies.
   >> ABBIE BARBIR:  Hi, everyone.  Thank you, Vijay, so the Authentication Working Group is part of the FIGI workstreams and so the focus of our working group was to look into authentication, but not just to talk about authentication.  We wanted to define what strong authentication means and also give examples of how authentication is used in real‑life situations, so it was more of an application and use cases as opposed to just theoretical.
This worked really well because we didn't take a lot of use cases and we did work together as a big group and we were able to ‑‑ but we wanted on top of it for people to be able to experiment with the technology that we didn't develop or talk about.  So with one of our vendors, CVS Northwest, they were able to have an endpoint at ITU that you could actually test what we have put in this report in real life, so there is an actual endpoint of FIDO authentication available to the ITU for people that want to test this technology.  So it's hands on.
So with that said, the Working Group was Chaired by me but there were multiple authors on the report and one of the main inputs efforts was done by Andrew Hughes, and he was what I call the main editor, so I need to give credit to Andrew because he was responsible for the majority of this report, so I have to thank Andrew.  Andrew joined the and is the Lead Strategist, but so he could not be with us in this meeting.
So the report could be downloaded.  There is a link on the website where you can download the report.  We did look at the report from various categories.  We looked at environments of authentication and how it regular relates to regulation and standards, and we tried to define what strong regulation was because up to today with all the advances in strong, the strong authentication is not really defined, there is a misdefinition of what strong authentication is depending on who is working with it, and we need to make sure we clarify that, what we mean by strong authentication and have it consistent.
We looked at various technology, some ITU and some are coming from outside of ITU technologies, and some coming from ‑‑ (audio is very soft) ‑‑ and we did not ‑‑ we wanted to go and be hands on so we have a list and implementation options.
So for authentication, two things happen with authentication.  The first question, especially if you're trying to do remote, the first question is who are you?  So there is an identity that we need to be fine, the identity need to be ‑‑ you need to make sure it is the actual identity, and this is done through that ‑‑ the report does not such include that.  It's a requirement to do authentication.  The vetting component can happen at various intervals, and based on the assurance of the vetting, you will have credential for authentication that you could possibly get.
The component is actually discussed by ‑‑ they have a very excellent report on digital identity and they really take a deep dive into the parts of identity and how ‑‑ I strongly encourage everyone to read the report on that.
So we did look at the two different technology, and so once you know who ‑‑ or we tried to do vetting from this online and now we do credential.  We issue a credential.  The purpose of the credential is next time you come to the site, you have to prove that I am one that has the credential.  (Speaking off mic).  How can I prove that I do hold the credential that was put in place and you need to do that online.
So, the report focused on that and focused on the needs on doing that.  So, before we go forward, we come to defining strong authentication and we have some authentication categories, and these trends of authentication, at least in the old school ‑‑ the old school say there are various categories, strong authentication and strong authentication becomes ‑‑ and the idea here is that you have to have one authentication factor from different categories.  Why we do that?  Because it's harder to prove authentications coming from different places, so the categories are something you know, and something you know is like password or something.  The other one is something you have like a phone, smartcar, other token card, and something that you are, which is physical, which is biometric.
So the idea here is that it's much tougher for the hacker to take over your account if you are asking for one factor from three different categories.  This is good on paper, but on practice it is not because there are ways to circumvent the factor that depending on what combination of multifactor that you use.  And then with this old school of thinking, the problem that you get iswith the user.  Now days after anything happens, you go to any website, I'm sorry we do not recognize you so we're going to send you as much as text to your phone.  It's the standard way of doing business now.  And it's not ‑‑ (Speaking off mic).
It's adding a little bit more security but at the end of the day there is a buffer requirement for consumer and it's impacting the consumer and having more and we don't want to do that.  It has to be a balance between strong authentication, convenience, and security.
So, I think most of the problem, most of the problem here in this slide is that the passwords, the passwords are really bad for various reasons.  People are not creative using passwords, they tend to reuse passwords, and with all the data breaches that are happening, recovery of an account using the password technique, it's really broken, so if you do dynamic KPI, multiauthentication, dynamic, practically most of the information that are in those systems, authenticated actor that wants to get into your account they can find, and if they cannot find, they can ‑‑
Account takeover is the weakest point of password system because the system is there, the account is there, the recovery is a couple of questions ‑‑ and you see most of the accounts for famous people that were taken over, that's ‑‑ we need to solve this aspect.
So this is why we wanted to define strong authentication because we have better technology today to solve for the strong authentication.
So what standards and integrations do we use?  Believe it or not, a lot of the work that we really need is ITU based or ITU‑T adopted, and we're fortunate to have that at least as access within our FIGI.  So 54 is based on the 63‑3‑3 which is being revised to reflect 800‑63‑3‑3 and focusing on B so it has very nice on how to do stronger authentication and how to achieve it.
So a lot of our work is based on the development of the eIDAS and other directive work is coming from the EU.  We also worked with ITU‑T recommendations that are based on title line authentication, in particular SS7 which are for identification that is resistant to the problems of multifactor authentication has and this is the key point here.  The FIDO solutions are not susceptible to program of multifactor authentication.
If you get spam email or phishing email, if you click on to that email, the probability that your account has been hacked is 40%.  Actually the success rate is 40%.  Any one that clicks on phishing emails, 40% of the accounts are taken over because even if you have as much as because the hacker just rely the SMS, user is expecting the SMS and the account has been taken over.  These are the hardest because the account has security ‑‑ so, you know, tomorrow during our FIDO session, we will talk about account takeover, how to detect, how to prevent, and what to do with potential account takeover recovery.  A lot of vendors for with this issue.
We looked into that.  We looked at various other technologies, combination of the connect, mobile connect we tried to do a lot of what ITU tried to do but they're based on the same accord basis, so they are smaller scope on working for SIM card and all of these are based on SIM ‑‑ (Speaking off mic).
However, the FIDO solution it's ubiquitous because it's technology after the W3C has verified credentials.  We also looked at IFAA derivative from FIDO for specific countries, but we have to go and take a look at it in these cases, and we looked at the Aadjharr regulation because we reason we didn't do that, related to identity vetting, and identity vetting varies from country to country.  Countries like Canada and the U.S., they don't have global ID, so the identity vetting has to rely on other data sources, but some countries like any other, you could have a direct credential and do the vetting based on the identity ‑‑ the national identity code, and also with China and other countries, so we had to cover at least these use cases just to be complete, okay, so we did that in the report.
So, what is leading us to a better and stronger authentication is a maturity of the technology ‑‑ (Speaking off mic) ‑‑ and today we're really blessed to have from W3C, a co‑chair of the Credential Working Group and she will cover that aspect of today, but tomorrow she will be covering in much more details of why the credentials are the key to liberate authentication and keep track of account takeover and so on, which is essential technologies because at the end of the day, it puts the link to a claim, and that claim is help and can refer to the climate of the user, and so you are the user as will be part of the authentication chain.
Passwords fail because authentication happens without the user involved.  I can take your user name and password and log on from anywhere in the world and you're not involved as the user, you're not aware of it it.  You only get involved once an account is taken over, so you have after the fact and not before the fact.  The trend with the fiber credential ‑‑ (Speaking off mic) ‑‑ easier to involve.  We hand it back.  And this is how we can have stronger authentication.  So we have to be very clear in educating people what strong authentication means, not multifactor, because you can still have all the same factors, but strong authentication is you as a user are aware.  You are aware that someone is using your credential 99% of the time.  This is where we have to go.  (Speaking off mic).
So our use cases, we had involvement and account offering and we have some of these based on various like whether you have national ID or non‑national ID, and also authentication based on DFS.  We looked at the areas of method using Aadhaar or fiber involvement or some specific edition ‑‑ (Speaking off mic).
And also ‑‑ (Speaking off mic).  You cannot just change direction and everything because we still have to deal with bigger systems.  Some people will have all the routers that are not transferable, some will be buying new devices, like every Android phone is fiber network in one way or another, whether it is software, the second pattern authenticator or browser was actually made for system which can have security on fiber op the Android phone.
So since this is not happening, the best way to achieve the strongest authentication is to do a risk authentication.  So one of the vendors we worked with from CVS Health they do authentication and they are the ones that put the ‑‑ for the ITU to experiment with, so Acceptto also contributed how to do risk‑based authentication based on the user and device.  All of that technology that is used to do the vetting work is (?) and also a profile user ‑‑ (Speaking off mic).
So you can use that to step up authentication when there is none, so if there is a high risk in access coming or requesting something that requires higher authentication because you transfer for example in a money transaction, so you could step up authentication.  So ‑‑ (Speaking off mic).
Okay.  With this, I want to do a transition to other colleagues, and to make strong authentication strong, the authentication layer, there are two other weaknesses in current systems, one is the vetting problem that we can solve with systematic approaches to define how to do the vetting, and Sharmista will talk about it, and then also the availability to link your authentication to you as part of the authentication flow.
(Applause).
   >> MODERATOR:  Thank you very much for sticking to the time as well.  I think you covered everything that was in the report, especially the use cases and we'll get a reading to come back with the use cases, but I think what Abbie was saying is we covered the strong authentication ‑‑ (Speaking off mic).
Now, we move to the next panelist.  I will invite Sharmista Appaya.
   >> SHARMISTA APPAYA:  So very glad to be here today I'm going to talk a little about the Digital ID Working Group which was set up under FIGI that ID is a foundational enabler of the digital economy.  What I'm going to talk about today is the report that was recently released by the Financial Action Task Force, FATF, and a report released talking about digital ID and some of the facets to consider with digital ID itself.
So just to start off with, and I'm assuming since most of you in the room are probably in the financial sector regulators, we need to explain who FATF is, it's an inter‑governmental policy‑making body, 39 members, two member organizations as well like the European Commission and Cooperation Authority there as well, eight regional bodies, bodies based in different parts of the world who are responsible for conducting assessments and compliance and there are 22 observers where the license of World Bank ‑‑ (Speaking off mic).
The main responsibility is to look at sort of AML CFD and set international standards for them, and so the way they've done this is had 40 recommendations and so those 40 recommendations are the standards, and quite often they're actually implemented into law in these individual countries to actually look at how this is looked at, how it's monitored, sort of the main areas surrounding that.
So, even though there is only 39 members within FATF, there is over 190 countries that have actually endorsed their standards.  So why did the FATF when they're only looking at AML CFD decide.  We know the rise in initial payments is pretty rampant recently, a 15% year on rise of additional payments and expected by 2022 that 60% of the world's GDP will be completely digitized.  And with this and growth of it comes quite numerous risks that are involved, and so the FATF decided that because digital ID is quite often the way that payments are tending to be made, they want to look at that.
The way they found the hook for that was Recommendation 10, and could Recommendation 10 of the 40 recommendations I mentioned before, specifically relates to CDD or Customer Due Diligence which are sometimes called KYC as well.
So when they ‑‑ so when they looked at customer due diligence, what they said was that they were going to look at it based on a risk‑based method using sort of different levels of assurance on how they were actually going to decide whether the method conducting ID was actually valid or not or useful enough.
So this is a decision matrix on how this was decided, so I'm just going to go through this quickly.  So is digital ID authorized by the government for use in CDD?  And if the answer is yes, it's quite simple, then the digital ID can be relied upon to do actually all the CDD verifications.
If it's not, then we ask the question to the regulator entity, is do you know the robustness and assurance levels of the ID system?  If it's no, then they need to go back and do an assessment to actually identify what those assurance levels are.  If it's yes, then they move on to the next stage, which is there assurance that it is providing sufficient to be actually used for CDD purposes?  If it's yes, then they can go ahead and use the digital ID for CDD purposes, and if it's not, then they need to sort of go back and actually refind a way to do that.
So, using this decision matrix, they've come up with a set of recommendation, which I'm come to right at the end, for authorities, regulated entity, and ID providers as a whole.  So, what are these levels of assurance?  Now, the levels of assurance are ‑‑ there are quite a number that are sort of available around the world, but the ones that happen to be the most popular are the ones that are used by National Institute of Standards of Technology, NIST, based in the U.S. and the EU Regulation, the levels of assurance tend to be three, usually, and it's from 1 to 3, so 3 being the fact that it's most robust and most reliable and 1 being the least.  And so each of these competentes that are listed down below on the slides will have three assurance levels.  Competence 1 talks about just the identity proofing, so it is the who are you.  The second is Competent 2 the authentication and looking at the identity lifecycle which is, are you who you say you are?  And then the third, which tends to be something that is a bit more optional, which is about the data portability, which I think we heard about a little bit before which talks about how can the data be portable and can the systems speak to each other and can identity be interrupted?
So whether a does all of this have to do with financial inclusion?  So a reason a risk‑based approach and levels of assurance are actually relevant and useful for financial inclusion is because it acts almost as the balance between something that has too many levels, and so it is excluding consumers from the system, versus something that allows everyone in so it has problems with the integrity of the system.
The levels of assure and the RBA help you reach the balance, what is rebust enough, what is reliable enough.  So just to take an example of subis a harren Africa where there are about 43% of people who are financially excluded and about 30% of them said the reason they haven't been able to get a bank account, which is generally how we tend to measure exclusion, which is on access, usage and right kind of product, is that they did not have the right kind of documentation.  They did not have the right kind of documentation to actually get the bank account, so how can wheation been laid out by the F ATF have a role to play in this?  Because it purports a use of a risk‑based method, uses levels of assurance and method that actually uses the risk that the consumer brings to the entity, it actually allows you to find balance as I previously said, and lowers the barriers for exclusivity.
So, the recommendations that the report lays out is based on three different tracks, the recommendations for the authorities, basically say that you need to take stock of the different types of digital identity systems that are available, and those digital identity systems should be audited and certified.  A risk‑based approach should be followed, and there should be an integrated multistakeholder approach that is based on outcomes and principles.
For regulated entity, it asks that the entity proofing and authentication is mapped to the CDD elements and that lower levels of assurance should be considered if the consumer doesn't actually show that much risk, or if they aren't at risk for money laundering or terrorist financing, but all the anti‑‑freud and cybersecurity processes should be taking on bored and implemented within the system, and also that the system should be transparent enough so that the authorities, so the authorities that actually regulate these entities can have a view of the relevant information that is underlying in that ID system.
Now, for ID providers themselves, they ask that they understand the AML and CFT requirements and that they actually seek and require that they are certified and they get certification from the government or an approved body, so in different parts of the world, the government will either ‑‑ so for example, in the UK, the government actually certifies lots of different providers who will actually give you a verified or license.
They also ask that there is transparency in the information and that transparency is provided to the regulating entities.  I'm going to stop there, so it's quite a whistlestop tour through the report, but I'm happy to take any questions later.
(Applause).
   >> MODERATOR:  Thank you very much.  So now we move to the next panelist, Kim Hamilton of MIT for her topic.
   >> KIM HAMILTON:  Hi.  I am Kim Hamilton and I'm with the MIT Digital Credentials Consortium and also the Co‑chair of the W3C Credentials Community Group.  Today I'm here to talk about one aspect of the report highlighted, which is emerging decentralized identity standards.
So, I'd like to start out with a couple of quotes from the report to sort of give the motivation for these emerging decentralized technologies.  So one of these is typical authentication systems in use today were designed for the pre‑mobile device Internet, so the Internet was designed without an identity layer and we've been paying for it ever since.  We ended up in a state where we rely too much on passwords and we do that poorly, in fact, we have strange methods of generating and remembering that don't do that well, and the digital financial services ecosystem requires standardized interoperable and strong authentication technologies to reduce risk and protect assets.
So, as Abbie outlined with the issues with multifactor authentication, one thing to highlight is that there is a movement beyond the simple password, the simple something that I know.  There is something I have, something I know, something I am, something the network knows, which could be used more effectively and highlight fraudulent activity, and then also, something I do.
So the report describes aspects and also the strengths of the various one.  So for example, with the FIDO2 project instead of technologies, you have secure authentication hardware devices where the authentication material never leaves the device, so this is a decentralization of the authentication material, which is already much better because as Abbie described, it's much harder for someone to both guess your password and have access to your device.
Data centralization risks remain.  Centralized data storage, so we're not talking about the authentication material but the data, we still have a lot of centralized data storage, logically at least, and these are attractive targets for hackers, strong incentive for hackers to want to get at it.  And effectively, users are at the mercy of each company's data‑handling policies, so with GDPR, for example in the EU, there are regulatory frameworks to help approach this, but in the U.S. where I'm from, we're very much at the mercy of all the companies, and I call it the only silver lining of the sad state that we're in is every time I give this presentation, I get to update with a fresh example.
So, two weeks ago we had a case where 1.2 billion records were found disclosed online on a single server, so this wasn't, in terms of sensitivity of the data, it wasn't credit card numbers and Social Security Numbers, but it was sufficient information that people could start to do something with.  It was on a lot of people, and so name, addresses, phone numbers, and actually social profiles and things like this.  Yeah, two weeks ago, so this just keeps happening.
So that's ‑‑ that's a limitation of centralized storage schemes which is sort of the next area that we want to chip away at, so the area that the report describes where this comes in is some emerging technologies and standards called Verifiable Credentials and Decentralized Identifiers.  Tomorrow we're going to go much more in depth in a series of sessions on how these work, but I'm just going to give a highlight of how or what benefits they provide.
So, the key thing is that the individual in the Verifiable Credentials model we call it the subject or the holder and they're at the subject of the change, and so to Abbie's point, it makes it a lot harder for someone to pretend that they're you because you are initiating the exchange and you are involved with in order to use a credential, a relying party can also ask that you prove that it's you.  So Verifiable Credentials and Decentralized Identifiers change that.  The architecture is designed to be decentralized at all levels, whether it's storage, the idea that the recipient or subject holder could have their data wherever it wants, but they could share it and someone could independently verify that it's ‑‑ that it hasn't been tampered with and that the issuer is who they expect it is.
So, just a quick introduction because the word credential can be confusing, and really it used to be called verifiable claims, so if you've been familiar with it before, this was a sort of year ago renamed.  So, by credential, we mean effectively any claim.  It could be a range of high stakes to low stakes material, a movie ticket, concert ticket, a card that is health care insurance, diploma, or even a password, so a credential is meant to represent, basically, a wide range of data about you that you might want to share and have prove of and accurate.  It's a lightweight wrapper, effectively a verifiable very confidential.  I said credential, and a verifiable credential is something that is able to be decentralized, and verifiable in a decentralized way.  So it contains some metadata like who the issuer is, things about when it expires, there is the claim itself which is the content that you see there, and then the proof.  So, this is also renamed.  We used to call it Signature but it was renamed to allow other forms of proving, so whether that's biometric proof or things like that.
So one of the benefits of it is that it's just a nice lightweight envelope, we call it, to express this wide range of credentials.  Now, what are decentralized identifiers?  They come in because they are what's called the subject of a verifiable credential, so decentralized identifiers, they are digital identifiers that are persistent, secure, and globally resolvable, and they don't require any central authority or immediatery, so for example, you don't necessarily have to contact a issuer of a credential to verify anything about it.
So, these enable, one, the subjects to decentralized verifier is embedded in the credential, so the subject can prove that I control this identifier and I can also prove that this credential is about me.  For relying parties it, enables a flexible trustable interaction with the subject.  And furthermore, it's designed to enable individual privacy, so in the fireside chat earlier, I think we were talking about virtual IDs, and that was interesting to hear because decentralized identifiers are really built around that concept, the idea that you can use and present different decentralized identifiers, and can you have a different one for each interaction, but you can still prove that you control them and you are basically a wallet or software agent acting on your behalf, can you aggregate and prove that the whole payload has to do with you.
This is a simple example of a decentralized identifier down here, so we start with the the type of scheme and there is the method there, about 40 different DID methods right now and more on that tomorrow.  But so, for example, a DID method might be anchored to the by the coin, Blockchain, might be on IPFS or the Sovereign Network and then within that you have the method specific identifier.
Let's see.  So that's probably enough about DIDs for now and more tomorrow, but this one visualizes what that might look like in the case of a project that I'm very involved with which is verifiable credentials for academic credential.
So we content layer that you see, that would be basically what I described as the verifiable credential, so that would be say adjacent payload, and embedded in there would be the recipient identifier, the recipient DID, as well as the issuer identifier or DID.
The display layer is capturing one thing that's very important, but that can get overlooked in verifiable credential deployments, and so if someone presents to you an image, they're likely not wanting to go look behind and find JSON and verify that that says the same thing, so some early implementations of Blockchain‑based credentials or decentralized credentials had this vulnerability.  But for example in verifiable credentials, you can embed a hash or there are a lot of different ways to represent it, but you can basically make sure that that image is tamper evident, so that gets rid of some form of attacks as well.
And then, the bottom layer is basically the proof.  It could be anchored to a Blockchain, but it doesn't have to be.  So one very common way of doing it to avoid problems of Blockchain storage is to only anchor the decentralized identifier to the Blockchain, but to have the credential ‑‑ even the credential hash of Blockchain.
So the benefits of this, one that I mention is that the recipient can prove control of their credentials and they can control them.  They are at the center of the exchange, they can take them around with them and use them in different contexts.  One area that is apparently a weird example, but it happens in the U.S. is colleges go out of business, so what happens to your diploma after they go out of business?
So, there are use cases like that, but more realistically, it's the idea of, you know, they are a central point of failure, whether it's a network concern or if you're worried about censorship, so the idea that it's verifiable without relying on a central authority opens up some new scenarios.
The other thing that's very interesting about it is I think of it as bootstrapping individuals with either non‑traditional backgrounds or maybe from more marginalized situations, and I think that verifiable credentials, especially, it's interesting in the vetting or the enrollment process.  So verifiable credentials combined with other techniques described in the report, they can let you view the history, this audit trail, and increase your confidence that this is a person and this is the person who they claim to be.
The standardization track, the W3C Verifiable Credentials Data Model recently got moved to Recommendation Status.  The decentralized identity data model is in the Working Group to perform that just kicked off, and so that's targeted May 2021.
There is a lot of work to do though, so there is the Verifiable Retention Ecosystem, how you share credentials with relying parties.  There is a lot in the Decentralized Identifier Stack including how you resolve, how you resolve a stream to a DID document.  And then also DID Auth and then lastly around secure data hubs and vaults and this is what helps the user or the individual with data portability.
So, thank you, and we will be moving to questions next.
(Applause).
   >> MODERATOR:  Okay.  Thank you very much, Kim.  So, now we'll move to a use case, and our next speaker, Matthew Davie from KIVA is going to talk about the digital identity ‑‑ (Speaking off mic).  Matthew, can you hear me?
   >> MATTHEW DAVIE:  Yeah.  I'm here.
   >> MODERATOR:  Go ahead, please.
   >> MATTHEW DAVIE:  I didn't realize.  Are we going to do the slides that I had from the other session?
   >> MODERATOR:  I'm sorry?  Your slides are on the screen.
   >> MATTHEW DAVIE:  Okay.  I didn't realize we were doing these slides.  I made these for another session, but I'm happy to go through these.
   >> MODERATOR:  No.  I'm sorry.  There are no slides.  There is just the screen.
   >> MATTHEW DAVIE:  Okay.  Perfect.  Thank you.  Perfect.  Thanks for having me.  I'm sorry to be audio only.  Some flight issues that will get you once in a while.
I wanted to start just with some quick reflections on what was said already and it's nice to go last because all of the smart things have basically been said already, but you know, starting with Abbie, I think that the movement toward putting consumers in the middle of the authentication of any process to access their identity or any information is super important, and we should do it because we can.
It's possible to put humans back in the middle of the Internet, and as Kim said, people were forgotten at the beginning when the Internet was designed and that doesn't have to be the case anymore.
And then just one of the things Sharmista said, I think it's important with emerging technologies and what's missed is getting the regulatory framework around them and technology often thinks of moving too fast or faster than regulatory capacity and as a technologist, I'm one of the few, but I think it's important to say that we were not elected as as technologists and do this so it's important to look at existing frameworks and figure out what's important on them but they need to fit into extended framework, and Kim I basically agree with everything you said because we see the world almost identical.
For the first couple of minutes before we go to questions and I'll be pretty brief.  I'm going to if he kus mostly on DIDs because that's the work that KIVA does and the most user‑centric and there is a ton of work going on here including the stuff that KIVA is doing.  A few things that often get missed when you talk about decentralization, I want to point them out upfront and then talk about some of the things that we're doing that interplays the government, private sector, and user.  A few things that get lost in terms of security is the first thing that someone does when you decentralize something for them is recentrallize it, so if you give them a decentralized identifier, the best case is they have a smartphone, they keep the data encrypted, off chain, only on their phone.  The people we're talking about for financial inclusion don't have access to that, so by design the first thing they're going to do is park it at agency with someone else, and so there is a minimum viable centralization to making this type of technology work, and you need to think about the security holes around that and what you're doing to user portability and what you're doing to user control over their data when you do that.
Even if they don't centralize it at all, they just put it on their phone, you've introduced user error, so whereas before it was a pain because the user or consumer couldn't be in the middle of their authentication, and now they have to be in the middle and they're forced to possibly make mistakes that they're not educated on what they're doing, and that's especially important for vulnerable populations.
And then Kim had a lot on where the data is stored on and off the chain, so I won't belabor that.  I'm going to take maybe two minutes and talk about what KIVA is doing, most notably in Sierra, but it's using them almost cookie cutten from Linux that follows W3C of decentralized identifier, emerging standard as Kim was talking about, and verifiable credentials and at a national scale plugging that in with what I call it three main groups in Siera Leon, the consumers interacting with all the people in the country for KYC checks and credit reporter.  There is the financial service providers, you talk about the minimum viable centralization and when you're talking about financial inclusion, you cannot make the assumption that the end user can be self‑sovereign and hold their credentials or hold their digital ID so there is going to be agency parked with financial service providers for some degree, and then the one that's often missed is with the government and regulators of helping extend consumer privacy practices, helping extend their technology capacity and ability to conform to KYC, AML CFD.  What we've done and I'm going to make a minute on this and then I'll be done is we've gone in and there is no system in there about 187 in terms of development, the shortest life expectancy on terms of the planet, 5 million adults, they just run an election in 2018 and UNDP worked with them to bootstrap getting national civil ID and getting basically 100% national coverage, about 98% cover ablg, and they did this to establish digital ID at the same time, and so we walked into a country where there was a centralized database of digital ID, regulations around consumer protection around this, and no iew tile tee for the digital ID after the election, used to vote in 2018 and then sitting there parked on a server.
So on that then we integrated a bunch of technology and we're helping them as they work with other advisors on the regulatory side to get the regulatory enablement, but we've made it so that they are an issuer, so when Kim was talking about issuers of credentials, they're issuers of decentralized identifiers and credentials to the end user.  The end user can choose to hold it on their phone if they have one, most choose to part it in agency with their financial service provider, so someone they already trusted and already trans acted with can be their guardian or agent of their digital identity, and then that decentralized digital identity can be used for authentication, for identity proofing, for all the things we're talking about here anywhere in the country, so any time the user wants to go and open an account, a KYC check can take two seconds and cost a penny instead of costing $6 and taking two weeks.
And getting someone's credit report can cost 10 cents and two seconds instead of costing 1.40 and taking two minutes and being incomplete.  So as we finish the integration and finish bootstrapping the country, what we're hopeful to see is the impact of this regulatory enablement that they're working on followed by the technology implementation that we're helping bring to make it faster, cheaper, and more secure to actually authenticate and use digital financial services at a national scale.
This is not the only thing that's happening.  Technology is moving super fast all over the world.  There were examples in Sub‑Saharan Africa and it's happening quickly there because digital is getting into the countries where there is no infrastructure, and so I and KIVA are super keen to try to get as many places to forward thinking because there are no systems today, so either we can put in archaic systems that we're talking about, man in the middle attacks, or we can find ways to leapfrog to 2015 or 2020 technology where you're setting them up, I think, for more success for the next 20 years.
I'll pause there.
   >> MODERATOR:  Thank you, Matthew, for this very brief introduction.  But we have some questions for you, that maybe you can talk a bit more in a few minutes.
So let's talk a bit about the report, Abbie.  You mentioned ‑‑ I mean, we talk a bit about strong consumer authentication and frameworks, and technologies, et cetera.  How would you define this?  What do we mean exactly?  I didn't see this.
   >> ABBIE BARBIR:  Yeah, so with strong authentication, I'm going to fall back to what FIDO does.  FIDO does two things that is the leap forward in terms of authentication.  The first thing it does is once you do an authentication step, there is a challenge.  The server will send a challenge to the FIDO agent, to the FIDO client and the FIDO client must advice the authentication so ‑‑ (Speaking off mic).  This is number one.  Number two, what the FIDO does is the actual privacy associated with private property is done at the agent, so if you're coming from Google.com, it will be stored under the Google.com vault and is validated by the client, a certified entity running a device.  So the task of validating is not left to the consumer.  They're not going to go check whether it is really Google.com or some funny name that once you go to the IP address you go to it and take a side, the hacker side.
The old traditional methods ‑‑ (Speaking off mic), it relies on the user.  The user is the weakest point.  So, for strong authentication, two things have to happen before we can continue.  We can kill the man in the middle, the phishing attack and not work with it with credential.  Because can you go to the phidhing side and come back to the FIDO agent and they will compare, and Google.com and XYZ and consider something.  The credential will not really, the user is not really aware, so we want to do that without the involvement of the user.  This is very critical because once you get the user involved, the user is your weakest point and they don't pay attention, they're not focused, and it's unfair because you're expecting a second level of sophistication here.  When you do consumer, you have to fit everyone, and everyone means that there is a different skill level when it comes to consumer technology.
So that said, I'll go back to what Matthew said, and I know that the question, I like some of the comments that Matthew said because we're going through decentralization but recentralization and there is a good reason for that because although like the decentralization is good in concept, not every consumer wants to be involved in their identity.  A lot of the people just want service.  I come to CVS because I'm sick and I want to use your telemedicine.  So if I'm sick, come to use our telemedicine, you have to set up the wallet and XYZ, and guess what?  I lost the consumer.  They're not going to do that when they're sick.  So I need to automate.  The trick here to get in the ecosystem is to be responsible part.  We have to be responsible as industry leader, so we can do the centralization under that.  Why we do that.  If the user won't forget me and using decentralization concept for data storage, there is one click I can forget everything.  Can comply with future regulation, I don't have to go back to CVS and reengineer and have more, so this is where.
If you want to come to CVS and say I have my identity with you and I need to go to another provider, I can issue you a verifiable credential, I can bootstrapping everywhere else, and I'm holding you hostage because of identity, you want you to be my customer because I provide for you better service, and this is where the future is going.  People will stick with you because you respect the user and we have the technology to do that here, and I think this is the bottom line of stronger authentication.  Better for the consumer, better services for the consumer, but don't have user consumer.  The old system is old school.  I own them because I own the data, and I don't think we should stick into that silo.  We have to move forward.
   >> MODERATOR:  Okay.  Thank you.  Thank you, Abbie, for this.  I now have a question for Sharmista.  So, you talk about this ‑‑ (Speaking off mic), do you think you can tell us a bit more about the issues related to individual ID systems that might affect the reliability and maintenance?  How they might be used in performing due diligence?
   >> SHARMISTA APPAYA:  Thank you.  So I think with ID systems, some of the big risks are, obviously, data privacy and protection.  And in any system that actually starts collecting biometric information or personal information, there is always going to be ethical concerns.  Some of these concerns are done away with with things like KPIs or public structures, but I think until the end of the day until we move to a decentralized system as some of my colleagues have been talking about, we're still in that model where data is collected centrally and there is an inherent risk in sort of data storage and what happens with the data once it's held there.
So, at the end of the day, I think it's still up to the government.  It's up to the government to actually look at data protection policies, to look at how data is stored, how data is collected, and how data is transmitted as well, and then what happens at the end of it.
Some other issues that potentially affect the reliability and independence is the uptick of data, of the digital ID systems themselves, and so going back to the FATF recommendations say they should be certified and almost give a stamp of approval by the government.  Going tack to the example of verify that I mentioned before, one of the biggest issues of Verify is there wasn't enough uptick in the UK itself, so I think it was one department that decided to take it up, but a number of the other government agencies wouldn't take it up.
The other issue with it is that the information that was collected in the digital ID systems was quite different to the information that was held within the systems of say the driving license, so the information that is held there, so there is a disconnect between there.
So I think the third issue is probably very important when the digital ID is the issue of data portability and interoperability between systems, so actually getting systems to speak to each other.  I'll pause there.
   >> MODERATOR:  Okay.  Thank you.  So moving on to Kim.  Kim, in your presentation you gave an example ‑‑ (Speaking off mic).  So in the context of digital financial services, can you talk maybe about the segments in the context of digital financial services, how would we verify?  How would this work?
   >> KIM HAMILTON:  The onbording part is one of the most compelling parts.  I do think that the onbording part is one of the most compelling aspects.  With verifiable credentials, it's a general architecture, it allows for multiple issuers, and to some extent the relying party gets to decide things like how much or what sort of trust they want to put in different issuers, what level of assurance they require, and but I think with decentralized identifiers, verifiable credentials, this data is all very inspectable and so you can use these credentials, one, to verify their accuracy.  But then can you also use it with other techniques to gather even greater confidence.
So, for example, one area of academic ‑‑ back to academic fraud, but so say even if someone is applying for a loan and they're trying to say there is someone different than who they are, if they present a fraudulent track record, sometimes people aren't even careful and maybe they get a Bachelor's degree after their PhD or something like this, so there is a lot of things about behavioral analysis, for example, that you can rule out by having these long histories of claims.
So, in the financial services sector, for example, I think that, you know, relying on a combination of these maybe smaller or localized networks, you can gain more trust over time in the track record of this person.  I think the other thing is in terms of ongoing exchange of information, so secure communication, but then also you know, in existing systems even after you authenticated, you may need to provide additional information about yourself, so how do you get that without contacting the original or the issuer of that claim, so verifying the credentials allows me to continually prove new things about me, allows me to inspect and verify.
>> (Speaking off mic).
>> The problem is bootstrap and with that someone has to issue first and the problem can become who can trust you so someone has to.  (Speaking off mic).  We are starting as one of the founders of the alliance and started a new alliance, and I don't know if you're familiar with it or not, but the data alliance is coming and it should be real ‑‑ what does the data alliance do?  It's going to be a collection or interoperable that boot strap every human being and for example get states ‑‑ (Speaking off mic).
Jump starting the process ‑‑ but this gap is being solved and I hope the data alliance should be announced in March and I'm hoping by next year we will have it.  A lot of high‑stake institutions, at least in the ‑‑
   >> MODERATOR:  Okay.  Thank you.  Matthew, please on the project you're doing in Siera Leon so how do you see helps you there.
   >> MATTHEW DAVIE:  Thank you.  I think to reflect what you said because it leads into it.  One is identities are a product of trust.  I think it was Abbie or maybe it was Kim, but someone was saying when the relying party when you're using DIDs has the opportunity to decide who they're going to trust, it turns up as an issuer of that identity or that credential, and I think that's really, really important because that allows you to not have to have individual people boot strapping their own.
Let me make an example.  Financial services a regular, which means even though in the U.S. every bank is booting up its own performance on KYC check, the regulator process and hoops they have to jump through are all exactly the same.  This is the perfect case to use decentralized identifier and give a KYC verification claim to an end user because if I go to Bank of America and I jump through all the hoops to establish that I am Matthew Davie and that I can open up this bank account and all the hoops I have to jump through to prove my identity, there is no reason JP Morgan has to go and reinvent the stuff again and DID would make that portable because you don't have to trust the issuer if you trust the process.  So the number of identities, let's go straight to the informal sector, the hard example, microfinance institutions, people that drive scooters with wads of cash out to villages, and the reason that interest rates are 60% in these villages is not because people default at 40%.  People default actually at under 3% and in some places under 2%.  The reason is because the agent gets out to the village, finds me Matthew, and wants to give me a loan or open an account for me and has no idea if 10 minutes ago I went and opened another account or checked out another loan with a competing financial service provider, and the reason they don't know that is because there is no consistent identity across my transactions that when I go and open these microfinance institution accounts, they're all in silos, non‑interoperable identities.  So whether a DIDs can get you, I think to think more of the wallets that the DIDs would live in and the claims would live in, it's just like your physical wallet.  It gives you one wallet that can prove that you're you and can prove it in multiple contexts, so in Sierra Leon, what does this mean?  It means as I mentioned before the government had a database of existing identities and that wasn't usable by the microfinance institution because they're way out of the village and don't have a connection.  If we can get the identity to the consumers in the village, they can reuse the same identifier and those sames credentials to go through and prove who they are to every single microfinance institution that comes to town, and what that means is that it's faster, cheaper, more secure for them to open an account and more importantly the data streams around their financial life and offline world, and this will start to bootstrap them and pull them up the funnel where they would actually be able to open a formal sector bank account or the microinstitution might decide they want two agents in the village instead of one, and I don't want to make this sound like it's too much of a silver bullet but it's a very, very foundational piece.  This interoperable, globally unique identifier that the human being can be in the middle of, like without doing this, it's going to take a long, long time to go and get those last people that are in rural villages who have been left behind by the current system.
   >> MODERATOR:  Okay.  Thanks.  Thanks, Matthew.  So let's move to something else now, stable coins.  Stable coins has been more and more popularity at the level of the financial arena, the international financial systems, so Sharmista, so what do you think about stable coins and the role that institutions play there?
   >> SHARMISTA APPAYA:  Right.  So as you mentioned, Vijay, they are getting more and more popular, so there are sort of private Crypto currencies or Crypto assets we call them, central bank issued digital currencies, and obviously the stable coins which tend to be backed by an asset, so either an asset owned by an institution or government‑backed assets as well are becoming more and more popular.
But, I guess what it needs to have is because the asset is backed sort of off the chain, a number of these stable coins are beginning to use sort of Blockchain as the system in which they work, and one of the key benefits of Blockchain is that the trust is actually built into the system, but because with the stable coin, you're actually relying on an asset that is still outside the system and you're relying on an institution and trust of the institution that's outside the system.  The trust is, again, still taken out of the system so you're still relying on trust of the stakeholders that are actually working in the system.
And so for this reason, digital currency ‑‑ I mean I'm sorry digital identity or identity of people are very important when dealing with stable coins.  There is a big risk of sort of AMLs, CFT issues because the players who are actually dealing with the stable coins and buying and selling are not always known, so there is an AML CFT risk and also risk because with the rise of digital currencies, they're removing the ‑‑ they're removing the banks as immediateries from the system, so if you're removing the immediateries that were previously responsible for doing the CDD and KYC checks, then you're introducing another level of risk into the system which needs things like identity to be able to authenticate and prove individual's roles.
And the third probably risk that is probably introduced in the system is because there are a number of new plairgs players, so a number of technology providers, if we look at PSD2, there is a new set of entities that entered the market called payment initiation, PISP and AISP for accounting service providers and payment service providers entering the sector, so all of these are new players entering the market that haven't been sort of regulated before, and so all of those, because of all of that risk that's involved, having a digital ID certified and authenticated digital ID is paramount.  If my colleagues want to add anything to that?
   >> MODERATOR:  Any members want to add anything?  Okay.  I think at this stage we open the floor to the audience for some questions for the panelists?  Yes?
   >> AUDIENCE MEMBER:  Hi.  I have two questions for Kim.  So you mentioned using DLTs for entities, how do you intend to use with identities in regions like EU when GDPR applies and citizens can request their privacy and erase of data.
Second question is regarding loss of prief see in DLT this is major issue, whether the private is lost or stolen, the underlying question would be in the case of stolen private keys that means the identities would be completely stolen and you can't recreate the identities, so how do you deal with this?
   >> KIM HAMILTON:  Okay.  There we go.  Great questions.  So, yes, I guess in general that's what's happening.  A general rant I have with Blockchain technology, despite using it a lot, is that people overuse it and it seems like a lot of basic solid architectural principles got lost along the way.  People wanted to put everything on a Blockchain and so responsible system design kind of got thrown out, and so this is a thing that happens the longer you've been in a space and the more bad practices you have to rant at.
But one of the problems that I see is with distributed ledgers or say Blockchains, I see two sides of problems, and so the only Blockchain that is sort of battle tested and it's been around public and you know it's actually been vetted, I would consider that Blockchain as Bitcoin the most trust worthy and now that's public, so if you anchor information to it, you have thier aisho problem you're talking about, so private Blockchains or enterprise Blockchains I worry equally about vendor lock ins, so I'm glad a lot of us are talking a lot about portable, so there are two sides of that, but then within the eraser problem it applies either way and I think that we don't know yet, so the thing that is a little weird in the space is as soon as people talking about GDPR and Blockchain, technologists instantly jump to a conversation about is a hash on a Blockchain sufficient?  And it feels like that conversation is just missing the boat because I think with GDPR and the privacy by design framework that it calls out, it gives you an opportunity to rethink, do you need to store this data, and you know, how do you identify people and why do you need to have this in your system even?
So I think, you know, really people should be rethinking the whole thing about information they store about people.  Now, with one way that sort of design for verifiable credential is say, not even hash of the credentials are on chain, so these centralized identifiers, if they are, you know, different on every event and therefore not correlatable, one way that people propose that it could be compliant is that, you know, there is no data on the chain to start with, there is not even a hash of the credentials on the chain, and there is just a decentralized identifier that no one knows anything about.
So, but, I think it's important that we don't know yet, so Blockchain technology is new, GDPR regulatory famework is new, and I think it's important that this conversation be ongoing.  There was a discussion earlier about regulating by principles and not by technology, so I think for me one of the interesting things is that I feel like GDPR is that and it opens a kind of ongoing conversation about how best to design systems.
And I think that on the loss of keys side, so okay erasers, and so I think just to sum up on that, I think we're still kind of sorting through some of the aspects of that but so with loss of keys, one aspect of just centralized identifiers that comes up is key rotation is built into the very notion of centralized identifiers, so create, read, update, delete, operations, and that works really well if it's a planned rotation, but say if someone, you know, someone gets access to your device or things like that, I think that okay, there are several ways.  Decentralized identifiers do call out ways of other means of identity recovery, so social recovery, things like that, but it's still new.  I think that it's important that those techniques get combined with other techniques called out in the report, so you know whether that's hardware, authentication devices, things like that.
So, but the answer is that we're still ‑‑ there are still a lot of standards and best practices that need to be developed as part of that.
   >> MODERATOR:  Okay.  There is one question here?
   >> AUDIENCE MEMBER:  I just had a follow‑on, I'm sorry.  And I don't want to get us down a spiral of just talking about Blockchain because I know the next panel is about that.
But if, and I think one of the things about Blockchain is that there is trust built into the system, right, so it's because of security in the system there is no single point of failure and all those sort of things.  If the data is taken and stored off chain, isn't that sort of going against sort of what Blockchain is meant to do in the first place?
   >> KIM HAMILTON:  So the data being stored off chain, there are two aspects of that.  One is that if you take a hash of the data and store that on chain, that's a technique that some people use to say, okay, we know that it hasn't been tampered with, but using that you can't look at the Blockchain and reverse engineer it.  The reason that I talked about what are the risks of having the hash on it, the risks are generally around correlation and things like that, so I think there is still aspects that we're picking through.
So there are ways to use Blockchain to, you know, kind of get the bare information that you need out of it, and that's where the responsible architecting comes in I think, and it's still new and we're still kind of figuring out what those best practices are.
   >> MODERATOR:  Thank you.
   >> AUDIENCE MEMBER:  Speaking again, so actually back on what the person from MIT said, I'm sorry I'm bad at remembering names, Kim.  Okay, so, actually, it goes beyond the conversation.  It goes beyond just saying a hash or not a hash or whatever.  We recently had had an event which was a Blockchain‑GDPR in Berlin and I attended remotely and it was part of the UN Series of events, where also representatives from the German Government and there were such issues gathering the connectivity to the Blockchain and GDPR were discussed and I'm not sure but I invite everyone here to consult that and slides are available on it.  And even for the tackling issues of making Blockchain long‑term secure and quantum resistant, which is another very important topic, but Blockchain rely on cryptography so they're as secure as their underlying cryptography is, and then this comes back to the other interventions by World Bank, which has data stored off chain and against the principle of Blockchain, and so actually with strong encryption what can be achieved is that you still store some personal data on the Blockchain, but encrypted, so you would still be able, right, to be GDPR compliant so you kind of make your ‑‑ you can do both maybe best of both worlds.
And now again, the inventors page is Blockchain‑GDPR.enforcement I invite everyone to see that.
   >> MODERATOR:  Okay.  The gentlemen over there?  Yeah.  Any questions?
   >> AUDIENCE MEMBER:  (Speaking off mic).
   >> MODERATOR:  You have a question?
   >> AUDIENCE MEMBER:  Yeah.  Okay.  I'm sorry.  With Broadcom so thank you for all the panels.  In fact, I have ‑‑ I'm troubled with one aspect, which is the trust.  So if I understand correctly, the system relies on parties that you guys trust, but what if at some point you cannot trust them anymore?
So, the point is that, yes, you rely on security that everyone is secure and so on, but I can prove to you that there are many security tools that are actually not secure.
So the old system relies on an assumption that is not said, which is who guards the guards, so I really have an issue on about from an architecture perspective, how are you going to continuously make sure that the parties you trust are really trustable?  I can imagine the speed at which that will happen, so I really wonder how programming ‑‑ and perhaps Abbie who knows me very well from Study Group 17.  Thank you.
   >> ABBIE BARBIR:  Okay.  I'll answer in whether it is ‑‑ it's not only the hash.  Even if we're like this gentlemen said, you can have quantum resistance.  This is not the issue.  When you store identity data, you're storing the history of that relationship.  If there is an identity ‑‑ (Speaking off mic).  At the end of the day to correct a problem on the block, you have to follow.  You cannot go back and unblock something that you have blocked.  And this is why we have to have off chain for user protection.  I mean, let's not miss the point here.  Whatever you start on the block, it's something to indicate something happened, where the hooks to encrypt and the hash for something that this ‑‑ (Speaking off mic).
Now, with respect to ‑‑ so the quantum resistance is not in play here.  Now how could you trust the trustee?  Remember, the credential is in your wallet.  The Bank of America issue you credential and you're using Bank of America credential to bootstrap your identity with JP Morgan.  You don't trust Bank of America, guess what, you don't use that credential.  You are involved, you have the wallet, you use today the same concept when you do a transaction.  If one bank gives you 20% interest rate and another one 34%, and you cannot pay your payment, you will go to the one that costs the least.
So, if you don't trust the players, credential in your wallet, you don't have to use it.  You know, but what you want to do is the problem of the relying party is you have a choice now.  Can you bootstrap your identity based on whatever you want.  And the other one is you don't have to do certain assertions.
   >> KIM HAMILTON:  I wanted to add something to that.  I think the other aspect is, you're right, you can decide that someone is untrust worthy, but some aspects of having transactions on chain, it gives you more visibility and transparency.  So for example, one of the use cases that we like is the idea of, okay, you can still have bad actors, you know, maybe they're issuing some kind of credential, some aspect of it is anchored on the chain, the issuance of it.
And then say they're a corrupt organization and they decide that I want to revoke all of these retentions.  The fact that you can see that on the chain, can you have, you know, the ecosystem can help decide that, okay, they're not acting in good faith, so there are aspects of it that, yes, you can use it to promote transparency to make these kind of decisions.
   >> MODERATOR:  Okay.  (Speaking off mic).  The next session of DLT.  If someone has a question on authentication?  Is it on authentication.
   >> AUDIENCE MEMBER:  My point is not actually on that.
   >> MODERATOR:  Okay.  Last question.
   >> AUDIENCE MEMBER:  So just to answer back to Abbie.  It has nothing to do with that.  It has to do with encryption does not equal to security and security by design does notes equal to security, so completely beyond it, I was not thinking at all about that, but my point is more about how are you going to ensure that precisely we all agree that we forgot the human in this whole architecture.  The first chance that we have to get the human in the architecture, no, we should not rely on the human because it is untrustable, so that's the paradox.
The other paradox is, yes, if I have something in my wallet, that's all good but how do I know that the other party is compromised in one way or another?  So my question is more whether the mechanism is first of all to get an experience that the user can't understand, and secondly, how you can transfer to the default parties the fact that the party has been compromised?  How do you evaluate that compromise?  How do you evaluate the risk you have?  How do you evaluate the security breach that you have?  So, there is an aggregation, there is ‑‑ what I mean is that there is a lack of security architecture in the background of all of that that could give you an architecture that captures all of the information, make competition with that and share with the other parties that hey this particular phenomenon was tagged and now we know it, or actually was two months ago and what do we do with it, or something like that.  This is this whole chain of security events that I think is missing in the picture, so maybe tomorrow in the architecture we can see something but this is it.
   >> MODERATOR:  Okay.  Thank you very much, so we will close this session, the question session, so basically in this session, we have covered the different secure or strong authentication technologies.  We have also raised a number of questions which we're now forwarding to the next session on DLT Security, and we prepare them for you, Leon, so all the best with your presentation in the next session.
And so I'd like first of all to a round of applause for our panelists.
(Applause).
  Okay, and it's now a good point to move for a coffee break, so we will have a 15‑minute coffee break, so we'll be back at 15:45 for the next session.  Thank you very much.
(coffee break).
(no audio at this time).
(captioner dropping call to reconnect).
>> Sort of a tech result, really, but the result is nobody has been able to attack by the coin Bitcoin.  The folks that are done on original Bitcoin are done on purpose, not as an offense of movement of attack.  Others would have a different view, but let's stick with that for now.  Instead the attacks against Blockchain implementation support tools, often similar to exploital software, resulted in ‑‑ (audio dropped, breaking up).
Just want to keep ahead.  Other areas of concern, download and dekript later.  It's longevity of the security of data of ledgers, we spoke about that quantum computing, I've got slide on that, that's one of the issues.  Authorized access, notes of distributed ledger can't usually distinguish between authorized or unauthorized users, and nodes ‑‑ node non‑availability is an issue.  A big one, yeah, and this speaks to the fragmentation and the interoperability between other concerns.  For example, the lightning network, which is ‑‑ it's a layer two.  So if you take layer one as the original Blockchain, then you have a layer two which is kind of an improvement.  So a Lightning Network is a layer two, and what that tries to fix is one of those items that I showed in the Trilema is a scalability problem.  Very slow.  You want to get to good processing speeds and right now you can't.  There is a tradeoff, you want scalability, you got to do something else.  Now, Lightning tries to do that.  It tries to be the accelerant, but the point is that it sits on top, but not in the original Blockchain, and again stylizing this way.
And there is a settlement done on the Lightning Network or peer‑to‑peer transactions, they report to the main layer one of original Blockchain and says, hi, we've got a quick set of transactions in layer two of Lightning and we now want to report to the main net.  Okay.  So that reporting is a vulnerability.  A bit of an air gap, if you want to call it that.
Okay.  So the user interfaces.
Also trust in nodes, so right now we replaced intermediaries with trust in node, you've got to trust the nodes, so without the nodes you might not know.
So, spark about quantum computing, this is by IDQuantic and the issue that they've come up with and tested these ‑‑ these encryption keys and found some of them are no longer secure, highlighted in red there.
And what they ‑‑ they're susceptible in terms of quantum computing in text as the quantum computing technology is now, so there is a risk, as I said, of the Crypto layer and so download and then decrypt it later when the quantum technology catches up.  Private leaks private data and not a good thing if you have a lot of personal data or private data.
Okay.  So what are the causes and risks of these vulnerabilities?  As I say, rush to implement solutions not properly tested, just get it out there, inexperienced developers, the concept of the wisdom of the crowd, means to some degree no central security assessments, and in fact I was in a talk with Vitaric one of the co‑developers of Atherium, and he said one of the main problems that he finds with Bitcoin is that Ms. Satashi Yakomota the author of Bitcoin, didn't build in some sort of mechanism to mediate disputes on development, so they fixed that to some degree in it Atheri mucker by design but you still have the problem with the Bitcoin.  So who gets together and decides whether there should be an improvement?  But it's ‑‑ it could be, and it has been, five people sitting together at a Starbucks in San Francisco affecting the entire ecosystem, and suddenly this change pops out of nowhere.  And no security assessment, and so as to whether or not the changes are viable.
Again, dependencies are often insecure third party data inputs, Oracles are vulnerable, sometimes offchain and that could be a trigger for a small contract..  A trigger could be small contract work, and it's if and then, and then something execute, self‑executing a small contract.  So if you get a wrong data input, like if there is a small contract resolving around interest rates or the weather or anything, if somebody feeds the, hacks the Oracle it's fed into the Blockchain and decisions are made automatically based on the incorrect data, so big problem there.
I mean, even to some degree the time and date of the Blockchain, it's just in some respects, even the time and date in Blockchain is an Oracle, it's fed in, so it is now Wednesday.  So if that's hacked, you've got problems.
Cryptoexchanges and user wallets, poor security, sort of a one‑sides fits all, broken dealer, meant to be exchange, custodians of private keys, and some of them are doing it but a lot not doing it well, so the.
(captioner change)

Services provided by:
      Caption First, Inc.	
      P.O. Box 3066        
      Monument, CO  80132
      800‑825‑5234
      www.captionfirst.com

***

This text, document, or file is based on live transcription.  Communication Access Realtime Translation (CART), captioning, and/or live transcription are provided in order to facilitate communication accessibility and may not be a totally verbatim record of the proceedings.  This text, document, or file is not to be distributed or used in any way that may violate copyright law.

                                             ***