Hello together, thanks to everybody for the very fruitful debate! This is exactly the kind of feedback I've anticipated :)
I'll try to summarize the possible further development options below. * Kevin Smith <kevin.sm...@isode.com> [2017-05-10 22:51]: > The thing that I’m very clear should be server-side is the acceptance > logic of the sub. This can be achieved with either solution, and it's very important to me to have a client-side acceptance fallback mechanism, because I'm less optimistic than Daniel, and because it can be done with limited effort. The options as I see them right now are: 1. Fixed Timestamp+HMAC token format (Daniel's proposal) (+) easy token generation and validation, on server or client (+) easy to implement client-side fallback (+) tokens can be generated immediately / while offline (+) secret storage in private pubsub, no new wire protocol (-) some server implementations don't support private pubsub?!? (-) no easy usage-count limit on token (maybe a showstopper?) (-) fixed token scheme (slightly longer token strings, business use case?) 2. Implementation-defined tokens (based on initial PARS) (+) Flexible limits on token usage (counters, time) (-) requires new wire format to create / invalidate tokens (IQ?) (-) requires online connection(*) (-) requires some structured token storage on the server (*) A client could pre-fetch tokens or upload locally generated tokens when it comes online, but this will be prone to timing problems and race conditions. Both solutions can be implemented with a client-side fallback if the user's server has no PARS support, though #1 will ensure cross-client compatibility. I think that the client-side implementation effort is comparable for #1 and #2, and for their respective client-side fallback mechanisms (maybe some more for #2, because the client needs to maintain a local list of tokens). Both solutions can provide easy UX for token invalidation/rotation. I really like Daniel's suggestion, and I tend to follow it. However, the two potential blockers for going this route are: - no XEP 223 support in a widely-used XMPP server implementation - no usage-count limit for tokens (I'd love to hear feedback from others on how problematic this might be) Sam, could you imagine elaborating a bit more of your potential business use case and how you see it conflict with HMAC-tokens? Thanks everybody, 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: standards-unsubscr...@xmpp.org _______________________________________________
