[Standards] Proto-XEP: Pre-Authenticated Roster Subscription
georg at op-co.de
Thu May 11 07:34:29 UTC 2017
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.smith at 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
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?
|| 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 ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the Standards