Extending HTTP for fun and non-profit How the API Italian Interoperability Framework is contributing to global standards Europython 2020 Roberto Polli API Ecosystem
AGENDA Agenda Writing API guidelines ➔ Identify standards and communities ➔ How writing the Italian API Writing an Internet-Draft Guidelines led us to contribute to the ➔ HTTP community The RateLimit headers Draft ➔
THE CHALLENGE Standardizing all public sector APIs Guidelines can uniform APIs 60M People produced by thousands of service providers +12k Public Agencies +8k Cities 20 Regions ( ∞ cultural heritage)
API GUIDELINES RISKS over-complexity: bureaucratic non-digital ➔ processes are mapped to convoluted APIs without a proper redesign Technical guidelines time-constrained engineering: a restricted ➔ Risks groups of people addressing the above use-cases within a short deadline Technical specifications in closed development: the IT community is rarely ➔ government risk to mimic a involved. Development happens in a close bureaucratic environment environment. Sometimes even the specifications are closed redundancy: when built on variation of existing ➔ standards without keeping in touch with the original communities
GOALS AND KEY FEATURES Consistent Design & Schema standardization: ➔ Identify Guideline goals introduce design rules and standard schemas to uniform APIs between different agencies and key features Reliability & Security: enforce a service ➔ To write a guideline you have to management model addressing cascading failures and security frameworks lowering legal prioritize goals and features: this eases the stakeholder identification risks for providers and the feature landscaping And always... engage and create Communities : government, developers, implementers and standards
GOALS AND KEY FEATURES Schema Design Reliability Security IDENTIFY GOALS - pick your own!
GOALS AND KEY FEATURES Schema Design Reliability Security National EU IETF, W3C, ... Communities Vendors IDENTIFY COMMUNITIES - pick your own
ADOPTING AND PROPOSING STANDARDS: AN EXCERPT OpenAPI, IETF, RFC7807, RFC3339, ISO4217, BCP47, Schema Jsonschema, HL7 RFC8259, .. OpenAPI, HTTP HTTP (RFC723x), OpenAPI Design IETF, ISO Reliability HTTP, TBD:service-management IETF, W3C , HTTP, JWx, Digest, I-D.signed-exchanges, Security Banking APIs TBD:non-repudiation ... IETF, W3C, ... Communities Fill the cells with specs, products, communities,..
CASE STUDY: NON REPUDIATION ON HTTP Case study: a non-repudiation framework based on HTTP . Find missing use-cases Study existing solutions and relevant technologies, and propose solutions including experimental proposals. Identify the various building blocks, which parts are Research and analyse actual not covered by standards, or have divergent solutions, even if not standard, and implementations. include experimental work or research papers. In our case, we focused on the simplest building block: the integrity of the payload body via Digest HTTP header.
CASE STUDY Our experience with the Digest HTTP Header: draft a standard solution fixing existing ➔ Participating to global loopholes and adding examples standards engage with communities, suppliers and ➔ vendors, look for co-editors, get feedback and awareness from implementers Engaging the HTTP community while get consensus inside IETF , resulting in the ➔ facing data integrity in REST, gave adoption of the Digest Internet-Draft unexpected outcomes. contribute: continue working until the ➔ Internet-Draft becomes a standard RFC We joined the community as volunteers for an "housekeeping work".
Digest Header Provides content integrity in various APIs included banking ones. Users Widely used in conjunction with signatures. Adapted to latest HTTP specifications. Better security considerations, covering signature usage. Ideas Clarify ambiguities found in its usage adding examples.
CASE STUDY Our experience with the Digest HTTP Header: Iterate! got social with other HTTP experts ➔ knowledge of IETF processes ➔ Working on Digest we made got involved in other HTTP specs friendship with the HTTP community ➔ and learnt many interesting HTTP discovered HTTP/3 and other features features ➔ Iterate on another missing use-case!
RateLimit Headers Every API gateway implements its own ratelimit headers. Users Thus many clients ignore them. Standardize three headers RateLimit-Limit RateLimit-Remaining RateLimit-Reset Ideas Working with suppliers and cloud providers to implement them.
OTHER SPECIFICATIONS AND COMMUNITIES WE ARE INVOLVED WITH Digest Headers HTTP Signatures We maintain the new I-D for the Digest header. Contributions are We participate to the discussion on HTTP Signatures which is used welcome on the IETF http-extension github repository. by many banking APIs sign transactions.. Rate-Limit Headers API metadata in OpenAPI We proposed a new I-D allowing servers to publish current Exposing API maturity and lifecycle informations into OpenAPI request quotas and clients to shape their request policy and avoid #1973. Considering well-known URIs for exposing service being throttled out. documentation and description. https://tinyurl.com/draft-ratelimit-html OpenAPI: Mutual TLS and Summary Suppliers & Community OpenAPI is WSDL for REST. We supported the inclusion of Supporting our Guidelines in various opensource software and mutualTLS and the "summary" field into the new 3.1 version. between suppliers and vendors. - WSO2 pull/7059 , - Apicast issues/953 , pull/929 - Kong issues/233/ - SaaS providers: reporting-throttling-information , openapi3
Roberto Polli • Email: roberto@teamdigitale.governo.it Contacts • GitHub: ioggstream www : https://innovazione.governo.it twitter: @InnovazioneGov — Document released with Images from unsplash a CC-BY-SA-4.0 license
An Interoperability Framework for Public Services should be: Main takings Oriented on data (resources) rather ➔ than processes independent from technological ➔ architectures (eg. gateways, ..) Main takings on based on industry and the facto ➔ standards used on the internet by interoperability the IT industry while writing the framework and confronting with agencies and Public sector should: countries. participate to the creation of ➔ industry standards to ensure that gov't use cases are represented in the appropriate fora coordinate when doing so ➔
TECHNICAL INTEROPERABILITY Technical interoperability affects user experience
ADOPTING AND PROPOSING STANDARDS: AN EXCERPT National ontologies RFC7807, RFC3339, Schema OpenAPI, IETF and shared repos ISO4217, BCP47, .. OpenAPI, Providers, Guidelines, REST HTTP, OpenAPI 3 Design Vendors Guidelines provided a IETF, Vendors basis for IETF RateLimit Headers, Reliability contributions HTTP Guidelines provided a JWT, Digest, HTTP IETF, W3C basis for IETF Signatures Security contributions National Industry Standards Communities & Vendors We joined the underlined spec/workgroups
TEMPLATE SCHEDA 3 Piattaforma abilitatrice all’accesso a servizi pubblici e privati, fisici e digitali STATO Piattaforma abilitatrice all’accesso a servizi pubblici e privati, fisici e digitali Semplificazione nelle procedure di identificazione in area Schengen e nei CITTADINI paesi con accordi bilaterali ai gate
ICONE VARIE
Recommend
More recommend
