RE: [soa-rm] Security

["Metz Rebekah" <metz_rebekah@bah.com>]

What about considering a division between the functional and the
operational aspects of interaction with a service?

I tend to use contract to represent the functional aspects of
interaction (which includes syntax and semantics) whereas I tend to use
policy to represent operational aspect of interaction (which would
include security, QoS, etc).  

Rephrasing Matt's message, we'd end up with:
"Service policy may mandate security requirements to be met, and if they
are not, interaction may be refused."

Rebekah


Rebekah Metz
Associate
Booz Allen Hamilton
Voice:  (703) 377-1471
Fax:     (703) 902-3457


> -----Original Message-----
> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
> Sent: Tuesday, April 12, 2005 1:22 PM
> To: Matthew MacKenzie
> Cc: Ken Laskey; Anders W. Tell; soa-rm@lists.oasis-open.org
> Subject: Re: [soa-rm] Security (Re: [soa-rm] Definition of "Service
> Consumer")
> 
> 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
> >>>    /
> >>>
> >>>
---------------------------------------------------------------------
> >>> -------------
> >>>
> >>>
> >>>
> >>
> >>
> >