Follow

We've submitted a new ProtoXEP to the and would love your feedback before it gets accepted. The TL;DR is that it lets the server authorize a third party entity to generate invites without the entity needing to communicate with the server. github.com/xsf/xeps/pull/1068

We've also created a little example tool that uses it to allow users of a Mastodon instance to self-provision an account on a chat server using the new token-based registration flow (this is just an example, don't use it in prod): github.com/mellium/fediverse-x

@mellium

I'm on mobile so have not read your XML and I'm only very cursorily acquainted with #XEP0401 but I was under the impression that the invitation token was meant to be (to the server at least) an opaque string?

different private key than the one used by user invites so that I can see how many users from the conference registered.

I'm really not sure that #XMPP should facilitate profiling at the protocol level. In any event, this is a massive #privacy red flag and ought to be properly covered in the security section.

The whole crypto part looks iffy to me. Why does it not leverage existing crypto the user is already using? @mellium - 2/2

@0 the token isn't opaque to the server, just to the client and this doesn't change. The server could already do all of this if it wanted (eg. import tokens issued using a different key at a conference). I don't understand what you mean about the crypto; it does use existing crypto. Having a shared secret is fine; this is just a simple signed token and a classic use of symmetric signing (think JWTs on the web which often work similarly).

@0 And the server can revoke credential-issuing privileges by changing the secret or just not accepting tokens signed with a particular secret.

@mellium

Thanks. Reading #XML diffs on a tiny screen while falling asleep is probably not conducive to clarity of understanding. I'll see about having a proper look at yours and 401 in the coming days, although this is outside my current area of #XMPP expertise.

@0 Sure thing; no pressure of course, but we'd always love to get your feedback!

@mellium
Without having actually read the #XML (it's a pain to do on mobile), I can see at least a couple of red lights:

1.

> third-party trusted services that share a private key

*Share* a private key???

@mellium

2.

> I want to use a different private key than the one used by user invites so that I can see how many users from the conference registered.

I'm really not sure that #XMPP should facilitate profiling at the protocol level. In any event, this is a massive #privacy red flag and ought to be properly covered in the security section.

3.

The whole crypto part looks iffy to me. Why not leverage existing user-related crypto? In particular #XEP0374?

@mellium

4.

I didn't see how the server can revoke credential-issuing privileges from a user.

Sign in to participate in the conversation
Fosstodon

Fosstodon is an English speaking Mastodon instance that is open to anyone who is interested in technology; particularly free & open source software.