 Cool, so I'll introduce yourself. So so we are in me and Roberto is going to talk to us about extending HTTP for fun and non-profit. Oh, the window is getting smaller. Hello everybody. So yeah, give him a big hand. Hi everybody, I am Roberto Poli from the Italian Digital Transformation Department. My work is to create a national API ecosystem that is capable to connect public and the private sector and Another of our goals is to provide cross-border services with the other European Union countries and today I will present how while writing the Italian API guidelines We started contributing to the HTTP protocol. So the agenda is the following after a brief Rational about using API guidelines to achieve goals and results We show how you can create minimal future landscape for your guidelines and identify relevant standards and communities to interact with Then the strategy will be presented using two case studies The first one is about writing an internet graph that extends HTTP starting from an old specification needing a refresh and the second one Where we wrote brand new specification From scratch to cover our use case that was not covered before Which is the go well one of the goal of the Italian digital strategy is to uniform the API's product produced by the old Italian agencies and This is quite challenging because we have What 60 million people? More than 20,000 public agencies eight cities 20 regions with some autonomy and To be able to create a uniform environment for Software produced by all those lights was Was was not easy the solution we found is to provide guidelines So that every agency should produce API's following those guidelines Well, when you write guidelines for the public sector you have a You have some risks because technical specification in government Risk to mimic a bureaucratic environment so you can have over complexity because Bureaucratic non-digital processes are just converted to Convoluted API's without a good redesign You have time constraint engineering because a small group of people should address Complex cases within a short deadlines Many times you have a closer development environment because the it community is rarely involved and Sometimes you have even closed specification And then redundancy because you are building Stuff with existing standards But you are not keeping in touch with the original communities so maybe you start to customize the behavior of Some specification you start customizing Protocols without asking for feedback from the original communities and This is quite risky. So When you write guidelines and You have to write something that should be followed by thousand of implementers and suppliers You have to prioritize your goal and features When you prioritize your goal and features It's easy to identify the stakeholder and The face feature landscaping, you know easily Which are the people you have to to talk and who you ask Who you need to ask for and we need to keep in touch So about the goals we found essentially four goals One the first one was a consistent design We wanted that all the API is produced by the agencies had a consistent design and Were based on a consistent rule set and another one very important is schemas standardization because when you have to create an ecosystem you should rely on standard schemas and the meaning in the semantic of Every field and Of the objects you're used should be confrontable for example If you use a person schema You should name the fields in a consistent way. You shouldn't use different fields for the same for the same For the same element and you should Split fields in a consistent way. For example If you split always name and surname Every agencies should split name and surname and shouldn't mix up those fields Another team is reliability and security. We wanted to enforce our service management model To address cascading failures and we need the security frameworks that lower a legal risk for providers because if you don't have a consistent set of security rules agencies Won't just provide API because they will be afraid of Data breaches they will be afraid of Falling on Some GDPR Regulation and data protection issues and then they will just Avoid serving citizen and all this stuff should be done Engaging and creating communities both in government in for developers for between implementers and standards So Let's see and simple example consistent design schema reliability and security. Let's make a Grid start with four rows. Those are our preliminary goals you can use your own if you are planning and Nego system. It is both valid for if you Work in a company in a private company. You can follow the very same framework so this is a pick your goals and then on the columns Identify the relevant communities and technologies For example for the schema for the design for the reliability We always have to confront with all the national agencies We will keep in touch with other European countries and check Let me see if your schemas for personal data are the same of Mine which are the difference. How do you implement security features and so on? This column the third column is the one on which we will focus today is the standard one These are the column with the ITF community the world what what consortium standard communities and here We will put all the information and all the relevant standards that we are going to use To provide schema design reliability to achieve the schema design reliability and security goals finally We have communities one community can be the Python communities for example but there are many other communities that can could be interested in works on security for example on design on schemas and another one we have vendors communities because if we have to provide features that People have to implement We will have to get feedback from vendors and this is very important so again Those are the main Communities we identified but sure in your context in your framework. You can pick your own communities and then let's start to feel all the Cells of the grid with standards for example for the schemas we decided to use between the others those standards The first one RFC 7807 is jason problem is a standard Jason schema for managing error and issues then we have a standard for timestamp. We have one for currency codes and Languages we are we are using J So just Write down all the relevant standard that you are going to use or that you are interested in for your API ecosystem on the design. We relied heavily on the standard Latest HTTP specification that is RFC 72 30 and over and Another interesting Community and specification is the open API Specification Under liability we visit everything on the HTTP with a rest approach But now we found a missing feature in the standard HTTP You cannot find enough Specification to provide up an integrated service management environment for such a large ecosystem So we just noted that we had to Work on that and keep in touch with communities and investigate Again on security we had similar issues because there are many specifications. There is the digest header. There is jason web token joth and so on but there are even draft standards that are not consolidated and Still there is not a non-revogation framework. So in HTTP With a rest approach, you don't have a very tight framework To define a non-revogation Protocol and well on the other column the community's column. We have a set of communities we Engaged with During this work for example on the security staff we discussed between ITF W3C HTTP communities and then banking API communities that was very interested in such Features so we now have agreed and that strategy to gather and get all the interesting Technologies relevant technologies And where we can find the missing blocks So Let's start for the first use case We started the first use case and we Started proposing solution we research and analyze actual solutions And even if not standard and we include in our study experimental work and research papers We wanted to achieve as we said in the slide before a non-revogation framework based on HTTP We identified the various building blocks for building such a non-revogation framework and We focused on the simplest building block that wasn't completely covered by standard specification This was to ensure the integrity of the payload body of each TTP request and responses This was usually done with the digest specification We did But this specification it's not It's not very used Recently so What did we do We started engaging with the community and this gave us a series of unexpected outcomes We found that many implementers didn't use the digest header in a proper way and This was because this specification was quite old and We then started to keep in touch with implementers and other HTTP experts and Everybody said okay digest could be a suitable solution, but it's quite old and Somebody should just rewrite it But nobody has the time to do it then I volunteer for this kind of work And I draft a standard solution. I rewrite revote all the digest header specification. I found Cloudflare employees that helped me in this work and we revote almost everything adding details and fixing loopholes We looked for People to help us we spoke with suppliers we and vendors We got feedback and awareness from many implementers and then when we thought that everything was quite good We got back to the ITF and They say that they liked our work and This resulted in the adoption of these Specification Now that I was inside the HTTP world group I learned a lot even in on Matters that I didn't know before and This helped me in improving our guidelines even on subject that were not expected before then we continued to contribute to The draft and to other specification and we will do it until the digest internet draft will Obsolete the old draft and became A new RFC So the trick here was to join the community not as somebody which wanted to get Something from the community But as a volunteer for an housekeeping work for something that Everybody wanted to be done, but nobody had the time to do here. We can see the Digest header drafts these these drafts Provides a content integrity for various API included banking warrants Now it is widely used in conjunction with signatures and Has now been adapted to the latest HTTP specification it has better security consideration covering signature usage and Clarify a lot of ambiguities in all these path We learned a lot. So it was not just something that We did to Push our use cases inside HTTP, but it was even something that We got from the HTTP community that is very warm and that is full of very very Knowledgeable people Okay Working with the first draft We made friendship with the HTTP community we had the opportunity to learn a lot of interesting HTTP features and In this way we got social with other HTTP experts We become became knowledgeable of the ITF process Now we know how which are the steps That you have to to do between the writing of Specification and the approval of the specification We got involved in other HTTP specification that was very interesting and useful because in this way we learned a lot about Security issues we have removed and fixed in our guidelines and Even we discovered the existence of the HTTP tree and other interesting features that are now work in progress inside the HTTP work group so With a strength of all these Social relations of the knowledge we got in working on the first specification We decided to work on another missing use case While did that just other was a missing use case that was based on an existing specification The second case was We worked in Greenfield because There was no existing specification on that And this is the rate limit header fields for HTTP When you issue a lot of HTTP requests a server may be Overloaded and if you if the server gives you just a limited amount of quota or request You may end out of requests and your request will just receive an error A nice way that could that the server can do for you is to warn you and Tell you in the response how many requests You are left So the current landscape is that when you use API getaways every API getaways returns This information at if in a different way So there are more than 12 possible HTTP rate limit headers because there is no specification. There is no standards Did the results is that many clients just ignored them and Their request eventually fails We then wrote these drafts Together with Alex Martinez from Red Hat Well, we standardize three rate limit headers. It's very simple drafts but there are some complexities for the management of security of the of this kind of draft and then we started working with suppliers and cloud providers to implement them in this case The interest the interactions with the HTTP were group were not the core point Okay of this specification the core point to manage The API gateway vendors to implement it and then we have the Kong API getaways Implemented it a readout API getaways implemented it Microsoft Azure API getaways Supported us and allowed To configure the API the Azure API getaways To implement these features we have libraries that are currently implementing that There is an API from the British Government that adopted this draft so in this in this work the The interaction and the communities were quite different and then the last slide There are some other communities and drafts and standards we are working on Well, there is a digest headers and the right limit headers. I presented now We work and manage to be approved even a couple of features into open API Just like the mutual TLS and the summary metadata Features, we are working inside each the ATF to support and HTTP signatures protocol. We are adding a metadata in open API and still continuing to work with suppliers and community to Implement features that we missing features that we are needed that are needed for our guidelines. Well, I'm Finished I hope you enjoyed the presentation. It was short, but I Tried to make it easy Those are my References well Feedback welcome and questions questions welcome Thank you Roberto if you want to drop a Question just use the zoom Q&A functionality We don't have any questions yet Roberto. Just wait for a little bit Okay, in case we can even continue On the slide or on the Talk on the yeah the talk channel on this card on this court All right. I'll just wait a little bit more if not Okay, so if you have any more questions to oh, there's a question here from Diego with all these different institutions What's the main challenge for integration? well the main challenge is probably the legacy and the knowledge of Technology inside the the institution. This is why we focused on our work With suppliers and technology providers because for example if I have Products of the shelf of products that supports a specification institutions can just Use those products those open source products and Doesn't they don't have to get to Too deep into the technology issues. So Those are I think the main the main problems and yes and the legacy institutions have legacy software legacy architectures that and there is a very there are very long times for Dismissing and renewing institution Architectures All right, thanks for better Give give Roberto big hands