Hi Sam, thank you for you feedback.
2017-05-09 22:46 GMT+02:00 Sam Whited <s...@samwhited.com>: > > * 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. The business logic consists of a definition on how to convert a timestamp into a sequence of bytes and hmacing that with a secret key from a PEP node. That's it. (And converting that to base64.) Different people might have different definitions on 'a lot' but too me that's not a lot. > 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 > What you are describing is what I would call the logic re-imagination or the logic transformation of current PARS into a server side PARS. I was carrying around similar ideas for a while. What's missing in your proposal is by the way a way to invalidate a token. (Which in my approach would be handled by pushing a new secret into the PEP node.) However what you are describing is a fairly complex client-server protocol (at least two commands for retrieving and invalidating the keys) that also requires permanent storage on the server. My proposal based on PEP and a commonly defined 'algorithm' for creating and validating the tokens is a deliberately dumbed-down alternative that uses an existing server side storage and an existing c2s protocol (PEP) for invalidating previous tokens. With the added benefit (but not the main reason I came up with that) that it can still act as a client-only XEP. (Which seems to be important to Georg as he doesn't believe (beside the compliance tester saying otherwise :-) ) that servers will implement that in time.) The only downsides I see - but are willing to accept - that this will limit us to multi-use tokens that only expire after a set amount of time and not a set amount of usages. And that the creation validation schema has to be - as Sam points out - carefully defined. However I think this can be made a lot less error prone by including an example in the XEP that shows the algorithm with all it's steps. (Take timestamp X -> convert it into bytes (show the bytes) -> use this key (show the key) hmac that (show the output) -> base64 that (again show that in the example) This way implementors can verify their own implementation. cheers Daniel
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
