* Daniel Gultsch <[email protected]> [2017-04-27 18:58]: > As stated in MUC I'm fine with an HMAC.
+1 > I think it might be useful for a client to know if they can rely on the > server to dealwith the authentication or if they will have to do that > themselves. I don't think this matters in any practical way. Your client will either receive a subscription request with a PARS token which it needs to verify, or it will receive a roster push ;) > > I see the UX problems, but I'm not sure if this is a good idea > > security-wise. I'd like to hear other opinions on this. > I guess in theory 'approving entities' can still do a rate limiting on the > tokens? However I would find it very hard to come up with a good N that > both works (me showing my QR code at a party to a bunch of people standing > around me) and also prevents annoying DOS attacks. Yeah, but what do you do if somebody posts your PARS link on twitter, to copy-cat a potential attack scenario from xsf@ ;) > In any case i don't think N should be configurable by the user. I can at least see use cases for N=1 and N=infinity. But yeah, it's making the UX harder. I'd really love to hear more opinions on this trade-off. Georg -- || http://op-co.de ++ GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N ++ || gpg: 0x962FD2DE || o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+ || || Ge0rG: euIRCnet || X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y? || ++ IRCnet OFTC OPN ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
