MHonArc v2.5.0b2 -->
emergency message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: RE: [emergency] CAP Visualization (was RE: CAP Developers'Forum...)
At 6:45 PM -0400 5/19/04, Speede, Kwasi wrote:
>Yes, we "fell back" on processing against system-specific <eventCode> values
>in the broker. <Event> was not appropriate for our purposes because multiple
>instances cannot be defined for a single message scenario.
Yes, I'm afraid it was a mistake to make <category> optional... as
arbitrary as our interim taxonomy was, I haven't come across anything
better. And perhaps it should be made multiple, too, in CAP 1.1.
>I am curious about the different approaches that are evolving or being
>proposed for determining who are the authorized CAP message originators
>across various implementation communities and how developers are intending
>to authenticate their messages when processing CAP.
This is a huge issue that cuts across a wide range of applications.
First off, you're right to distinguish between the policy question of
authorization and the technical problem of authentication.
Especially at the local level, policies about authorization are
liable to vary, which could make inter-system policy complicated.
But as with spam, rules don't really matter until we can authenticate
individual messages.
The simple approach to that, and the one most widely implemented so
far, is to establish access control at the individual server level,
using something like passwords secured by SSL. The good thing about
that is that it's easy to implement. The bad thing is that it's a
single-hop model, with no inherent way of ensuring the "end-to-end"
integrity or authenticity of a message that traverses more than one
system.
An attractive alternative is to use digital signatures, which can
verify both integrity and authenticity no matter how a message got
routed... but that requires a public key infrastructure (certificate
authorities, certificate revocation lists, etc.) While the standards
are there, nobody's stepped up to the task of coordinating it for the
80,000 or so local safety agencies in this country. (The OASIS PKI
TC has a project right now to try to identify and address the
roadblocks to uptake of the existing standards and technologies.)
And, of course, there are hybrid approaches possible. For the
California EDIS rebuild we're using server-based authorization for
the individual agencies, but we may apply a global digital signature
to the content at the state level so forwarded messages can be
authenticated at least as far back as the state OES gateway.
- Art
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]