One, two. Is that what you needed? Good afternoon. My name's Jennifer Cooke. I'm director of the Africa program here at CSIS. And I want to welcome you all to this panel today on the way forward on Sudan's Comprehensive Peace Agreement. We have a terrific panel today to talk about the challenges ahead, how to move the process forward. And I think that the agreement which is facing particular challenges in these coming years is at a critical moment. Just to start, I think the CPA was always understood to be a starting point in a long process. There were limitations to the agreement. I think these were acknowledged and recognized really from the very beginning that this was a limited agreement initially between the two belligerent parties to end what was at the time the hot conflict within Sudan between the SPLM and cartoon. And it was understood that that was limited, but this was meant to be, as I said, a starting point. And to tackle the larger problems of a transformation of Sudan, you needed to end that particular conflict first and then begin a process of political transformation. So the weaknesses, I think, and the limitations of the agreement were well understood at the very beginning. It was understood at the very beginning that the process of transformation and implementation of the CPA would require a great deal of international stewardship, hand-holding, brow-beating, and pushing both parties to live up to the commitments they made within the CPA. And arduous as the process was and as detailed as the final agreement was, I think much of the vision within the CPA was held in the minds of some of the principal negotiators, most notably John Gurang and Taha. And I think with the passing of John Gurang, there was lost a great deal of the vision for the ultimate implementation of the CPA. Part of what we're going to hear today, I think, is an assessment of where we stand in the implementation process of this, what the looming challenges are. And now as we stand at the beginning of a new administration here in the United States, what are the critical issues that this next administration is going to have to pick up? A perfect implementation of the CPA is very unlikely or a complete implementation of the CPA. But what are those critical red lines that must be followed through? And what are the greatest threats? And how can we preempt or mitigate those threats to the CPA? So let me introduce the panel. You have their bios, so I won't go into great detail, but we're very pleased to have Sir Derek Plumley here, who's come just for this event a very long way. Sir Derek is chair of the Sudan Assessment and Evaluation Commission since 2008, so he's fairly new to the CPA process, but not new to the region at all. He was UK ambassador to Egypt and to Saudi Arabia, and he's been director of the Middle East and North Africa at the UK Foreign Office. He is highly respected within the British FCO, as I've heard from many of his colleagues, and we're delighted to have him here. We're also using this occasion to highlight and profile the launch of a Chatham House report, which was authored by Dr. Edward Thomas, who's with us today, the report called Against the Gathering Storm, Securing Sudan's Comprehensive Peace Agreement. I think there are a number of copies available, and I'm sure you can find information on how to get more on the Chatham House website as well. Eddie has spent a long time in Sudan since the mid-'80s. He was a teacher in northern Sudan. He's worked with Sudanese refugee groups, and he'll talk a little bit about the methodology and the recommendations of his most recent report. Next, we have Ambassador Andrew Nazios. I think most of you who know, he is today on the faculty of the Walsh School of Foreign Service at Georgetown University. And he was most relevant here, special envoy to Sudan from December 06 to September 07, where he worked, indefatigably, on very complicated and often frustrating circumstances. He was also the administrator of USID and formally served as director of the Office of Foreign Disaster Assistance. Again, his biosphere, he has many more accomplishments that I won't go into. And then Alex Daval, who is a great friend of CSIS. He's program director at the Social Science Research Council in New York. He's been engaged on Sudan and on Darfur, in particular, probably longer than most people in this room. He's been a director of Justice Africa in London, and he's been a tireless advocate and analyst for the way forward in Sudan. So with that, I will turn to Sederik Plumlee, and we'll then, who will give the keynote, we'll then have presentations and open it as quickly as we can for question and answers from the audience. Well, Jennifer, thank you very much for giving me this opportunity to update on the CPA and for giving me the opportunity to come to Washington as well. It's much appreciated. Thank you. I think the meeting is timely, not just because of what's going on here in Washington and the impending change of administration, or indeed because of what may or may not happen in The Hague, but because it coincides almost exactly with the fourth anniversary of the signature of the CPA, which was marked in Malakal in southern Sudan last weekend, and thus with the beginning of the final and decisive two years of the six-year interim period set for CPA implementation in the agreement. And it sounds it's a bit trite to say so, but the CPA, it's worth stating, I think at the beginning, was a historic achievement in the sense that it ended Africa's longest-running civil war and the one which was possibly most costly in terms of loss of life and retired development. I'm very conscious of the weight of experience on the rest of the discussions on this panel and defer to it, but particularly, I would commend to you Edward Thomas' report on securing Sudan's comprehensive peace agreement, which I think sets out the background and the way things have developed very clearly and very well. My own perspective is very much that of a diplomat who's tasked with protecting the CPA and helping as best I can as best the commission I chair can to secure its effective implementation. The AEC, which gets a somewhat modest write-up in Edward's report, brings together the parties, they sit in on everything, as full members, along with the governments which supported the signature, witnessed the signature of the CPA, and supported the preceding negotiations, including, of course, the United States, and the international organizations which witnessed it, the African Union, the Arab League, the UN, and the EU. It's tasked with monitoring and supporting the agreement, and particularly so, particularly producing a report at the midterm in CPA implementation, which was the point reached in July last year. And so to a certain extent, what I have to say now is drawn out of that report, because it is an agreed assessment by the parties and by members of the commission. But what I say also reflects my own personal views of the way things have gone, and particularly so, of course, in respect to the last six months. The evaluation report noted that the CPA has been resilient in the sense that peace has been preserved between North and South, that the ceasefire has largely, I stress the word largely, but has largely held, the institutions of government provided for in it, and notable amongst these, of course, all those institutions in the South, the government of Southern Sudan, the autonomous government there, have been created and sustained, and revenue from oil produced in the South has been shared. And as a result of the agreement, some 2 million refugees and IDPs have been able to return to their homes in Southern Sudan. Against that, mistrust has persisted, fed by delays, partial, non-implementation of parts of the agreement. We could spend a lot of time attributing blame for that. In part, I think it's attributable to the complexity of the agreement, as Jennifer was pointing out. It was a very large task, really, to put in place all of the institutions and to pursue all of the provisions, which are there in the various protocols of the agreement. But as a consequence of these delays, many of the elements in the sort of CPA structure, which one might have considered essential to the success of, or success in achieving the objective of making unity attractive. A National Civil Service Commission, for example, or the National Committee on the Rights of Non-Muslims in the National Capital, or a program of national reconciliation and healing, or Human Rights Commission. These have either been set up belatedly and not fully resourced, or in the case of the Human Rights Commission, for example, haven't yet seen the light of day at all. Disatisfaction with the progress achieved led the SPLM to suspend its participation in the Government of National Unity in 2007. They came back into Government just over a year ago, and since they resumed participation, some significant milestones have been passed. The census, which is a CPA requirement, took place, albeit with Southern reservations in April and May of last year. The Oslo Donors Conference, the follow-up to the initial Oslo Conference, which was held three years on, was held in May 2 and was a success. There was fighting, serious fighting, which you'll about to be aware and abye, just after that. But in the wake of it, the parties moved to draw up a roadmap with tight deadlines for the establishment of interim arrangements in the area, and provision for the underlying dispute taken to international arbitration. Legislation providing a framework for elections at all levels in Sudan in 2009, as provided for in the CPA, was adopted in July, and the National Electoral Commission was appointed after a further delay, but in November. So there was progress during the course of last year, but it was intermittent and, at times, painfully slow. What I'd like to focus on here now, I think, is just five areas, five specific subjects. I mean, the CPA is, as I said, complex, and all of the provisions interlock with each other, and lack of success in some is likely to impact other aspects of the agreement. But nonetheless, five areas, which are crucial, I think, for there to be a chance of success in the coming two years. The five subject areas in question are the three areas, that is to say, Abye, Southern Kordifan, and Blue Nile, which is subject to specific protocols of their own under the CPA. Border demarcation, security sector reform, developments in the security sector, particularly, elections, and the 2011 referendum and what happens after it. With regard to Abye, the highest profile of the three areas, the immediate priority is to ensure full implementation of the roadmap. It has proceeded, that implementation, more or less has agreed, but with deadlines which have slipped, against deadlines which have slipped seriously. The final step in SAF withdrawal from the DIFRA oil field has still to be taken, SAF, the Sudan Armed Forces. A shooting incident last month in Abye, between elements in the Joint Integrated Unit and the Joint Integrated Police Unit, two units which have been put in place to take over security from the withdrawing forces of the SAF and the SPLA, underlined their continued vulnerability, the continued vulnerability of these units and the need for material support and training. The interim administration which has been put in place lacks of budget, and this is something which we in the AEC have been working on rather closely in the last week or two to try to encourage the administration and the government to get together and to agree what is needed. All of this needs to be put in place quickly, if IDPs are to return, and if there is to be any sort of foundation in place at the point at which the Permanent Court of Arbitration reports in June. At that point, in preparation for that, in my view, it would be wise really for the parties actually to engage in discussion now on arrangements for the longer term to implement the Abye protocol, which would hold whatever is the result of the arbitration process. As in the case of Abye, volatility in southern Kordiffan could threaten the CPA, the AEC visited areas in the state in November, and we were made aware of the anger felt by many in the former SPLA-controlled areas in the Newper Mountains, and indeed by others, including in majority Missaria areas, and neglect since the CPA was signed in 2005. Power sharing there has been torturous and aid and government funding inadequate. We heard differing assessments of the trend in security incidents, but all agreed that the state is awash with arms and the risk of violence real. There has been positive movement in the past six months in the shape of security agreements between the parties, which have resulted in the opening of the formerly SPLA-controlled areas, redeployments south by the SPLA units concerned, and moves to absorb and integrate the former SPLM, SPLA, police and civil service. But the fragility of the process was illustrated if that were needed in the past few days by an incident involving former SPLA elements, again in the JRU and government paramilitaries. The SPLM in the state feel vulnerable and fear reinforcement of government forces. Confidence-building measures and funding in support of integration are essential if security and stability are to be achieved. Unmiss and the international community need to encourage and support the integration process. The second priority is demarcation of the North-South border, which is now more than three years overdue. We have been told repeatedly in the AAC by the parties that the report of the technical committee, which has been working on this, it's always almost ready for submission to the presidency. But when it is, work will then be needed. Work on presentation to ensure that demarcation is understood as disadvantaging nobody and that the border is open in every sense of the word. And I think to resolve remaining points of difference, it should be moved forward now. Further delay will prolong uncertainty and tension in disputed areas and impact CPA implementation across a wide range of issues from redeployment to elections to the referendum. The third priority I mentioned relates to the security sector and the issues here are of course various and I haven't got time to go into all of them. But the persistence of mistrust between the parties is reflected in high defence expenditure and the concentration of forces in the border areas. The government in the south has another security challenge in the shape of the availability of arms there and is engaged both in efforts to disarm civilians and also to professionalise the SPLA. In the AEC, working collectively, we have honed in on really two issues. One is the need for support for the JIUs which I've mentioned, which are important and which are starved of equipment, training, you name it, they don't have it. And the other priority is a major programme of disarmament, demobilisation and reintegration as envisaged in the CPA. That programme is now moving. If it were implemented in full, then 80,000 people and their communities would benefit. But wisely, I think, UNMIS and the Northern and Southern DDR Commissions have chosen to proceed in stages, starting with what looked like the areas of greatest vulnerability and volatility, specifically Blue Nile and Southern Côte d'Fan, two of the three areas that I mentioned earlier. And we have been working with UNMIS to try to resolve donor questions about this and just last week the Japanese came forward with the first major pledge for the DDR programme. Successful handling of these three priorities, which in itself is a major challenge, that's to say the three areas, border demarcation and security issues, is essential if the CPA is to move forward successfully over the next two years and a return to violence avoided. Getting the remaining ones, elections and preparations for 2011 right, will determine the future of Sudan. Under the CPA, the constitution and the electoral law, elections should be held before July 2009. Taking the rainy season into account, this could mean they're having to be held in the next four months. The parties are working on bringing relevant legislation, the press and security laws, primarily, into line with the CPA, and the National Electoral Commission is working with urgency on issues related to its own organisation and funding. The preparations have yet to begin for a new electoral register, for any sort of public awareness campaign, and for the drawing up of constituency boundaries, which of course would be dependent both on the demarcation of the border, which hasn't yet taken place, and in theory at least on census results, which are still to be announced and likely to be controversial. There's also the issue of how Darfur should be represented when the election takes place. The task of identifying feasible dates in 2009 has been lies, squarely and squarely, with the National Electoral Commission and the parties. And I don't think that any of the problems I've mentioned though large are insuperable. Successful elections are central to the democratic transformation envisaged in the CPA, and arguably offer the best prospect of making unity attractive. But they will need careful preparation and international support, both in terms of technical and financial assistance and monitoring, when they take place. The fifth and final priority area, to which I'd like to draw attention, is the need to begin now to prepare for 2011. The CPA envisaged passage in the third year of the interim period of the legislation needed to make arrangements for the referendum which will enable the people of southern Sudan to exercise their right to self-determination. The right and the referendum itself lie at the heart of the CPA. The parties are now agreed to try, at least, to finalise the referendum law before the present assembly is dissolved, the present national assembly is dissolved, i.e. before the preparations for the elections take off. If that were to be achieved, it would be, I think, an important reassurance to the Southerners who feel that they may lose their blocking minority in the next assembly, possibly as a result of the census. There is a second aspect to this that is to say to the preparations for the referendum in 2011. The AEC's remit is to help make unity attractive. But anybody who's spent any length of time in the south of Sudan recently will know that the possibility of a vote for secession is real. Equally, however, the fundamental interdependence of north and south Sudan is self-evident, as is the need for both to continue to work together in peace. I think probably on this issue, the best thing to do is actually to repeat the message that we agreed in the midterm evaluation as regards the importance of the parties using the remainder of the interim period to discuss and develop links and arrangements across the political, economic, energy and security fields which look beyond 2011 and will hold whatever the outcome of the referendum. The mutual interest in a long-term, well-sharing deal in particular is obvious given the extent of interdependence in the sector and the degree of reliance both of the government in Khartoum and the government of national unity and the government of southern Sudan on oil income. Discretely encouraging dialogue on this is amongst the most important things the international community can do in the remainder of the interim period. Other deadlines in CPA implementation have slipped, but 2011 is one which, given the nature of the agreement and the strength of a sentiment, cannot. During the reconciliation event in Malikal, both President Bashir and First Vice President Salvekir from their different perspectives concentrated on the narrowing window with the President reaffirming the commitment to self-determination but also setting out steps a committee on a program of national reconciliation development projects along the border and then the south designed to make unity attractive. We could talk at length within the parties, but my belief is that both in their different ways are concerned to stick with the CPA through the remaining two years of the interim period. For all the mistrust, they need each other. But the agenda is dauntingly full both of outstanding business, notably I think I would highlight talking of red lines, the ABA arbitration and its successful handling and border demarcation and also full of a concentration of transformational events elections at all levels from the Presidential down to the State Assembly. Popular consultation in Blue Nile and Southern Coordefine provided for in their protocols with regard to the future of governance in the States and the referendum in ABA as well as that in the site itself. And all of these will require careful management. They're also going to require a degree of international backing and support. Indeed, I think you could say the process of negotiating the CPA was achieved with strong international support and a strong international presence. The need for coordinated international facilitation and encouragement will be at its greatest in the two years that are upcoming. Unmiss, the physical presence physical manifestation of the international community on the ground will be called on to take on new roles in support of elections along the border perhaps if and when demarcation takes place. I think it's worth asking how the activity of the International Criminal Court affects all of this. The answer must be that it depends in significant part on the governments and organizations who gather every month, almost every week actually in different formats around the AEC table including the United States including also both the movements which are represented in the Government in the North and in the South of Sudan all may come under pressure to react to developments in ways which are unlikely to advance the accountability agenda but could undermine opportunities for cooperation in support of the CPA and it will in my view be important for the members of the international community most concerned, whatever happens to find ways to signal their determination to stay engaged with both parties in support of development in security in the South areas and in support of the broader purposes of the CPA early appointment of a special envoy here with that sort of mandate but would be one such signal. I hope that a key message that people will take away from this meeting will be one of the centrality of the CPA itself to peace in Sudan. Without peace between North and South there could be no prospect of peace in the country more generally as Edward Thomas paper makes clear the CPA provides the framework within which the aspirations of other regions and parties in Sudan can be realised. Decentralisation the constitution and the specific possibilities opened up by elections this year. Some of the CPA institutions in waiting the Human Rights Commission or the National Land Commission for example could I am sure be crafted in such a way as to address imperatives in other peace processes. The SPLM along with others in Sudan needs to be enabled to play its part in the search for peace in Sudan but I will just end on one note of caution and that is that it would in my view be rash in the extreme to think in the context of an all Sudan approach the country is right of reopening the CPA in order to accommodate the approach. Peace between North and South and the opportunities it has opened up in the South and the areas affected by the Civil War remains an enormous prize. The agreement may not have been implemented fully as Jennifer said but or as its authors intended but the balance within it remains very delicate and this late stage is not the moment we are in. Thank you.


