[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [egov] Missing Securty: Update Working Draft for Workflow Standards
>The work of the XDS initiative is also important here - and the use of >ebXML Registry as a >certificate store for partner participation and exchange certification >tied into their CPA entries. David, Note that at least my paper only put the very basic question on how *true* end-2-end encryption can work with typical business processes. http://w1.181.telia.com/~u18116613/A.R.AppliedPKI-Lesson-1.pdf This question has not been answered but has been described as an operational/contractual issue. This is incorrect, this is an entirely technical issue, either it works or it does not. I claim the latter. I really hope that the partner information handled by XDS does not mean individual Order Receivers as is (effectively) required by the Federal PKI model. Because if you send an order using e-2-e encryption to a sick Order Receiver your order will not be processed. How incredibly silly! Anders I'm working on an implementation right now that uses this approach with Registry. Obviously you can also federate into registry as well from other registries and then authenticate via the remote CPA profile(s). We are presenting tomorrow at the OASIS event in Brussels on part of this with XDS - and at XML 2004 the plan is to demonstrate part of this as well. There is still details to be worked - but the basic Registry / CPA / Certificate management is a simple model at least! DW =============================================== Anders Rundgren wrote: >Joe, >Thanx for your quick response. >I'm indeed familiar with SAML and did actually contribute to >the POST profile although I'm only listed in the references. > >However, if you have an enterprise PKI a la the Federal PKI >your only choice is to run all PKI-related activities from the >clients' own desktop computers because that is the only PKI >you got. If the latter is not true, we are not talking about >the federal PKI anymore. This client-centric world though >eliminates SAML, thin clients, information consolidation, >and essentially everything that we took for granted before >confronted with the federal PKI. As I have mentioned, >northern Europe have selected an entirely different approach >which they though not even themselves have yet fully understood >the power of! > >Anders R > >----- Original Message ----- >From: "Chiusano Joseph" <chiusano_joseph@bah.com> >To: "Anders Rundgren" <anders.rundgren@telia.com>; "Monica J. Martin" <Monica.Martin@Sun.COM> >Cc: "OASIS eGov list" <egov@lists.oasis-open.org> >Sent: Tuesday, October 05, 2004 15:45 >Subject: RE: [egov] Missing Securty: Update Working Draft for Workflow Standards > > >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. >> >> >> >> > >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/leave_workgroup.php. > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]