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

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