On 14.02.2016 22:25, Daniel Gultsch wrote:
> Hi,
>
> I said this before but I'll say it again on public record. I like it a
> lot. It's very simple, straight forward and thus easy to implement. Both
> on the server as well as on the client side.
Thanks for the positive feedback. I believe the sam
On 14 February 2016 at 20:29, Florian Schmaus wrote:
> On 13.02.2016 12:31, Jonas Wielicki wrote:
> > On 12.02.2016 11:08, Florian Schmaus wrote:
> >> Here is my suggestion how such a XEP could look like:
> >
> >> http://geekplace.eu/xeps/xep-qsr/xep-qsr.html
> >
> >> As always: This is an early
Hi,
I said this before but I'll say it again on public record. I like it a lot.
It's very simple, straight forward and thus easy to implement. Both on the
server as well as on the client side.
One comment regarding the isr:location attribute. It's not specified
whether this will be a normal conne
On 13.02.2016 12:31, Jonas Wielicki wrote:
> On 12.02.2016 11:08, Florian Schmaus wrote:
>> Here is my suggestion how such a XEP could look like:
>
>> http://geekplace.eu/xeps/xep-qsr/xep-qsr.html
>
>> As always: This is an early draft, the source code can be found at
>> https://github.com/flowd
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 12.02.2016 11:08, Florian Schmaus wrote:
> Here is my suggestion how such a XEP could look like:
>
> http://geekplace.eu/xeps/xep-qsr/xep-qsr.html
>
> As always: This is an early draft, the source code can be found at
> https://github.com/flowd
On 12.02.2016 11:34, Michal Piotrowski wrote:
> Hi Florian,
>
> Your extension looks very convenient. As I understand the token can be
> used only once and only in context of stream resumption. What if the
> stream resumption fails? Should the client authenticate by regular
> SASL method like SCRA
Hi Florian,
Your extension looks very convenient. As I understand the token can be
used only once and only in context of stream resumption. What if the
stream resumption fails? Should the client authenticate by regular
SASL method like SCRAM-SHA-1 or would it be possible to use the token
to authen
On 06.02.2016 12:22, Florian Schmaus wrote:
> On 05.02.2016 20:04, Lance Stout wrote:
>> Integrating this sort of token authentication with XEP-0198 would be the
>> bigger win, because then SASL could be skipped entirely along with the
>> initial stream setup (like how we can use BOSH with pre-bind
Hello Florian,
> On 06 Feb 2016, at 12:22, Florian Schmaus wrote:
>
> Exactly. I always thought a fast reconnect (fr) mechanism based on
> stream management should work something like this:
...
> What do you think? I'm willing to XEPify this, if the approach is
> considered useful.
Yes, I thi
Thanks for all the feedback. It's really valuable. This protoXEP
describes an implementation we already did and wanted to share and get
feedback. I also thought this matches some of the discussions we had
during the XMPP Summit 19.
After reading all responses I agree the solution as described here
On 05.02.2016 20:04, Lance Stout wrote:
> Integrating this sort of token authentication with XEP-0198 would be the
> bigger win, because then SASL could be skipped entirely along with the
> initial stream setup (like how we can use BOSH with pre-binding). The
> stream management ID could easily be
> On 5 feb. 2016, at 20:04, Lance Stout wrote:
>
> 3) This does not really decrease the initial authentication and subsequent
> stream setup time. It is still using the full SASL process, so time wise
> it is exactly the same as PLAIN. It is exactly one round trip faster than
> SCRAM-SHA-1. It d
So, from what I can tell, what this XEP introduces is the ability to fetch
a token after authenticating that can be used for subsequent authentication
attempts, and the goal is to reduce the initial time to log in.
I am not convinced that this particular approach, as presented, is the solution.
> On 5 feb. 2016, at 17:15, XMPP Extensions Editor wrote:
>
> The XMPP Extensions Editor has received a proposal for a new XEP.
>
> Title: Token-based reconnection
>
> Abstract: This specification defines a token-based session authentication
> mechanism similar to OAuth.
>
> URL: http://xmpp
Oops, hit send early. Another point:
> a regular XMPP authentication mechanism like SCRAM-SHA-1 or DIGEST-MD5
DIGEST-MD5 is old, broken, and we're having a hard enough time getting
rid of it as is. While I'm aware that this statement isn't an
endorsement of DIGEST-MD5 (I hope), I feel that we sho
> This specification defines a token-based session authentication mechanism
> similar to OAuth.
The token based reconnect can be used with any token (eg. JWT tokens,
which are valid oauth tokens, are given as an example below), if I'm
understanding the intent behind this spec correctly. The refe
The XMPP Extensions Editor has received a proposal for a new XEP.
Title: Token-based reconnection
Abstract: This specification defines a token-based session authentication
mechanism similar to OAuth.
URL: http://xmpp.org/extensions/inbox/token-reconnection.html
The XMPP Council will decide in
17 matches
Mail list logo
