[Standards] Proto-XEP: Pre-Authenticated Roster Subscription

Georg Lukas georg at op-co.de
Thu May 11 07:34:29 UTC 2017

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.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?

Thanks everybody,

|| 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...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20170511/2db15e1f/attachment.sig>

More information about the Standards mailing list