[Standards] MUC Spam and MUC invites

[Alex Mauer]

Dave Cridland wrote:
> Ah, that's a plan. Pawn ticket technologies have been deployed in
> Lemonade's forward without download stuff, so there's some prior art we
> can draw on. Take a look at the URLAUTH RFC, erm, RFC 4467.
> 
> That model would have the room supply the token for the use of the
> invitee, so there's an additional round-trip involved, but it's nicely
> secure.

Is it insecure to have the inviter supply the token instead?  I can't
see any problems, unless the inviter's client doesn't bother to generate
a different token each time or something dumb like that. (and you could
theoretically have the same problem with the server, though I guess it
would be easier to fix)

I think it works out the same , as round-trips go:

my way:
inviter -> muc:     here's the token
muc -> inviter:     OK, got it
inviter -> invitee: invite, here's the token
invitee -> muc:     I'm joining, here's the token.
muc: -> invitee:    OK, you're joined.

your way:
inviter -> muc:     What token should I use?
muc -> invitee:     Here's the token
inviter -> invitee: invite, here's the token
invitee-> muc:      I'm joining, here's the token.
muc -> invitee:     OK, you're joined.

-Alex Mauer "hawke"

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 252 bytes
Desc: OpenPGP digital signature
Url : http://mail.jabber.org/pipermail/standards/attachments/20070905/ddff28cb/attachment.pgp