Alex Mauer wrote: > 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.
One benefit of Dave's way is that it meshes with the original reason for invites to go through the room (e.g., permissions check to determine that the invitor is allowed to send invitations, room adds invitee to the member list if the room is members-only). So I'd prefer Dave's approach. But I haven't had a chance to look at RFC 4467 yet... Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
