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"
signature.asc
Description: OpenPGP digital signature
