RE: [soa-rm] Definition of "Service Consumer"

["Vikas Deolaliker" <vikas@sonoasystems.com>]

I think the question should be how many different types of security models
will this RM support? 

Vikas

-----Original Message-----
From: Ken Laskey [mailto:klaskey@mitre.org] 
Sent: Monday, April 11, 2005 9:47 AM
To: Andrew Nash; Frank McCabe; Chiusano Joseph
Cc: soa-rm@lists.oasis-open.org
Subject: RE: [soa-rm] Definition of "Service Consumer"

Agreed.  The important question is how must security be included in the RM.

Ken

At 12:43 PM 4/11/2005, Andrew Nash wrote:
>Ken,
>
>I do not think the details are required - but in most models (let me count
>the ways) security considerations are not considered until the end are then
>shoe horned in at the last moment. Particularly in highly distributed
models
>the need for identification increases dramatically in the business cases I
>am observing where experience has moved well beyond simple configurations.
>
>At some point the black box may look like a black hole :^) - these are
>security or at least identity capabilities that need to be at least
>understood as potential attributes of the black box.
>
>--Andrew
>
>
>-----Original Message-----
>From: Ken Laskey [mailto:klaskey@mitre.org]
>Sent: Monday, April 11, 2005 12:36 PM
>To: Andrew Nash; Frank McCabe; Chiusano Joseph
>Cc: soa-rm@lists.oasis-open.org
>Subject: RE: [soa-rm] Definition of "Service Consumer"
>
>Andrew,
>
>  From a RM perspective, is it necessary to note these distinctions or just
>that a black box exists to deal with the overall capability?
>
>Ken
>
>At 12:09 PM 4/11/2005, Andrew Nash wrote:
>
> >The type of authentication required will certainly vary depending on the
> >type of service and the "domain" in which a service or its requestor
>reside.
> >So different "strengths" or other attributes of a particular
authentication
> >credential are important in different contexts. This will also be
different
> >between a credential that may be used to represent a human participant
and
> >the web service or consumer.
> >
> >Financial institutions are certainly interested in performing correlation
> >among a collection of services to detect phishing or other fraudulent
> >activity. To do this most of the folks I have talked to require an
identity
> >associated with the transaction "originator" to be used in conjunction
with
> >the identity of one or more of the web service, requestor or
>intermediaries.
> >
> >--Andrew
> >
> >
> >-----Original Message-----
> >From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com]
> >Sent: Monday, April 11, 2005 11:58 AM
> >To: Chiusano Joseph
> >Cc: soa-rm@lists.oasis-open.org
> >Subject: Re: [soa-rm] Definition of "Service Consumer"
> >
> >I read this morning in the paper that some banks are guarding against
> >phishing -- by noting that if a customer normally accesses his or her
> >bank account from Sunnyvale, CA, it is pretty unlikely that the
> >customer access it from Chechnya!
> >
> >More prosaically, I was thinking of the kinds of
> >authentication/verification on a given request will vary depending on
> >whether its internal, external, already part of a conversation, etc.
> >
> >Frank
> >
> >On Apr 10, 2005, at 11:00 AM, Chiusano Joseph wrote:
> >
> > > <Quote>
> > > Here is an example of why its important: the appropriate business
logic
> > > to apply to a service request will depend on many factors: the means
by
> > > which the request was delivered,
> > > </Quote>
> > >
> > > Could you please expand on what you mean by "the means by which the
> > > request was delivered,"? I'm thinking MVC violation (using term
> > > "violation" loosely, for point) here, but perhaps not depending on
your
> > > usage of this phrase.
> > >
> > > Joe
> > >
> > > Joseph Chiusano
> > > Booz Allen Hamilton
> > > Visit us online@ http://www.boozallen.com
> > >
> > >
> > >> -----Original Message-----
> > >> From: Frank McCabe [mailto:frank.mccabe@us.fujitsu.com]
> > >> Sent: Thursday, April 07, 2005 12:00 PM
> > >> To: soa-rm@lists.oasis-open.org
> > >> Subject: Re: [soa-rm] Definition of "Service Consumer"
> > >>
> > >> There is a distinction between the software *entity*
> > >> (agent/component/J2EE bean/.../) that interacts with a
> > >> service in order to achieve some goal, and the person or
> > >> persons for whom that interaction is taking place.
> > >>
> > >> The reason that this distinction is important is similar to
> > >> the distinction between a service interface and the service itself:
> > >> accessing your bank account from an ATM or on-line will use
> > >> different interfaces but ultimately all use the same service.
> > >>
> > >> Here is an example of why its important: the appropriate
> > >> business logic to apply to a service request will depend on
> > >> many factors: the means by which the request was delivered,
> > >> the request itself and the person (or
> > >> persons) for whom the request was made. This last aspect is
> > >> completely independent of mode of requesting and is purely
> > >> business/application specific.
> > >>
> > >> Incidentally, the above definition: "an agent that interacts
> > >> with a service in order to achieve a goal" seems to be a
> > >> reasonable definition of a service requester.
> > >>
> > >>
> > >> On Apr 7, 2005, at 7:23 AM, Gregory A. Kohring wrote:
> > >>
> > >>> Matthew,
> > >>>
> > >>> OK, here a fewer other choices which might be deemed more
> > >>> "respectful"...
> > >>>
> > >>> Service Consumer:
> > >>>
> > >>> 1) End-user of a service.
> > >>>
> > >>> 2) An agent which, acting on behalf of its owner, uses a service.
> > >>>
> > >>> 3) An entity which utilizes a service
> > >>>
> > >>> 4) An entity which consumes the product or information produced by a
> > >>>    service.
> > >>>
> > >>>
> > >>> Note all of these definitions depend upon the definition of
> > >> the term
> > >>> "service".  Have we agreed on this already? Perhaps we should start
> > >>> there first...
> > >>>
> > >>>
> > >>> -- Greg
> > >>>
> > >>>
> > >>
>
>--
>
>---------------------------------------------------------------------------
-
>-----
>    /   Ken
>Laskey                                                                \
>   |    MITRE Corporation, M/S H305    phone:  703-883-7934   |
>   |    7515 Colshire Drive                    fax:      703-883-1379   |
>    \   McLean VA 22102-7508                                              /
>
>---------------------------------------------------------------------------
-
>------
>
>
>

--
 
----------------------------------------------------------------------------
-----
   /   Ken 
Laskey                                                                \
  |    MITRE Corporation, M/S H305    phone:  703-883-7934   |
  |    7515 Colshire Drive                    fax:      703-883-1379   |
   \   McLean VA 22102-7508                                              /
 
----------------------------------------------------------------------------
------