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

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-assembly message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-assembly] Action re. SCA Assembly Issue 233


serverAuthentication
clientAuthentication

Can these intents be specified without talking about who does the authentication?  In an earlier thread Jim and Sanjay tripped over the question of the transaction boundary (producer -> consumer, or merely producer -> "channel" or "SCA runtime").  Authentication is the same.  Your text, Sanjay, says:

These intents ensure that the consumer is allowed to receive events from a producer and the producer is allowed to send events to a consumer.  They seem useful for eventing. Not sure where these intents should be applied.
which is actually about authorization.  Authentication is a lesser requirement.  I understand producer identification - the ability to know who produced an event, but I'm not sure I understand consumer identification, or to whom it goes.
It may make sense in a peer-peer mechanism, but far less so if you're using a hub-and-spoke like JMS.  In the JMS case, it's far more common for producer and consumer to identify themselves to the JMS server, and not to each other.  The consumer may or may not get information as to who the producer is (for JMS, it does, but I'm only using JMS as an example), but the producer will almost certainly not get any information as to who consumed its messages.

mutualAuthentication has similar issues.

confidentiality - not sure if the question is in scope, but there's a big difference as to who decides who's authorized, and how that happens.

not sure how "transport" or "message/event" qualification would work.

authorization - you say this doesn't apply to eventing.  If not, how would confidentiality (" The contents of the event are accessible only to those authorized to have access") work?  You seemed to imply authorization in your comments on authentication.

Danny

On 10/26/2011 7:38 AM, ashok malhotra wrote:
See the attached doc as a first cut at which SCA Policy intents apply to eventing.
Needs discussion.


---------------------------------------------------------------------
To unsubscribe, e-mail: sca-assembly-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: sca-assembly-help@lists.oasis-open.org

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]