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

["Monica J. Martin" <Monica.Martin@Sun.COM>]

>Chiusano: 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/
>
mm1: We may have multiple types/levels of requirements here:

    * Transport security: Agree with Joe that SAML, WSS, + provide
      controls at the messaging level.
    * Discovery (if a registry used): Process artifacts may be stored
      and discoverable; ebXML Reg/Rep for example is planned (soon) to
      use SAML and provides access controls.
    * Process artifacts (in addition to above):  Some process artifacts
      could be 'packaged' and made available to partners, customers,
      communities, etc.  I would envision that messaging level security
      could handle this. However, I also refer back to my original
      comments about how the process 'provides guidance' about the
      underlying infrastructure based on the business requirements (see:
      http://www.oasis-open.org/archives/egov/200410/msg00009.html).
      There are then two facets (at a minimum): 1) making the artifacts
      available for review and use and 2) inferring business
      requirements on their use.
    * Process execution: Environment may provide the security. That's
      not to say that the executing or processes being monitored may not
      require some level of security. I'll think more about that and
      would encourage any comments.

One final (for this round) comment, in this world of loose-coupling, 
allowing the process to be independent of the underlying infrastructure 
provides quite a bit of flexibility. That's not to say the use of the 
process will unconstrained and, as noted, may place conditions on 
execution.  The process itself may evidence QoS properties related to 
auditability, persistence, etc.  Thanks.