RE: [egov] Missing Securty: Update Working Draft for Workflow Standards

["Chiusano Joseph" <chiusano_joseph@bah.com>]

Anders, thanks for this document. I've glanced over it, and I believe
that it's highly possible that the issues raised in this document can be
satisfied not only by SAML (as mentioned earlier), but possibly by a
combination of OASIS Web Services Security (the now "official" full name
of WS-Security, aka "WSS") and W3C XKMS (XML Key Management
Specification), whose version 2.0[1] is currently a Candidate
Recommendation as of April 2004. That is, XKMS would be employed to
manage (distribute and register) the PKI certificates that are
referenced/placed within WSS headers. 

I know that there was discussion within the XKMS committee sometime in
2003 regarding a white paper to this end, but as of late 2003 I was told
that there had been no movement on it past discussion. You may want to
present your document to the XKMS committee for their feedback.

[1] http://www.w3.org/TR/xkms2/

Kind Regards,
Joe Chiusano
Booz Allen Hamilton
Strategy and Technology Consultants to the World
 

> -----Original Message-----
> From: Anders Rundgren [mailto:anders.rundgren@telia.com] 
> Sent: Tuesday, October 05, 2004 9:23 AM
> To: Monica J. Martin
> Cc: OASIS eGov list
> Subject: Re: [egov] Missing Securty: Update Working Draft for 
> Workflow Standards
> 
> Thanx Monica,
> Although things like WS-Security exists, it only represents a 
> "format".  When you put it in a real context I claim that we 
> have reached an area which is almost unexplored even research-wise.
> In case of doubts, I urge you and other interested in secure 
> WF applications to read the following short document:
> 
> http://w1.181.telia.com/~u18116613/A.R.AppliedPKI-Lesson-1.pdf
> 
> That is, the e-gov working group also needs a security 
> architecture arm in order to get anywhere.  As you probably 
> can imagine, this would be pioneering work and probably 
> anything but easy.
> But that is the also the sad truth: Nothing screws up 
> interoperability as incompatible security solutions as 
> "flexibility" is the opposite to "security" as the latter 
> _by_design_, is rigid.
> 
> best
> Anders Rundgren
> 
> ----- Original Message -----
> From: "Monica J. Martin" <Monica.Martin@Sun.COM>
> To: "Anders Rundgren" <anders.rundgren@telia.com>
> Cc: "OASIS eGov list" <egov@lists.oasis-open.org>
> Sent: Monday, October 04, 2004 22:22
> Subject: Re: [egov] Missing Securty: Update Working Draft for 
> Workflow Standards
> 
> 
> Anders Rundgren wrote:
> 
> >Monica & List.
> >I have some input regarding security standards which seems 
> to be lacking.
> >
> >You could add WS-Security for example.  However, it is also
> >important to note that many pieces still are entirely absent and are
> >not even known targets for standardization.  The most obvious deficit
> >is the lack of a method for a user to sign a document/transaction in
> >a browser environment.  The only thing I have heard of is XAML that
> >MSFT is putting in Longhorn that unfortunately requires that
> >we all convert to Longhorn.  All e-govs are currently investing in
> >proprietary signature solutions making inter-agency workflow a local
> >matter and definitely not cross-border.
> >
> >For those who are interested in security it may be interesting to
> >know that the PKI pioneered by the US federal agencies is
> >largely incompatible with any kind of workflow system server
> >as a concept that is based on using encryption certificates 
> of employees
> >will disable any intermediary service like a purchasing system
> >from reading outgoing messages.  The governments in northern
> >Europe have therefore defined an entirely different PKI architecture
> >that is compatible with any kind of workflow process.
> >
> >So maybe you should extend your paper with "missing standards"
> >as well?
> >  
> >
> mm1: Anders, not all process specifications have implicit 
> support. For 
> example, ebXML BPSS specifies QoS attributes that provide business 
> guidance that could/likely will impact the technical infrastructure - 
> isTamperDetectable, isAuthenticated, and isConfidential. 
> There are also 
> persistent requirements inherent in the non-repudiation capabilities 
> defined. [1] WS-BPEL recommends use of WS-Security 
> (non-normative). [2] 
> WS-Choreography may consider a QoS proposal before their current last 
> call Dec 2004.  WfMC, in earlier documents, specified use of OMG 
> Security Services (CORBA legacy); however, the references I see are 
> implementation based and in support of conformance requirements.
> 
> You have provided some valuable input. Are you suggesting 
> that we cite 
> impacts to adoption of particular process specifications such as (and 
> the list could be quite large): transactions, security, messaging 
> infrastructure, context, authentication, etc.? Should we cite 
> these as 
> constraints and important conditions to consider? Any 
> thoughts from the 
> eGov team would be greatly appreciated. Thank you.
> 
> [1] Implementation is not specified.
> [2] Appear to be impacted by your references above.
> 
> 
> To unsubscribe from this mailing list (and be removed from 
> the roster of the OASIS TC), go to 
> http://www.oasis-open.org/apps/org/workgroup/egov/members/leav
> e_workgroup.php.
> 
>