user-id should have been common to all waveops

[GoogleCodeExporter]

We had decided not to repurpose xmpp's from/to because they are used for 
message routing.
This means we need user-id as a common attribute on waveops to know who is 
making the change.

Original issue reported on code.google.com by daniel.berlin on 4 Jun 2009 at 7:05

[GoogleCodeExporter]

If your not using the JID (what goes into the from/to) as the base for who is
modifying a wave, then where will the wave userid <-> JID mapping happen?

Will anyone signing up to a wave server have to now also pick a userid?  Or will
there be a disconnect so that if I receive a wave change via a federated server 
I now
have no idea who is doing the sending or if they are a member of the sending 
server's
roster.

Wouldn't this just become the primary spam vector synonymous to smtp not 
requiring a
strict mapping of the from sender?

Original comment by bear42 on 4 Jun 2009 at 10:18

[GoogleCodeExporter]

Why create new identifiers when the standard JID will serve the functions you 
need? Yes, JIDs are used for stanza 
routing, but they are also used as, for example, the "key" to information 
storage in XMPP rosters. I'd encourage 
you to rethink this decision. --stpeter

Original comment by stpe...@gmail.com on 5 Jun 2009 at 3:57

[GoogleCodeExporter]

I think you both misunderstand.  I have never said the wave user-id will not be 
a JID, only that we can't use the 
from/to on an iq request to double as the user-id for wave operations enclosed 
in that request.

Original comment by daniel.berlin on 5 Jun 2009 at 5:28

[GoogleCodeExporter]

daniel.berlin, you still didn't explain why not. In most of the XMPP Extension
protocols we have defined up till now, we use the bare JID derived from the 
sender's
JID (the 'from' attribute on the stanza) for identification, authentication and
authorization. They are definitely not just for routing.

In some protocols, though, we sometimes pass an additional JID to make clear 
which
exact resource we want to perform an operation on. An example of this is the
publish-subscribe protocol (XEP-0060), where we have a 'jid' attribute that is 
sent
along with a subscription request. This points out which resource the 
notifications
should be sent to. Usually, the bare JID of that attribute and the bare JID of 
the
sender are checked to be identical by the publish-subscribe service. Privileged 
users
(like an admin), however, could also set up subscriptions this way.

The downside of passing a superfluous JID is that you need to do that check if 
the
two JIDs have a common base JID, or worse, you have to check that you can 
actually
perform the requested action on the embedded JID as that particular sender.

Original comment by ralphm.net on 5 Jun 2009 at 6:52

[GoogleCodeExporter]

Okay, i thought it was implied, but to be explicit: Because the wave
delta operation may have come from a wildly different place/user than
the servers transmitting it to each other.

IE the servers may be transmitting a delta request from server a to
server b that contains an operation done by user c, where user c
shares nothing in common with server a or server b.

As such, the user-id on the wave operation is necessarily different
from who the iq request is from/to, and can't be taken from there (the
verification protocol isn't going to allow you to spoof the from to
make it appear like it went from that user c to server b in the above
example).
This happens, for example, when i transmit historical deltas.
The iq result will have a to containing a JID for the server
requesting the deltas, and a from containing a JID of the server
sending them back.
However, the actual wave operations themselves have their own user-ids of
who sent the wave operation originally, which could be users of neither
server.  And there could be a lot of different users contributing in
the historical delta info.

As such, the wave-operations need their own user-ids (or at least,
deltas do, I have requested clarification internally whether a delta
group ever contains wave-ops from different user-ids). These user-ids
can certainly be JID's themselves.

Original comment by daniel.berlin on 5 Jun 2009 at 7:08

[GoogleCodeExporter]

We took out the to and from attributes in the iq stanzas in the June 8 revision 
of
the protocol spec. This is based on the assumption that the stanzas travel on a
direct connection between two authenticated domains, i.e., the XMPP stream setup
identifies which domain is on each end.

The author attribute in the delta element and the access-address elements in the
submit-request element specify the wave addresses of the parties who contribute 
the
each delta. This will be described better in the upcoming access control white 
paper.

Original comment by so...@google.com on 11 Jun 2009 at 3:12

• Changed state: Fixed