<Quote>
Is there a difference between a contract requiring security and the RM
including (abstract) mechanisms needed to enforce security? I think so.
</Quote>
I do as well. I would also add the following to Ken's excellent list of
security concepts below (sorry that I don't have time now to provide
definitions - can at a later point if required):
- Identity Management
- Confidentiality
- Message-Level Security (a la OASIS WSS)
Joe
Joseph Chiusano
Booz Allen Hamilton
Visit us online@ http://www.boozallen.com
> -----Original Message-----
> From: Ken Laskey [mailto:]
> Sent: Tuesday, April 12, 2005 7:12 PM
> To: Duane Nickull
> Cc: Francis McCabe; Matthew MacKenzie; Anders W. Tell;
>
> Subject: Re: [soa-rm] Security (Re: [soa-rm] Definition of
> "Service Consumer")
>
> Is there a difference between a contract requiring security
> and the RM including (abstract) mechanisms needed to enforce
> security? I think so. I certainly do not want us to get
> into the details of security policies or implementations but
> we need to consider what are the abstract concepts related to
> security. From past efforts, I can remember four:
> - authentication (the service provider can unambiguously
> identify the service requester)
> - authorization (the service provider can unambiguously
> determine that the service requester has the right to use the service)
> - integrity (the service provider, possibly through the
> communication mechanism, can be unambiguously assured that
> the request has not been modified from what was sent by the
> service requester (except possibly as otherwise authorized))
> - nonrepudiation (neither the service requester nor the
> service provider can later claim they were not part of the request and
> response)
>
> Note, I described this in the context of request/response but
> I believe it can be generalized to other MEPs.
>
> Is this abstract enough to at least consider?
>
> Ken
>
> On Apr 12, 2005, at 1:44 PM, Duane Nickull wrote:
>
> > Would this inference be accurate:
> >
> > A security policy, in addition to other service policies,
> is part of a
> > service contract. A security policy is a declaration of a set of
> > requirements that must be met in order to consume a service. A
> > declaration that indicates no requirements must be met is still
> > conceptually considered a security policy.
> >
> > Duane
> >
> >
> >
> > Francis McCabe wrote:
> >
> >> This is how I see it also. The contract represents the
> syntactic,
> >> semantic and pragmatic constraints on the use of a service. That
> >> covers security, and I hope QoS management, etc.
> >> Frank
> >>
> >> On Apr 12, 2005, at 8:08 AM, Matthew MacKenzie wrote:
> >>
> >>> Security could be fit into the RM indirectly via "Contract" (or a
> >>> less controversial word, such as "Agreement"). You
> talking about
> >>> refusing service tweaked this in my brain...
> >>>
> >>> "Service use agreement may mandate security requirements
> to be met,
> >>> and if they are not, service may be refused."
> >>>
> >>> -matt
> >>>
> >>>
> >>> Anders W. Tell wrote:
> >>>
> >>>> Hi,
> >>>>
> >>>> This is getting interesting so Ill just join in
> >>>>
> >>>> There seem to be good reasons why security or maybe more
> >>>> appropriate security related functions could be part of a
> >>>> (abstract) RM. Functions such as (add,verify)integrity,
> >>>> (add,verify)confidentiality, (add,verify)authentication etc.
> >>>>
> >>>> If one wants to later relate a RM to economical and
> legel aspects
> >>>> such as those found in service level agreements then
> such abstract
> >>>> function seems relevant.
> >>>>
> >>>> The rigth to refuce service access may be a function of
> >>>> authenticationverification of issuer, sender ,indended
> receive,
> >>>> addressee.
> >>>>
> >>>> So Ill think Ken is right that it maybe a good point
> keeping it on
> >>>> the agenda and removed later if deemed to concrete.
> >>>>
> >>>> /Anders
> >>>>
> >>>> Ken Laskey wrote:
> >>>>
> >>>>> Moreover, the question is whether all SOAs SHOULD have security
> >>>>> and whether that needs to be captured in the RM. As noted,
> >>>>> secuirty is often just tacked on and that may not be
> sufficient
> >>>>> for *any* SOA to be successful.
> >>>>>
> >>>>> Ken
> >>>>>
> >>>>> At 02:27 PM 4/11/2005, Duane Nickull wrote:
> >>>>>
> >>>>>> The RM does not support security models. A reference model is
> >>>>>> used to guide the design of architecture that may include
> >>>>>> specific security protocols or models. Our
> requirement must be
> >>>>>> to ensure that nothing we place in the RM makes any specific
> >>>>>> security model a requirement (since not all SOA's
> have security)
> >>>>>> and to ensure that we do not preclude a specific type of
> >>>>>> security model from being used.
> >>>>>> Duane
> >>>>>>
> >>>>>> Vikas Deolaliker wrote:
> >>>>>>
> >>>>>>> I think the question should be how many different types of
> >>>>>>> security models
> >>>>>>> will this RM support?
> >>>>>>> Vikas
> >>>>>>>
> >>>>>>> --
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> --
> >>>>>> ***********
> >>>>>> Senior Standards Strategist - Adobe Systems, Inc. -
> >>>>>> http://www.adobe.com
> >>>>>> Vice Chair - UN/CEFACT Bureau Plenary -
> >>>>>> http://www.unece.org/cefact/
> >>>>>> Adobe Enterprise Developer Resources -
> >>>>>> http://www.adobe.com/enterprise/developer/main.html
> >>>>>> ***********
> >>>>>>
> >>>>>
> >>>>> --
> >>>>>
> ------------------------------------------------------------------
> >>>>> -
> >>>>> -- ------------
> >>>>> / Ken Laskey
>
> >>>>> \
> >>>>> | MITRE Corporation, M/S H305 phone: 703-883-7934 |
> >>>>> | 7515 Colshire Drive fax:
> >>>>> 703-883-1379 |
> >>>>> \ McLean VA 22102-7508
>
> >>>>> /
> >>>>>
> >>>>>
> ------------------------------------------------------------------
> >>>>> -
> >>>>> -- -------------
> >>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>
> >>
> >
> > --
> > ***********
> > Senior Standards Strategist - Adobe Systems, Inc. -
> > http://www.adobe.com Vice Chair - UN/CEFACT Bureau Plenary -
> > http://www.unece.org/cefact/ Adobe Enterprise Developer
> Resources -
> > http://www.adobe.com/enterprise/developer/main.html
> > ***********
> >
> >
>
> --------------------------------------------------------------
> ----------
> ------------------
> Ken Laskey
> MITRE Corporation, M/S H305 phone: 703-883-7934
> 7515 Colshire Drive fax: 703-883-1379
> McLean VA 22102-7508
>
>
>
