Re: issue 8273: proposal for WS-Eventing

Li,

You haven't answered my question. In your opinion, are the ownership 
relations in the current versions of WS-Eventing and WS-Enumeration 
sufficiently described, or are the protocols incomplete?

- gp

On 5/6/2010 1:49 PM, Li, Li (Li) wrote:
>
> Gil,
>
> I should have said:
>
> The ownership relations are entailed by the protocols themselves 
> (otherwise, the protocols would be incomplete).
>
> Thanks,
>
> Li
>
> ------------------------------------------------------------------------
>
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Thursday, May 06, 2010 2:40 PM
> *To:* Li, Li (Li)
> *Cc:* public-ws-resource-access@w3.org; Chou, Wu (Wu)
> *Subject:* Re: issue 8273: proposal for WS-Eventing
>
> Li,
>
> I agree with most of what you say but this sentence intrigues me: "The 
> ownership relations should be entailed by the protocols themselves 
> (otherwise, the protocols are incomplete)." In your opinion, are the 
> ownership relations in the current versions of WS-Eventing and 
> WS-Enumeration sufficiently described, or are the protocols incomplete?
>
> - gp
>
> On 5/4/2010 9:39 AM, Li, Li (Li) wrote:
>
> Gil,
>
> Please see comments inline. Thanks.
>
> <><<>>><<<<<>>>>>>>><<<<<<<<<<<<<
> Li Li, Ph.D.
> Dialogue System Research Group
> Avaya Labs Research
> 233 Mt. Airy Road
> Basking Ridge, NJ 07920
> Voice: 908-696-5141
> Fax: 908-696-5402
> Email: lli5@avaya.com <mailto:lli5@avaya.com>
> ><>><<<>>>>><<<<<<<<>>>>>>>>>>>>>
>
> ------------------------------------------------------------------------
>
> *From:* Gilbert Pilz [mailto:gilbert.pilz@oracle.com]
> *Sent:* Thursday, April 22, 2010 7:21 PM
> *To:* Li, Li (Li)
> *Cc:* public-ws-resource-access@w3.org 
> <mailto:public-ws-resource-access@w3.org>; Chou, Wu (Wu)
> *Subject:* Re: issue 8273: proposal for WS-Eventing
>
> Li,
>
> A couple of comments on your proposed changes.
>
>    1. I would prefer not to use the term 'endpoint' in sentences like
>       "the requester ought to be checked against the endpoint that
>       performed the original Subscribe request". Firstly, what are
>       talking about here are representations of authenticated
>       identity. Although it is a kind of identity, an 'endpoint' (as
>       represented by an EPR) is not a representation of an
>       authenticated identity in the way that, for example, X.509 certs
>       or SAML tokens are. Secondly, when you tell a developer that
>       "the requester ought to be checked against the endpoint that
>       performed the original Subscribe request", they might think that
>       all they need to do is check the ReplyTo of the GetStatus
>       request against the ReplyTo of the original Subscribe request
>       and they are done - which is not what we want to say. If you can
>       think of another, better term for 'authenticated entity' I would
>       welcome any suggestions. In my DCE days we use to just call
>       these things 'principals' (derived from the Kerberos term) and
>       everyone knew what we meant . . .
>
> Wu/Li: Our use of "endpoint" follows from WSDL 1.1 and the rest WS-RA 
> specs. The concept is not tied to WS-A per se, as WS-A is one way to 
> represent an endpoint. For security purpose, other information, such 
> as certificate or username token, can be associated with an endpoint. 
> But "check against the endpoint" covers all these cases as it means to 
> check the security data associated with the endpoint. If you think 
> this is confusing, we can:
>
> Option 1: delete the sentence in bracket, since it does not add any 
> significant information.
>
> Option 2: Change to "the requester ought to be checked against the 
> identity authorization requirements performed in the original 
> Subscribe request."
>
> Option 3: Change it to "the requester ought to be checked against the 
> authenticated identity of the endpoint that performed the original 
> Subscribe request"
>
>    2. W/regards to the notion of "subscription/enumeration ownership",
>       it is very hard to discuss this stuff without that concept
>       creeping in. It's understood that subscriptions and enumerations
>       are instances of context that are shared between the client and
>       service. This is why we needed the state tables. When you are
>       authorizing messages (e.g. Renew, SubscriptionEnd) it is natural
>       to think of yourself and your peer (the thing that you share
>       context with) as co-owners of the shared context. We can
>       describe the authorization decisions without using the word
>       "owner", but I'm not sure if that helps make things any clearer.
>
>     What makes things even harder is that, although we can speak of a
>     "subscription owner/co-owner" we really can't say much about how
>     the owner->subscription relationship is established. For example,
>     the most intuitive way to think of establishing the
>     "subscriber-owner->subscription" relationship is to say "the
>     identity of the thing that sent the Subscribe request is the
>     'subscriber-owner' of the subscription", but this might not
>     necessarily be the case. That's what I attempted (clumsily) to say
>     in the sentence "Note that determinations of subscription
>     ownership are particular to individual deployments."
>
>     Wu/Li: The ownership relations should be entailed by the protocols
>     themselves (otherwise, the protocols are incomplete). And
>     therefore, we don't have to use new concepts to restate them. In
>     addition, we want to stay away from overstating things that may
>     limit potential applications.
>
> - gp
>
> On 4/20/2010 7:41 AM, Li, Li (Li) wrote:
>
> Gil,
>   
> Thanks for the proposal. We agree the general technical content but have
> the following editorial changes to
>   
> 1) avoid introducing new concepts that are already defined in WS-E, such
> as "notification stream", "entity", "source owner" and "sink owner" etc.
> 2) remove some advices that are either well-known or too specific (to be
> specific on threats, but general on solutions).
> 3) Clarify some statements (e.g. per-notification authorization).
> 4) shorten some sentences without changing their meaning.
>   
> The attached word document, which a copy of Ram's version, has our
> change marks.
>   
> Thanks,
>   
> Wu, Li
>