RE: [emergency] CAP Visualization (was RE: CAP Developers'Forum...)

[Art Botterell <acb@incident.com>]

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