RE: issue 8273: proposal for WS-Eventing

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

________________________________

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