OASIS Open Mailing List Archives  ·  All Lists  ·  emergency-sc  ·  2007-07

emergency-sc — archive

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]

CAP - INSTEDD - IDtrust


Patrick: The identity issue you raise is an important one. Who/what organization(s) is allowed to send out what kind of alert for what geographic area? Who/what organizations are allowed to receive what kinds of alerts for what geographic areas? And then how do we know that you really sent this message? But these issues apply much more broadly than CAP. They apply to all the inter-organizational emergency messaging we have been working on. Indeed, setting up an identity control system for single uses, such as CAP, would likely be creating a stove pipe. We hope that all emergency messages will use the OASIS EDXL Distribution Element standard and then payloads such as CAP, HAVE and the others coming from Elysa's committee. The DE was specifically designed to carry and be governed by the information contained in external directories and rule books (e.g. agency name, incident type, area of incident). But for any of those messages to be processed properly in a safety eco-system of thousands and thousands of organizations, there needs to be a service(s) of identity management and access control (IM/AC) -- independent of specific proprietary applications. We and others call this a "core service", because ideally these would be shared by all emergency response organizations and related groups, whatever application they were using, and web service access to them would be standardized. This is quite different than what is growing up now where each grouping (domain, city, profession, warning project, etc) creates its own directory and own rule book internalized to its system or application -- thus preventing communication across systems. Standardized core services are both critical to interoperability, and threatening to those who want to control by architecture ("everyone has to use "my" message router because that's where the security rules are") as opposed to by policy (implemented in the IM/AC core service which services multiple routers and systems). The reality of emergency communications today is that there is no single organization that will ever be "in charge", so we need to agree on federated systems that reside outside the control of any one "owner". We, NCOIC, the Red Cross, NENA and others have been working hard on defining requirements for core services, and the specific technical designs for first instantiations of two of them. We hope in the future that the results of this work can become the basis for standards. David K. Aylward, Director COMCARE - Emergency Response Alliance 1701 K Street NW Fourth Floor Washington, DC 20006 Telephone: 202.429.0574 ext. 201 202.255.3215 (mobile) 202.296.2962 (fax) [email protected] This communication is intended for the use of the recipient to which it is addressed, and may contain confidential, personal and/or privileged information. Please contact us immediately if you are not the intended recipient of this communication, and do not copy, distribute, or take action relying on it. Any communication received in error, or subsequent reply, should be deleted or destroyed.

[Date Prev]  |  [Thread Prev]  |  [Thread Next]  |  [Date Next]   —  [Date Index]  |  [Thread Index]  |  [Month Index]  |  [List Home]