OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

soa-rm message

[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.


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]