Fair warning, I'm not fully up to date on this discussion, but I was asked to drop some notes from the room earlier into the thread so here I am, this message from Daniel appears to be a good place to start.
On Thu, Apr 27, 2017 at 10:56 AM, Daniel Gultsch <[email protected]> wrote: > 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. I agree. > 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) This all still requires a lot of business logic on the client, and means that the client must understand the token format which restricts us to a single type of token. I think this could maybe be further simplified by moving almost all the business logic to the server and letting the clients effectively act as a dumb layer into data managed by the server. The flow I envision (which may be similar to what was in PARS originally?) is as follows: 1. Client 1 asks its server for a PARS token 2. The server returns an opaque token to Client 1 3. Client 1 shares the token with Client 2 out of band (QR code, NFC, email, website, etc.) 4. Client 2 sends the token to their server 5. Their server decodes the token and extracts the address of client 1's server (at least part of the token must be in a standard format and carry this information) 6. Client 2's server sends a presence subscription request to Client 1's server which authorizes or denies the request based on the validity of the token This flow allows the token format to be opaque to both clients, and partially opaque to the server (they do need to be able to find the other server, but after that the token can contain any other information, eg. an hmac which the server can verify it signed, or a nonce which the server looks up in the database). This is vaguely similar to one of the OAuth2 flow or to JWT where you can have a number of arbitrary claims (but only one or two of them are known in advance and required and tokens may be signed or looked up in a database depending on the policy of the service issuing the tokens). —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