Good afternoon, everyone. Thanks for attending this talk. I'm Samuel. I work for Intel. And I'm going to talk about mobile payments. So first of all, a little background on why I want to talk about that. I'm the NFC maintainer in the kernel. And one mode of NFC is called card emulation. And this is the last mode that we enabled. And card emulation is actually about payment and transactions. So this is the last remaining mode to support to be able to claim that NFC support in the kernel is full and complete. So I got dragged into this stuff. And I'm going to talk about it now. So what are we going to talk about? So first of all, what's a mobile payment? Just to make sure we're talking about the same thing. There's several kinds of mobile payments. So I'm not going to talk about all of them, but just a specific one. How does it work? So what does it mean to do a mobile payment? How the transaction flows and so on. We're going to look at the existing bits in Linux. Can we do that already with Linux? And if not, what's missing? And finally, well, obviously if I'm talking about this, we cannot do it fully. So we have a proposal to do that completely. So what's a mobile payment? Well, it's a money transaction or simply put a transaction from a mobile device. It's simple as that. There are several kinds of mobile payments. You have SMS payments, direct billing to your operator, and contactless payments. So today I want to focus on contactless payments. SMS payments, direct billing. If you have a real telephony stack on your device, then you can do that already. So not really interesting to talk about. So what's a contactless payment? Contactless payment is basically a payment where NFC is the carrier between your mobile device and a point of sale. Like in this picture where this guy's paying for his coffee with his phone. It's not only about payments. It's also about coupons, loyalty tickets, actually events, tickets, and that kind of stuff. But also, some car manufacturers are starting to talk about having keyless cars or rental cars. So you could rent your car on the internet, and your phone becomes your key. And you don't have to go through all the, you don't have to go through the desk and everything. Same thing for the hotel, where even in this hotel, for example, the keys are RFID already. So you could simply use your phone and not do the checking, for example, do everything online. Contactless payment is actually already existed. I mean, it's a widely deployed technology. In a lot of transit network, for example, in Europe, I don't know about the US, but I hope it's also the case. But in a lot of transit network in Europe, you actually can already pay with some RFID card. And that's a contactless payment right there. So you have the point of sale. In that case, it's the metro reader. And you have your card, which is a smart card, with a little storage that contains the credentials and credits. And what you do is you just put your card in front of the reader. Magnetic fields go up, or go through, actually, and your storage removes some credit from the card. And this is contactless payment right there. So what we want is to be able to use our mobile device, our phone, to do all of this. Not only pay for your metro, but also for your rental car, for anything that accepts contactless payments. And to do that, we use the special mode of NFC, which is called card emulation. So we want to use NFC card emulation to do contactless payments. To be relevant and to be usable, it has to be at least as secure as contactless payment as it is today with an actual card. And the advantage of this, obviously, is to have everything in one device. So your mobile phone, your credit card device, your transit card, and everything else. So one device, a lot of services. So this is what we want, but this is what card issuers want. So EMDs, your card, MasterCard, Visa, all those guys work together, they actually allow you to do contactless payments under some very strict requirements. So to do that, you have your platform of the tamper resistant. It has to have security domain and very secure storage. And it has to be FIPS and CC certified crypto engines on the platform. So this is basically what the card issuer require from the mobile device OEMs and from the network operators. So you won't be able to even certify a mobile platform if you don't fulfill all those requirements. And this is not exactly what you find on your typical mobile SoC. So the Qualcomm, NVIDIA, SoC that you find in your mobile phone are not capable of doing that. Actually, not capable of fulfilling those requirements. I'm not saying they're relevant. I'm not saying they make sense. But this is what the EMDs will require from you. So their answer to those requirements are called secure elements. So secure element is basically a security, a secure platform that fulfill the requirements that I just listed. It's typically a very small platform that stores and run a few applications. Your SIM card is a secure element. But you also find other secure elements on a mobile phone. So all the mobile phones that have an NFC controller do have what we call an embedded secure element. So when you put an NFC controller on your mobile phone, the NFC controller manufacturer is smart enough to add a secure element on there that you could use for transaction and payments. It's really crucial because, as I'm saying here, a secure element is basically a space to rent for the secure element manufacturer. So whoever owns the secure element actually owns the transaction and allows you to put an application there. Because this is the application that runs on the secure element and on the host that's going to do the transaction. So as the secure element owner, if you say, I don't know, the Macy's application, I don't want it to be on my secure element, then Macy is out of your ecosystem. And this is typically Visa or MasterCard that decide on this stuff in agreement with the secure element owner. So it's really the key of the mobile payment world that it's currently happening. So who owns the secure element and what it does with it? And as long as you can say who can actually leave on your secure element, you can obviously take care of the transaction. So this is why it's crucial. So we know that now the transaction happens from the secure element. So how does all this work? So POS is the point of sale. So it's basically the transaction reader. So it's several steps. First of all, the point of sale sees the device and recognizes it as a card. So your device must run the NFC card emulation mode to be able to be seen as a smart card. So from the point of sale point of view, it doesn't make a difference if you're a mobile phone or an actual card. It doesn't see the difference, it's the same thing. Once it sees it and selects you as a smart card, it will actually select a specific application on the secure element. So if your point of sale is distributed by MasterCard, it will select the MasterCard application to simplify it, to put it simply. Once the application is selected, it actually runs on the secure element and it will start talking with the reader with the point of sale and talk to ISO 7816 APDUs. And this is where the transaction happens. So once the application is selected and running, everything is exactly like you would do with an actual contact card. So when you put your credit card on a credit card reader, once the point of sale has selected the secure element on the application on the secure element, this is exactly the same thing. So credentials are exchanged and then the point of sale get in touch with the bank and the car issuer to make sure that you have the credits and the transaction happens this way. Once the transaction is done, the secure element will typically try to modify the host if needed. If it decides that it needs to notify it that the transaction is done or that it needs more input from the user. So the host will be notified and you have a counter part to the application running on the secure element that's running on the host that will pop up and tell you, hey, the transaction is done or I need a PIN code or whatever. Whatever the application of the secure element decides to notify the host. So in that configuration, the NFC controller is really nothing but a pass through. So it gives an antenna to the secure element application and after that, from the host point of view, you don't really see what's happening. You just get a notification, as I said, if the application of the secure element decides to notify you. Yes, a certify API, you mean? Is that the question? No, it's, there's a Similiance API that typically EMVs will ask you to implement. But then you have stuff like Google Wallet, for example, that doesn't implement this. And they have their own stuff and they don't really care about EMVs. Although they have deals with them but they're so big that they can afford not implementing this API. But yes, there is an API. It's not mandatory but it's strongly required by the EMVs. So to summarize what I just said and so you have the host with the payment application running on the host, that's not the application that does the transaction. The one that does the transaction is provision on the SIM card. So first of all, the payment application will typically enable a secure element because this is another issue. Now you have a SIM card and you have the NFC manufacturer that gives you an embedded secure element. So you have two secure elements and typically the OEMs will provision the embedded secure element with some payment application and then the mobile operators will also provision the SIM secure element with other application. So your payment application running on the host needs to know which secure element it has to enable because many of those NFC controller actually don't run really well with two secure elements enabled. So the first thing you do is selecting which secure element you want to enable. After that you actually have a physical link between the NFC controller and the SIM card. I'm taking the SIM card here as an example. You have a dedicated line between the SIM card and the NFC controller. So you need to have a SIM card that's NFC enabled that has this specific line actually running. And after that the point of sale tries to detect you. So it sends some 14, 4, 3 frames that you would typically, oops, reply to. And after that you basically have an NFC link established between your point of sale and the NFC controller. At that point the host stops seeing, I mean it knows that it has an NFC controller but any of the NFC traffic is just, you don't see it anymore. It just goes through the NFC link through the SIM and backward. So the point of sale selects a specific application on the SIM card and this is the application that's gonna do the transaction. Like I said, when we reach that point, it's exactly like a contact card. So the point of sale will talk through NFC as it would talk over actual physical lines. It talks to the application on the SIM card, credentials are exchanged, and the next thing that the point of sale does is talking to your bank asking for, hey, does this guy have enough credit? If it wants to, in practice, busy business actually do batching, so they don't talk to your bank until the end of the day and they only accept small amount of money if you have to pay for, I don't know. I think the typical limit is $50. So if you have to pay more than $50, it would talk to your bank, otherwise it will try to avoid it and just ask at the end of the day or the week. Once the transaction is done, the secure limit application may notify you of the transaction termination and success or failure and the payment is done. So what do we need in Linux to actually enable all of this? As you probably understand now, most of the payment actually happen on the secure limit, so what we really need is a secure limit manager. So you may think that maybe only enable a secure limit is enough, once the secure limit is enabled then the transaction goes without any of your help, but there are more requirements than that, so the EMVs will require you to be able to talk to the secure limit, and not specifically to the payment application, but for example, so they have other meta applications that manages all the outlets installed there, all the payment application and they want you to be able from the host to know which application are installed and maybe even talk to some of this payment application to for example, ask what's your credit on your bus ticket. So the EMVs, these are mastercard people, will require you to do that, so you have to implement something from the host to be able to send those APDUs and request whatever the payment application on the host will request. They also require you to implement access control, so there is an access control list in the secure limit that you're supposed to fetch when you detect the secure limit that will tell you which application is allowed to send which APDUs to which application on the secure limit, so it's basically a whitelist of application and APDUs. On the host you also must be able to route notifications, so you get notification of transactions and you should be able to push that to the right application on the host. And finally, this is the API that you were talking about. It's not a mandatory requirement, but you probably want to implement that. So it's defined by the CMLI answer and it's a set of APIs that payment application on the host are typically expecting to find on your platform and they will implement their payment application on the host based on those APIs defined by the CMLI. So do we have that on Linux? Well, we have something called SIG for Android while SIG stands for secure limit evaluation kit. It's open source, it's Apache 2 license, but it's really specifically designed for Android and it's implemented by a TSM, which is TSMs are companies that are allowed to provision secure limits. So this company actually implement SIG for Android to show you how you would do that on Android. So it's really an evaluation kit more than anything else and specifically designed for Android. It has very limited hardware support, so you can run that on the Android emulator and you can run that on fairly old Android platform, some of the old Nexus. What we're seeing is some manufacturers are actually using SIG for Android as their payment framework. So I think Sony Ericsson used that for implemented their wallets. It's very seam centric, so it doesn't support the embedded secure limit really well and it doesn't support the SDIO secure limit really well neither. It has only Java APIs, so not really nice. And as I said, this is not your Google wallets, so the Google wallet doesn't use SIG for Android. It has its own implementation. It doesn't even implement the SIEM Alliance APIs. So what we propose for implementing a payment, a mobile payment framework on Linux is first of all extending the NFC netting API. As you saw from the previous diagrams, the only piece of hardware that actually knows where the secure limit are is the NFC controller. So it's the only piece of hardware that can tell you if there is a SIEM card that contains a secure limit and if there is an embedded secure limit on the system. So we extended the NFC netting API to send you a notification of available secure limit on the system. And we added a couple, well one netting command to enable or disable those secure limit. And the last thing that we defined but haven't implemented yet is of the NFC event. So when the transaction is done or when the secure limit, the application of secure limit needs you to provide some input. It sends some specific NFC events and you're supposed to broadcast or unicast that to a specific application and we have to forward that through NFC as well, to netlink as well. We obviously need a secure limit digmint to manage the secure limit, implement the access control that I was talking about and do all the APUs implementations. And finally the SIEM Alliance API. We want to implement that through debuts for application to, for payment application to use that as a SIEM Alliance compatible API. So this is what, this is how it looks like. We have the secure limit daemon there. It's plugin based so you can talk to your favorite telephone stack or you can talk to your favorite NFC stack. Obviously on Linux there is basically only one which is nerd and so the secure limit daemon abstracts the APUs for you. So abstracts the APUs handling for you. So if you want to send a specific APUs, your specific secure limit, you will go through either the telephone stack or the NFC stack without you having to bother about it. You don't know if the secure limit is on the NFC controller or if it's SIEM based, you just need to send this APU. And the debuts API you will see will be, we hope it will be used for implementing payment application on the host on top of it. So as I said, the Netting API is used for secure limit discovery and enablement. It's already upstream. It's even implemented for the PN544 which is currently the most popular mobile NFC controller. It's found on still most of the Android devices. Android switched to a Broadcom chipset recently but it's still not really widespread. The Netting API also allows you to send the APUs. It's implemented on a specific branch on NFCnext. It's not upstream yet. Those APUs are typically a few bytes and the payment application for a specific payment will send at least at most a couple of them. It's really low traffic and very small tables. And finally the NFC events for transaction termination inputs providing. Those are, they're defined but they're not implemented yet. So we don't broadcast them yet. This is something we're gonna do later. The secure limit demon. So it does all the APUs at fraction and we currently only support NFC and telephony. We don't do the ASSD because the secure, the SD consortium define as a specification for doing NFC secure elements on an SD card. This is something that I personally never seen. I don't know of any hardware that does that. It's basically an SD card with a couple of additional lines to be able to talk with your NFC controller. So from the NFC controller point of view it's really seen as yet another secure limit. We don't support that. If someone has this kind of hardware, I'm happy to buy it. From the secure limit demon we also implement the access control list which is specified by the global platform which is a consortium of network operators, ENVs, so these are master card people are there as well that are trying to define a set of specification for secure limit. So this specification tells you that the enforcement of this access control is entirely done on the host. So the secure limit doesn't do any enforcement of this access control. So if your platform is not certified you basically can send any kind of APUs to any kind of application on the secure limit. It will probably fail because typically the payload on the APUs are encrypted but still if you don't have this access control implemented on the host basically you can talk to any application on the secure limit and send in any payload you want. There's a fallback mechanism because this is a fairly recent specification that's based on basically a SIM file system. So there are some files on the SIM file system that will give you this access control list as well but we have not implemented yet. And NFC events are not supported yet. And finally the DeBus API, we want it to be compatible with the Simo INS API because as I said also it's not required by ENVs. It's typically the API that payment application companies will expect to find a new host. So if they have an Android application that's running on top of SICK for Android for example, it will be a lot easier for them to port that into a Linux based system. So the DeBus API lists allows you to see all the secure elements and enable, disable them. It gives you access to the basic channel. So there's one specific IO channel on the SIM card that's called the basic channel, where you do all the management of the SIM card. And it allows you to open a logical channel linked to a specific application ID. So if you want to talk to a specific application on the SIM card, you have to open a logical channel, link it to a specific, to this specific application and then you can talk to your application. Most of the SIM card support that and this is a way for them to do multitasking. So with several logical channels, they can run several applications at the same time. Well, not really at the same time obviously, but yeah, that's what they do for multitasking.  And the secure element demon will be released with Nerd. So Nerd is the NFC demon and it will be part of the Nerd releases. It's not yet there, but it's gonna be there quite soon. So the next step, I've been talking about the physical secure element, so the secure element that you find on the SIM card and on the NFC controller. But there are two new kinds of secure elements that are making their way to reality. The first one is the software secure element. So even though they're less secure than actual physical secure elements, a lot of people are starting to implement secure element through trusted execution environment on the host. So the ARM trust zone, for example, and X86 also has many TEs implementation should allow you to implement software secure element, host-based secure element that will, I mean, EMVs will tell you that the security is not as high as an actual secure element on the SIM card, for example, but a lot of companies are finding it's way enough to implement stuff like ticketing, loyalty coupons, and that kind of stuff. If you wanna do real payment and you probably don't want to put your master card on the software secure element right now, and EMVs will actually forbid you to do that. But for other use cases, it's perfectly enough. There are other secure elements, cloud-based secure elements. So there are several solutions for that. The Google wallet is almost there. It's almost a cloud-based secure element. So we want to be able to implement that through the secure element demand and see cloud-based secure element as just regular secure elements and talk to them the same way. We have to implement the access control for that mechanism. This is mandatory for satisfying your platform through EMVs and NFC events again. And finally, we want to be able to provide hooks for provisioning the embedded secure element. So one of the problem with mobile payment right now is that someone has to write into your SIM card to add the payment application. And that's someone need to be trusted, really, really trusted. And there are a few companies called TSNs that do that for mobile operators and EMVs. So we call them TSN, Trusted Security Managers. And those are the one that are provisioning your secure element with the right application. So when you, for example, install the Google wallet on your Android device, there's a trusted, there's a TSN that is contacted and that opens a secure channel between your SIM card and their servers and provision your SIM card without you actually seeing anything happening. But for the embedded secure, I mean, for the SIM card, it all goes through the telephony stack and everything is there. It already exists for doing that. But for the embedded secure element, we need to provide hooks. And those hookups are specified by the global platform and the SIM alliance that will allow TSN to also provision your embedded secure element through the NFC stack and the NFC controller. So that's missing right now. And I'm done. So if you have any questions, the EMVs. So the EMVs will tell you if it's secure or not. And, well, you can do that, but I mean, this is basically what the software secure elements are. They're almost that, but you can do that and you can say, hey, this is my secure element. But then to be able to have any TSN provisioning your secure element, you need to go through EMV certification. And EMV certification will look at your setup at your platform and they will just tell you this is not something we want. So basically you have a secure element, but it's empty. An existing what? Yes, the security is in the SIM card. It's in the secure element. So the payment credentials are in the SIM card. And according to EMVs, this is something you cannot get easily. This is what makes it secure. Yeah, yes, it's, their biggest problem is about, yeah, crypto engines and how it's certified and also storage. So where you store the credential material and is a X86 or an ARM platform secure enough? According to them, it's not. So they don't want to put any of their payment application right now on a whole space secure element. It will obviously cut the dependency on TSMs and the telephony stack and network operators that you could just provision it through any networking connection. But yeah, we're not there yet. But EMVs are right now accepting software secure elements. So secure elements running on the host on trusted execution environments for low security use cases. So ticketing, yeah, loyalty coupons, that kind of stuff. They're fine with that but not with actual payment. Yes, ARM trust zone is the specified software secure element but EMVs still don't want to do payment through ARM trust zone. They're fine with doing most of everything else, transaction, but not actual payment. Say that again, sorry. They can move it to anything. I mean, as long as they consider it secure enough, so yeah, if your watch does have an NFC controller with an embedded secure element, they just fine with it, it's no problem because it's certified by them. So people will provision it. Actually, with embedded secure element, it's pre-provisioned because typically you don't have the network connection to provision it properly and the TSM wouldn't want to do that without going through the telephone attack. So it's pre-provisioned. Google does that, for example. The Google wallet, you get your embedded secure element pre-provisioned with the Google wallet master card virtual application already there. So when you buy a mobile phone, if the OEMs agreed with Google to use the Google wallet, you already have your embedded secure element pre-provisioned with the right application. So you could do exactly the same with a watch or anything like this. Thank you.


