On Wed, May 10, 2017 at 1:41 PM, Daniel Gultsch <dan...@gultsch.de> wrote: > 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.
That's fair; to me anything more than a simple query to ask for a token and insert it into some sort of payload feels like more than what a client should be doing, but I'm ont stuck on that point. > 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.) That's fair, I was thinking this would be entirely up to the server, but it would also need to advertise that it supported revocation, and clients would need some sort of "revoke this token" IQ as well. It does mean that we have to define more wire format. > 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. PEP requires storage on the server too (not necessarily permanent of course, but depending on the implementation this could share a data store with PEP too; again, that woudl all be up to 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. I like this a lot. > 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.) I suppose this is where I'm torn; I'm not completely against making this a client-only protocol, but in general I think things like this should be handled as much by the server as possible. > 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. The other downside, and what I'm most concerned about, is that this limits the spec to being used in the scope of servers that operate on the individual-account model where you have a personal account which you add friends on. Service operators who maintain their own services which are self-branded (I'm not sure what to call that) but interoperate with the XMPP network may want to impose restrictions on how people can add eachother to their roster, eg. tokens might be issued only for specific users without hitting the database to do lookups (HMAC), or only for n-uses (hit the database have a counter), etc. Supporting multiple token policies seems more desirable to me than making this a client-only protocol personally. —Sam _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
