This is a relevant proposal for some stuff I'm working on, so ^5 for writing this.
It looks like there's a clear path for mapping these permissions to and from OAuth scopes, which I'm glad to see since that's how permissions would be managed for the systems I've worked on. *puts council hat on* - It doesn't look like there is a defined way to edit or remove permissions once granted (at least for the client case). There is text saying that should be possible, using XEP-0050, which is good. However, a well-defined node where that permissions editing command lives should be provided (similar to how MAM provides the command node "urn:xmpp:mam#configure"). - There is an interesting case here: Could something request permission for the 'urn:xmpp:privilege:0' namespace? That feels like a bad thing to allow. There is text suggesting that namespaces should be filterable or whitelisted, but this case warrants an explicit mention. - What is the intention behind Business Rule #2? If I'm logged in with two clients which support this XEP, one of which also supports XEP-0050 and the other not, and I happen to accept the permission request with the one that does not support XEP-0050, what is supposed to happen? Lance
signature.asc
Description: Message signed with OpenPGP using GPGMail