Most African countries have an ambitious plan to be self-sufficient in rice. However, the effects of climate change like flooding pose a major threat to these ambitions. But there is something we can do about it. Our team has been working on this incredible rice variety that can survive and thrive after being submerged in water for two weeks. And it aims to mitigate the risk of flooding in an environmentally sustainable manner. In this competition, we have been testing these varieties in five countries in Africa. And the on-farm trials clearly shows that farmers in flood-prone ecology who use our improved rice varieties with sub-1 gene can get twice the yield of farmers who use their traditional varieties in their fields. Estimate shows that the combined work of all these activities in Africa can generate at least $3 billion in revenue in the next five years. And for every dollar that is invested in our technology, we can expect at least $43 in return. So ladies and gentlemen, the science behind this initiative is irrefutable. The technology is cost-effective, environmentally sustainable and scalable. And the business model and strategy is foolproof. The generous prize in AgriTech by Milken and Motspe can help us bring this innovation to the hands of those who need it the most at net-faster pace. We hope that you can help us in this mission. Thank you.


We have almost looked at all of the different ways that a batter can be put out And so I just want to keep going on that topic and we can look at a few more in this video so these are Situations where the ball is most of them are where the ball was put into play, but they are just not the traditional and the most common Outs that you would see like groundouts or flyouts, so The first one that we'll take a look at is if a third strike is not caught by the catcher When first base is occupied before two outs before there are two outs so a third Strike is not caught By the catcher first base is occupied before two outs and so you remember that if a catcher drops the third strike and and say that first base is Unoccupied which is to say there is no runner on first base Then the the batter is allowed to run in an attempt to to make it there and beat the force play on First and there's also the the rule also states that if it is Occupied with two outs then the the runner is also there the batter is also free to to run but in this case if if first base is occupied before two outs then it's it's the batter is is automatically out So the second way We can look at is that after hitting or bunting a fair ball He the batter's bat hits the ball for a second time in fair territory after hitting or bunting a Fair ball The bat Hits the ball a second time Fair territory and so this is Just saying that if If for whatever reason we have the batter and he he drops He he he buns the ball Or he or he hits it and it doesn't go very far and he he lets his bat go or he throws it and It makes contact with the ball a second time then that's an automatic out and so We're this rule is really just trying to prevent A batter maybe you know hitting the ball twice if the ball only goes a couple feet and he He hits it again or something like that to try to make it to go farther That's what this rule is preventing So so if the hits it if the bat hits the ball a second time in fair territory He's automatically out and there's a second part to that which says that if the the batter simply drops his bat and he's not intentionally hitting the ball then Then the umpire can judge that that play will simply continue and it's a fair ball The third way is That after hitting or bunting a ball that continues to move into foul territory He intentionally deflects the course of the ball While he's running to first base. So this is kind of a similar Rule to the second one here, so this is after hitting bunting a foul ball or a ball Into foul territory the batter intentionally the course of the ball first base and so Again, this is a similar one to this this above rule that we just looked at so if the ball Is hit out here and maybe the batter is is running toward first base and and he's right next to the ball and Generally, he shouldn't he should have dropped his bat by now But if for some reason he would to take his bat and and try to knock it fair or something like that then Then the batter would be called out for that So really it's irrelevant if the ball was fair or foul if he he you know tries to hit the ball a second time then could be called out the next way is that a preceding runner shall intentionally interfere with a fielder who's attempting to Make a play on the ball. So and that this would then would put the batter out So a runner You know somebody other than the batter is is Intentionally interferes a fielder attempting To catch a thrown ball or throw a ball You know attempting to complete the play So so this would would a lot of times this will Might see this whenever there is a play Taking place if we have a second baseman, and then we have a runner Who's on first base and he's running to second and and so if the balls hit here Basically, we're saying that the runner has to make or has to allow the fielder the opportunity to make a play on the ball so if the Runner doesn't if he runs into the fielder intentionally or or certainly in also if the ball hits the Runner then the runners automatically out. So so and then the other Time we might see this is if there is a double play being attempted And we have a say this is the shortstop is run over here and that he gets the ball Maybe the second baseman has Flipped him the ball and then a runner on first Who's out due to the force play here. He he makes some kind of Movement where he doesn't get out of the way and and So that that intentionally interferes with that player then trying to make the play


Hi guys, I'm Tasman Okudas, I'm with Steven Ogarkovic, and this is the Mr and Mrs game. Alright, who's smarter? Depends in what, who? You read a little bit, don't you? Oh, that's alright, if you get to kindle out on occasions. Yeah, yeah. I give you book smarts. Yeah. Who has the better taste in music? Yeah, this is quite neutral.  Yeah, well, we'll keep it to ourselves. I'm such a stitch city. Fair play though. Just put you down for who's smarter now after that one too. Who would win in a fight? Now I've seen Steven in the gym. I do get pretty hard. There's a lot to be afraid of. Orik and Steven would take me. Yeah, but I wouldn't want to hurt the man either, so we'd just do the quality. But you picked me. We call it even. Who has the best fashion sense? Well, I'm going to go me with this one, because these shoes he's wearing just proves my point. You can't be wearing that. It's just not on you. These are Birkensoft, ladies and gentlemen. It's not on. Thanks guys for watching. That was the Mr and Mrs game.