That sounds even better, and another reason to approve 1.2 and move on.
Rob
Original Message-----
From: Rex Brooks [mailto:rexb@starbourne.com]
Sent: Monday, February 15, 2010 4:25 PM
To: Rob Torchon
Cc: 'Ron Lake'; 'David RR Webber (XML)'; 'Gary Timm'; emergency@lists.oasis-open.org; 'Oien,Chuck'; 'Sanzero,George'; 'Ammerlahn,Heidi'; 'Lee Tincher'; 'David E. Ellis'
Subject: Re: [emergency] SBE Viewpoint
IN a nutshell, Rob,
This is what the Reference Information Model SC is tasked with, and
we're hip deep in the ValueListURN at the moment. However that is
directly applicable to EDXL-DE 2.0 which we decided to pursue in the
face-to-face Infrastructure SC meeting last Monday, so it is relevant.
However, I think the EDXL-DE 2.0 work does, for most intents and
purposes, encapsulate most of this issue.
However, it will also be necessary, in my opinion, to accommodate a
non-DE, standalone CAP in addition to a DE-distributed non-standalone
CAP in CAP 2.0. How we do that is the question.
Cheers,
Rex
Rob Torchon wrote:
>
> These have been the most interesting email threads we €™ve seen in a
> long time. Discussing security issues is almost as much fun as
> religion or politics.
>
> From the top level this is as much an issue addressing all our
> standards, and therefore cannot be limited to the current CAP
> proposal. The solution, whatever it may be, needs to be applied
> uniformly throughout our work. CAP 1.2 is not the place to make this
> decision.
>
> As such I would propose we make this issue the subject of a separate
> sub-committee and have the results apply to the TC in general the
> same way we approach GIS.
>
> I €™m voting yes to approve.
>
> Rob
>
> 805-551-6232
>
>
>
> *From:* Ron Lake [mailto:rlake@galdosinc.com]
> *Sent:* Monday, February 15, 2010 3:03 PM
> *To:* David RR Webber (XML)
> *Cc:* Gary Timm; emergency@lists.oasis-open.org; Oien,Chuck;
> Sanzero,George; Ammerlahn,Heidi; Lee Tincher; rexb@starbourne.com;
> David E. Ellis
> *Subject:* RE: [emergency] SBE Viewpoint
>
> Hi David:
>
> I don €™t disagree with what you are saying, but I think it is an
> issue for message envelope and envelope handling (my main point) and
> not message content. XML signatures I think would go a long way in
> practical terms of providing identification of the source,
> non-tampering with the contents, and non-repudiation.
>
>
> R
>
> *From:* David RR Webber (XML) [mailto:david@drrw.info]
> *Sent:* February 15, 2010 2:17 PM
> *To:* Ron Lake
> *Cc:* Gary Timm; emergency@lists.oasis-open.org; Oien,Chuck;
> Sanzero,George; Ammerlahn,Heidi; Lee Tincher; rexb@starbourne.com;
> David E. Ellis
> *Subject:* RE: [emergency] SBE Viewpoint
>
> Ron,
>
> I wish that your example with digital signature was so! All this does
> is increase confidence that the probability might be. Nothing digital
> can be absolute.
>
> Dave gives some great scenario insights between single key nuclear
> authorization systems and by comparison a distributed emergency
> alerting system.
>
> How do the people driven systems work today? I think we can learn a
> lot from studying how say an evacuation order from Wash DC gets actioned.
>
> What I'm seeing is that you have a system where multiple channels
> contribute to your confidence that the information you are receiving
> is authentic. People will "pick up the phone" and talk first hand
> particularly. Now compare that to say a campus building alert system.
> Perhaps you would allow that to be automatically triggered without
> more verification. Or a home system that summons an ambulance or law
> enforcement response.
>
> So - what I'm seeing is that you need a supporting system of level of
> authority and increasing confidence compared to the seriousness of the
> action requested.
>
> This should be something you can publish as implementation
> non-normative notes that support the specification.
>
> In this regard again - notice that today on the ebCORE TC - Pim
> published a standalone CPA ID specification garnered from the original
> eXML CPPA - so that you can create these kinds of trust relationships
> - beyond the mechanics of digital signatures and encryption alone.
> Nice thing is this is then standalone - not dependent on transport
> delivery system specifically - but supports the role and context
> needed - that is otherwise missing from the simple message exchange data.
>
> Thanks, DW
>
>
Original Message --------
> Subject: RE: [emergency] SBE Viewpoint
> From: "Ron Lake"