Hi, as mentioned several times in various MUCs I don't think a client side solution is actually going to improve the situation PARS attempts to solve.
So here is the outline of a proposal for a server side verification/pre authentication. * Clients subscribe to private PEP node. (See XEP-0223 on how to make a pep node private) * One client (the first client that ever wants to create a token) generates a 32 byte secret key and uploads that key into the node (base64) * New tokens are created by generating a 16 byte IV, an expiration date as unix time stamp (2 byte) (Expiration date should be choose about 24-72h into the feature depending on use case)). The 2 byte expiration date is encrypted using AES256-GCM using the 32 byte key and the 16 byte IV. The token is the concatenation of the 16 byte IV, the output of the encryption and the authentication tag in base64. * A server which is also in possession of the secret key (due to it being in the PEP node) can 'decrypt' the tokens and check if the expiration date is >= NOW() and authenticate a subscription request on the users behalf. * A server which can do that should probably announce the pars namespace on the account. * Server support is basically optional since all clients who are superscribed to the PEP node can do the verification on the client side. * Any client can at any given time upload a new 32 byte secret invalidating all old tokens * A token can be used multiple times. However I consider that desirable because I a) want to send the same link to multiple recipients b) avoid the UX problem of having the user decide if they want to create a single use token or a multi use token. cheers Daniel 2016-06-12 14:16 GMT+02:00 Georg Lukas <[email protected]>: > Hello, > > I've collected some feedback off-list, removed the 'returntoken' element > and have a git repo tracking the changes now: > > https://op-co.de/tmp/xep-pars.html > https://op-co.de/tmp/xep-pars.xml > https://github.com/ge0rg/proto-xeps/commits/master > > One feedback I received was a strong objection to this XEP because in an > ideal world it would better be implemented on the server-side. > > While I agree with the principal idea to make this a server (or rather > account) feature, my stance is as follows: > > 1. The proposed wire protocol (xmpp: URI extension and <presence> > extension) can be used in the same way irregardless of whether the > feature is terminated in a client or on the user's server. > > 2. In the real world (as opposed to our imagination as the XSF) it takes > years for all servers to roll out a new XEP, and this feature can be > rolled out as a client-only implementation overnight, with little > additional complexity and an immediate benefit to new XMPP users. > > 3. Even when implemented at the server side, this needs client support. > Romeo's client needs to query its server to obtain the token / > invitation link, before it can send it OOB. (Or alternatively, to inform > the server about a client-generated token, which is probably not really > better). > > My opinion is that making this a server feature actually has some > benefits, i.e. Romeo's server can create both the xmpp: URI and an > opaque HTTPS URI hosted on itself, only containing an invitation token. > As we can assume that the web server can access the XMPP server's > internal data structures (or communicate in some other way), Romeo's > server can translate the example URI https://montague.net/i/deadbead > into the N-tuple ([email protected], 'deadbeef', 'Romeo Montague', > 2016-06-26), thus presenting a landing page with the full information, > while preventing easy manipulation of the URI parameters. > > I would propose putting the interaction between Romeo's client and his > server into an additional XEP. This would include a mechanism for the > client to query for new invitation links (possibly also to remove > earlier ones), and a notion where the server is responsible for > auto-approving subscription requests that contain a valid token (as seen > from the server perspective). > > > Kind regards, > > 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 ||_________________________________________________|| > > _______________________________________________ > Standards mailing list > Info: http://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > >
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
