[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [soa-rm] Security (Re: [soa-rm] Definition of "Service Consumer")
I'd prefer to stick to the highest level primitive: "Security constraints". I really don't think we need to get down into all of the functional areas of information security in the RM. -matt Anders W. Tell wrote: > Ken Laskey wrote: > >> 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? > > > IMO This functional level is most likelly the right one, to include > "primitive" categories such as authentication. However the levels of > granularity need to be discussed since all above mentioned concepts > are categories of functions. A more detailed level includes functions > such as: > > *addAuthentication of sender/requestor > *addAuthentication of intended addresse > * verifyAuthentication of sender * etc. > > The enactment of these more detailed functions could be delegated to > another service, an authentication service provider. > > > /anders > > > > > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]