2017-05-10 21:02 GMT+02:00 Sam Whited <[email protected]>: > On Wed, May 10, 2017 at 1:41 PM, Daniel Gultsch <[email protected]> wrote: > 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. >
Oh yes the normal revocation after being used would be handled by the server. But I was thinking of a 'this token got leaked by accident and now the user wants to invalidate it' kind of scenario. > 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. > Just to be clear; When I say client-only I only mean this as a fallback. The default and preferred method would be to have this handled by the server. And I can imagine a prosody module for this would have like 10 lines of code and see pretty fast adoption. > 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. > This probably speaks to a broader point of who we are making extensions for and who is our target audience and is a very theoretical question that goes way beyond discussing this particular extension. IMHO the hypothetical service operators who maintain their own service which are self-branded are very welcome to step forward now and try to get their use case covered but keeping them in mind without knowing who they are is a waste of time. If we can agree (we don't necessarily have to) that my approach is simpler and easier to implement and covers *our* use case I don't see why would should add complexity for users who don't even bother to read the mailing list. cheers Daniel
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
