open-standards
open-standards copied to clipboard
co-cddo
Use of the Common Alerting Protocol (CAP) v1.2 as the emergency alert messaging standard in the UK
Create A Challenge
Title
Use of the Common Alerting Protocol (CAP) v1.2 as the emergency alert messaging standard in the UK
Category
- [X] Data
- [X] Document
- [X] Technical
- [ ] Other Suggestions
Challenge Owner
Frazer Rhodes is the challenge owner - he is the Service Owner in the Incident Management & Resilience team in the Environment Agency. The challenge was originally posted by Simon Nebesnuick - a Senior Advisor in the same team.
Short Description
When an emergency occurs, members of the public who are nearby need to be alerted quickly via as many different communications channels as possible. Responder organisations, such as local police forces, the Environment Agency, or the Met Office, currently operate a number of bespoke public warning systems. Therefore it is important to standardise the format of the alert messages so that they can be issued from different systems yet take advantage of any nationally available capabilities that might be available.
The proposed standard, the Common Alerting Protocol (CAP) v1.2, allows a consistent alert message to be disseminated simultaneously over many different warning systems. The standard includes everything required to communicate the urgency, severity, certainty, location and response required for many emergency situations. The standard also allows for support for multiple languages.
User Need
Users in this context may include:
- Incident commanders i.e. Gold Commanders
- Flood warning staff i.e. Environment Agency and Natural Resources Wales flood warning teams
- Recipients i.e. members of the public in an at risk area
- Publishers of alert messages i.e. Google Public Alerts
Inconsistent dissemination of emergency information could cause potentially devastating consequences by causing confusion to people in the affected area. For serious emergencies, messages may need to be pushed out via as many channels as possible, as quickly as possible and the information needs to be consistent in order to provide clear actionable guidance.
Expected Benefits
Targeted and timely alerts that can be delivered through many channels will help to save lives and protect property. A standardised format for messages would deliver the following benefits:
- the wider dissemination of time critical alert messages via a number of different channels
- facilitation of targeted alerting; message receivers could filter information to a user's current location
- the ability to withdraw messages if there was accidental transmission or rescind them once an emergency is over
- triggering of automated systems such as sirens and warning lights as well as direct messaging services
- a clear understanding of the authority that has sent the message
- allows 3rd parties who re-use alert information can commit to development without the concern over the standard changing
Functional Needs
The Common Alerting Protocol (CAP) v1.2 standard supports:
- Integration with existing dissemination systems
- Consumption via third party applications
- Dissemination of emergency information in multiple languages simultaneously
- Identifiers for emergency agencies
- Identifiers for emergency scenarios (flood, fire, terrorism)
- Multiple message types (warnings, test messages, expirations and cancellations, updates and amendments)
- Targeting of messages to specific geographical areas
- Different levels of urgency
- Different levels of certainty
- Level of threat severity
- Different response/action advice and guidance
- A mechanism to handle supplemental information (image files, digital video, text)
- Publishing geospatial information in a machine readable format
This challenge was originally suggested on standards.data.gov.uk but stalled in early 2015.
Considerable work had been undertaken up to that point, and since then there has been additional work. For example, the Flood Warning System, used by the Environment Agency in England and Natural Resources Wales, now supports CAP as a channel. The Environment Agency provides a public feed of CAP feed in ATOM format.
Questions posed during the original submission around linkages to other potential government open standards have also been answered. The CAP 1.2 standard would align with these existing gov open standards:
Thank you for submitting this challenge. It appears that things have moved forward since the original stalled.
As with all proposed open standards an assessment was carried out of CAP 1.2 in the previous emergency alert challenge. This can be read in the archived standards hub page.
The previous assessment makes reference to a patent disclosure. The disclosure refers to the patent affecting CAP v1.1, but not v1.2.
The patent in question (United States Patent Number 6,359,97) has also since expired.
We are seeking confirmation on above from OASIS.
We have had confirmation from OASIS that the patent is both expired and ONLY related to CAP 1.1. We have also confirmed with OASIS that you do NOT need to be a member of OASIS to use the standard and anyone can use it with attribution.
OASIS also confirm that there is NO licensing requirement of any kind to use CAP 1.2.
I believe this answers the remaining issues from the previous assessment. @Lawrence-G can you please advise next steps?
Great, It's good to have that confirmed. Next, we should publish the revised assessment Q&As here and invite comments from the community on the assessment and any other points.
In emergency situations there is a critical need to share information about the emergency. CAP XML 1.2 has been specifically designed to capture that information in a structured way, ensuring there is a common vocabulary around the severity, urgency and certainty of the emergency. The situation is also described in terms of a headline, description and also instructions to stay safe. Using a common standard means different producers and consumers can share information. The protocol also includes several ways to describe the impacted area ranging from specific geo-names to polygons encompassing the area.
It is vital that multiple agencies and response organisations don't create individual "point-to-point" bespoke integrations and hence there is the need for this open standard to be approved.
CAP 1.2 standard assessment
The challenge owner and the Open Standards team have revised the original assessment answers from the previous emergency alert challenge and posted them below.
The 47 question assessment is part of our open standard selection process and is based on a subset of the CAMSS questions.
Formal specification
Q1. Does the formal specification address and facilitate interoperability between public administrations? A.Yes It is a generic format for exchanging emergency alerts and public warnings over various networks. It provides an open, non-proprietary digital message format for all types of alerts and notifications. CAP enables the sharing of alert messages through different communications channels (such as mobile phones and computers) as well as different departments (such as the Environment Agency and the Civil Contingencies Secretariat during a flooding event). It is currently in use in public administrations around the world including the Australian, Canadian and US governments. It is also in use in the private sector.
Q.2. Does the formal specification address and facilitate the development of digital services in government? A. Yes It provides an open, XML-based file format that can be adapted, developed and customised to suit specific user needs. This has been demonstrated in the development of the Australian and Canadian versions of the Common Alert Protocol (CAP), both of which have taken v1.2 of CAP and tailored it to suit their needs. It has also been adopted as a component of the US National Information Exchange Model to facilitate national-level interoperable information sharing and data exchange
Q.3. Are the functional and non-functional requirements for the use and implementation of the formal specification clearly defined? A. Yes The specification is available here: http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf The file format has been implemented successfully by numerous governments and in conjunction with other software as shown here: http://en.wikipedia.org/wiki/ Common_Alerting_Protocol - Feedback from implementers on a UK challenge to adopt a Public Emergency Alert Message Standard indicated that the specification is appropriately detailed.
Q.4. Is the formal specification applicable and extensible for implementations in different domains? A. Yes CAP has been designed to maximise interoperability between systems, it is compatible with legacy and existing systems as well as both internal and external systems.
Q.5. Is the formal specification largely independent from products of single providers (either open source or proprietary)? A. Yes The specification is independent. It has been developed by the OASIS Emergency Management (EM) Technical Committee (TC). Members participating in the EM TC range from approximately 6 global organisations (both large and smaller enterprises), 5 governmental bodies and 14 individuals - developers, academia and independent experts. A list of current members on the TC is available here: https://www.oasis-open.org/committees/membership.php?wg_abbrev=emergency
Q.6. Is the formal specification largely independent from specific platforms? A. Yes It is available and used on Emergency Alert System (EAS), broadcast, internet and cellular platforms.
Q.7. Has the standard been written such that its realisation can be/is demonstrated using more than one technology (e.g. XML and JSON)? A. Yes CAP has been implemented using an XML schema, and using ASN.1. Applications of CAP are varied and have been demonstrated in a wide variety of technologies such as computers and mobile telephones.
Q.8. Has the formal specification been sufficiently developed and in existence for a sufficient period to overcome most of its initial problems? A. Yes The need for CAP was identified in November 2000 by a National Science and Technology Council (NSTC) report on “Effective Disaster Warning”. Formal development of the standard began in 2001 with input from over 120 emergency managers. The CAP v1.0 specification was approved by OASIS in April 2004. The OASIS Technical Committee for CAP was formed in 2003. CAP v1.0 was approved as an OASIS standard in April 2004. Subsequent versions are: CAP v1.1 approved as OASIS standard, in October 2005. Following user feedback from the original CAP v1.0 - CAP v1.2 is a minor update to CAP v1.1 based on US experience developing the American Integrated Public Alert & Warning System (IPAWS) system. CAP v1.2 was approved as an OASIS standard in July, 2010 Corrections to CAP are captured in the Errata documents. The following shows the activities of the TC in maintenance of the standard: - CAP v1.1 Approved Errata 01 was approved by the EM TC in October 2007 as part of the International Telecommunication Union’s (ITU) (the UN’s specialised agency for Information and Communication Technologies) adoption of CAP. http://docs.oasis-open.org/emergency/cap/v1.1/errata/approved/CAP-v1.1-errata.pdf Maintenance activities have shifted to CAP v1.2.
Q.9 Are there existing or planned mechanisms to assess conformity of the implementations of the formal specification (e.g. conformity tests, certifications, plugfests etc.)? A. Yes CAP can be adapted to suit the needs of different countries by adding constraints to the existing version of CAP These versions of CAP may include optional extras or limitations and are called CAP profiles. There is an EM TC subcommittee for CAP (EM CAP Profiles SC) which ensures that proposed CAP profiles conform to the OASIS standard. The US Federal Emergency Management Agency (FEMA) established a Conformity Assessment (CA) Programme in 2010 to assess vendors’ products compliance with CAP for its Integrated Public Alert & Warning System (IPAWS). Google Labs has also published a CAP-validation tool wherein users can input their schema and check it against existing standards. https://cap-validator.appspot.com Plugfests have been a mechanism for conformance testing for CAP between application vendors in the past (such as at Sahana Software). The OASIS EM CAP Profiles SC: https://www.oasis-open.org/committees/tc_home.php?wstions and comments and also copiedg_abbrev=emergency-cap-profiles
Q.10 Has the formal specification sufficient detail, consistency and completeness for the use and development of products? A. Yes Demonstrated by the wider implementation across many emergency alert systems internationally and by the length of time and money invested in its development. See: http://en.wikipedia.org/wiki/Common_Alerting_Protocol Implementation of the formal specification
Q.11 Does the formal specification provide available implementation guidelines and documentation for the implementation of products? A. Yes The specification includes implementation guidelines for the file format. The EM TC mailing list is available for additional clarification. https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency #feedback
Q.12 Does the formal specification provide a reference (or open source) implementation? A.No No reference implementation, however, the formal specification provides schema and examples for implementation of CAP in XML and ASN.1 http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.html
Q.13 Does the formal specification address backward compatibility with previous versions? A. Yes Backward compatibility with previous versions of CAP is part of the design of the specification. References to previous versions of CAP are contained throughout the standard.
Q.14 Have the underlying technologies for implementing the formal specification been proven, stable and clearly defined?** A. Yes CAP is built around an XML schema which is one of the most common and reliable coding formats available. It has been in existence since 1996 with the last revision in 2008. With ITU-T adoption of CAP in 2007, ITU-T recommended (ITU-T Rec. X.691) that there should be an ASN.1 translation for the CAP XML. ASN.1 is a joint standard of the International Organisation for Standardisation (ISO), the International Electrotechnical Commission (IEC) and the ITU and was originally defined in 1984. The latest available version is from 2008 and is backward compatible with the 199 version. Underlying technologies in OASIS CAP v1.2, which includes WGS 84, are listed in the specification in the section ‘normative references’. http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf
Openness
Q.15 Is information on the terms and policies for the establishment and operation of the standardisation organisation publicly available? A. Yes OASIS: The information is available at: https://www.oasis-open.org/policies-guidelines and https://www-oasis-open.org/committees/tc_home.php?wg_abbrev=emergency
Q.16 Is participation in the creation process of the formal specification open to all relevant stakeholders (e.g. organisations, companies or individuals)? A. Yes OASIS participation is open to all relevant stakeholders – for example, organisations, companies and individuals – through a membership structure (fees associated). Individuals may join through a personal membership and can work in the committees, but are not eligible to vote.
Q.17 Is information on the standardisation process publicly available? A. Yes OASIS documents its standardisation process here: https://www.oasis-open.org/policies-guidelines/tc-process
Q.18 Information on the decision making process for approving formal specifications is publicly available? A. Yes The OASIS Technical Committee (TC) process for approval of formal specifications is available here: https://www.oasis-open.org/policies-guidelines/tc-process#standApprovProcess The OASIS TC’s draft the standard and manage it through the approval process.
Q.19 Are the formal specifications approved in a decision making process which aims at reaching consensus? A. Yes OASIS works on a basis of consensus. Decision making takes place at two levels – within the TC and within OASIS as a whole. OASIS process: https://www.oasis-open.org/policies-guidelines/tc-process
Q.20 Are the formal specifications reviewed using a formal review process with all relevant external stakeholders (e.g. public consultation)? A. Yes OASIS specifications are reviewed using a formal process which includes a mandatory public review of 60 days. https://www.oasis-open.org/policies-guidelines/tc-process#standApprovProcess
Q.21 Can relevant stakeholders formally appeal or raise objections to the development and approval of formal specifications? A. Yes OASIS: Objections can be raised throughout the development and approval process through various mailing lists. OASIS also has a formal appeals process to raise any objections to the process itself. https://www.oasis-open.org/policies-guidelines/tc-process#appeals If a stakeholder disagrees on technical matters they can express their concern with the Technical Committee. Appeals processes are for procedural issues.
Q.22 Relevant documentation of the development and approval process of formal specifications is publicly available (e.g. preliminary results, committee meeting notes)? A. Yes Drafts are published publicly by the EM Technical Committee. The formal specifications can also be found here. https://www.oasis-open.org/committees/tc_home.php?wg_abbrev=emergency Discussions take place online in archived mailing lists, where minutes of the meetings are also available. https://lists.oasis-open.org/archives/emergency/
Access to the formal specification
Q.23 Is the documentation of the formal specification publicly available for implementation and use at zero or low cost? A. Yes OASIS Standard CAP v1.2 and earlier can be downloaded at no cost from http://www.oasis-open.org/standards
Q.24 Is the documentation of the IPR for formal specifications publicly available (is there a clear and complete set of licence terms)? A. Yes OASIS IPR policy https://www.oasis-open.org/policies-guidelines/ipr
Q.25 Is the formal specification licensed on a royalty-free basis? A. Yes The OASIS CAP Standard is licensed on a royalty-free basis with Limited Terms https://www.oasis-open.org/policies-guidelines/ipr All members of the TC agree to follow the intellectual property rules of the Technical Committee.
Versatility/flexibility of the proposed standard
Q.26 Has the formal specification been used for different implementations by different vendors/suppliers? A. Yes CAP v1.1 &1.2: Examples are FEMA IPAWS, Comlabs inc, MyStateUSA, IEM, USGS, Google Public Alerts, Canadian National Public Alerting System (NPAS), CAP-AU-STD, ITU-T, EU Joint Research Centre (JRC), Meteoalarm and more: Sources: http://en.wikipedia.org/wiki/Common_Alerting_Protocol
Q.27 Has the formal specification been used in different industries, business sectors or functions? A. Yes CAP has been adopted extensively throughout the emergency management sector, including all major providers of meteorological forecast and warning systems. The specification has been used by: 1. software developers for implementation e.g. Google, Monroe Electronics, 2. End users of applications which implement the specification.
Q.28 Has interoperability been demonstrated across different implementations by different vendors/suppliers? A. Yes Interoperability is one of the key requirements of the CAP design philosophy due to the number of different systems required for a successful alerting and warning system. An Interoperability demo during an XML conference in 2004 highlighted what was working well with CAP 1.0. https://www.oasis-open.org/news/pr/oasis-interoperability-demos-showcase-cap-ebxml-ws-reliability-ws-caf-and-wsrp-at-xml-2004
End user effect of the formal specification
Q.29 Do the products that implement the formal specification have a significant market share of adoption? A. Yes The majority of governments and organisations with a need for public alert or emergency messages use CAP.
Q.30 Do the products that implement the formal specification target a broad spectrum of end-uses? A. Yes As CAP is used for public alert and emergency messages, the end user can vary widely. From alerting the public in a no notice incident at a COMAH site, or rising tide incidents like flooding to dispelling false alerts. CAP is also used in the missing child AMBER alert system (part of the wider IPAWS system in the USA).
Q.31 Has the formal specification a strong support from different interest groups? A. Yes It has seen widespread global adoption with notable examples being the US, Australian and Canadian governments all of whom have adopted CAP in their own public alerting systems. CAP has also been officially adopted by ITU-T as recommendation x.1303. The OASIS EM Technical Committee also has representation from public administration, global technology corporations, independent experts and academics. CAP is standard in EENA spec for the compulsory warning systems in EU countries: https://eena.org/knowledge-hub/documents/public-warning-systems-2019-update/
Q.32 Is there evidence that the adoption of the formal specification supports improving efficiency and effectiveness of organisational process? A. Yes This specification has demonstrated interoperability across several communications channels and will enable interoperable exchange of emergency alerts across government department and public boundaries for use on different channels and in different systems. Following adoption of CAP, operational efficiency will be improved. An example of this would be the current need to translate the formatting of the bespoke EA FWD’s messages for compatibility with other communications systems. By providing one common standard, similar issues will no longer occur. A key benefit of CAP is the ability to activate multiple alerting or communications systems with the sending of a single message.
Q.33 Is there evidence that the adoption of the formal specification makes it easier to migrate between different solutions from different providers? A. Yes Many products are compatible with CAP so migration between them is reported as being much simpler than migrating between different formats. Comments on the UK challenge for a PEAM standard supported this. CAP is an open standard based on XML making migration easier than from closed, binary formats. The CAP v1.2 rollout in 2010 also saw the integration of CAP within the wider Emergency Data Exchange Language (EDXL).
Q.34 Is there evidence that the adoption of the formal specification positively impacts the environment? A. Yes Not proven though as we have found no specific research. Depending on what system is being replaced the efficient XML of CAP will have a benefit for instance, in power consumption and carbon dioxide emissions for servers and cooling.
Q.35 Is there evidence that the adoption of the formal specification positively impacts financial costs? A. Yes CAP is an open source standard meaning that the standard itself incurs zero cost to users and licensing fees are significantly reduced. This meets the UK Government requirement that users must not have costs imposed upon them, or be digitally excluded by the IT choices which the government makes. For government, an open standard facilitates choice of vendors and can help drive down cost. Total cost of ownership (including exit costs) must be considered by government organisations.
Q.36 Is there evidence that the adoption of the formal specification positively impacts security? A. Yes CAP offers standards on how to encrypt sensitive data, including Web Services Security (WSS). The standard includes mechanisms to sign messages to enable verification of authenticity The standard includes mechanisms to allow messages to be withdrawn.
Q.37 Is there evidence that the adoption of the formal specification can be implemented alongside enterprise security technologies? A. Yes We are not aware of any conflict with enterprise security technologies. CAP can be used alongside enterprise security technologies such as antivirus solutions.
Q.38 Is there evidence that the adoption of the formal specification positively impacts privacy? A. No None that is known.
Q.39 Is the formal specification largely compatible with related (not alternative) formal specifications in the same area of application? A. Yes Compatible with all technologies on which it is based and components that are used, such as WGS 84, HTML, ASN.1 and XML. See section on ‘normative references’ for components used. http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2-os.pdf
Q.40 Is there evidence that the adoption of the formal specification positively impacts accessibility and inclusion? A. Yes CAP supports inclusion as it is implemented in a wide range of free tools, ensuring that there is no financial barrier to accessing and working with government information. CAP also promotes accessibility by delivering messages through a myriad of channels such as via SMS or voice messages. This enables all users to be able to receive a CAP message. Accessibility relating to messages is mainly achieved through a combination of appropriate formatting by the author of the message and the applications used rather than the specification of the communications channels Maintenance of the formal specification
Q.41 Does the formal specification have a defined maintenance organisation? A. Yes Published versions of CAP are maintained by OASIS The EM TC takes the overall lead at OASIS with a specific CAP subcommittee also providing oversight and maintenance.
Q.42 Does the maintenance organisation for the formal specification have sufficient finances and resources to be sure of freedom from short- to medium-term threats? A. Yes The organisation has a steady funding stream. CAP is funded through membership fees to OASIS. Work in the technical committees (TCs) is carried out by the members of the committees funded by their organisations or on a voluntary basis. The size and diversity of the members of the TC is a healthy indication that sufficient resources are available.
Q.43 Does the maintenance organisation have a public statement on intention to transfer responsibility for maintenance of the formal specification if the organisation were no longer able to continue? A. No No public statement found after extensive research. It is assumed that none exists. In lieu of a public statement, this standards body has been in existence since 1993. For full details see : https://www.oasis-open.org/org If a TC is closed, there is a policy for maintenance which allows the specification to be continued by a different TC https://www.oasis-open.org/policies-guidelines/tc-process#maintenanceActivity Interestingly the Canadian Federal/Provincial/Territorial (F/P/T) Senior Officials Responsible for Emergency Management (SOREM) oversaw the development of a Change Management Process (CMP) by the Canadian Emergency Management Communications Specifications (CEMCS) Specification Committee (SC) which was published and distributed in July 2013. The CMP identifies the need for governance and maintenance of the CAP-CP profile amongst others. The CMP would be used to manage and maintain specifications of national importance.
Q.44 Does the formal specification have a defined maintenance and support process? A. Yes Maintenance and support for CAP is carried out by the OASIS CAP SC. The process at OASIS is called Approved Errata. Support is via a public comment list. https://www.oasis-open.org/policies-guidelines/tc-process#errata
Q.45 Does the formal specification have a defined policy for version management? A. Yes Called the OASIS naming directive - more of a naming convention - how the rules are used in the schema files. http://docs.oasis-open.org/specGuidelines/ndr/namingDirectives.html
Related European standards
Q.46 Is this an existing European standard or an identified technical specification in Europe? (Note: CEN, CENELEC or ETSI are the European standards bodies. Technical specifications provided by organisations other than CEN, CENELEC or ETSI can be under consideration to become a European standard or an identified technical specification in Europe for example through the Multi Stakeholder Platform.) A.No CAP v1.2 is an OASIS standard. It has also been adopted as an official recommendation by ITU-T (a UN specialised x.1303). It is also under investigation by the EU Joint Research Centre based in Italy whilst this is not a European standard or an identified technical specification, ETSI and OASIS signed a memorandum of understanding in 2011 regarding CAP. CAP is a standard in the EENA specification for the compulsory warning systems in EU countries: https://eena.org/knowledge-hub/documents/public-warning-systems-2019-update/
Q.47 Does this specification or standard cover an area different from those already identified or currently under consideration as an identified European standard or specification? A.No CAP is an OASIS standard and whilst it is in use by the EU Meteoalarm website it is not currently under consideration.
Recommendation that emergency alerts published in CAPXML are signed so receiving services can authenticate they are from a trusted source. Digital signatures are described in CAP V1.2: http://docs.oasis-open.org/emergency/cap/v1.2/CAP-v1.2.html
Discussed in House of Lords - https://hansard.parliament.uk/lords/2021-04-21/debates/FC1F7E76-DF5E-498A-B0E1-1D93F33F01BC/MobileTelephonesPublicEmergencyAlertSystem
Latest iOS now supports Emergency Alerts https://twitter.com/frazer_HX/status/1386766241432580097
