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]